From nobody Sat Aug 1 20:45:45 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD41A3A0B9D for ; Sat, 1 Aug 2020 20:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 AQ2Ew8yseBZG for ; Sat, 1 Aug 2020 20:45:38 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2114.outbound.protection.outlook.com [40.107.93.114]) (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 AA03F3A0B9C for ; Sat, 1 Aug 2020 20:45:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l1dX3hWwV1G3mc5jiZRdlZnKMVqkObsJ9GISJSh+u8yzpWWw0O6eoKV+qBSgodvxdxzM9dkY5l0CD5tjKlGdsz2W5iJ37GQLMRbEJkDr5g4dOpWREi5eotyzLslZiE9cYigJ1MYsEOQgTOZRvx7FrniHbajPqn0/IijLnzGQ/EDDjeAeVyspJs6nmEcTrnmGyspRVyWmmfhplNNzyapgDushWPhYQ2a3F1uNXuJ7Z6Lch1U+Rf92UQZ07Io7da/OrcHKW2CIV7aWdECIG7Ri38gAaKIC6pYVdsdWUQ+gg4stavw1DgsL3sTmT+7fAfjCsRimM0RPdT0mFZ3Z20S58g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AjLOiDkQg+CfofAT73828upwIiBoNoNAyszHJVnl7A8=; b=oL6D6hLymgw1wwYzXJXksf7lI1TW5S2dQ22sOnVkckxvZv+lT0mEdDv3GIpVyv7W8iJZoI+RpwzfTXaG3LS45s/evCQPbC5U+z55cZoW5V3pkVT328SBomIi15apXGw2iE8s1lKm1eaqz0i4tdt4QZO3uCm3ZKG8QuvR0baRGGh/PL/NKB9QefzOXhxHmF3uw+nM8drKKzLwNVToy1wbE78SLlMZwbnoTgeLdwf5gty/4p3Xw86RJR5W2FyIraqrHC1LqAS6ihy0TuoSoKc410Eni5RXbfQdDD9ls14SdSb7M5qp5srS8UzSO7U5C3a3RG9BHwPnpRIEZVTiLTduTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AjLOiDkQg+CfofAT73828upwIiBoNoNAyszHJVnl7A8=; b=gUDBwswyFkvTV3gTmuZ57EOODWL4g0Pvvp8rgAE6p8ew/btUOSAY46aUdxLuI3nkM725t9fTLJcgQUMkvC/FRQxsEtPPOJBMNX632wG5ec2mW5MtwX2cXFN0t4K8Wvvy5kOEtmU632O3VJ7Q3dzmxD3tFaxCCqHunHnVxJNzQFw= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB3992.namprd13.prod.outlook.com (2603:10b6:208:26c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Sun, 2 Aug 2020 03:45:33 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3261.013; Sun, 2 Aug 2020 03:45:33 +0000 From: Huaimo Chen To: Bruno Decraene CC: "spring@ietf.org" Thread-Topic: draft-hu-spring-segment-routing-proxy-forwarding-10 Thread-Index: AQHWaH7G6cgJgixKvkCyZxnoixrS5g== Date: Sun, 2 Aug 2020 03:45:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.114.233.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8b6c68d-aeb1-44a7-df35-08d836968276 x-ms-traffictypediagnostic: MN2PR13MB3992: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8jDYwZyBt3TClpb9uKEEvGj+RM0MCnhl6Gw0jF7yM0PS2t/p8phisndHg3s8Re0foABKnN6hEboIGEuZx6/TLB0fNPT1IfV4nYt5b5HPtAqyLvhkJWxrMXDIR7diat5a7DAXzRFplHJOZBY++KvEdV3FJi0Fb+632/ZPGMOBQZdKEo6GO7Jp6/bHIYPPlMwPPRoYULoSYOeVzq+9GKl5qguE4s4pHiPpY3GN26vP8ZvAQJCttL3zpnwOOa1x7PHPnpLHZ+1oh/2ocr+Cu28FULn577Uv4oIA6JGEGbNMyl9BqiMvMhhJP+VTJykix6gd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39830400003)(376002)(396003)(366004)(136003)(44832011)(6506007)(66446008)(64756008)(558084003)(71200400001)(66476007)(66946007)(66556008)(55016002)(478600001)(4326008)(9686003)(19627405001)(52536014)(7696005)(8936002)(6916009)(86362001)(8676002)(316002)(33656002)(2906002)(186003)(26005)(76116006)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: wtmF2g4pnAHljqLb1k+owSzSDWJG9XOIbloV0PpxV153cQAZUeLTMCWIht7XS8mmd2tdN/LMes6i8s4ElagwuSvIxnoGzFUzFwFPmS7J2xULMPsWV+caTYsC9G0YFzJdcsdkFL+UgADx89/zSvTVSADN4b+EOfFCc4BaHL8lWPLrV7l1EQ7wMNjb+nnxiQicdEKMFA1MZp984LatZ4RPO36EVo0sdtxxCUrNRTOyJZ5W5wyqbCFRU6+g2ny5Q3kkR+HnMJejHSKnGhKf1E6WXsLsMF8p1NY6buWqASS/429VjhjHRa3fOpu3UolYcmj9sGAiHFIBeORE2FYINNY5+FjLP+KK5rv+IXD8zIzfdTr5Iq5vXcV91rIrwrD4pe93ibEY/OiLy7yLi7CaZU3qtTU8eMIRc1taQyHaQJRhrZs/CjIgAVkZTHlt7JFJSjmdgxyUyt9y7Nqmi8+Se+JwIfu6aDeN9Koc4alBM2BDwE/X6HHiBjunfvjmQ1tFTXvkYL5msUw5HfghAp5jjbilp15X/2+dlkhqG4jzRPVFvYKFWitSg7FPEIgdukxOHevR3zAo8z79nXyamDZWXST1FbjeHMVB+1z4meNi2cX6oaD08mmmPArhzJH++xnRtgiem1fkGp798AeaLWDRPBGhNQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB31176119A2609320CAAE2D32F24C0MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8b6c68d-aeb1-44a7-df35-08d836968276 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2020 03:45:33.2769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: L8GWggtkRIJsr48A9oyyaB7dWYLZvxa9EtDT2Hc/+gZY/g7hOUW5D2AXTKoDE6L37z3TCljLSH/CuvfYt5PMvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3992 Archived-At: Subject: [spring] draft-hu-spring-segment-routing-proxy-forwarding-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 03:45:44 -0000 --_000_MN2PR13MB31176119A2609320CAAE2D32F24C0MN2PR13MB3117namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thank you very much for your valuable comments in IETF 104. [Bruno] Clarify in the draft -- nhop will not disappear. IP prefix may be u= sed by BGP. [H] =85 [Bruno] Follow up on the list. We have clarified it in the draft uploaded. Best Regards, Huaimo --_000_MN2PR13MB31176119A2609320CAAE2D32F24C0MN2PR13MB3117namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Bruno,

    Thank you very much for your valuable comments in IETF 104.

[Bruno] Clarify in the draft -- = nhop will not disappear. IP prefix may be used by BGP.

[H] =85=

[Bruno] Follow up on the list.


    We have clarified it in the draft uploaded.

Best Regards,
Huaimo
--_000_MN2PR13MB31176119A2609320CAAE2D32F24C0MN2PR13MB3117namp_-- From nobody Sat Aug 1 21:11:31 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034673A0BD1 for ; Sat, 1 Aug 2020 21:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 JNh_0AgdLbFQ for ; Sat, 1 Aug 2020 21:11:28 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680100.outbound.protection.outlook.com [40.107.68.100]) (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 8F50A3A0BD2 for ; Sat, 1 Aug 2020 21:11:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mr9qutpbgWydb1Ml4GU3KYTxH7NuYl/QjxNcL0Lbe1C8fkPzn+/LE+ZvQGRxw23lnXYrRhKE4dCaDAP1jhs2vPBnXpImNgPkQiYcuOOYywfnSKMZE3BHpOkC5NBZL6TM2f1TL9LIkCJhxCd0iFdYBJ6u1GaFcF8vU6Kosd9WidTvA1G0hSKr95C+N85x4DksS0A9lsFV+D7NALs5SLakis+vwv65gRUpyOKCkqaEBcAB5L9c3KF0kuYAqHOrIDxj9tUekyBWOvM+LWiBrdR0SEBj3HaD3jMg6WS/zlQabdKkyqbVnnzGnEYguYS7BOiEODBLoHWzZnPZ2Brxb0zkqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YTvUT4AYh3BnwvD7TfDCnchMmujcMG5oygwTx+dRVRA=; b=KooyW1ln27AqwuKTJ3Fy5ofI2DMtv+ln+l+IhmpRl5SUE9qT9XRIYCRfj3n1NYbH/qPp4VUELWOEVgMrB+zPiocwyL8XUl6nGX+jjCs5ukfjcCK1u9AQnuaTUyOKql79l+m8Ds2v0RFJfNnF++WpP1sgJ9Stn9ih7yhfXf4ZdLmU16f3139QlfmZfcmfjhSEqM8eNpjKNQTMIyEosibOmcpCAZCjg5okZj8daFmeLU5Uy+T5fTyn7Y0Fd84+Gu/qs2TPqIssWQ5SkOfF0B/ZkG8ai+20vw99vWrWfUewCyBQOuMPrd1usBRF5+i5ts8pGuiqiVzj7gxUN+NUn60MhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YTvUT4AYh3BnwvD7TfDCnchMmujcMG5oygwTx+dRVRA=; b=GHyBdrThqU8kJrvHwvYEtswe2PwvZe+1JflP7Er/bHo4z3vqqXyq+dq4yQ0dhi5EMTFz6jUxd15aqAi0oR56syzVQOeO213IjSE/tRJv38/MBfJ+ybilkmGObvi6ggZ19SYVI12te2Td4GVrpgpKuChUvxPGgNxNfRg3H6XxwmA= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB4039.namprd13.prod.outlook.com (2603:10b6:208:269::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.13; Sun, 2 Aug 2020 04:11:26 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::bd0d:e70d:94e5:81e7%7]) with mapi id 15.20.3261.013; Sun, 2 Aug 2020 04:11:26 +0000 From: Huaimo Chen To: Peter Psenak CC: "spring@ietf.org" , Bruno Decraene Thread-Topic: draft-hu-spring-segment-routing-proxy-forwarding-10 Thread-Index: AQHWaH7G6cgJgixKvkCyZxnoixrS5qkkLe5L Date: Sun, 2 Aug 2020 04:11:25 +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: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.114.233.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ee61fdb9-9be3-4b3c-2c90-08d8369a1ff4 x-ms-traffictypediagnostic: MN2PR13MB4039: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ale8nCjvce9ZyDP4iuo5q4yQSjBt9tnQe7TlcS8yP3K4emfG7G7TIfxZDVFkHODW+TLU4N4R+xdOcE20zYi6l3NlRPVr2++nTV+4oHPeWRuq+fd7vEizmmxsOUVo7MP2Axg80vU/VorJaAsFc5Fe0Y5jTBEl61PjPFS1AWyKIo/GahH71fMzU5B1uFGmiJnXA0+BWD4MbwdBMr5yhvmdRR+B2W0zZQZjGYyWGB2sRchx3MyHxnWgvrtLI/iU/FVlqQ84Mh64ewDz3u2zwLUPF3ypgntRKeWVnQsqjtUyUP/W6++FZY/+gXhcopzVj3Oz7KGd5q7keKBOmkpvaQLNsQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39830400003)(376002)(396003)(346002)(366004)(136003)(478600001)(8676002)(86362001)(52536014)(6916009)(5660300002)(2906002)(54906003)(316002)(8936002)(4326008)(66476007)(71200400001)(44832011)(26005)(7696005)(33656002)(2940100002)(76116006)(83380400001)(9686003)(19627405001)(55016002)(53546011)(66556008)(66446008)(66946007)(6506007)(186003)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xkOpQR9kAdEWpGoOU6toLAOfnlnUezhUNZer+qrD6g7wPH1uRfmvNwf9gsSB5Upna/xWtmvs4EDdKRFx0+/19+Fzw2zO/tULxgaN4vhPo/ZIjTCY1n5jmrVgHKaYLCSfm6yKkD7KrEaAbaEQ6V0HzWyhoJccJDBamVRibqMptQqDKS5nWGVq9Tuas9C3VggNpCNMg1uKhVnke3chCbO0jolNSAlAPBhFFMz3HZbyj1wq7FymqGvWfyVTyOnUcSXif9kDoLzF2LhfGomH4W7I9TbfVy1n2F361B/vUeUPmaCyKO+RM7KOQJQ6XwBRAL6knkm9BiWyQTcYgkiP0JPZuM02jLe8/RYI/IqsvaG6jeambhqG0biUWSvdQVj70XY7TiXr+5FEtqy6rimiMbayvhBPmVsCKI2aSX+ONNiM0l2dwkoWEoyJjpmTmWoZ4hWy5nR1ZuUiAneT68k2sKtBhsuZsdWpo77YVgrQOHLx+niMDzNT02CeSCA+5uUCDBVYv0S2ujKWaTNufRu4z8+RQ01OTYPJ6OjYOCy4VTC3YZFmltxj43Pd5013I6+8K3blFhi/4j0XhrsO6d250VkUQpMPv/jSvg0D/UFWJUqm00FxRwv/YB9Q4v7XE7MOig3rf9lG27y3vo+/p/2BeaKb3g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB31171EE249DB93781268AE9CF24C0MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee61fdb9-9be3-4b3c-2c90-08d8369a1ff4 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2020 04:11:25.9875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wWwUuqHSFPIGjFw5O2S9BuEYiVdcGy2A2q86R2Dg3yWpfWgw/xcGAtOWhNnBi6oee/Dsc/FCt74Xpa42tdkM8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB4039 Archived-At: Subject: Re: [spring] draft-hu-spring-segment-routing-proxy-forwarding-10 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 04:11:30 -0000 --_000_MN2PR13MB31171EE249DB93781268AE9CF24C0MN2PR13MB3117namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Peter, Thank you very much for your valuable comment in IETF 104. [peter psenak] no problem with node protection -- but I don=92t consider th= at pretending a SID that has gone is a good idea. There can be second failu= res. If you need this kind of protection then we should precompute disjoint= path. You are right. A backup disjoint path should be pre-computed. For pro= tecting a node, the proxy forwarding pre-computes a backup disjoint path as= suming that the node is down. This seems similar to other local protections= such as TILFA and LFA. Best Regards, Huaimo on behalf of co-authors ________________________________ From: spring on behalf of Huaimo Chen Sent: Saturday, August 1, 2020 11:45 PM To: Bruno Decraene Cc: spring@ietf.org Subject: [spring] draft-hu-spring-segment-routing-proxy-forwarding-10 Hi Bruno, Thank you very much for your valuable comments in IETF 104. [Bruno] Clarify in the draft -- nhop will not disappear. IP prefix may be u= sed by BGP. [H] =85 [Bruno] Follow up on the list. We have clarified it in the draft uploaded. Best Regards, Huaimo --_000_MN2PR13MB31171EE249DB93781268AE9CF24C0MN2PR13MB3117namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Peter,

    Thank you very much for your valuable comment in IETF 104.

[peter psenak]= no problem with node protection -- but I don=92t consider that pretending a SID that has gone is a good idea. There can be = second failures. If you need this kind of protection then we should precomp= ute disjoint path.

    You are right. A backup disjoint path should be pre-computed.=    For protecting a node, the proxy forwarding pre-computes a bac= kup disjoint path assuming that the node is down. This seems similar to oth= er local protections such as TILFA and LFA.

Best Regards,
Huaimo on behalf of co-authors
From: spring <spring-bou= nces@ietf.org> on behalf of Huaimo Chen <huaimo.chen@futurewei.com>= ;
Sent: Saturday, August 1, 2020 11:45 PM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: spring@ietf.org <spring@ietf.org>
Subject: [spring] draft-hu-spring-segment-routing-proxy-forwarding-1= 0
 
Hi Bruno,

    Thank you very much for your valuable comments in IETF 104.

[Bruno] Clarify in the draft -- n= hop will not disappear. IP prefix may be used by BGP.

[H] =85<= /p>

[Bruno] Follow up on the list.


    We have clarified it in the draft uploaded.

Best Regards,
Huaimo
--_000_MN2PR13MB31171EE249DB93781268AE9CF24C0MN2PR13MB3117namp_-- From nobody Sun Aug 2 16:50:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DA33A0DD2 for ; Sun, 2 Aug 2020 16:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=joelhalpern.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 fiG0myA2NHMo for ; Sun, 2 Aug 2020 16:50:41 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 449C03A0DD1 for ; Sun, 2 Aug 2020 16:50:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BKd7P0HWxz6G8tX for ; Sun, 2 Aug 2020 16:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596412241; bh=eFDJ5unKbgAX06l13/EqmpklRd46aWJ3XzwrwBrQPhw=; h=To:From:Subject:Date:From; b=phDhCc19EhVNmBZODmSsulx3SLNQqNqkrfpaSvOmy20OlKxuMYaZWetw1iOdT1eDH O21E9h+191N89V8DRcVgngvn6k4UipF20Bn17vg2tWRfY9XWkpQ36n3AcJkdzlGBhA pFhZU+uGMDSU1k7FgSbnEMtCtsaGB6Y9cyd3akKs= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BKd7N4Ldxz6G7Lk for ; Sun, 2 Aug 2020 16:50:40 -0700 (PDT) To: "spring@ietf.org" From: "Joel M. Halpern" Message-ID: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> Date: Sun, 2 Aug 2020 19:50:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 23:50:42 -0000 (WG Chair hat Off, this is merely a note from a slightly confused WG participant.) I have been reading the various repair drafts, and the various networks programming and service programming draft, and I am trying to figure out one aspect of the combination. How does a node that is doing some form of bypass (suppose, for simplicity, it is Node N2 deciding to bypass the next SID for a failed node N3) know that it is safe to do so? If the path was just for TE, then it is "safe" if the new path meets the TE criteria. or maybe it is safe if it is even close, as long as it is not used for too long. But what if the node were a Firewall, included to meet legal requirements? Or was some other necessary programmatic transform (wince we are deliberately vague about what nodes can do when asked suitably.) Is there some "can be bypassed" indication in the routing advertisements that I missed? Thank you, Yours, Joel From nobody Sun Aug 2 16:56:35 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591D13A0DDD; Sun, 2 Aug 2020 16:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 U1w3n006X0ok; Sun, 2 Aug 2020 16:56:32 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 E19F03A0DDC; Sun, 2 Aug 2020 16:56:31 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id i19so19532327lfj.8; Sun, 02 Aug 2020 16:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gwgwK3Aa7mK+y7VidIhNSHgx+qEt+kaYnSpI9hlF5hE=; b=FywlSW8tXMrURaw0VubM5/SZggN+tmDmjnqTP1bmAMxX3Zq7x2iU8FKKCeBp6K+MYv cyZouyu/5GDlecetMFc8K6Npjl7dPYenqvmNmpWBb67mybdSxJACJtkxSWIvFr+aJdhI NfZS3kDSXljKpX86+RoRlYrdimFXpm3EfDCouAdh6ZuTK3zJSDgGwFRQdfvuZB6xjB8f xWxWqHXKNi29ou7AuXFwsUbAflGpBkvxmG3kAZwF0gDihYb2ZnIzK7EbeFRAgOmUhzav kWDP5VvBXnuedOXwWZ2+eUtNvPCXFXMQIBiX8/9XcMKQBLoXc23Tc/F4Cxd4dqE4Cotb Zc7g== 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=gwgwK3Aa7mK+y7VidIhNSHgx+qEt+kaYnSpI9hlF5hE=; b=aIx921NiPmoeUAe/B5kySWfG+5Wim1PgmRN0DRZIhemPqCGDO+2x+eRIwsNJnh66XD pJw73qloIEmVZ7VDGUKURtdjiHyKheht3hbjauhm32OSlMOIz3hAriJvU9yVsORL9ZLi p5H7Fyr1mqdoFXtF5krBmntmHaybpJhWfAmrCchb4gbQO8itwCjg6vKhdl4m88lZw+PP s46RIpzCg7nhS2lkfSOFUhHsZcvJ0RGRYaCMtMhrGvEg0a/MgMlSjbvCyx1Xt3QjWwE9 FGGzWfL21UN1ohxNwPNFqWjZBFlPlE1UYxkX1VJgFUNAYRzCskR9+D38LIpTBdkgoZHZ lzLQ== X-Gm-Message-State: AOAM532h/sKkn9oBWTmPOi20f635n66AEteyx9PUd2McjkVlhZSYd6oA Cc4mMLxdEwoTTFjE0ekLjZzmkqZGk8GiC2rZe8bO/g== X-Google-Smtp-Source: ABdhPJxE5Gef6C/oFPMgRtvPeysav44OGD7HEOgQZvBYNeZTujuOyCzSNBtt3Nky2tOPH3ajAVEdYZ1sPVz4RuDJPac= X-Received: by 2002:a19:be53:: with SMTP id o80mr7089166lff.33.1596412589727; Sun, 02 Aug 2020 16:56:29 -0700 (PDT) MIME-Version: 1.0 From: Greg Mirsky Date: Sun, 2 Aug 2020 16:56:18 -0700 Message-ID: To: spring , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000005362d405abedc535" Archived-At: Subject: [spring] Where a trigger for the protection switchover in SR-MPLS will come from? X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 23:56:33 -0000 --0000000000005362d405abedc535 Content-Type: text/plain; charset="UTF-8" Dear All, after reviewing draft-hegde-spring-node-protection-for-sr-te-paths I've got a question to ask Where a trigger for the protection switchover in SR-MPLS will come from? The draft discusses methods to provide local link and node protection. Obviously, the protection is triggered by the detection of the failure. The document refers to Section 5.2 RFC 8679 in which relationships between the defect detection mechanism used and the scope of protection (link or node) are discussed. RFC 8679 is MPLS-centric and, though not explicitly referenced, BFD over MPLS LSP (RFC 5884) can be used as the defect detection mechanism. To the best of my knowledge, SPRING WG doesn't have a WG document describing defect detection mechanism in an SR-MPLS network. Hence my question in the subject line. Of course, not having a solution does not affect the value of draft-hegde-spring-node-protection-for-sr-te-paths but it probably would stand out as the more comprehensive solution if the specification of the defect detection in SR-MPLS was produced by the SPRING WG soon after. Regards, Greg --0000000000005362d405abedc535 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
after reviewing=C2=A0draft-hegde-spring-node= -protection-for-sr-te-paths I've got a question to ask=C2=A0Where a tri= gger for the protection switchover in SR-MPLS will come from?
The= draft discusses methods to provide local link and node protection. Obvious= ly, the protection is triggered by the detection of the failure. The docume= nt refers to Section 5.2 RFC 8679 in which relationships between the defect= detection mechanism used and the scope of protection (link or node) are di= scussed. RFC 8679 is MPLS-centric and, though not explicitly referenced, BF= D over MPLS LSP (RFC 5884) can be used as the defect detection mechanism. T= o the best of my knowledge, SPRING WG doesn't have a WG document descri= bing defect detection mechanism in an SR-MPLS network. Hence my question in= the subject line. Of course, not having a solution does not affect the val= ue of=C2=A0draft-hegde-spring-node-protection-for-sr-te-paths but it probab= ly would stand out as the more comprehensive solution if the specification= =C2=A0of the defect detection in SR-MPLS was produced by the SPRING WG soon= after.

Regards,
Greg
--0000000000005362d405abedc535-- From nobody Sun Aug 2 20:30:26 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBEF3A058F for ; Sun, 2 Aug 2020 20:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoFzi-8eNkQw for ; Sun, 2 Aug 2020 20:30: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 9A2AB3A053E for ; Sun, 2 Aug 2020 20:30:22 -0700 (PDT) Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 24ADEF6F1852ACBB7CBC for ; Mon, 3 Aug 2020 04:30:20 +0100 (IST) Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 04:30:19 +0100 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 3 Aug 2020 04:30:19 +0100 Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.246]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Mon, 3 Aug 2020 11:30:15 +0800 From: Mach Chen To: "Joel M. Halpern" , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfMKyLC4PEJ3U24t3+Dp7H1BakluDxQ Date: Mon, 3 Aug 2020 03:30:14 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> In-Reply-To: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 03:30:24 -0000 Hi Joel, I think this is a good point that may not be discussed in the past. And I a= lso don't think there is a "can be bypassed" indication in the routing adve= rtisement for now. IMHO, the information advertised by routing is neutral, such information (c= an or cannot be bypassed) is more path specific, thus normally the controll= er should be responsible for deciding whether/which SID can be bypassed.=20 Best regards, Mach > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. Halper= n > Sent: Monday, August 3, 2020 7:51 AM > To: spring@ietf.org > Subject: [spring] Spring protection - determining applicability >=20 > (WG Chair hat Off, this is merely a note from a slightly confused WG > participant.) >=20 > I have been reading the various repair drafts, and the various networks > programming and service programming draft, and I am trying to figure out > one aspect of the combination. >=20 > How does a node that is doing some form of bypass (suppose, for simplicit= y, > it is Node N2 deciding to bypass the next SID for a failed node N3) know = that > it is safe to do so? >=20 > If the path was just for TE, then it is "safe" if the new path meets the = TE > criteria. or maybe it is safe if it is even close, as long as it is not = used for too > long. >=20 > But what if the node were a Firewall, included to meet legal requirements= ? > Or was some other necessary programmatic transform (wince we are > deliberately vague about what nodes can do when asked suitably.) >=20 > Is there some "can be bypassed" indication in the routing advertisements > that I missed? >=20 > Thank you, > Yours, > Joel >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Sun Aug 2 21:42:26 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C29403A0A2E; Sun, 2 Aug 2020 21:42:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <159642972574.13001.12516770436692231190@ietfa.amsl.com> Date: Sun, 02 Aug 2020 21:42:05 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-19.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 04:42:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-19.txt Pages : 33 Date : 2020-08-02 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-19 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-19 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 Aug 2 23:36:42 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C993A0768 for ; Sun, 2 Aug 2020 23:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 oN4Jrger-Qi1 for ; Sun, 2 Aug 2020 23:36:39 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C243A064A for ; Sun, 2 Aug 2020 23:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1596436598; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aeM5/VjCifB6C24kBxjp328kEbjOeaCeWnYfLk+D/A0=; b=qhAlAGlt5fuiDMirJytXiE5q39/BgwQVW77paKEZ/jWworT1GzxvppRFyt0bjR3YNIfsWs CU8JvzhJCkvOoaVyjGT1P7kMCyhgzkfb5Usvkl5WGWIixe1ORs9yb59UilFldT7cZCifo3 DtgWHcFznUKuV9a3H2rfmzRdZn9b+7w= Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-306-4n8Pjjb-OMO1vffwwiWXGQ-3; Mon, 03 Aug 2020 02:36:36 -0400 X-MC-Unique: 4n8Pjjb-OMO1vffwwiWXGQ-3 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (104.47.0.52) by AZWPVEXEdge02.ecitele.com (10.0.2.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Mon, 3 Aug 2020 09:36:35 +0300 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR03MB5602.eurprd03.prod.outlook.com (2603:10a6:208:171::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Mon, 3 Aug 2020 06:36:33 +0000 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1]) by AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1%6]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 06:36:33 +0000 From: Alexander Vainshtein To: Mach Chen , "Joel M. Halpern" CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JA= Date: Mon, 3 Aug 2020 06:36:33 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.183.63.9] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 766261f1-556f-49a7-b262-08d837779084 x-ms-traffictypediagnostic: AM0PR03MB5602: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W39iklkAgnOnS+bjDBvvGE7OA4U5PQ8eRkT3EG6Q6m943i6+rsUBFlQk2xa+3qfc8aZuErfDwIK7kzYHKPQcAbUjtOcWuwCu2R27hDKcuhUAZCDUWiAlmEUx35T9qjHjbgOXLx8R/h95g0Ptx1GfdLK/qC01ygjCj7F4XXwiHWT3NZw5nxcQh7P0qjftwI3W3lhe6Y3BGSxy4PloaHiHXleRzoO8O9nzvgA3Nct1mMqYklkN5UgkD0yMiUIVrR/5mN/qUs/57Hz9rB2f4hPfrt0rVos6wMYA2USraJWzC4bXZN2Yo3ZPCCyoQuxCtU4ZX0Kh2HAT3Hwo1FCVd4/f863RMcyOMtA2RgUsUXUx77X7i0JOXMnI2rgm/PbkHfiZyR8g/cbDkkE2ymh3mmwteg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4499.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(7696005)(6506007)(53546011)(8676002)(83380400001)(64756008)(66476007)(66446008)(66556008)(66946007)(33656002)(76116006)(71200400001)(186003)(26005)(166002)(966005)(52536014)(478600001)(316002)(5660300002)(55016002)(86362001)(110136005)(8936002)(4326008)(9686003)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: VUxyq6qhe6loZzHFF+fW8DHuGaF12fyR/35+oDnJV40QXbH9PSdI3tPnzqxUNIqLU3O92gTKo+W3xdScSiAFAk892DZ2PYN0Ow083uyc5wCahNhf1s9hJXVCjznFJJ4ZUfQthuuqTw2Dg8wkiGFjd2dYi5QF8W25aaEjnXDh9CuRQbQZfnZwmjl+uAv6flQBzqh43BQMBPedIZgyKolKEgj5PV6ZRfCtz6LPcOsGBaV/8QtaFpz+4sGD6a8O7Et58dOiwnTWpykpzZZzv8TOp9K2H2X6RxWmW4R5nHdFoJ6lgBmXYv18cCdz5Y88hg8jESiljYxFlwxSe/Adpzy12AAA+AQ4BaP0YQb8i6gfk+ZPSeNHHhgNjJKjgj1WoNub0nHSk86diOwMo8b62yDMOZ0b0sOqoX9YBJifo1U6imHNfl+YyOAGYh0bDwTkgjPBpThe2AAfEAki80TyOmp2OFCLoDAHr7MzMRnEL1LWv12GCcUTizse91B9RJvlURZmNF+8khzHGPa5wUuluGEaAaLzTVnE76t0R22n3pep5BUW0dUntDQs+FrB2j2VbfN9hztnLkVicbOOrzsQL6eB0c0FdSBPrjAr/gegn39EnlFLTKh4RL8i0N5uEUCRgEI6z7A6KhSDgvA5sElZCdiFMQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4499.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 766261f1-556f-49a7-b262-08d837779084 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 06:36:33.7566 (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-CrossTenant-userprincipalname: L7YzuarP2fzUddBF/BOWL7NXudszgPl9t0q/WIU9jtURI2v2QeQZofbOGp+ewkOWLM6L5PjUoeClyDhyfdvpzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5602 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0AM0PR03MB4499eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 06:36:42 -0000 --_000_AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0AM0PR03MB4499eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mach, Joel and all, I think that in most cases: 1. There is clear differentiation between "topological" and "service"= instructions in SID advertisements. E.g.: o IGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the correspond= ing IGP advertisements) represent topological instructions o Service SIDs for SRv6 (see SRv6 BGP-Based Overlay Services draft) unsurpri= singly represent "service" instructions 2. Segments that represent topological instructions can be bypassed, = while segments that represent service instructions require alternative prot= ection mechanisms. This view seems to be aligned with RFC 8402 that says in Section 1: In the context of an IGP-based distributed control plane, two topological segments are defined: the IGP-Adjacency segment and the IGP-Prefix segment. In the context of a BGP-based distributed control plane, two topological segments are defined: the BGP peering segment and the BGP-Prefix segment. In the case of SR-MPLS this differentiation is assumed in Section 3.4 of th= e Node Protection for SR-TE Path draft that s= ays: The node protection mechanism described in the previous sections depends on the assumption that the label immediately below the top label in the label stack is understood in the IGP domain. When the provider edge routers exchange service labels via BGP or some other non-IGP mechanism the bottom label is not understood in the IGP domain. The egress node protection mechanisms described in the draft [RFC8679] is applicable t= o this use case and no additional changes will be required for SR based networks The scenarios in which differentiation between "topological" and "service"= instructions is broken are indeed problematic. E.g., consider the use case= in which a Node SID in the ERO of a SR-TE path identifies a node that acts= as a firewall for all packets it receives, i.e., provides the firewall ser= vice without any dedicated service SID identifying it. One could say that t= he Node SID of such a node would combine topological and service instructio= ns thus breaking the differentiation between the two. I am not sure if usage of such "combined" SIDs could be prevented or at lea= st discouraged. If not, providing an ability to identify such SIDs in the advertisement mec= hanisms would be useful IMHO. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: spring On Behalf Of Mach Chen Sent: Monday, August 3, 2020 6:30 AM To: Joel M. Halpern ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi Joel, I think this is a good point that may not be discussed in the past. And I a= lso don't think there is a "can be bypassed" indication in the routing adve= rtisement for now. IMHO, the information advertised by routing is neutral, such information (c= an or cannot be bypassed) is more path specific, thus normally the controll= er should be responsible for deciding whether/which SID can be bypassed. Best regards, Mach > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. > Halpern > Sent: Monday, August 3, 2020 7:51 AM > To: spring@ietf.org > Subject: [spring] Spring protection - determining applicability > > (WG Chair hat Off, this is merely a note from a slightly confused WG > participant.) > > I have been reading the various repair drafts, and the various > networks programming and service programming draft, and I am trying to > figure out one aspect of the combination. > > How does a node that is doing some form of bypass (suppose, for > simplicity, it is Node N2 deciding to bypass the next SID for a failed > node N3) know that it is safe to do so? > > If the path was just for TE, then it is "safe" if the new path meets > the TE criteria. or maybe it is safe if it is even close, as long as > it is not used for too long. > > But what if the node were a Firewall, included to meet legal requirements= ? > Or was some other necessary programmatic transform (wince we are > deliberately vague about what nodes can do when asked suitably.) > > Is there some "can be bypassed" indication in the routing > advertisements that I missed? > > Thank you, > Yours, > Joel > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2<= https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252> > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ---------------------------------------------------------------------------= -------------------------------------------- Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipie= nt. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly= prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies,= including any attachments. ---------------------------------------------------------------------------= -------------------------------------------- --_000_AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0AM0PR03MB4499eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Mach, Joel and all,

 

I think that in most cases:

1.       There is clear differentia= tion between "topological" and "service" instructions i= n SID advertisements. E.g.:

o   IGP Prefix Node SID= s IGP Adj-SIDs (identified as such in the corresponding IGP advertisements)= represent topological instructions

o   Service SIDs for SR= v6 (see SRv6 BGP-Based Overlay Services draft) unsurprisingly represent “= service” instructions  

2.       Segments that represent to= pological instructions can be bypassed, while segments that represent servi= ce instructions require alternative protection mechanisms.

 

This view seems to be aligned with RFC 8402 that says in Section 1:

 

   In the context of an IGP-base=
d distributed control plane, two
   topological segments are defined: the IGP-=
Adjacency segment and the
   IGP-Prefix segment.
 
   In the context of a BGP-based=
 distributed control plane, two
   topological segments are defined: the BGP =
peering segment and the
   BGP-Prefix segment.

 

In the case of SR-MPLS this differentiation is as= sumed in Section 3.4 of the Node Protection for SR-TE Path draft that says:=

 

   The node protection mechanism described=
 in the previous sections
   depends on the assumption that the label immediately below =
the top
   label in the label stack is understood in the IGP domain.  When the
   provider edge routers exchange service =
labels via BGP or some other
   non-IGP mechanism the bottom label is n=
ot understood in the IGP
   domain.
 
   The egress node protection mechanisms d=
escribed in the draft
   [RFC8679] is ap=
plicable to this use case and no additional changes
   will be required for SR based networks<=
o:p>

 

The scenarios in which  differentiation betw= een “topological” and “service” instructions is bro= ken are indeed problematic. E.g., consider the use case in which a Node SID= in the ERO of a SR-TE path identifies a node that acts as a firewall for all packets it receives, i.e., provides the firewall service without a= ny dedicated service SID identifying it. One could say that the Node SID of= such a node would combine topological and service instructions thus breaki= ng the differentiation between the two.

 

I am not sure if usage of such “combined= 221; SIDs could be prevented or at least discouraged.

If not, providing an ability to identify such SID= s in the advertisement mechanisms would be useful IMHO.

 

My 2c,

Sasha

 

Office: +972-39266302

Cell:      +972-54926630= 2

Email:   Alexander.Vainshtein@ecitele.c= om

 

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Mach Chen
Sent: Monday, August 3, 2020 6:30 AM
To: Joel M. Halpern <jmh@joelhalpern.com>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability

 

Hi Joel,

 

I think this is a good point that may not be disc= ussed in the past. And I also don't think there is a "can be bypassed&= quot; indication in the routing advertisement for now.

 

IMHO, the information advertised by routing is ne= utral, such information (can or cannot be bypassed) is more path specific, = thus normally the controller should be responsible for deciding whether/whi= ch SID can be bypassed.

 

Best regards,

Mach

 

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

> From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of Joel M.

> Halpern

> Sent: Monday, August 3, 2020 7:51 AM

> To: spring@ietf.org=

> Subject: [spring] Spring protection - determ= ining applicability

>

> (WG Chair hat Off, this is merely a note fro= m a slightly confused WG

> participant.)

>

> I have been reading the various repair draft= s, and the various

> networks programming and service programming= draft, and I am trying to

> figure out one aspect of the combination.

>

> How does a node that is doing some form of b= ypass (suppose, for

> simplicity, it is Node N2 deciding to bypass= the next SID for a failed

> node N3) know that it is safe to do so?=

>

> If the path was just for TE, then it is &quo= t;safe" if the new path meets

> the TE criteria.  or maybe it is safe i= f it is even close, as long as

> it is not used for too long.

>

> But what if the node were a Firewall, includ= ed to meet legal requirements?

> Or was some other necessary programmatic tra= nsform (wince we are

> deliberately vague about what nodes can do w= hen asked suitably.)

>

> Is there some "can be bypassed" in= dication in the routing

> advertisements that I missed?

>

> Thank you,

> Yours,

> Joel

>

> ____________________________________________= ___

> spring mailing list

> spring@ietf.org

> https://clicktime.sym= antec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2

> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspri= ng

 

_______________________________________________

spring mailing list

spring@ietf.org

https://clickt= ime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%= 2Fmailman%2Flistinfo%2Fspring



Notice: Th= is e-mail together with any attachments may contain information of Ribbon C= ommunications Inc. that is confidential and/or proprietary for the sole use= of the intended recipient. Any review, disclosure, reliance or distributi= on by others or forwarding without express permission is strictly prohibite= d. If you are not the intended recipient, please notify the sender immedia= tely and then delete all copies, including any attachments.
 --_000_AM0PR03MB4499A048326D9A2E8DA5F46B9D4D0AM0PR03MB4499eurp_-- From nobody Mon Aug 3 02:14:25 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0C3A0CFA for ; Mon, 3 Aug 2020 02:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkG1-N9Meld0 for ; Mon, 3 Aug 2020 02:14: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 5532C3A0CF9 for ; Mon, 3 Aug 2020 02:14:22 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 248B1FB22F7D75A63275 for ; Mon, 3 Aug 2020 10:14:18 +0100 (IST) Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 3 Aug 2020 10:14:17 +0100 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Mon, 3 Aug 2020 10:14:17 +0100 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.133]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0487.000; Mon, 3 Aug 2020 17:14:08 +0800 From: "Chengli (Cheng Li)" To: Mach Chen , "Joel M. Halpern" , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfMxHlh+yzcCkewTBiyswjXMaklNGAAgACNQuA= Date: Mon, 3 Aug 2020 09:14:07 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 09:14:24 -0000 Hi Joel and Mach, Yes, we should consider to bypass or not bypass the node in different cases= . Like Joel said, we can not skip the firewall, while it can be fine to skip = a TE node, if the repair path meets the TE SLA requirements. Regarding these two cases, AFAIK, two documents describes the related mecha= nisms * Bypass: https://tools.ietf.org/html/draft-chen-bess-srv6-service-bypass-= sid-00 * No bypass: https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lf= a/ Hope it help the discussion, and comments are welcome!=20 Respect, Cheng -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Mach Chen Sent: Monday, August 3, 2020 11:30 AM To: Joel M. Halpern ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi Joel, I think this is a good point that may not be discussed in the past. And I a= lso don't think there is a "can be bypassed" indication in the routing adve= rtisement for now. IMHO, the information advertised by routing is neutral, such information (c= an or cannot be bypassed) is more path specific, thus normally the controll= er should be responsible for deciding whether/which SID can be bypassed.=20 Best regards, Mach > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M.=20 > Halpern > Sent: Monday, August 3, 2020 7:51 AM > To: spring@ietf.org > Subject: [spring] Spring protection - determining applicability >=20 > (WG Chair hat Off, this is merely a note from a slightly confused WG > participant.) >=20 > I have been reading the various repair drafts, and the various=20 > networks programming and service programming draft, and I am trying to=20 > figure out one aspect of the combination. >=20 > How does a node that is doing some form of bypass (suppose, for=20 > simplicity, it is Node N2 deciding to bypass the next SID for a failed=20 > node N3) know that it is safe to do so? >=20 > If the path was just for TE, then it is "safe" if the new path meets=20 > the TE criteria. or maybe it is safe if it is even close, as long as=20 > it is not used for too long. >=20 > But what if the node were a Firewall, included to meet legal requirements= ? > Or was some other necessary programmatic transform (wince we are=20 > deliberately vague about what nodes can do when asked suitably.) >=20 > Is there some "can be bypassed" indication in the routing=20 > advertisements that I missed? >=20 > Thank you, > Yours, > Joel >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Mon Aug 3 04:45:33 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E27C3A0E96; Mon, 3 Aug 2020 04:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Btvgeuta; dkim=pass (1024-bit key) header.d=juniper.net header.b=G03Aajf0 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 NkEYGZJHy13o; Mon, 3 Aug 2020 04:45:28 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C8E103A0E8E; Mon, 3 Aug 2020 04:45:28 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 073BbMLD030682; Mon, 3 Aug 2020 04:45:27 -0700 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 : mime-version; s=PPS1017; bh=6V+YA+/vFkPdDKo9lPmF7tpP1Ht6bPpy59gVyKkGt+I=; b=Btvgeuta/T74ZsGBoX6vzvh56ppYTeIvw6SFbpP83OuJMGkN+BT4MZEVW9w/KhWjJfa/ Vxw0hBsdFbYeAXQ1NngA0zktamM4pnnjUkzuX8v7RHttDPJRA1oAr+D+FIJGnGorvrCr M5nJqjGME9QCYOCdIwpxtaoAYfxoFyzYIx4yacJL8vQ3LMIEzUTlZ1AtHGI4JSWag0oE sP0/tqM0aNBgBJH6la12xrUIkFEd7zJWWak/A8nUOXgfVtlwEtfOzCu/jnU2zxhp7aDS EglTnK7ymGhH32hld27cnqXj2yJf1fT+yWITItmEWAKVQbsBqHJtM5jhdzVXdrmWOgvG bA== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2046.outbound.protection.outlook.com [104.47.66.46]) by mx0b-00273201.pphosted.com with ESMTP id 32n6w5a8jd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 04:45:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=keHJ6UEtpCfTJQ4Kg3UG+k44FEuyQ39SVQ3PjidND02p2Osvc0ezfkp2OoD2iNI+8rmpnR1wYh9/9ehzfTGl+e7qPcwj6bfHm0Mb5F41h1w0V5RroVJjElsaLR7d6hsjMNm3WeAbV2o+3HAjRNkiz6TIzzoNsFvPUNZ6cFXmc7ujek1dwodW+q2htFZhJ7MJV63Ob2MvbdpN2PxYXkPck8imfd+bGH7LXdcmekjxXZ4ipXgR0t/zAFEGkjU35NceKQpC73vAAzA1wWCRTvNnz+mL6pc2beO3lLtmXL9c8/GPmwXCjhDlz99vkzUN2YvgUuljP3Vsb9x+67r/t2fKGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6V+YA+/vFkPdDKo9lPmF7tpP1Ht6bPpy59gVyKkGt+I=; b=em5b+Oc673NyD/acUxTV1y+AnRhlzxV8cngViSEQcdtKmBneWLOif+p4+ywfs3SCyV7z7Lc4y5WF5ePn3Qw6rvy+xjG4/Q4n9JdK6FUezkgh4lVR7909wW3BGHHeQbE7U+XFOunIJL7DG5kz2OTXW8iwBgTge84hnpL07V4OGWPaXYo2qa9Iv1BbECbxwA7gkPvMDjrnf4SOZGKXe201DMVew0HEiHlwX9NzHbDBcLVtnP8PBa2mY+TfTl642bjoLUP6BRQbzxxSCvxnBNl92yMn41tfbYVJaS/McbCTkmgvs+J4R4ROfVyTg6hS5YaF7HVJ1lqWc4P23RHh2Jry6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6V+YA+/vFkPdDKo9lPmF7tpP1Ht6bPpy59gVyKkGt+I=; b=G03Aajf0RCn9njhSYMe6k6L40KuNCLOzv2HWDgk4dOR3IfPmetCkW9kwTIPxvkmDmLwVFQsjwcL2g3FVD9XtoUhkTpYmRYrH/d9TAIqWN85nQnCDpJbmdnmJynqKSxKKzFcuqLA6VYxwlF85WBOFRJjs0YfmU3ZecAVclFgNk1o= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3511.namprd05.prod.outlook.com (2603:10b6:910:50::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Mon, 3 Aug 2020 11:45:24 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3261.014; Mon, 3 Aug 2020 11:45:24 +0000 From: Shraddha Hegde To: Greg Mirsky , spring , "spring-chairs@ietf.org" Thread-Topic: [spring] Where a trigger for the protection switchover in SR-MPLS will come from? Thread-Index: AQHWaSiUG4kZqchX3EmOSh9NLrrz/akmQ2nQ Date: Mon, 3 Aug 2020 11:45:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-03T11:45:22Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=8135b8ec-aa30-4de7-8e1c-667c93f22f84; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [122.171.69.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b674be65-09df-4975-ef04-08d837a2b5c6 x-ms-traffictypediagnostic: CY4PR05MB3511: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ydbVSKJ6v8sh9oXQN+MkI7m+qjKDY62L0b8WX4sRNEWar+UtKynvwHRFbOTg1S0ywMbtTNxIVCg0qROLofvunv4qGz2Rd6n5NHuflrcYKCWGzemawgAWxrWqC7LBooMSQul8CTONIAaYLe0DBXwAVhDjV2Mk6VHmo0P03OjPi5y8aXBlUAKV92kFXxvrvvjGKj2t1i7q3q+jf3U8/H8+thufa7RU1NPZb5b2G8T+ZBuQ+jMIOyGQXzrMVmjAEzoRqBubRV5oyHSRRVUXWs2pC865AaLiboKiutWFJEwbCNaprFk4ng1m4ySw+B0qmvVt0ZtDi3AlpJoXirXas8CYZnOnCBGqVzKDcVMZ9adMQHm2mlkeThVjd79EO6/Rgg8sWiiPaEGX53gmMcz7kFSjcA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(136003)(396003)(366004)(166002)(5660300002)(186003)(33656002)(316002)(9686003)(110136005)(52536014)(83380400001)(2906002)(966005)(86362001)(478600001)(26005)(66476007)(7696005)(64756008)(66556008)(55016002)(9326002)(66946007)(76116006)(8936002)(6506007)(8676002)(53546011)(66446008)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 9jp+b2qgbrYrV3RX81XiQAtlytZoOc0zkbrp3600Xz0z3zU/DcuvfsibEWQqzHZVBs137U+e6Z7jBn7SKYp0t+hJjdSqy15teoV7OT8wHP42k+9qERiOZ2HDtgDtm3n0LILfnRHIRCPLxW/36tMZnQPRaVCETMoCSoYNorMxt2j8E4Y9FHIxMmHJTc9n/MUaVthsNBx61UtzVlQb7cSLTaE1S9AtdUNSQPYKGNV3gh/PgX7hl6M8nv+iVYDb6OIgoIBDIG/KKDvF4jmCQcGX5ICGz9IfNmGbruKcixy8nRz/zFGB7CmqUDdqmpaB1ERJAgxiylMn8w0FTTje69xTg97IRL6DBD29Lb8Mea2YlrtNdV2/YbEe0dlqnSWddFVxJGSl49igmfc4YT3kql1R6YWWKLVqNu1BYFhaTk/A9i0ZS3J8+YcZ7Tjuv5iNaHm2e8wPwcdwHKtuxlcx+k9a5r+iMNz3CyaF38U6vb8NLnbMs+A6Y6HYy2fOh1ctdjfQ/6lapWpui9ENDUq3pNB6aRSj2ffzhu+l0DkG9EOh+K2oV/ffapRDFHS0j7ULa/+y4wmFpcMN1oFityr7Wm1uUGjBdS6QKESPQDE5ZcdnvVspymFujLpmNalx9ZIUbBcybgFULmVUpvUGb/rP/+djzg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR05MB357697EF2293C2486C09A693D54D0CY4PR05MB3576namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b674be65-09df-4975-ef04-08d837a2b5c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 11:45:24.6078 (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-CrossTenant-userprincipalname: K6T/I+bjjsIMPnrtOgFQTWzamech3S/fm/Pbb71zIF92Qu1idtL8CnzSoQDxwYnh08Gol03KFfYNUdRipqqM6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3511 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-03_09:2020-08-03, 2020-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 phishscore=0 clxscore=1011 suspectscore=0 spamscore=0 malwarescore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030087 Archived-At: Subject: Re: [spring] Where a trigger for the protection switchover in SR-MPLS will come from? X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 11:45:30 -0000 --_000_CY4PR05MB357697EF2293C2486C09A693D54D0CY4PR05MB3576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, There is an individual document in SPRING WG that describes BFD for SR-MPLS= LSP https://datatracker.ietf.org/doc/draft-ali-spring-bfd-sr-policy/?include_te= xt=3D1 The draft-hegde-spring-node-protection-for-sr-te-paths is focused on local= repair triggered on the PLR . Headend triggered path protection is out of scope for draft-hegde-spr= ing-node-protection-for-sr-te-paths. Rgds Shraddha Juniper Business Use Only From: spring On Behalf Of Greg Mirsky Sent: Monday, August 3, 2020 5:26 AM To: spring ; spring-chairs@ietf.org Subject: [spring] Where a trigger for the protection switchover in SR-MPLS = will come from? [External Email. Be cautious of content] Dear All, after reviewing draft-hegde-spring-node-protection-for-sr-te-paths I've got= a question to ask Where a trigger for the protection switchover in SR-MPLS= will come from? The draft discusses methods to provide local link and node protection. Obvi= ously, the protection is triggered by the detection of the failure. The doc= ument refers to Section 5.2 RFC 8679 in which relationships between the def= ect detection mechanism used and the scope of protection (link or node) are= discussed. RFC 8679 is MPLS-centric and, though not explicitly referenced,= BFD over MPLS LSP (RFC 5884) can be used as the defect detection mechanism= . To the best of my knowledge, SPRING WG doesn't have a WG document describ= ing defect detection mechanism in an SR-MPLS network. Hence my question in = the subject line. Of course, not having a solution does not affect the valu= e of draft-hegde-spring-node-protection-for-sr-te-paths but it probably wou= ld stand out as the more comprehensive solution if the specification of the= defect detection in SR-MPLS was produced by the SPRING WG soon after. Regards, Greg --_000_CY4PR05MB357697EF2293C2486C09A693D54D0CY4PR05MB3576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

There is an individual document in SPRING WG that de= scribes BFD for SR-MPLS LSP

https://datatracker.ietf.org/doc/= draft-ali-spring-bfd-sr-policy/?include_text=3D1

 

The  draft-hegde-spring-node-protection-for-sr-= te-paths is focused on local repair triggered on the

PLR . Headend triggered path protection is out of sc= ope for draft-hegde-spring-node-protection-for-sr-te-paths.

 

Rgds

Shraddha

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of Greg Mirsky
Sent: Monday, August 3, 2020 5:26 AM
To: spring <spring@ietf.org>; spring-chairs@ietf.org
Subject: [spring] Where a trigger for the protection switchover in S= R-MPLS will come from?

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Dear All,

after reviewing draft-hegde-spring-node-protect= ion-for-sr-te-paths I've got a question to ask Where a trigger for the= protection switchover in SR-MPLS will come from?

The draft discusses methods to provide local link an= d node protection. Obviously, the protection is triggered by the detection = of the failure. The document refers to Section 5.2 RFC 8679 in which relati= onships between the defect detection mechanism used and the scope of protection (link or node) are discussed. R= FC 8679 is MPLS-centric and, though not explicitly referenced, BFD over MPL= S LSP (RFC 5884) can be used as the defect detection mechanism. To the best= of my knowledge, SPRING WG doesn't have a WG document describing defect detection mechanism in an SR-MPLS net= work. Hence my question in the subject line. Of course, not having a soluti= on does not affect the value of draft-hegde-spring-node-protection-for= -sr-te-paths but it probably would stand out as the more comprehensive solution if the specification of the de= fect detection in SR-MPLS was produced by the SPRING WG soon after.

 

Regards,

Greg

--_000_CY4PR05MB357697EF2293C2486C09A693D54D0CY4PR05MB3576namp_-- From nobody Mon Aug 3 07:21:10 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C403A0AC5; Mon, 3 Aug 2020 07:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=fnnNJkBj; dkim=pass (1024-bit key) header.d=juniper.net header.b=JY9/Y479 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 kGsSCF3srfqr; Mon, 3 Aug 2020 07:21:06 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 3A6E13A0ACB; Mon, 3 Aug 2020 07:21:06 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 073ED7RU025813; Mon, 3 Aug 2020 07:21:05 -0700 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 : mime-version; s=PPS1017; bh=o3oNMIZLBrUMybhDHPo+WKOZST1WSUldhngn8P04Ohk=; b=fnnNJkBjPYVJUyhIm4e/XlkDSslKqU4ESO1HEehox5Oi+b52JMk13M6PxevA+aRIbFBv GetF31gZLq9Rr2joZGAU6d0FCjnZLb03dQpTeAUtSjw2d+JivOLWjHrGiqly/Z5WNlY+ kbJhlJGu4i3tQWCwtrU1R4Tw7pOj0vM848D8kQGaX8GpUEFTyoB4uhuLV6ry8THFkJlk wHHf9sTdDrPnNcsowpFhhn2wvVpwRq/cv1z3ZUgWJFOkNN4LIMO9N4DA2kaHuHyuvPlP gc6XUe90j/Fi1JTmOzpWeYq6bDCWkThHkmttaZXa7Q3pQXs7Nk5+77Rmw75mYgHyCufg 4w== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by mx0b-00273201.pphosted.com with ESMTP id 32n6vs2g29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 07:21:05 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E1Bc3b0o6dMsnHxWYjUSXLWkwbtRFqSJt+6jm7XHDPwIhNNGEOR68DWvUdiP9ZkjxwLw2EnGfEpdvgfMubGY9oc5xbmRgf3OM1YyohQzHzrh/sGQ8bXZb3x3K2yO8ujy31+jQCZCWQJwO4u4FFkt+jzcA3WhCxQAzbtZChUD5tmjH0sA+KecrdCtQblulD0FSl7gVVZJbw0/9YzMhF9F0nLXmq0TxCZQBEEs82WOLE55uGoE+fEo/x+35G3rLPS72lmNbjMIC2Mp6o7osXTYXwzW5iJyGlwsJxd2e1/BUTiTER0EB0pSY1VBFZKzt+Ot4Az09Z5kbd/3YsqBbDjQGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o3oNMIZLBrUMybhDHPo+WKOZST1WSUldhngn8P04Ohk=; b=grPfpqSV5FS+TkyyA6VhYswusZMvqWCx8N7TeUr5jfkdVu97MFzoTtccQx2mLXdNUwa3HJyjR9P/YrdJctera0RgBGlH1+n7KL3yV1FOyFPTpYiwpDuskA7/HGt+Vk3pzYWyWlL9cbkoAJC+I1V6jpZxK8TTDVyHDkbbWiiC6NAdpOolv15SUVbVwdENkIS9u6l7fItJ4r14QTmlGAiEXGXj0dk1CDUqNehBNG11NPmv4TSZI7zpgAm3OGOCKdIOaCri4qjmZOdcm74PsQlRv4QNaT+9yUpbk4PR5rFdwQ3PRNwTc1UmgbyOD9WCH+oCz3/sujM/f71k3Y/Ld5gAww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o3oNMIZLBrUMybhDHPo+WKOZST1WSUldhngn8P04Ohk=; b=JY9/Y479Y1Y9YaF6kmXsRsN8NEI1IJC5kbKwr4H5BnBX48OCysWfcTBSSLkTKR+Plxadj6GosQifafkcM5cdOv1wx+GdT+CELbyNTf2Md8ohLmlqOuoqWVgzWXFskKb9WxrAEcUcY+K0t5VaYVbnAS/ZLjgXGGmwjOez3ndiXl0= Received: from BYAPR05MB6567.namprd05.prod.outlook.com (2603:10b6:a03:ec::11) by BYAPR05MB5351.namprd05.prod.outlook.com (2603:10b6:a03:7e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.14; Mon, 3 Aug 2020 14:21:02 +0000 Received: from BYAPR05MB6567.namprd05.prod.outlook.com ([fe80::940b:bf9f:2c38:8987]) by BYAPR05MB6567.namprd05.prod.outlook.com ([fe80::940b:bf9f:2c38:8987%7]) with mapi id 15.20.3261.014; Mon, 3 Aug 2020 14:21:02 +0000 From: Yimin Shen To: "bruno.decraene@orange.com" , "spring@ietf.org" CC: "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Thread-Topic: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths Thread-Index: AdZmaxBja895PvK+QsirQTKFBBYlewDFLggA Date: Mon, 3 Aug 2020 14:21:02 +0000 Message-ID: <23F5A4BD-67C0-4E08-B521-9BFF5AA6FB29@juniper.net> References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=cd3a67c9-e593-497e-bd82-00001a2fe435; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-03T14:19:52Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 848f9196-df29-4952-d842-08d837b8737a x-ms-traffictypediagnostic: BYAPR05MB5351: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4imJ/jY0g+Ug7a60PmVLKZrkIO7zEgxVyq8dU4HKO/ThXYG5aaZ0nIB69DXW4u1t+bLSmaR9gIHcmQwwqKzkobpEAhxEMok3FnJ7Pt/EotYr5u0++D/Z7hJ77cayiK/z3dfO/ekUKGGUgigytdARnPejKrZShFJ3Bn7TXzd1DgZwB6Za3qBpmvggpECDEesRhR8lJC1yq3YDEfmYoWCwac7YzE8jxApamXFcY4iYUVRHHkYr9cBjABXyOUjF0QfjBLCkyko2zX3N78sHFIdQfVkqeIduoSeVoPZApYCnteNiTgUZu2YTSrWbO3GnID1g+mPCgMONZI7pJUUDMK+r/Sn402DcxwrcHEOTK7wYOx4cw7R8Gjx78LQ5NendXPSK/7bDHY6KK94qN37wWZHlmg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB6567.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(136003)(346002)(376002)(2906002)(71200400001)(36756003)(6512007)(86362001)(6486002)(478600001)(83380400001)(166002)(66446008)(64756008)(66556008)(66476007)(66946007)(8676002)(5660300002)(316002)(110136005)(76116006)(33656002)(53546011)(6506007)(91956017)(4326008)(966005)(26005)(2616005)(186003)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 7YCzMuHxjNRIksvIaYWcdWt/k9rYL2qJEQ6DadTtoKi1FjWBDTJP3nrPahHSLgd/nzwqYIlAHiSpJ9rmEe58SyX4q4QFyPiAGr8nHrSWrRRyIK82xH6MYyDiwMHZ2F31QlYYSaqK/DQxxg1MPSqXPjfAyekaLwb4u1RZxFB57D4NOy1vak7M0BFYGj+7SoTgwKbmqiWA2IwMZh0+2Un0PFVZxmiG9FSonE4CjzF5VCwmTDRWbonEvGQoiK38/ZJnKJFcuPx4DpC2oLkK0warjrPhuTOKhjw5hThDJWOghYoKpKZ0z2z5EeYG0QvfnleKVjn+X+hGlBSysQsj05lMm+V8F+AJ3a3MlwpPpEIxy5HtqtNzmsCwwuQA/hHUGM7AO0aRgj4CmGwaHhATjYPI3j0m+lhQ+8AooJ2A+He6PQzpy/QEIZiQK+gBIEAA/gIBM6Jvnj62+UmJBiKtwvRwu8qSMAAeXXY3hZq85qwM6aiVquEo2jVPUc49ROmQdz+oBENrdFUytG2b4KiwihTdA6liv5e653vXKIo7/DFAMYKqwSVySlR4P+3RI4v3uk0LnIbhWI7fSSo3J6UDjFT/4malu1NePhOhRwLNwoSGJzkynxjkCctMBTV6DSv8jUA2WTcMOC0ZGbFdikLu10jfEQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_23F5A4BD67C04E08B5219BFF5AA6FB29junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB6567.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 848f9196-df29-4952-d842-08d837b8737a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 14:21:02.3106 (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-CrossTenant-userprincipalname: 3L6k3FqREsLpJD1SS1LhEkeDJ5l7jS7VTGc8hwQx660it4Ek2oO6mrXi+O+TUv9eFpTRXsbXNUEeuxzK97x9Cg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5351 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-03_13:2020-08-03, 2020-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 bulkscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030107 Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 14:21:08 -0000 --_000_23F5A4BD67C04E08B5219BFF5AA6FB29junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgV0cgYWRvcHRpb24gZm9yIHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rcywNCi0t IFlpbWluIFNoZW4NCg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgImJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iIDxicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tPg0KRGF0ZTogVGh1cnNkYXksIEp1bHkgMzAsIDIwMjAgYXQgODoyNCBBTQ0KVG86 ICJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWhlZ2RlLXNw cmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzQGlldGYub3JnIiA8ZHJhZnQtaGVn ZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbc3ByaW5nXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1oZWdkZS1zcHJpbmctbm9k ZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocw0KDQpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRp b3VzIG9mIGNvbnRlbnRdDQoNCkhpIFNQUklORyBXRywNCg0KQXV0aG9ycyBvZiBkcmFmdC1oZWdk ZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocyAgWzFdIGhhdmUgYXNrZWQg Zm9yIFdHIGFkb3B0aW9uLg0KDQpQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0LCBjb21tZW50 cywgb3Igb2JqZWN0aW9uLCBmb3IgYWRvcHRpbmcgdGhpcyBkcmFmdCBhcyBhIHdvcmtpbmcgZ3Jv dXAgaXRlbSBieSBBdWd1c3QgMjB0aCAyMDIwLiAoKikNCg0KQ291bGQgdGhvc2Ugd2hvIGFyZSB3 aWxsaW5nIHRvIHdvcmsgb24gdGhpcyBkb2N1bWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgbGlzdC4g VGhhdCBnaXZlcyB1cyBhbiBpbmRpY2F0aW9uIG9mIHRoZSBlbmVyZ3kgbGV2ZWwgaW4gdGhlIHdv cmtpbmcgZ3JvdXAgdG8gd29yayBvbiB0aGlzLg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KQnJ1bm8s IEppbSwgSm9lbA0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlZ2Rl LXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3PGh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZWdkZS1zcHJp bmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wN19fOyEhTkV0NnlNYU8tZ2shVng2 bU5wMlVROXNoUklQV3dKN3g1X293NThTOU9iemMzR09ucDFrZUEzY0hEU2lURy1KbVlEUXl3MEln LWxjJD4NCigqKSAzIHdlZWtzIHRvIGFjY291bnQgZm9yIHRoZSBJRVRGIG1lZXRpbmcgd2VlayBh bmQgdGhlIGF1Z3VzdC9zdW1tZXIgcGVyaW9kLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0K DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9u bHkNCg== --_000_23F5A4BD67C04E08B5219BFF5AA6FB29junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3DF1BBB8BA7A564984FDE4645A0E64C2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkxhdG87DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cHBvcnQg dGhlIFdHIGFkb3B0aW9uIGZvciB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0m bmJzcDtZaW1pbiBTaGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+c3By aW5nICZsdDtzcHJpbmctYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O2Jy dW5vLmRlY3JhZW5lQG9yYW5nZS5jb20mcXVvdDsgJmx0O2JydW5vLmRlY3JhZW5lQG9yYW5nZS5j b20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBKdWx5IDMwLCAyMDIwIGF0IDg6MjQg QU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5n QGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7ZHJhZnQtaGVnZGUtc3ByaW5nLW5v ZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHNAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWhl Z2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5bc3ByaW5nXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1o ZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRoczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTIuMHB0O2JhY2tncm91bmQ6I0ZGRUI5QyI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TGF0byZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5bRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdPG86cD48L286cD48L3Nw YW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSBTUFJJTkcg V0csPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5BdXRob3JzIG9mIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2Rl LXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzJm5ic3A7IFsxXSBoYXZlIGFza2VkIGZvciBXRyBh ZG9wdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQs IGNvbW1lbnRzLCBvciBvYmplY3Rpb24sIGZvciBhZG9wdGluZyB0aGlzIGRyYWZ0IGFzIGEgd29y a2luZyBncm91cCBpdGVtIGJ5IEF1Z3VzdCAyMHRoIDIwMjAuICgqKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+Q291bGQgdGhvc2Ugd2hvIGFyZSB3aWxsaW5nIHRvIHdvcmsgb24gdGhpcyBkb2N1bWVudCwg cGxlYXNlIG5vdGlmeSB0aGUgbGlzdC4gVGhhdCBnaXZlcyB1cyBhbiBpbmRpY2F0aW9uIG9mIHRo ZSBlbmVyZ3kgbGV2ZWwgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gd29yayBvbiB0aGlzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5CcnVubywgSmltLCBK b2VsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlsxXSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3It dGUtcGF0aHMtMDdfXzshIU5FdDZ5TWFPLWdrIVZ4Nm1OcDJVUTlzaFJJUFd3Sjd4NV9vdzU4UzlP YnpjM0dPbnAxa2VBM2NIRFNpVEctSm1ZRFF5dzBJZy1sYyQiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBh dGhzLTA3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPigqKSAzIHdlZWtzIHRvIGFjY291bnQgZm9yIHRoZSBJRVRGIG1lZXRpbmcgd2Vl ayBhbmQgdGhlIGF1Z3VzdC9zdW1tZXIgcGVyaW9kLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxw IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZTo3cHQ7Y29sb3I6IzAwMDAwMDtt YXJnaW46MTVwdDsiIGFsaWduPSJDZW50ZXIiPg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTxi cj4NCjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_23F5A4BD67C04E08B5219BFF5AA6FB29junipernet_-- From nobody Mon Aug 3 09:43:24 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29413A0EBC for ; Mon, 3 Aug 2020 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.053 X-Spam-Level: *** X-Spam-Status: No, score=3.053 tagged_above=-999 required=5 tests=[BITCOIN_SPAM_02=2.497, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MISSING_HEADERS=1.207, NICE_REPLY_A=-0.949, PDS_BTC_ID=0.498, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 oqonFrU0DjQh for ; Mon, 3 Aug 2020 09:43:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 8011D3A0E4A for ; Mon, 3 Aug 2020 09:43:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BL3br2KmHz6G9nh for ; Mon, 3 Aug 2020 09:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596473000; bh=1Gi4SX8qRJ9CEbOINs8uGSG0XrZL72On3JL2ZeZQVg4=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=fdVAbz4/RZ3u7RaCh7lvFpo4kWZyKJYAjspLum4J+uEaecEc+S4aVWd1fSFa8Rhm2 qTfhK5IUfdwAyX7OvuY9HIh/bHKnBQUFrOrmos/wb8Ma9eyoMSNdmW3KG2JdK96C8Y nc+rcHHPVFszib9bTMpoBiUareL17o7vO88D13XM= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BL3bq62gfz6G9kX for ; Mon, 3 Aug 2020 09:43:19 -0700 (PDT) Cc: "spring@ietf.org" References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <0f1c2ea9-1096-5806-3962-1cee8d525ae6@joelhalpern.com> Date: Mon, 3 Aug 2020 12:43:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 16:43:22 -0000 What I am hearing is that we all know there is an issue here, but the documents do not connect the dots? Yours, Joel On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > Mach, Joel and all, > > I think that in most cases: > > 1.There is clear differentiation between "topological" and "service" > instructions in SID advertisements. E.g.: > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > corresponding IGP advertisements) represent topological instructions > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > draft) unsurprisingly represent “service†instructions > > 2.Segments that represent topological instructions can be bypassed, > while segments that represent service instructions require alternative > protection mechanisms. > > This view seems to be aligned with RFC 8402 > that says in Section 1: > >    In the context of an IGP-based distributed control plane, two > > topological segments are defined: the IGP-Adjacency segment and the > >    IGP-Prefix segment. > >    In the context of a BGP-based distributed control plane, two > > topological segments are defined: the BGP peering segment and the > >    BGP-Prefix segment. > > In the case of SR-MPLS this differentiation is assumed in Section 3.4 of > the Node Protection for SR-TE Path > > draft that says: > >    The node protection mechanism described in the previous sections > >    depends on the assumption that the label immediately below the top > > label in the label stack is understood in the IGP domain.  When the > >    provider edge routers exchange service labels via BGP or some other > >    non-IGP mechanism the bottom label is not understood in the IGP > >    domain. > >    The egress node protection mechanisms described in the draft > >    [RFC8679 ] is > applicable to this use case and no additional changes > >    will be required for SR based networks > > The scenarios in which  differentiation between “topological†and > “service†instructions is broken are indeed problematic. E.g., consider > the use case in which a Node SID in the ERO of a SR-TE path identifies a > node that acts as a firewall for all packets it receives, i.e., provides > the firewall service without any dedicated service SID identifying it. > One could say that the Node SID of such a node would combine topological > and service instructions thus breaking the differentiation between the two. > > I am not sure if usage of such “combined†SIDs could be prevented or at > least discouraged. > > If not, providing an ability to identify such SIDs in the advertisement > mechanisms would be useful IMHO. > > My 2c, > > Sasha > > Office: +972-39266302 > > Cell:      +972-549266302 > > Email:   Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: spring On Behalf Of Mach Chen > Sent: Monday, August 3, 2020 6:30 AM > To: Joel M. Halpern ; spring@ietf.org > Subject: Re: [spring] Spring protection - determining applicability > > Hi Joel, > > I think this is a good point that may not be discussed in the past. And > I also don't think there is a "can be bypassed" indication in the > routing advertisement for now. > > IMHO, the information advertised by routing is neutral, such information > (can or cannot be bypassed) is more path specific, thus normally the > controller should be responsible for deciding whether/which SID can be > bypassed. > > Best regards, > > Mach > > > -----Original Message----- > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. > > > Halpern > > > Sent: Monday, August 3, 2020 7:51 AM > > > To: spring@ietf.org > > > Subject: [spring] Spring protection - determining applicability > > > > > > (WG Chair hat Off, this is merely a note from a slightly confused WG > > > participant.) > > > > > > I have been reading the various repair drafts, and the various > > > networks programming and service programming draft, and I am trying to > > > figure out one aspect of the combination. > > > > > > How does a node that is doing some form of bypass (suppose, for > > > simplicity, it is Node N2 deciding to bypass the next SID for a failed > > > node N3) know that it is safe to do so? > > > > > > If the path was just for TE, then it is "safe" if the new path meets > > > the TE criteria.  or maybe it is safe if it is even close, as long as > > > it is not used for too long. > > > > > > But what if the node were a Firewall, included to meet legal > requirements? > > > Or was some other necessary programmatic transform (wince we are > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > Is there some "can be bypassed" indication in the routing > > > advertisements that I missed? > > > > > > Thank you, > > > Yours, > > > Joel > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 > > > > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > ------------------------------------------------------------------------ > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ------------------------------------------------------------------------ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Aug 3 11:10:24 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AC93A104E for ; Mon, 3 Aug 2020 11:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.846 X-Spam-Level: * X-Spam-Status: No, score=1.846 tagged_above=-999 required=5 tests=[BITCOIN_SPAM_02=2.497, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, PDS_BTC_ID=0.498, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 CgnhmVbid90q for ; Mon, 3 Aug 2020 11:10:21 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 582F83A104B for ; Mon, 3 Aug 2020 11:10:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BL5XF1z5wz6GBFn; Mon, 3 Aug 2020 11:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596478221; bh=fxSYLTRm0tgU8SAChZrAiKxxN8lI/YIdpkqmWMWoVdc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QzJBNlf6Ff0CJ5dT3jnqsH5EKJt8SIe3dcQ2gyFX0/SzbR/vMNKdNwMIdCLY5Vod4 oYbEOKjJU6j7myN657R3zz7Ezw/zYAVQ3OLmv6bbhI2/DhUe3was+BJOldZLZ5s9Hm W/52Zb6NFci2jpuNlAst+1/LIijzlvUjXwe1u3yY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BL5XD59nqz6G9BC; Mon, 3 Aug 2020 11:10:20 -0700 (PDT) To: Alexander Vainshtein Cc: "spring@ietf.org" References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Mon, 3 Aug 2020 14:10:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 18:10:23 -0000 Well less serious for TE SIDs, I am not sure the problem is restricted to just service SIDs. Suppose that the PCE has specified the path to meet some complex te objective. The bypass node has no way of knowing what those constraints were. And for some kinds of traffic, it is better to drop the packet than to deliver it outside the envelop. I suspect that the right answer to this is "too bad". If so, as with the distinction regarding service nodes, we should say so, shouldn't we? Yours, Joel On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > Mach, Joel and all, > > I think that in most cases: > > 1.There is clear differentiation between "topological" and "service" > instructions in SID advertisements. E.g.: > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > corresponding IGP advertisements) represent topological instructions > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > draft) unsurprisingly represent “service†instructions > > 2.Segments that represent topological instructions can be bypassed, > while segments that represent service instructions require alternative > protection mechanisms. > > This view seems to be aligned with RFC 8402 > that says in Section 1: > >    In the context of an IGP-based distributed control plane, two > > topological segments are defined: the IGP-Adjacency segment and the > >    IGP-Prefix segment. > >    In the context of a BGP-based distributed control plane, two > > topological segments are defined: the BGP peering segment and the > >    BGP-Prefix segment. > > In the case of SR-MPLS this differentiation is assumed in Section 3.4 of > the Node Protection for SR-TE Path > > draft that says: > >    The node protection mechanism described in the previous sections > >    depends on the assumption that the label immediately below the top > > label in the label stack is understood in the IGP domain.  When the > >    provider edge routers exchange service labels via BGP or some other > >    non-IGP mechanism the bottom label is not understood in the IGP > >    domain. > >    The egress node protection mechanisms described in the draft > >    [RFC8679 ] is > applicable to this use case and no additional changes > >    will be required for SR based networks > > The scenarios in which  differentiation between “topological†and > “service†instructions is broken are indeed problematic. E.g., consider > the use case in which a Node SID in the ERO of a SR-TE path identifies a > node that acts as a firewall for all packets it receives, i.e., provides > the firewall service without any dedicated service SID identifying it. > One could say that the Node SID of such a node would combine topological > and service instructions thus breaking the differentiation between the two. > > I am not sure if usage of such “combined†SIDs could be prevented or at > least discouraged. > > If not, providing an ability to identify such SIDs in the advertisement > mechanisms would be useful IMHO. > > My 2c, > > Sasha > > Office: +972-39266302 > > Cell:      +972-549266302 > > Email:   Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: spring On Behalf Of Mach Chen > Sent: Monday, August 3, 2020 6:30 AM > To: Joel M. Halpern ; spring@ietf.org > Subject: Re: [spring] Spring protection - determining applicability > > Hi Joel, > > I think this is a good point that may not be discussed in the past. And > I also don't think there is a "can be bypassed" indication in the > routing advertisement for now. > > IMHO, the information advertised by routing is neutral, such information > (can or cannot be bypassed) is more path specific, thus normally the > controller should be responsible for deciding whether/which SID can be > bypassed. > > Best regards, > > Mach > > > -----Original Message----- > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. > > > Halpern > > > Sent: Monday, August 3, 2020 7:51 AM > > > To: spring@ietf.org > > > Subject: [spring] Spring protection - determining applicability > > > > > > (WG Chair hat Off, this is merely a note from a slightly confused WG > > > participant.) > > > > > > I have been reading the various repair drafts, and the various > > > networks programming and service programming draft, and I am trying to > > > figure out one aspect of the combination. > > > > > > How does a node that is doing some form of bypass (suppose, for > > > simplicity, it is Node N2 deciding to bypass the next SID for a failed > > > node N3) know that it is safe to do so? > > > > > > If the path was just for TE, then it is "safe" if the new path meets > > > the TE criteria.  or maybe it is safe if it is even close, as long as > > > it is not used for too long. > > > > > > But what if the node were a Firewall, included to meet legal > requirements? > > > Or was some other necessary programmatic transform (wince we are > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > Is there some "can be bypassed" indication in the routing > > > advertisements that I missed? > > > > > > Thank you, > > > Yours, > > > Joel > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 > > > > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > ------------------------------------------------------------------------ > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ------------------------------------------------------------------------ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Aug 3 11:30:40 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41B63A1057 for ; Mon, 3 Aug 2020 11:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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=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 LHNOh2tBfvz6 for ; Mon, 3 Aug 2020 11:30:37 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 45D553A0980 for ; Mon, 3 Aug 2020 11:30:37 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id o18so39665534eje.7 for ; Mon, 03 Aug 2020 11:30:37 -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=PMu81VNnlFjbh2DwDWP+DdG5vchyBJdc5iYwk3cR/nI=; b=VjixHb4U/MkCw/KxyF8uA23Ig3pUwwauNGMyUMFBmA1F2KmBsNpbg9oXxBdjoj3hnF AnGH5464cNNhF35l8xaCwcW7Fg/39glmoc1rPhmVf8g9wGgSVaCp+kvsTf/3UfHKzQ5M BFHjL77qRzTMjzYUf5+pbS/aZ13JIGe3WRaTkeFDZzT/HuaJasLk/BtWyYE3S9oc6GnL j/IWoqkiXyhWYPkPXcjnNV3F4xbtZmddqZ7tpyIalEJZB9HSJNRa9pB+Zm/7ZvBNjEbC wSM2toeo1vZhWTTlOEJyqiOMEHyqpODNmADWbqKryABHt0ABhfxBt5qUYqee2/n0wI1q PNjw== 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=PMu81VNnlFjbh2DwDWP+DdG5vchyBJdc5iYwk3cR/nI=; b=sGhCp7nr7F20KGCE+ct03k+4iEc/1fzMODpPuWcs2h1FEKHQJiYjG+PnZxCcjuyV4b rtxpkTW260ZsDFTCVIx3O2JOAcHl3SJfA6UDCdrVxBwKyYTwFluEw4hjvZoWb486GwtL MYtbf8pgFD5GzXIRy0figsuoasAJmrRNQB7pthPu4QfeM2uNuGqDJQq2xmm5Kix47OdS X6v99KUQGF04M1z8wjjCguEz1MK9/lsWjJpfR5JZxNTmcovj2RtYZWDz1CuyIxI44ifl woISsU69og80mx3nc0KMWYthQAigtXJV/U+I0lEy5vE97+cfrLWcUCEQO8OJVOrDn1kq LfCw== X-Gm-Message-State: AOAM533oz+veE85pPAWcv9HaiR7fPlKxVM8q1XXDoZnXVNvh3PXXSvBb FeH83RvR4Fp/JgqGsVjymiuZXysu79+Szmbhobfb/5VO X-Google-Smtp-Source: ABdhPJwurRJrWiO42YaKBlBsZyHKPnY3VLfC4y3P35a/R2+Mb7ipANFFVPZ8eNHLB5X84RqOA0f1Yzxyl/nlTk+T/mI= X-Received: by 2002:a17:906:868d:: with SMTP id g13mr17618770ejx.242.1596479435622; Mon, 03 Aug 2020 11:30:35 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Mon, 3 Aug 2020 20:30:25 +0200 Message-ID: To: "Joel M. Halpern" Cc: Alexander Vainshtein , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a6e69805abfd55a3" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 18:30:40 -0000 --000000000000a6e69805abfd55a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joel, Are we still talking about IP networks here ? Or perhaps some hard slicing with real resource reservations or detnets ? Because if we are talking about IP networking I have two observations: A) If you need to traverse via a specific node (ie. firewall) you better apply IP encapsulation to that node. I don't think IP encapsulation can be hijacked today such that destination address of the packet is ignored. B) Have you seen any IP network where upon topology change (link or node failure) you suddenly start dropping flows in spite of SPT offering perhaps few ms longer path with 10 ms more jitter ? Or are some SR marketing slides promise to turn IP networks in something new ? Worse ... do they mention path quality guarantees, resource reservations ? I hope not. Thx, R. On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern wrote: > Well less serious for TE SIDs, I am not sure the problem is restricted > to just service SIDs. > > Suppose that the PCE has specified the path to meet some complex te > objective. The bypass node has no way of knowing what those constraints > were. And for some kinds of traffic, it is better to drop the packet > than to deliver it outside the envelop. I suspect that the right answer > to this is "too bad". If so, as with the distinction regarding service > nodes, we should say so, shouldn't we? > > Yours, > Joel > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > Mach, Joel and all, > > > > I think that in most cases: > > > > 1.There is clear differentiation between "topological" and "service" > > instructions in SID advertisements. E.g.: > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > corresponding IGP advertisements) represent topological instructions > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instructions > > > > 2.Segments that represent topological instructions can be bypassed, > > while segments that represent service instructions require alternative > > protection mechanisms. > > > > This view seems to be aligned with RFC 8402 > > that says in Section 1: > > > > In the context of an IGP-based distributed control plane, two > > > > topological segments are defined: the IGP-Adjacency segment and the > > > > IGP-Prefix segment. > > > > In the context of a BGP-based distributed control plane, two > > > > topological segments are defined: the BGP peering segment and the > > > > BGP-Prefix segment. > > > > In the case of SR-MPLS this differentiation is assumed in Section 3.4 o= f > > the Node Protection for SR-TE Path > > < > https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-= for-sr-te-paths-07#section-3.4> > > > draft that says: > > > > The node protection mechanism described in the previous sections > > > > depends on the assumption that the label immediately below the top > > > > label in the label stack is understood in the IGP domain. When the > > > > provider edge routers exchange service labels via BGP or some other > > > > non-IGP mechanism the bottom label is not understood in the IGP > > > > domain. > > > > The egress node protection mechanisms described in the draft > > > > [RFC8679 ] is > > applicable to this use case and no additional changes > > > > will be required for SR based networks > > > > The scenarios in which differentiation between =E2=80=9Ctopological=E2= =80=9D and > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed problematic= . E.g., consider > > the use case in which a Node SID in the ERO of a SR-TE path identifies = a > > node that acts as a firewall for all packets it receives, i.e., provide= s > > the firewall service without any dedicated service SID identifying it. > > One could say that the Node SID of such a node would combine topologica= l > > and service instructions thus breaking the differentiation between the > two. > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs could be= prevented or at > > least discouraged. > > > > If not, providing an ability to identify such SIDs in the advertisement > > mechanisms would be useful IMHO. > > > > My 2c, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > > From: spring On Behalf Of Mach Chen > > Sent: Monday, August 3, 2020 6:30 AM > > To: Joel M. Halpern ; spring@ietf.org > > Subject: Re: [spring] Spring protection - determining applicability > > > > Hi Joel, > > > > I think this is a good point that may not be discussed in the past. And > > I also don't think there is a "can be bypassed" indication in the > > routing advertisement for now. > > > > IMHO, the information advertised by routing is neutral, such informatio= n > > (can or cannot be bypassed) is more path specific, thus normally the > > controller should be responsible for deciding whether/which SID can be > > bypassed. > > > > Best regards, > > > > Mach > > > > > -----Original Message----- > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. > > > > > Halpern > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > To: spring@ietf.org > > > > > Subject: [spring] Spring protection - determining applicability > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly confused WG > > > > > participant.) > > > > > > > > > > I have been reading the various repair drafts, and the various > > > > > networks programming and service programming draft, and I am trying = to > > > > > figure out one aspect of the combination. > > > > > > > > > > How does a node that is doing some form of bypass (suppose, for > > > > > simplicity, it is Node N2 deciding to bypass the next SID for a fail= ed > > > > > node N3) know that it is safe to do so? > > > > > > > > > > If the path was just for TE, then it is "safe" if the new path meets > > > > > the TE criteria. or maybe it is safe if it is even close, as long a= s > > > > > it is not used for too long. > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > requirements? > > > > > Or was some other necessary programmatic transform (wince we are > > > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > advertisements that I missed? > > > > > > > > > > Thank you, > > > > > Yours, > > > > > Joel > > > > > > > > > > _______________________________________________ > > > > > spring mailing list > > > > > spring@ietf.org > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%= 2 > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2> > > > > > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > -----------------------------------------------------------------------= - > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000a6e69805abfd55a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joel,

Are we still talking about IP net= works=C2=A0here ? Or perhaps some hard slicing with real resource reservati= ons or detnets ?=C2=A0

Because=C2=A0if we are talk= ing=C2=A0about IP networking I have two observations:=C2=A0

<= /div>
A) If you need to traverse via a specific node (ie. firewall) you= better apply IP encapsulation to that node. I don't think IP encapsula= tion=C2=A0can be hijacked today such that destination address of the packet= is ignored.=C2=A0

B) Have you seen any IP network= where upon topology change (link or node failure) you suddenly=C2=A0start = dropping=C2=A0flows in spite of SPT offering perhaps few ms longer path wit= h 10 ms more jitter ?=C2=A0

Or are some SR marketi= ng slides promise to turn IP networks in something=C2=A0new ? Worse ... do = they mention path quality guarantees, resource reservations=C2=A0? I hope n= ot.=C2=A0

Thx,
R.









On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halper= n <jmh@joelhalpern.com> wr= ote:
Well less s= erious for TE SIDs, I am not sure the problem is restricted
to just service SIDs.

Suppose that the PCE has specified the path to meet some complex te
objective.=C2=A0 The bypass node has no way of knowing what those constrain= ts
were.=C2=A0 And for some kinds of traffic, it is better to drop the packet =
than to deliver it outside the envelop.=C2=A0 I suspect that the right answ= er
to this is "too bad".=C2=A0 If so, as with the distinction regard= ing service
nodes, we should say so, shouldn't we?

Yours,
Joel

On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> Mach, Joel and all,
>
> I think that in most cases:
>
> 1.There is clear differentiation between "topological" and &= quot;service"
> instructions in SID advertisements. E.g.:
>
> oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
> corresponding IGP advertisements) represent topological instructions >
> oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
> <https://datatracker.i= etf.org/doc/html/draft-ietf-bess-srv6-services-04>
> draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instructions=
>
> 2.Segments that represent topological instructions can be bypassed, > while segments that represent service instructions require alternative=
> protection mechanisms.
>
> This view seems to be aligned with RFC 8402
> <https://tools.ietf.org/html/rfc8402> that says in= Section 1:
>
>=C2=A0 =C2=A0=C2=A0 In the context of an IGP-based distributed control = plane, two
>
> topological segments are defined: the IGP-Adjacency segment and the >
>=C2=A0 =C2=A0=C2=A0 IGP-Prefix segment.
>
>=C2=A0 =C2=A0=C2=A0 In the context of a BGP-based distributed control p= lane, two
>
> topological segments are defined: the BGP peering segment and the
>
>=C2=A0 =C2=A0=C2=A0 BGP-Prefix segment.
>
> In the case of SR-MPLS this differentiation is assumed in Section 3.4 = of
> the Node Protection for SR-TE Path
> <https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-p= rotection-for-sr-te-paths-07#section-3.4>
> draft that says:
>
>=C2=A0 =C2=A0=C2=A0 The node protection mechanism described in the prev= ious sections
>
>=C2=A0 =C2=A0=C2=A0 depends on the assumption that the label immediatel= y below the top
>
> label in the label stack is understood in the IGP domain.=C2=A0 When t= he
>
>=C2=A0 =C2=A0=C2=A0 provider edge routers exchange service labels via B= GP or some other
>
>=C2=A0 =C2=A0=C2=A0 non-IGP mechanism the bottom label is not understoo= d in the IGP
>
>=C2=A0 =C2=A0=C2=A0 domain.
>
>=C2=A0 =C2=A0=C2=A0 The egress node protection mechanisms described in = the draft
>
>=C2=A0 =C2=A0=C2=A0 [RFC8679 <https://datatracke= r.ietf.org/doc/html/rfc8679>] is
> applicable to this use case and no additional changes
>
>=C2=A0 =C2=A0=C2=A0 will be required for SR based networks
>
> The scenarios in which =C2=A0differentiation between =E2=80=9Ctopologi= cal=E2=80=9D and
> =E2=80=9Cservice=E2=80=9D instructions is broken are indeed problemati= c. E.g., consider
> the use case in which a Node SID in the ERO of a SR-TE path identifies= a
> node that acts as a firewall for all packets it receives, i.e., provid= es
> the firewall service without any dedicated service SID identifying it.=
> One could say that the Node SID of such a node would combine topologic= al
> and service instructions thus breaking the differentiation between the= two.
>
> I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs could b= e prevented or at
> least discouraged.
>
> If not, providing an ability to identify such SIDs in the advertisemen= t
> mechanisms would be useful IMHO.
>
> My 2c,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
>
> Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com
>
> -----Original Message-----
> From: spring <spring-bounces@ietf.org> On Behalf Of Mach Chen
> Sent: Monday, August 3, 2020 6:30 AM
> To: Joel M. Halpern <jmh@joelhalpern.com>; spring@ietf.org
> Subject: Re: [spring] Spring protection - determining applicability >
> Hi Joel,
>
> I think this is a good point that may not be discussed in the past. An= d
> I also don't think there is a "can be bypassed" indicati= on in the
> routing advertisement for now.
>
> IMHO, the information advertised by routing is neutral, such informati= on
> (can or cannot be bypassed) is more path specific, thus normally the <= br> > controller should be responsible for deciding whether/which SID can be=
> bypassed.
>
> Best regards,
>
> Mach
>
>=C2=A0 > -----Original Message-----
>
>=C2=A0 > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. >
>=C2=A0 > Halpern
>
>=C2=A0 > Sent: Monday, August 3, 2020 7:51 AM
>
>=C2=A0 > To: sp= ring@ietf.org <mailto:spring@ietf.org>
>
>=C2=A0 > Subject: [spring] Spring protection - determining applicabi= lity
>
>=C2=A0 >
>
>=C2=A0 > (WG Chair hat Off, this is merely a note from a slightly co= nfused WG
>
>=C2=A0 > participant.)
>
>=C2=A0 >
>
>=C2=A0 > I have been reading the various repair drafts, and the vari= ous
>
>=C2=A0 > networks programming and service programming draft, and I a= m trying to
>
>=C2=A0 > figure out one aspect of the combination.
>
>=C2=A0 >
>
>=C2=A0 > How does a node that is doing some form of bypass (suppose,= for
>
>=C2=A0 > simplicity, it is Node N2 deciding to bypass the next SID f= or a failed
>
>=C2=A0 > node N3) know that it is safe to do so?
>
>=C2=A0 >
>
>=C2=A0 > If the path was just for TE, then it is "safe" if= the new path meets
>
>=C2=A0 > the TE criteria.=C2=A0 or maybe it is safe if it is even cl= ose, as long as
>
>=C2=A0 > it is not used for too long.
>
>=C2=A0 >
>
>=C2=A0 > But what if the node were a Firewall, included to meet lega= l
> requirements?
>
>=C2=A0 > Or was some other necessary programmatic transform (wince w= e are
>
>=C2=A0 > deliberately vague about what nodes can do when asked suita= bly.)
>
>=C2=A0 >
>
>=C2=A0 > Is there some "can be bypassed" indication in the= routing
>
>=C2=A0 > advertisements that I missed?
>
>=C2=A0 >
>
>=C2=A0 > Thank you,
>
>=C2=A0 > Yours,
>
>=C2=A0 > Joel
>
>=C2=A0 >
>
>=C2=A0 > _______________________________________________
>
>=C2=A0 > spring mailing list
>
>=C2=A0 > spring= @ietf.org <mailto:spring@ietf.org>
>
>=C2=A0 >
> https://clicktime.syman= tec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
> <https://clicktime= .symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252>
>
>=C2=A0 > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
> _______________________________________________
>
> spring mailing list
>
> spring@ietf.org <mailto:spring@i= etf.org>
>
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAv= P46H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
>
>
> ----------------------------------------------------------------------= --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or =
> proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
> recipient, please notify the sender immediately and then delete all > copies, including any attachments.
> ----------------------------------------------------------------------= --
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring >

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000a6e69805abfd55a3-- From nobody Mon Aug 3 11:35:53 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36443A09B9 for ; Mon, 3 Aug 2020 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.846 X-Spam-Level: * X-Spam-Status: No, score=1.846 tagged_above=-999 required=5 tests=[BITCOIN_SPAM_02=2.497, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, PDS_BTC_ID=0.498, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 CEPb0g9Cders for ; Mon, 3 Aug 2020 11:35:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 17D093A0983 for ; Mon, 3 Aug 2020 11:35:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BL65d60r3z6G937; Mon, 3 Aug 2020 11:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596479749; bh=hEWnt0rSLdJP49OItNc3gVQbUaJvTadviGr8Tc3uDwE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jt/jqtRgWN2zKAgxQUEm3PN1SGp3ujOPf2DKeqNVod8mzXVBZq8Qi6cGdYCEqOZg8 z2UKT0WiEY6nK4qgHSNnVtUeC+3qd6VdfY7qeUTpgUN3hv/uWCroLu1ShztD6ZnCOL Q1NMVP7erV1/wNmjiBbf8/6s5fHN//ZGe//fQlko= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BL65d1Zfwz6G7l2; Mon, 3 Aug 2020 11:35:48 -0700 (PDT) To: Robert Raszuk Cc: "spring@ietf.org" References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> Date: Mon, 3 Aug 2020 14:35:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 18:35:52 -0000 (Since the thread has gotten long enough, reiterating that this is as a participant, not a WG chair.) Yes, we are talking IP networks. And yes, I have seen IP networks that choose to drop packets. For all sorts of reasons. I think there are likely other reasons why one may not want a random path rather than a chosen TE path. I think it is important we be clear about what constraints may be / are violated when we tell people they have this tool (protective rerouting) that is intended to preserve QoS. Let's be clear. I am not arguing that this is not a good idea. It is a good idea. And useful. I am trying to figure otu what combination of additional mechanisms and clear descriptions will lead to everyone getting the behavior they expect (which may not be the behavior they desire, but sometimes is the best we can do.) Yours, Joel On 8/3/2020 2:30 PM, Robert Raszuk wrote: > Joel, > > Are we still talking about IP networks here ? Or perhaps some hard > slicing with real resource reservations or detnets ? > > Because if we are talking about IP networking I have two observations: > > A) If you need to traverse via a specific node (ie. firewall) you better > apply IP encapsulation to that node. I don't think IP encapsulation can > be hijacked today such that destination address of the packet is ignored. > > B) Have you seen any IP network where upon topology change (link or node > failure) you suddenly start dropping flows in spite of SPT offering > perhaps few ms longer path with 10 ms more jitter ? > > Or are some SR marketing slides promise to turn IP networks in > something new ? Worse ... do they mention path quality guarantees, > resource reservations ? I hope not. > > Thx, > R. > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > wrote: > > Well less serious for TE SIDs, I am not sure the problem is restricted > to just service SIDs. > > Suppose that the PCE has specified the path to meet some complex te > objective.  The bypass node has no way of knowing what those > constraints > were.  And for some kinds of traffic, it is better to drop the packet > than to deliver it outside the envelop.  I suspect that the right > answer > to this is "too bad".  If so, as with the distinction regarding service > nodes, we should say so, shouldn't we? > > Yours, > Joel > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > Mach, Joel and all, > > > > I think that in most cases: > > > > 1.There is clear differentiation between "topological" and "service" > > instructions in SID advertisements. E.g.: > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > corresponding IGP advertisements) represent topological instructions > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > draft) unsurprisingly represent “service†instructions > > > > 2.Segments that represent topological instructions can be bypassed, > > while segments that represent service instructions require > alternative > > protection mechanisms. > > > > This view seems to be aligned with RFC 8402 > > that says in Section 1: > > > >     In the context of an IGP-based distributed control plane, two > > > > topological segments are defined: the IGP-Adjacency segment and the > > > >     IGP-Prefix segment. > > > >     In the context of a BGP-based distributed control plane, two > > > > topological segments are defined: the BGP peering segment and the > > > >     BGP-Prefix segment. > > > > In the case of SR-MPLS this differentiation is assumed in Section > 3.4 of > > the Node Protection for SR-TE Path > > > > > > draft that says: > > > >     The node protection mechanism described in the previous sections > > > >     depends on the assumption that the label immediately below > the top > > > > label in the label stack is understood in the IGP domain.  When the > > > >     provider edge routers exchange service labels via BGP or some > other > > > >     non-IGP mechanism the bottom label is not understood in the IGP > > > >     domain. > > > >     The egress node protection mechanisms described in the draft > > > >     [RFC8679 ] is > > applicable to this use case and no additional changes > > > >     will be required for SR based networks > > > > The scenarios in which  differentiation between “topological†and > > “service†instructions is broken are indeed problematic. E.g., > consider > > the use case in which a Node SID in the ERO of a SR-TE path > identifies a > > node that acts as a firewall for all packets it receives, i.e., > provides > > the firewall service without any dedicated service SID > identifying it. > > One could say that the Node SID of such a node would combine > topological > > and service instructions thus breaking the differentiation > between the two. > > > > I am not sure if usage of such “combined†SIDs could be prevented > or at > > least discouraged. > > > > If not, providing an ability to identify such SIDs in the > advertisement > > mechanisms would be useful IMHO. > > > > My 2c, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell:      +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > -----Original Message----- > > From: spring > On Behalf Of Mach Chen > > Sent: Monday, August 3, 2020 6:30 AM > > To: Joel M. Halpern >; spring@ietf.org > > Subject: Re: [spring] Spring protection - determining applicability > > > > Hi Joel, > > > > I think this is a good point that may not be discussed in the > past. And > > I also don't think there is a "can be bypassed" indication in the > > routing advertisement for now. > > > > IMHO, the information advertised by routing is neutral, such > information > > (can or cannot be bypassed) is more path specific, thus normally the > > controller should be responsible for deciding whether/which SID > can be > > bypassed. > > > > Best regards, > > > > Mach > > > >  > -----Original Message----- > > > >  > From: spring [mailto:spring-bounces@ietf.org > ] On Behalf Of Joel M. > > > >  > Halpern > > > >  > Sent: Monday, August 3, 2020 7:51 AM > > > >  > To: spring@ietf.org > > > > > >  > Subject: [spring] Spring protection - determining applicability > > > >  > > > > >  > (WG Chair hat Off, this is merely a note from a slightly > confused WG > > > >  > participant.) > > > >  > > > > >  > I have been reading the various repair drafts, and the various > > > >  > networks programming and service programming draft, and I am > trying to > > > >  > figure out one aspect of the combination. > > > >  > > > > >  > How does a node that is doing some form of bypass (suppose, for > > > >  > simplicity, it is Node N2 deciding to bypass the next SID for > a failed > > > >  > node N3) know that it is safe to do so? > > > >  > > > > >  > If the path was just for TE, then it is "safe" if the new path > meets > > > >  > the TE criteria.  or maybe it is safe if it is even close, as > long as > > > >  > it is not used for too long. > > > >  > > > > >  > But what if the node were a Firewall, included to meet legal > > requirements? > > > >  > Or was some other necessary programmatic transform (wince we are > > > >  > deliberately vague about what nodes can do when asked suitably.) > > > >  > > > > >  > Is there some "can be bypassed" indication in the routing > > > >  > advertisements that I missed? > > > >  > > > > >  > Thank you, > > > >  > Yours, > > > >  > Joel > > > >  > > > > >  > _______________________________________________ > > > >  > spring mailing list > > > >  > spring@ietf.org > > > > > >  > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 > > > > > > >  > F%2Fwww.ietf.org > %2Fmailman%2Flistinfo%2Fspring > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > ------------------------------------------------------------------------ > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential > and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the > intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Mon Aug 3 12:00:40 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464493A11CB; Mon, 3 Aug 2020 12:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQAP_CKZCSB4; Mon, 3 Aug 2020 12:00:32 -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 EF30F3A1183; Mon, 3 Aug 2020 12:00:22 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id s26so18696154pfm.4; Mon, 03 Aug 2020 12:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=88C8rOOhTPZuZHsIcwUkpp2OfxNkVCAu7E/5eZ5IMBM=; b=NYV27k7rrR5u9Lfw2xO3MFd8IEFCcjrq09psz+VmB0P+lnEoqP4lTvyFtDyWkxjuSq DMyPlrO411hshpPVv0k1PuAlPJa/x+n42h/8UZtTO05QTe56Sd0LQ7lyzH0EKzZe+2fO 8JowatQZamQncQa6Oue25J+YV1Hs/a2Q2BT5MgsThFgs9t4n4x0tQyZ9Dmrz6HwNQMlp 7SfITCiU1p/rijPwxx3KXgV/Si7ykL0evfoJltmLUYvwW2V1m2hpEZJvskpLLykcubaN /nCI+931JJpD//Knl8hMl3mLZOs2Cwzr267pVS7Q4Ut1GOIILwnXqrnUsHfQJPbF3Bhz JuOQ== 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:subject:date:references:to :in-reply-to:message-id; bh=88C8rOOhTPZuZHsIcwUkpp2OfxNkVCAu7E/5eZ5IMBM=; b=RxZzZbqcwdb6uc/WL1tfLBSGfrMC/yYB8sn0jOF7g6tyhYHdrwOFxwfvuz2RJKJuFt 2ypenAB8+LkYBGc78vLcna6NbUWAUvNYepCZNfvKs9bVvUQuHCn4hehtlSD2xCg4SRWW ePfRUU8x3CJnZliDfRoCtfJAeRcz6h8XP0ES/Fznq++8Ap5+ZMfNTY340apRbFq1m7Ic hZPEGLHXwrExN+bEh0po7j/Q7V3OsBEPOAC1bNyFg8S6674A1Y1kDdgKzx/Q06+FApS7 5asizWhILIxSM2Lvzdz0Yn/62N/z+uuS4B3H3DIaMA1ePmHp0qfQajDriR6lfpJFA17U zYgQ== X-Gm-Message-State: AOAM530tOyz5hv8G67MrdhiAsWhGDKqDOr3vKLGgezkhQhAkZAzTYbGK NYxGxNp7iF3sw/ylWPaB9ajvw4gW8dI= X-Google-Smtp-Source: ABdhPJxMe3DXekTyAhSMI0PXMNE0K81TFlYDw6iZ37FVqm7qKhAgVqWfeRtg1QPqyHsAted7cCfZdA== X-Received: by 2002:a63:1250:: with SMTP id 16mr7815543pgs.288.1596481221814; Mon, 03 Aug 2020 12:00:21 -0700 (PDT) Received: from kszarkowicz-mbp.jnpr.net (jpams-nat10.juniper.net. [193.110.49.10]) by smtp.gmail.com with ESMTPSA id m26sm20403778pff.84.2020.08.03.12.00.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2020 12:00:21 -0700 (PDT) From: Krzysztof Szarkowicz Content-Type: multipart/alternative; boundary="Apple-Mail=_FB7B0B3D-7329-435A-87F8-1AC25AF3A937" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 3 Aug 2020 21:00:18 +0200 References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <23F5A4BD-67C0-4E08-B521-9BFF5AA6FB29@juniper.net> To: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" In-Reply-To: <23F5A4BD-67C0-4E08-B521-9BFF5AA6FB29@juniper.net> Message-Id: <9D335EA6-EED2-4B62-AEDA-982DA65D95A3@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 19:00:39 -0000 --Apple-Mail=_FB7B0B3D-7329-435A-87F8-1AC25AF3A937 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Support for adoption. The draft covers important piece of the missing puzzle in the overall SR = protection story. Thanks, Krzysztof =20 > From: spring > on behalf of = "bruno.decraene@orange.com " = > > Date: Thursday, July 30, 2020 at 8:24 AM > To: "spring@ietf.org " > > Cc: "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org = " = > > Subject: [spring] WG adoption call for = draft-hegde-spring-node-protection-for-sr-te-paths > =20 > [External Email. Be cautious of content] > =20 > Hi SPRING WG, > =20 > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] = have asked for WG adoption. > =20 > Please indicate your support, comments, or objection, for adopting = this draft as a working group item by August 20th 2020. (*) > =20 > Could those who are willing to work on this document, please notify = the list. That gives us an indication of the energy level in the working = group to work on this. > =20 > Thanks, > Regards, > Bruno, Jim, Joel > =20 > [1] = https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-p= aths-07 = > (*) 3 weeks to account for the IETF meeting week and the august/summer = period. > =20 > = __________________________________________________________________________= _______________________________________________ > =20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > =20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > Juniper Business Use Only >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_FB7B0B3D-7329-435A-87F8-1AC25AF3A937 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Support for adoption.

The draft covers important piece of the missing puzzle in the = overall SR protection story.

Thanks,
Krzysztof
 

From: spring = <spring-bounces@ietf.org> on behalf of "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Date: Thursday, July 30, 2020 = at 8:24 AM
To: "spring@ietf.org" <spring@ietf.org>
Cc: "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org= " <draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org= >
Subject: [spring] WG adoption = call for draft-hegde-spring-node-protection-for-sr-te-paths
 
[External Email. Be cautious of content]
 
Hi SPRING WG,
 
Authors of = draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked = for WG adoption.
 
Please indicate = your support, comments, or objection, for adopting this draft as a = working group item by August 20th 2020. (*)
 
Could those who are willing to work on this = document, please notify the list. That gives us an indication of the = energy level in the working group to work on this.
 
Thanks,
Regards,
Bruno, Jim, = Joel
 
[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-= for-sr-te-paths-07
(*) 3 weeks to account for the IETF meeting = week and the august/summer period.
 
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses =
pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans =
autorisation. Si vous avez recu ce message par erreur, veuillez le =
signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute =
responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its =
attachments may contain confidential or privileged information that may =
be protected by law;
they should not be distributed, used or copied without =
authorisation.
If =
you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or falsified.
Thank you.

Juniper Business Use Only

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_FB7B0B3D-7329-435A-87F8-1AC25AF3A937-- From nobody Mon Aug 3 14:46:21 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946153A1105 for ; Mon, 3 Aug 2020 14:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 mSOlnmVbtvNX for ; Mon, 3 Aug 2020 14:46:15 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [207.82.80.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3825D3A10FD for ; Mon, 3 Aug 2020 14:46:14 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2053.outbound.protection.outlook.com [104.47.12.53]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-20-TdNO18m3NWG_s9v8T_Eprw-1; Mon, 03 Aug 2020 22:46:07 +0100 X-MC-Unique: TdNO18m3NWG_s9v8T_Eprw-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VE1PR03MB5646.eurprd03.prod.outlook.com (2603:10a6:803:11f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Mon, 3 Aug 2020 21:46:06 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117%3]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 21:46:05 +0000 From: Andrew Alston To: "Joel M. Halpern" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfFqqBapiFGQU+SeGw1le2xJKklun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADOyIA== Date: Mon, 3 Aug 2020 21:46:05 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2c0f:fe40:3:2:1f5:9343:5fd4:b3ae] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ca206373-9b61-413d-a262-08d837f6a017 x-ms-traffictypediagnostic: VE1PR03MB5646: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cArxtpJTU35PTPEFq1yCiaTGIHoviWVoboWVXIVv1qGH9VHwnixTRHx8islqpGrqfbE8TfeFg+ujGC6UNzd+QmpKo0/n8Jjo8ldcQeFIS7tKeud1/In5BwKdUG5sok4dyEXRAq7GcZVOFRzA7A/7eVLh9aHrg6vhpJIjmr1ZdB0SnJ5ciAVlCJThFNdhQkznkEeWCnW9sM6fHjlVc2g6r/Su028IavTkWku1rQ+TCbiorEOW6B3HbWmerGPg5FasKVFtpB5AGddM3OTRRqHb49d1tMET5c0bKoWM2sbBYJPWKi4zIYDy5ZrWbQ+fkivzPNLsn162Y4UNniQM/avgKsuH/tKsLkmKk7HJZINEA6W5VG1zZhtKaB5BTTGs0+pT4BMRGUUdehfywEKAUpKdSA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(376002)(396003)(346002)(66446008)(6506007)(33656002)(55016002)(71200400001)(53546011)(76116006)(66946007)(66556008)(9686003)(66476007)(478600001)(166002)(64756008)(83380400001)(86362001)(5660300002)(8936002)(52536014)(30864003)(2906002)(8676002)(966005)(316002)(110136005)(7696005)(186003)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 93DVU/2n83tjYnPIvLsQiMvMiZSf6lstA7eeUR+gaS+tZyKwVsLeeuoAXHhZUSKi2QqXM2dO5pCAghsVB1OZFc0GsfqqE1B68zIh4BJhRIU5zocN4nyILn9of/Uz+cY8yJao/JMcRZm+yNuON3TC43ii4f4YVy08NK8lqEi5pb1Ujx0uP8ywwNUv3/YSnwFFtFsQBPfprVD3S//YzBkDHBXsUhErDLAazYTlsROEGpg5tGn3tikgos8l5qPmbxhzZOeY6noxkNgGvFMuJh6xNaEZajclgwKh0Dr1TmusvdYbs3w57MZ4hJhKmghlDsJaSGCeQxtGjBTkWCMUavqxj/5h6ikSEmGzxHELp4iBWHzpc6as5yMNaPbuit3O5ml4qu+zYvs5wFDyY2upK9ZnaraH5uRsi+5ihZ2cnkSrZV7UudxoPeN7msJMr36EvJSNotNTOH3pKNR/IwEuqX5lLL77ASUa/1nBEK2hBPaZujF1YrBK+gteIJahDl+HnDMfhYruhsQ/COmHsyWHVJUjCysVIwFAR39Tw0pFW6lQQ+eYrriFjBzyEUvipz9s+V0ddEDbek9vyzuRtLbsKRCvAF4TgsvDWLIihnfbjkiY/lDqkcSi/ZQXAapyA2G2owJTgf+hldw6HNqV21OYM6ts7bzwkIPKw9fsYpiCxu2DcyMrYDZYMnjA2ieKBbC/6tOc x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR03MB5056.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca206373-9b61-413d-a262-08d837f6a017 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 21:46:05.8332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kJr+7vkWnxn3K0wq6TpCOv5ROqtH25bfEzlAtZikGdQ7W1VUUg/kp7PledqOoXEKZnAtaJvykyc4ulxBHoRxVYKTyq8029Rp+WlqaAkC+7g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR03MB5646 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_VI1PR03MB50560EA5D95C76F7501608FBEE4D0VI1PR03MB5056eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 21:46:19 -0000 --_000_VI1PR03MB50560EA5D95C76F7501608FBEE4D0VI1PR03MB5056eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 U28g4oCTDQoNCk9uZSBvZiB0aGUgdXNlIGNhc2VzLCBpbiBmYWN0LCBzb21lIHZlcnkgbWFqb3Ig dXNlIGNhc2VzIGluIGFueSBzcHJpbmcgdGVjaG5vbG9neSBmb3IgdXMgcmV2b2x2ZSBhcm91bmQg dGhlIGZvbGxvd2luZw0KDQoNCiAgMS4gIFRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2YgY2VydGFp biBub2Rlcw0KICAyLiAgVGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIHNlY3Rpb25z IG9mIHRoZSBuZXR3b3JrDQoNCkFueXRoaW5nIHRoYXQgY291bGQgcmVzdWx0IGluIHRoYXQgZXhw bGljaXQgYXZvaWRhbmNlIGJlaW5nIHZpb2xhdGVkIOKAkyB3b3VsZCBjcmVhdGUsIHNoYWxsIHdl IHNheSBzaWduaWZpY2FudCBwcm9ibGVtcy4NCg0KTXVjaCBvZiB0aGUgdXNlIGNhc2UgaXMgbm90 IGEgY2FzZSBvZiB3aGljaCBub2RlcyB0aGUgcGFja2V0cyBmbG93IHRocm91Z2gg4oCTIGJ1dCBy YXRoZXIg4oCTIHdoaWNoIG5vZGVzIC8gbmV0d29yayBzZWdtZW50cyBpdCBjYW4gbmV2ZXIgdG91 Y2ggb3IgZmxvdyB0aHJvdWdoLiAgRWZmZWN0aXZlbHksIHRvIGJlIHVzZWQgYXMgYSB0ZWNobm9s b2d5IHRvIGF2b2lkIGNlcnRhaW4gdGhpbmdzIGZvciBzcGVjaWZpYyByZWFzb25zLg0KDQpUaGlz IGlzIGFsc28gb25lIG9mIHRoZSByZWFzb25zIGZvciBuZWVkaW5nIHN1Y2ggZGVlcCBsYWJlbCBz dGFja3Mg4oCTIHRoaXMga2luZCBvZiBkZXRhaWxlZCBwYXRoIHByb2dyYW1taW5nIHRlbmRzIHRv IGRlZXBlbiB0aGUgc3RhY2sgYmVjYXVzZSB5b3Ugc29tZXRpbWVzIGhhdmUgdG8gYmUgcHJldHR5 IGV4cGxpY2l0Lg0KDQpJdCBpcyBhYnNvbHV0ZWx5IGNyaXRpY2FsIHRvIHVzIHRoYXQgdGhpcyBm dW5jdGlvbmFsaXR5IGlzIHRoZXJlIOKAkyBhbmQgdGhhdCB3ZSBjYW4gYXZvaWQgc2l0dWF0aW9u cyB3aGljaCBjb3VsZCBjYXVzZSB0cmFmZmljIHRvIGFjY2lkZW50bHkgaGl0IHRoaW5ncyBleHBs aWNpdGx5IGF2b2lkZWQuDQoNCkkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgdGhhbiB0 aGlzLCBidXQgaXQgaXMgd2hhdCBpdCBpcy4NCg0KVGhhbmtzDQoNCkFuZHJldw0KDQoNCkZyb206 IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhh bHBlcm4NClNlbnQ6IE1vbmRheSwgMyBBdWd1c3QgMjAyMCAyMTozNg0KVG86IFJvYmVydCBSYXN6 dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0K DQooU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCByZWl0ZXJhdGluZyB0 aGF0IHRoaXMgaXMgYXMgYQ0KcGFydGljaXBhbnQsIG5vdCBhIFdHIGNoYWlyLikNCg0KWWVzLCB3 ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29y a3MgdGhhdA0KY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFsbCBzb3J0cyBvZiByZWFzb25z Lg0KSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9uZSBtYXkgbm90 IHdhbnQgYSByYW5kb20NCnBhdGggcmF0aGVyIHRoYW4gYSBjaG9zZW4gVEUgcGF0aC4gSSB0aGlu ayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXINCmFib3V0IHdoYXQgY29uc3RyYWludHMgbWF5 IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUgdGhleQ0KaGF2ZSB0aGlzIHRv b2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0aGF0IGlzIGludGVuZGVkIHRvIHByZXNlcnZlIFFv Uy4NCg0KTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlzIGlzIG5vdCBh IGdvb2QgaWRlYS4gSXQgaXMgYQ0KZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJIGFtIHRyeWluZyB0 byBmaWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2YNCmFkZGl0aW9uYWwgbWVjaGFuaXNtcyBh bmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVyeW9uZQ0KZ2V0dGluZyB0aGUg YmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJlaGF2aW9yIHRoZXkN CmRlc2lyZSwgYnV0IHNvbWV0aW1lcyBpcyB0aGUgYmVzdCB3ZSBjYW4gZG8uKQ0KDQpZb3VycywN CkpvZWwNCg0KT24gOC8zLzIwMjAgMjozMCBQTSwgUm9iZXJ0IFJhc3p1ayB3cm90ZToNCj4gSm9l bCwNCj4NCj4gQXJlIHdlIHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya3MgaGVyZSA/IE9y IHBlcmhhcHMgc29tZSBoYXJkDQo+IHNsaWNpbmcgd2l0aCByZWFsIHJlc291cmNlIHJlc2VydmF0 aW9ucyBvciBkZXRuZXRzID8NCj4NCj4gQmVjYXVzZSBpZiB3ZSBhcmUgdGFsa2luZyBhYm91dCBJ UCBuZXR3b3JraW5nIEkgaGF2ZSB0d28gb2JzZXJ2YXRpb25zOg0KPg0KPiBBKSBJZiB5b3UgbmVl ZCB0byB0cmF2ZXJzZSB2aWEgYSBzcGVjaWZpYyBub2RlIChpZS4gZmlyZXdhbGwpIHlvdSBiZXR0 ZXINCj4gYXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuIEkgZG9uJ3QgdGhpbmsg SVAgZW5jYXBzdWxhdGlvbiBjYW4NCj4gYmUgaGlqYWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRlc3Rp bmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpcyBpZ25vcmVkLg0KPg0KPiBCKSBIYXZlIHlv dSBzZWVuIGFueSBJUCBuZXR3b3JrIHdoZXJlIHVwb24gdG9wb2xvZ3kgY2hhbmdlIChsaW5rIG9y IG5vZGUNCj4gZmFpbHVyZSkgeW91IHN1ZGRlbmx5IHN0YXJ0IGRyb3BwaW5nIGZsb3dzIGluIHNw aXRlIG9mIFNQVCBvZmZlcmluZw0KPiBwZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRoIDEw IG1zIG1vcmUgaml0dGVyID8NCj4NCj4gT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNsaWRlcyBw cm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4NCj4gc29tZXRoaW5nIG5ldyA/IFdvcnNlIC4u LiBkbyB0aGV5IG1lbnRpb24gcGF0aCBxdWFsaXR5IGd1YXJhbnRlZXMsDQo+IHJlc291cmNlIHJl c2VydmF0aW9ucyA/IEkgaG9wZSBub3QuDQo+DQo+IFRoeCwNCj4gUi4NCj4NCj4NCj4NCj4NCj4N Cj4NCj4NCj4NCj4NCj4gT24gTW9uLCBBdWcgMywgMjAyMCBhdCA4OjEwIFBNIEpvZWwgTS4gSGFs cGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTIw JTBiPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQo+DQo+IFdlbGwgbGVz cyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRoZSBwcm9ibGVtIGlzIHJlc3Ry aWN0ZWQNCj4gdG8ganVzdCBzZXJ2aWNlIFNJRHMuDQo+DQo+IFN1cHBvc2UgdGhhdCB0aGUgUENF IGhhcyBzcGVjaWZpZWQgdGhlIHBhdGggdG8gbWVldCBzb21lIGNvbXBsZXggdGUNCj4gb2JqZWN0 aXZlLiAgVGhlIGJ5cGFzcyBub2RlIGhhcyBubyB3YXkgb2Yga25vd2luZyB3aGF0IHRob3NlDQo+ IGNvbnN0cmFpbnRzDQo+IHdlcmUuICBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywgaXQg aXMgYmV0dGVyIHRvIGRyb3AgdGhlIHBhY2tldA0KPiB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lk ZSB0aGUgZW52ZWxvcC4gIEkgc3VzcGVjdCB0aGF0IHRoZSByaWdodA0KPiBhbnN3ZXINCj4gdG8g dGhpcyBpcyAidG9vIGJhZCIuICBJZiBzbywgYXMgd2l0aCB0aGUgZGlzdGluY3Rpb24gcmVnYXJk aW5nIHNlcnZpY2UNCj4gbm9kZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT8NCj4N Cj4gWW91cnMsDQo+IEpvZWwNCj4NCj4gT24gOC8zLzIwMjAgMjozNiBBTSwgQWxleGFuZGVyIFZh aW5zaHRlaW4gd3JvdGU6DQo+ID4gTWFjaCwgSm9lbCBhbmQgYWxsLA0KPiA+DQo+ID4gSSB0aGlu ayB0aGF0IGluIG1vc3QgY2FzZXM6DQo+ID4NCj4gPiAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVu dGlhdGlvbiBiZXR3ZWVuICJ0b3BvbG9naWNhbCIgYW5kICJzZXJ2aWNlIg0KPiA+IGluc3RydWN0 aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46DQo+ID4NCj4gPiBvSUdQIFByZWZpeCBO b2RlIFNJRHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4gdGhlDQo+ID4gY29y cmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMpIHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0 cnVjdGlvbnMNCj4gPg0KPiA+IG9TZXJ2aWNlIFNJRHMgZm9yIFNSdjYgKHNlZSBTUnY2IEJHUC1C YXNlZCBPdmVybGF5IFNlcnZpY2VzDQo+ID4NCj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQ8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0w ND4+DQo+DQo+ID4gZHJhZnQpIHVuc3VycHJpc2luZ2x5IHJlcHJlc2VudCDigJxzZXJ2aWNl4oCd IGluc3RydWN0aW9ucw0KPiA+DQo+ID4gMi5TZWdtZW50cyB0aGF0IHJlcHJlc2VudCB0b3BvbG9n aWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5cGFzc2VkLA0KPiA+IHdoaWxlIHNlZ21lbnRzIHRo YXQgcmVwcmVzZW50IHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHJlcXVpcmUNCj4gYWx0ZXJuYXRpdmUN Cj4gPiBwcm90ZWN0aW9uIG1lY2hhbmlzbXMuDQo+ID4NCj4gPiBUaGlzIHZpZXcgc2VlbXMgdG8g YmUgYWxpZ25lZCB3aXRoIFJGQyA4NDAyDQo+ID4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM4NDAyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyPj4gdGhhdCBzYXlz IGluIFNlY3Rpb24gMToNCj4gPg0KPiA+ICAgICBJbiB0aGUgY29udGV4dCBvZiBhbiBJR1AtYmFz ZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwgdHdvDQo+ID4NCj4gPiB0b3BvbG9naWNhbCBz ZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIElHUC1BZGphY2VuY3kgc2VnbWVudCBhbmQgdGhlDQo+ ID4NCj4gPiAgICAgSUdQLVByZWZpeCBzZWdtZW50Lg0KPiA+DQo+ID4gICAgIEluIHRoZSBjb250 ZXh0IG9mIGEgQkdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bw0KPiA+DQo+ ID4gdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBCR1AgcGVlcmluZyBzZWdt ZW50IGFuZCB0aGUNCj4gPg0KPiA+ICAgICBCR1AtUHJlZml4IHNlZ21lbnQuDQo+ID4NCj4gPiBJ biB0aGUgY2FzZSBvZiBTUi1NUExTIHRoaXMgZGlmZmVyZW50aWF0aW9uIGlzIGFzc3VtZWQgaW4g U2VjdGlvbg0KPiAzLjQgb2YNCj4gPiB0aGUgTm9kZSBQcm90ZWN0aW9uIGZvciBTUi1URSBQYXRo DQo+ID4NCj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGVn ZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDcjc2VjdGlvbi0zLjQ8 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmct bm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyNzZWN0aW9uLTMuND4+DQo+DQo+ID4g ZHJhZnQgdGhhdCBzYXlzOg0KPiA+DQo+ID4gICAgIFRoZSBub2RlIHByb3RlY3Rpb24gbWVjaGFu aXNtIGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbnMNCj4gPg0KPiA+ICAgICBkZXBl bmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVsIGltbWVkaWF0ZWx5IGJlbG93DQo+ IHRoZSB0b3ANCj4gPg0KPiA+IGxhYmVsIGluIHRoZSBsYWJlbCBzdGFjayBpcyB1bmRlcnN0b29k IGluIHRoZSBJR1AgZG9tYWluLiAgV2hlbiB0aGUNCj4gPg0KPiA+ICAgICBwcm92aWRlciBlZGdl IHJvdXRlcnMgZXhjaGFuZ2Ugc2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBzb21lDQo+IG90aGVy DQo+ID4NCj4gPiAgICAgbm9uLUlHUCBtZWNoYW5pc20gdGhlIGJvdHRvbSBsYWJlbCBpcyBub3Qg dW5kZXJzdG9vZCBpbiB0aGUgSUdQDQo+ID4NCj4gPiAgICAgZG9tYWluLg0KPiA+DQo+ID4gICAg IFRoZSBlZ3Jlc3Mgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBk cmFmdA0KPiA+DQo+ID4gICAgIFtSRkM4Njc5IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL3JmYzg2Nzk8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9y ZmM4Njc5Pj5dIGlzDQo+ID4gYXBwbGljYWJsZSB0byB0aGlzIHVzZSBjYXNlIGFuZCBubyBhZGRp dGlvbmFsIGNoYW5nZXMNCj4gPg0KPiA+ICAgICB3aWxsIGJlIHJlcXVpcmVkIGZvciBTUiBiYXNl ZCBuZXR3b3Jrcw0KPiA+DQo+ID4gVGhlIHNjZW5hcmlvcyBpbiB3aGljaCAgZGlmZmVyZW50aWF0 aW9uIGJldHdlZW4g4oCcdG9wb2xvZ2ljYWzigJ0gYW5kDQo+ID4g4oCcc2VydmljZeKAnSBpbnN0 cnVjdGlvbnMgaXMgYnJva2VuIGFyZSBpbmRlZWQgcHJvYmxlbWF0aWMuIEUuZy4sDQo+IGNvbnNp ZGVyDQo+ID4gdGhlIHVzZSBjYXNlIGluIHdoaWNoIGEgTm9kZSBTSUQgaW4gdGhlIEVSTyBvZiBh IFNSLVRFIHBhdGgNCj4gaWRlbnRpZmllcyBhDQo+ID4gbm9kZSB0aGF0IGFjdHMgYXMgYSBmaXJl d2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4sDQo+IHByb3ZpZGVzDQo+ID4g dGhlIGZpcmV3YWxsIHNlcnZpY2Ugd2l0aG91dCBhbnkgZGVkaWNhdGVkIHNlcnZpY2UgU0lEDQo+ IGlkZW50aWZ5aW5nIGl0Lg0KPiA+IE9uZSBjb3VsZCBzYXkgdGhhdCB0aGUgTm9kZSBTSUQgb2Yg c3VjaCBhIG5vZGUgd291bGQgY29tYmluZQ0KPiB0b3BvbG9naWNhbA0KPiA+IGFuZCBzZXJ2aWNl IGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRpb24NCj4gYmV0d2Vl biB0aGUgdHdvLg0KPiA+DQo+ID4gSSBhbSBub3Qgc3VyZSBpZiB1c2FnZSBvZiBzdWNoIOKAnGNv bWJpbmVk4oCdIFNJRHMgY291bGQgYmUgcHJldmVudGVkDQo+IG9yIGF0DQo+ID4gbGVhc3QgZGlz Y291cmFnZWQuDQo+ID4NCj4gPiBJZiBub3QsIHByb3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50 aWZ5IHN1Y2ggU0lEcyBpbiB0aGUNCj4gYWR2ZXJ0aXNlbWVudA0KPiA+IG1lY2hhbmlzbXMgd291 bGQgYmUgdXNlZnVsIElNSE8uDQo+ID4NCj4gPiBNeSAyYywNCj4gPg0KPiA+IFNhc2hhDQo+ID4N Cj4gPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gPg0KPiA+IENlbGw6ICAgICAgKzk3Mi01NDky NjYzMDINCj4gPg0KPiA+IEVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+IDxtYWlsdG86QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI+PiA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnPj4gT24gQmVoYWxmIE9mIE1hY2ggQ2hlbg0KPiA+IFNlbnQ6IE1vbmRheSwgQXVndXN0 IDMsIDIwMjAgNjozMCBBTQ0KPiA+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVy bi5jb20NCjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYj4+IDxtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBw cm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiA+DQo+ID4gSGkgSm9lbCwN Cj4gPg0KPiA+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgcG9pbnQgdGhhdCBtYXkgbm90IGJlIGRp c2N1c3NlZCBpbiB0aGUNCj4gcGFzdC4gQW5kDQo+ID4gSSBhbHNvIGRvbid0IHRoaW5rIHRoZXJl IGlzIGEgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBpbiB0aGUNCj4gPiByb3V0aW5nIGFk dmVydGlzZW1lbnQgZm9yIG5vdy4NCj4gPg0KPiA+IElNSE8sIHRoZSBpbmZvcm1hdGlvbiBhZHZl cnRpc2VkIGJ5IHJvdXRpbmcgaXMgbmV1dHJhbCwgc3VjaA0KPiBpbmZvcm1hdGlvbg0KPiA+IChj YW4gb3IgY2Fubm90IGJlIGJ5cGFzc2VkKSBpcyBtb3JlIHBhdGggc3BlY2lmaWMsIHRodXMgbm9y bWFsbHkgdGhlDQo+ID4gY29udHJvbGxlciBzaG91bGQgYmUgcmVzcG9uc2libGUgZm9yIGRlY2lk aW5nIHdoZXRoZXIvd2hpY2ggU0lEDQo+IGNhbiBiZQ0KPiA+IGJ5cGFzc2VkLg0KPiA+DQo+ID4g QmVzdCByZWdhcmRzLA0KPiA+DQo+ID4gTWFjaA0KPiA+DQo+ID4gID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPg0KPiA+ICA+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnDQo+IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUzY21haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyUzZT5dIE9uIEJlaGFsZiBPZiBKb2VsIE0uDQo+ID4NCj4gPiAgPiBIYWxwZXJuDQo+ ID4NCj4gPiAgPiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDc6NTEgQU0NCj4gPg0KPiA+ ICA+IFRvOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQo+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5n QGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYu b3JnPj4+DQo+ID4NCj4gPiAgPiBTdWJqZWN0OiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAt IGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiAoV0cg Q2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20gYSBzbGlnaHRseQ0KPiBj b25mdXNlZCBXRw0KPiA+DQo+ID4gID4gcGFydGljaXBhbnQuKQ0KPiA+DQo+ID4gID4NCj4gPg0K PiA+ICA+IEkgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIHZhcmlvdXMgcmVwYWlyIGRyYWZ0cywgYW5k IHRoZSB2YXJpb3VzDQo+ID4NCj4gPiAgPiBuZXR3b3JrcyBwcm9ncmFtbWluZyBhbmQgc2Vydmlj ZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW0NCj4gdHJ5aW5nIHRvDQo+ID4NCj4gPiAgPiBm aWd1cmUgb3V0IG9uZSBhc3BlY3Qgb2YgdGhlIGNvbWJpbmF0aW9uLg0KPiA+DQo+ID4gID4NCj4g Pg0KPiA+ICA+IEhvdyBkb2VzIGEgbm9kZSB0aGF0IGlzIGRvaW5nIHNvbWUgZm9ybSBvZiBieXBh c3MgKHN1cHBvc2UsIGZvcg0KPiA+DQo+ID4gID4gc2ltcGxpY2l0eSwgaXQgaXMgTm9kZSBOMiBk ZWNpZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcg0KPiBhIGZhaWxlZA0KPiA+DQo+ID4g ID4gbm9kZSBOMykga25vdyB0aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/DQo+ID4NCj4gPiAgPg0K PiA+DQo+ID4gID4gSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0IGlzICJzYWZl IiBpZiB0aGUgbmV3IHBhdGgNCj4gbWVldHMNCj4gPg0KPiA+ICA+IHRoZSBURSBjcml0ZXJpYS4g IG9yIG1heWJlIGl0IGlzIHNhZmUgaWYgaXQgaXMgZXZlbiBjbG9zZSwgYXMNCj4gbG9uZyBhcw0K PiA+DQo+ID4gID4gaXQgaXMgbm90IHVzZWQgZm9yIHRvbyBsb25nLg0KPiA+DQo+ID4gID4NCj4g Pg0KPiA+ICA+IEJ1dCB3aGF0IGlmIHRoZSBub2RlIHdlcmUgYSBGaXJld2FsbCwgaW5jbHVkZWQg dG8gbWVldCBsZWdhbA0KPiA+IHJlcXVpcmVtZW50cz8NCj4gPg0KPiA+ICA+IE9yIHdhcyBzb21l IG90aGVyIG5lY2Vzc2FyeSBwcm9ncmFtbWF0aWMgdHJhbnNmb3JtICh3aW5jZSB3ZSBhcmUNCj4g Pg0KPiA+ICA+IGRlbGliZXJhdGVseSB2YWd1ZSBhYm91dCB3aGF0IG5vZGVzIGNhbiBkbyB3aGVu IGFza2VkIHN1aXRhYmx5LikNCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBJcyB0aGVyZSBzb21l ICJjYW4gYmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmcNCj4gPg0KPiA+ICA+ IGFkdmVydGlzZW1lbnRzIHRoYXQgSSBtaXNzZWQ/DQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4g VGhhbmsgeW91LA0KPiA+DQo+ID4gID4gWW91cnMsDQo+ID4NCj4gPiAgPiBKb2VsDQo+ID4NCj4g PiAgPg0KPiA+DQo+ID4gID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPg0KPiA+ICA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gPg0KPiA+ICA+IHNw cmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4NCj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4g Pg0KPiA+ICA+DQo+ID4NCj4gaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRL aVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyPg0KPiA+DQo+IDxo dHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/ dT1odHRwcyUzQSUyNTI8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVr elc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyPj4NCj4gPg0KPiA+ICA+IEYlMkZ3d3cuaWV0 Zi5vcmcNCj4gPGh0dHA6Ly8yRnd3dy5pZXRmLm9yZzxodHRwOi8vMkZ3d3cuaWV0Zi5vcmc+PiUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPg0KPiA+IHNwcmluZyBtYWlsaW5nIGxp c3QNCj4gPg0KPiA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcNCjxtYWlsdG86c3By aW5nQGlldGYub3JnJTBiPj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KPiA+DQo+ID4NCj4g aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0Nkgy P3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJp bmc8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0 NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz cHJpbmc+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gTm90aWNl OiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0K PiA+IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMgY29u ZmlkZW50aWFsDQo+IGFuZC9vcg0KPiA+IHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywNCj4gPiBkaXNjbG9zdXJlLCByZWxp YW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dA0KPiA+ IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5v dCB0aGUNCj4gaW50ZW5kZWQNCj4gPiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsDQo+ID4gY29waWVzLCBpbmNsdWRpbmcg YW55IGF0dGFjaG1lbnRzLg0KPiA+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzcHJpbmcgbWFp bGluZyBsaXN0DQo+ID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3ByaW5nPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nPg0KPiA+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZz4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmc8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc+ DQo= --_000_VI1PR03MB50560EA5D95C76F7501608FBEE4D0VI1PR03MB5056eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1s ZWZ0OjM2LjBwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjExNzIzNzg1OTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwMzc3MjI2OTIgLTEyMDI1NDMxODggNTM2ODcwOTM3 IDUzNjg3MDkzOSA1MzY4NzA5MjcgNTM2ODcwOTM3IDUzNjg3MDkzOSA1MzY4NzA5MjcgNTM2ODcw OTM3IDUzNjg3MDkzOTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXC5cKSI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJlbi1LRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28g4oCTIDxvOnA+DQo8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+T25lIG9mIHRoZSB1c2UgY2FzZXMsIGluIGZhY3QsIHNvbWUg dmVyeSBtYWpvciB1c2UgY2FzZXMgaW4gYW55IHNwcmluZyB0ZWNobm9sb2d5IGZvciB1cyByZXZv bHZlIGFyb3VuZCB0aGUgZm9sbG93aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4t dG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgZXhwbGlj aXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9kZXM8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+VGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIHNlY3Rpb25zIG9m IHRoZSBuZXR3b3JrPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QW55dGhp bmcgdGhhdCBjb3VsZCByZXN1bHQgaW4gdGhhdCBleHBsaWNpdCBhdm9pZGFuY2UgYmVpbmcgdmlv bGF0ZWQg4oCTIHdvdWxkIGNyZWF0ZSwgc2hhbGwgd2Ugc2F5IHNpZ25pZmljYW50IHByb2JsZW1z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk11Y2ggb2YgdGhlIHVzZSBjYXNlIGlz IG5vdCBhIGNhc2Ugb2Ygd2hpY2ggbm9kZXMgdGhlIHBhY2tldHMgZmxvdyB0aHJvdWdoIOKAkyBi dXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2VnbWVudHMgaXQgY2FuIG5ldmVy IHRvdWNoIG9yIGZsb3cgdGhyb3VnaC4mbmJzcDsgRWZmZWN0aXZlbHksIHRvIGJlIHVzZWQNCiBh cyBhIHRlY2hub2xvZ3kgdG8gYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNv bnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBpcyBhbHNvIG9uZSBvZiB0 aGUgcmVhc29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwgc3RhY2tzIOKAkyB0aGlzIGtp bmQgb2YgZGV0YWlsZWQgcGF0aCBwcm9ncmFtbWluZyB0ZW5kcyB0byBkZWVwZW4gdGhlIHN0YWNr IGJlY2F1c2UgeW91IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBleHBsaWNpdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JdCBpcyBhYnNvbHV0ZWx5IGNyaXRpY2FsIHRvIHVz IHRoYXQgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIHRoZXJlIOKAkyBhbmQgdGhhdCB3ZSBjYW4gYXZv aWQgc2l0dWF0aW9ucyB3aGljaCBjb3VsZCBjYXVzZSB0cmFmZmljIHRvIGFjY2lkZW50bHkgaGl0 IHRoaW5ncyBleHBsaWNpdGx5IGF2b2lkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SSB3aXNoIEkgY291bGQgYmUgbW9yZSBzcGVjaWZpYyB0aGFuIHRoaXMsIGJ1dCBpdCBpcyB3 aGF0IGl0IGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9ImVuLUtFIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gc3ByaW5nICZsdDtzcHJpbmctYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Sm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgMyBBdWd1 c3QgMjAyMCAyMTozNjxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJh c3p1ay5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBw bGljYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPihT aW5jZSB0aGUgdGhyZWFkIGhhcyBnb3R0ZW4gbG9uZyBlbm91Z2gsIHJlaXRlcmF0aW5nIHRoYXQg dGhpcyBpcyBhcyBhDQo8YnI+DQpwYXJ0aWNpcGFudCwgbm90IGEgV0cgY2hhaXIuKTxicj4NCjxi cj4NClllcywgd2UgYXJlIHRhbGtpbmcgSVAgbmV0d29ya3MuIEFuZCB5ZXMsIEkgaGF2ZSBzZWVu IElQIG5ldHdvcmtzIHRoYXQgPGJyPg0KY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFsbCBz b3J0cyBvZiByZWFzb25zLjxicj4NCkkgdGhpbmsgdGhlcmUgYXJlIGxpa2VseSBvdGhlciByZWFz b25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9tIDxicj4NCnBhdGggcmF0aGVyIHRoYW4g YSBjaG9zZW4gVEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXIgPGJy Pg0KYWJvdXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlvbGF0ZWQgd2hlbiB3ZSB0 ZWxsIHBlb3BsZSB0aGV5IDxicj4NCmhhdmUgdGhpcyB0b29sIChwcm90ZWN0aXZlIHJlcm91dGlu ZykgdGhhdCBpcyBpbnRlbmRlZCB0byBwcmVzZXJ2ZSBRb1MuPGJyPg0KPGJyPg0KTGV0J3MgYmUg Y2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlzIGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQg aXMgYSA8YnI+DQpnb29kIGlkZWEuIEFuZCB1c2VmdWwuIEkgYW0gdHJ5aW5nIHRvIGZpZ3VyZSBv dHUgd2hhdCBjb21iaW5hdGlvbiBvZiA8YnI+DQphZGRpdGlvbmFsIG1lY2hhbmlzbXMgYW5kIGNs ZWFyIGRlc2NyaXB0aW9ucyB3aWxsIGxlYWQgdG8gZXZlcnlvbmUgPGJyPg0KZ2V0dGluZyB0aGUg YmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJlaGF2aW9yIHRoZXkg PGJyPg0KZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBiZXN0IHdlIGNhbiBkby4pPGJyPg0K PGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCk9uIDgvMy8yMDIwIDI6MzAgUE0sIFJv YmVydCBSYXN6dWsgd3JvdGU6PGJyPg0KJmd0OyBKb2VsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBB cmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JrcyZuYnNwO2hlcmUgPyBPciBwZXJo YXBzIHNvbWUgaGFyZCA8YnI+DQomZ3Q7IHNsaWNpbmcgd2l0aCByZWFsIHJlc291cmNlIHJlc2Vy dmF0aW9ucyBvciBkZXRuZXRzID88YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVjYXVzZSZuYnNwO2lm IHdlIGFyZSB0YWxraW5nJm5ic3A7YWJvdXQgSVAgbmV0d29ya2luZyBJIGhhdmUgdHdvIG9ic2Vy dmF0aW9uczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSkgSWYgeW91IG5lZWQgdG8gdHJhdmVyc2Ug dmlhIGEgc3BlY2lmaWMgbm9kZSAoaWUuIGZpcmV3YWxsKSB5b3UgYmV0dGVyIDxicj4NCiZndDsg YXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuIEkgZG9uJ3QgdGhpbmsgSVAgZW5j YXBzdWxhdGlvbiZuYnNwO2NhbiA8YnI+DQomZ3Q7IGJlIGhpamFja2VkIHRvZGF5IHN1Y2ggdGhh dCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXMgaWdub3JlZC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3aGVyZSB1cG9uIHRv cG9sb2d5IGNoYW5nZSAobGluayBvciBub2RlIDxicj4NCiZndDsgZmFpbHVyZSkgeW91IHN1ZGRl bmx5Jm5ic3A7c3RhcnQgZHJvcHBpbmcmbmJzcDtmbG93cyBpbiBzcGl0ZSBvZiBTUFQgb2ZmZXJp bmcgPGJyPg0KJmd0OyBwZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRoIDEwIG1zIG1vcmUg aml0dGVyID88YnI+DQomZ3Q7IDxicj4NCiZndDsgT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNs aWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4gPGJyPg0KJmd0OyBzb21ldGhpbmcm bmJzcDtuZXcgPyBXb3JzZSAuLi4gZG8gdGhleSBtZW50aW9uIHBhdGggcXVhbGl0eSBndWFyYW50 ZWVzLCA8YnI+DQomZ3Q7IHJlc291cmNlIHJlc2VydmF0aW9ucyZuYnNwOz8gSSBob3BlIG5vdC48 YnI+DQomZ3Q7IDxicj4NCiZndDsgVGh4LDxicj4NCiZndDsgUi48YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQg ODoxMCBQTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tJTIwJTBiIj5qbWhAam9lbGhhbHBlcm4uY29tDQo8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPm1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBXZWxsIGxlc3Mgc2Vy aW91cyBmb3IgVEUgU0lEcywgSSBhbSBub3Qgc3VyZSB0aGUgcHJvYmxlbSBpcyByZXN0cmljdGVk PGJyPg0KJmd0OyB0byBqdXN0IHNlcnZpY2UgU0lEcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgU3Vw cG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0aGUgcGF0aCB0byBtZWV0IHNvbWUgY29t cGxleCB0ZTxicj4NCiZndDsgb2JqZWN0aXZlLiZuYnNwOyBUaGUgYnlwYXNzIG5vZGUgaGFzIG5v IHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2U8YnI+DQomZ3Q7IGNvbnN0cmFpbnRzPGJyPg0KJmd0 OyB3ZXJlLiZuYnNwOyBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywgaXQgaXMgYmV0dGVy IHRvIGRyb3AgdGhlIHBhY2tldDxicj4NCiZndDsgdGhhbiB0byBkZWxpdmVyIGl0IG91dHNpZGUg dGhlIGVudmVsb3AuJm5ic3A7IEkgc3VzcGVjdCB0aGF0IHRoZSByaWdodDxicj4NCiZndDsgYW5z d2VyPGJyPg0KJmd0OyB0byB0aGlzIGlzICZxdW90O3RvbyBiYWQmcXVvdDsuJm5ic3A7IElmIHNv LCBhcyB3aXRoIHRoZSBkaXN0aW5jdGlvbiByZWdhcmRpbmcgc2VydmljZTxicj4NCiZndDsgbm9k ZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT88YnI+DQomZ3Q7IDxicj4NCiZndDsg WW91cnMsPGJyPg0KJmd0OyBKb2VsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDgvMy8yMDIwIDI6 MzYgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOjxicj4NCiZndDsgJmd0OyBNYWNoLCBK b2VsIGFuZCBhbGwsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCBp biBtb3N0IGNhc2VzOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAxLlRoZXJlIGlzIGNs ZWFyIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuICZxdW90O3RvcG9sb2dpY2FsJnF1b3Q7IGFuZCAm cXVvdDtzZXJ2aWNlJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IGluc3RydWN0aW9ucyBpbiBTSUQgYWR2 ZXJ0aXNlbWVudHMuIEUuZy46PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IG9JR1AgUHJl Zml4IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZpZWQgYXMgc3VjaCBpbiB0aGU8YnI+ DQomZ3Q7ICZndDsgY29ycmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMpIHJlcHJlc2VudCB0 b3BvbG9naWNhbCBpbnN0cnVjdGlvbnM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgb1Nl cnZpY2UgU0lEcyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92ZXJsYXkgU2VydmljZXM8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0Ij5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmVzcy1zcnY2LXNl cnZpY2VzLTA0PC9hPiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBkcmFmdCkgdW5zdXJw cmlzaW5nbHkgcmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9wb2xvZ2ljYWwg aW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCw8YnI+DQomZ3Q7ICZndDsgd2hpbGUgc2VnbWVu dHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMgcmVxdWlyZTxicj4NCiZndDsg YWx0ZXJuYXRpdmU8YnI+DQomZ3Q7ICZndDsgcHJvdGVjdGlvbiBtZWNoYW5pc21zLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlzIHZpZXcgc2VlbXMgdG8gYmUgYWxpZ25lZCB3aXRo IFJGQyA4NDAyPGJyPg0KJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODQwMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDI8L2E+ Jmd0OyB0aGF0IHNheXMgaW4gU2VjdGlvbiAxOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmbmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJhc2VkIGRpc3Ry aWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyB0 b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIElHUC1BZGphY2VuY3kgc2VnbWVu dCBhbmQgdGhlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNw OyBJR1AtUHJlZml4IHNlZ21lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyZuYnNwOyBJbiB0aGUgY29udGV4dCBvZiBhIEJHUC1iYXNlZCBkaXN0cmlidXRlZCBj b250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgdG9wb2xvZ2lj YWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBCR1AgcGVlcmluZyBzZWdtZW50IGFuZCB0aGU8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IEJHUC1QcmVm aXggc2VnbWVudC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSW4gdGhlIGNhc2Ugb2Yg U1ItTVBMUyB0aGlzIGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb248YnI+DQom Z3Q7IDMuNCBvZjxicj4NCiZndDsgJmd0OyB0aGUgTm9kZSBQcm90ZWN0aW9uIGZvciBTUi1URSBQ YXRoPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9u LWZvci1zci10ZS1wYXRocy0wNyNzZWN0aW9uLTMuNCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10 ZS1wYXRocy0wNyNzZWN0aW9uLTMuNDwvYT4mZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg ZHJhZnQgdGhhdCBzYXlzOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgVGhlIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoZSBw cmV2aW91cyBzZWN0aW9uczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBsYWJlbCBpbW1lZGlh dGVseSBiZWxvdzxicj4NCiZndDsgdGhlIHRvcDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBsYWJlbCBpbiB0aGUgbGFiZWwgc3RhY2sgaXMgdW5kZXJzdG9vZCBpbiB0aGUgSUdQIGRvbWFp bi4mbmJzcDsgV2hlbiB0aGU8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5i c3A7Jm5ic3A7IHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBleGNoYW5nZSBzZXJ2aWNlIGxhYmVscyB2 aWEgQkdQIG9yIHNvbWU8YnI+DQomZ3Q7IG90aGVyPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90dG9tIGxhYmVs IGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1A8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGRvbWFpbi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7Jm5ic3A7IFRoZSBlZ3Jlc3Mgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlz bXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmbmJzcDsmbmJzcDsgW1JGQzg2NzkgJmx0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODY3OSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9yZmM4Njc5PC9hPiZndDtdIGlzPGJyPg0KJmd0OyAmZ3Q7IGFwcGxpY2FibGUg dG8gdGhpcyB1c2UgY2FzZSBhbmQgbm8gYWRkaXRpb25hbCBjaGFuZ2VzPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyB3aWxsIGJlIHJlcXVpcmVkIGZvciBT UiBiYXNlZCBuZXR3b3Jrczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgc2NlbmFy aW9zIGluIHdoaWNoICZuYnNwO2RpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs 4oCdIGFuZDxicj4NCiZndDsgJmd0OyDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBicm9r ZW4gYXJlIGluZGVlZCBwcm9ibGVtYXRpYy4gRS5nLiw8YnI+DQomZ3Q7IGNvbnNpZGVyPGJyPg0K Jmd0OyAmZ3Q7IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUgU0lEIGluIHRoZSBFUk8gb2Yg YSBTUi1URSBwYXRoPGJyPg0KJmd0OyBpZGVudGlmaWVzIGE8YnI+DQomZ3Q7ICZndDsgbm9kZSB0 aGF0IGFjdHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4s PGJyPg0KJmd0OyBwcm92aWRlczxicj4NCiZndDsgJmd0OyB0aGUgZmlyZXdhbGwgc2VydmljZSB3 aXRob3V0IGFueSBkZWRpY2F0ZWQgc2VydmljZSBTSUQ8YnI+DQomZ3Q7IGlkZW50aWZ5aW5nIGl0 Ljxicj4NCiZndDsgJmd0OyBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2gg YSBub2RlIHdvdWxkIGNvbWJpbmU8YnI+DQomZ3Q7IHRvcG9sb2dpY2FsPGJyPg0KJmd0OyAmZ3Q7 IGFuZCBzZXJ2aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRp b248YnI+DQomZ3Q7IGJldHdlZW4gdGhlIHR3by48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgSSBhbSBub3Qgc3VyZSBpZiB1c2FnZSBvZiBzdWNoIOKAnGNvbWJpbmVk4oCdIFNJRHMgY291 bGQgYmUgcHJldmVudGVkPGJyPg0KJmd0OyBvciBhdDxicj4NCiZndDsgJmd0OyBsZWFzdCBkaXNj b3VyYWdlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgbm90LCBwcm92aWRpbmcg YW4gYWJpbGl0eSB0byBpZGVudGlmeSBzdWNoIFNJRHMgaW4gdGhlPGJyPg0KJmd0OyBhZHZlcnRp c2VtZW50PGJyPg0KJmd0OyAmZ3Q7IG1lY2hhbmlzbXMgd291bGQgYmUgdXNlZnVsIElNSE8uPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE15IDJjLDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBTYXNoYTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPZmZpY2U6ICs5NzIt MzkyNjYzMDI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQ2VsbDombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgKzk3Mi01NDkyNjYzMDI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgRW1haWw6IDxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbSI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PGJyPg0KJmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5tYWlsdG86 QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBG cm9tOiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUw YiI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0OyZndDsgT24gQmVoYWxmIE9mIE1hY2ggQ2hlbjxicj4NCiZndDsgJmd0OyBTZW50 OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDY6MzAgQU08YnI+DQomZ3Q7ICZndDsgVG86IEpvZWwg TS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMGIiPmpt aEBqb2VsaGFscGVybi5jb208YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20iPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7OyA8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj4NCnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0 OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3Rl Y3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IEhpIEpvZWwsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgdGhpbmsgdGhp cyBpcyBhIGdvb2QgcG9pbnQgdGhhdCBtYXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0aGU8YnI+DQom Z3Q7IHBhc3QuIEFuZDxicj4NCiZndDsgJmd0OyBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMg YSAmcXVvdDtjYW4gYmUgYnlwYXNzZWQmcXVvdDsgaW5kaWNhdGlvbiBpbiB0aGU8YnI+DQomZ3Q7 ICZndDsgcm91dGluZyBhZHZlcnRpc2VtZW50IGZvciBub3cuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IElNSE8sIHRoZSBpbmZvcm1hdGlvbiBhZHZlcnRpc2VkIGJ5IHJvdXRpbmcgaXMg bmV1dHJhbCwgc3VjaDxicj4NCiZndDsgaW5mb3JtYXRpb248YnI+DQomZ3Q7ICZndDsgKGNhbiBv ciBjYW5ub3QgYmUgYnlwYXNzZWQpIGlzIG1vcmUgcGF0aCBzcGVjaWZpYywgdGh1cyBub3JtYWxs eSB0aGU8YnI+DQomZ3Q7ICZndDsgY29udHJvbGxlciBzaG91bGQgYmUgcmVzcG9uc2libGUgZm9y IGRlY2lkaW5nIHdoZXRoZXIvd2hpY2ggU0lEPGJyPg0KJmd0OyBjYW4gYmU8YnI+DQomZ3Q7ICZn dDsgYnlwYXNzZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTWFjaDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgRnJvbTogc3ByaW5nIFs8YSBocmVmPSJtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIlM2UlMjAlM2NtYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmclM2UiPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsg Jmx0O21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+XSBPbiBCZWhhbGYgT2Yg Sm9lbCBNLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEhhbHBlcm48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBTZW50OiBNb25kYXksIEF1 Z3VzdCAzLCAyMDIwIDc6NTEgQU08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3Jn PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmcg Jmx0O21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBTdWJqZWN0OiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlv biAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IChX RyBDaGFpciBoYXQgT2ZmLCB0aGlzIGlzIG1lcmVseSBhIG5vdGUgZnJvbSBhIHNsaWdodGx5PGJy Pg0KJmd0OyBjb25mdXNlZCBXRzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7IHBhcnRpY2lwYW50Lik8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEkgaGF2ZSBiZWVuIHJl YWRpbmcgdGhlIHZhcmlvdXMgcmVwYWlyIGRyYWZ0cywgYW5kIHRoZSB2YXJpb3VzPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgbmV0d29ya3MgcHJvZ3JhbW1pbmcgYW5k IHNlcnZpY2UgcHJvZ3JhbW1pbmcgZHJhZnQsIGFuZCBJIGFtPGJyPg0KJmd0OyB0cnlpbmcgdG88 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBmaWd1cmUgb3V0IG9uZSBh c3BlY3Qgb2YgdGhlIGNvbWJpbmF0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSG93IGRv ZXMgYSBub2RlIHRoYXQgaXMgZG9pbmcgc29tZSBmb3JtIG9mIGJ5cGFzcyAoc3VwcG9zZSwgZm9y PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgc2ltcGxpY2l0eSwgaXQg aXMgTm9kZSBOMiBkZWNpZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcjxicj4NCiZndDsg YSBmYWlsZWQ8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBub2RlIE4z KSBrbm93IHRoYXQgaXQgaXMgc2FmZSB0byBkbyBzbz88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 IElmIHRoZSBwYXRoIHdhcyBqdXN0IGZvciBURSwgdGhlbiBpdCBpcyAmcXVvdDtzYWZlJnF1b3Q7 IGlmIHRoZSBuZXcgcGF0aDxicj4NCiZndDsgbWVldHM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0OyB0aGUgVEUgY3JpdGVyaWEuJm5ic3A7IG9yIG1heWJlIGl0IGlzIHNh ZmUgaWYgaXQgaXMgZXZlbiBjbG9zZSwgYXM8YnI+DQomZ3Q7IGxvbmcgYXM8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBpdCBpcyBub3QgdXNlZCBmb3IgdG9vIGxvbmcu PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBCdXQgd2hhdCBpZiB0aGUgbm9kZSB3ZXJlIGEgRmly ZXdhbGwsIGluY2x1ZGVkIHRvIG1lZXQgbGVnYWw8YnI+DQomZ3Q7ICZndDsgcmVxdWlyZW1lbnRz Pzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IE9yIHdhcyBzb21lIG90 aGVyIG5lY2Vzc2FyeSBwcm9ncmFtbWF0aWMgdHJhbnNmb3JtICh3aW5jZSB3ZSBhcmU8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBkZWxpYmVyYXRlbHkgdmFndWUgYWJv dXQgd2hhdCBub2RlcyBjYW4gZG8gd2hlbiBhc2tlZCBzdWl0YWJseS4pPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyBJcyB0aGVyZSBzb21lICZxdW90O2NhbiBiZSBieXBhc3NlZCZxdW90OyBpbmRp Y2F0aW9uIGluIHRoZSByb3V0aW5nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgYWR2ZXJ0aXNlbWVudHMgdGhhdCBJIG1pc3NlZD88YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7IFRoYW5rIHlvdSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBZ b3Vycyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBKb2VsPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IHNwcmlu ZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9h PiZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNj bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyAmbHQ7bWFpbHRv OnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2Ns aWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUz QSUyIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRl QXZQNDZIMj91PWh0dHBzJTNBJTI8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVB dlA0NkgyP3U9aHR0cHMlM0ElMjUyIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3 cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTI8L2E+Jmd0Ozxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEYlMkZ3d3cuaWV0Zi5vcmc8YnI+DQomZ3Q7 ICZsdDs8YSBocmVmPSJodHRwOi8vMkZ3d3cuaWV0Zi5vcmciPmh0dHA6Ly8yRnd3dy5pZXRmLm9y ZzwvYT4mZ3Q7JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3By aW5nQGlldGYub3JnJTBiIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPGJyPg0KPC9hPiZndDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8 L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQ NDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c3ByaW5nIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVH QzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGc3ByaW5nPC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAm Z3Q7IE5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW48YnI+DQomZ3Q7ICZndDsgaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRp b25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWw8YnI+DQomZ3Q7IGFuZC9vcjxicj4NCiZndDsg Jmd0OyBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQuIEFueSByZXZpZXcsPGJyPg0KJmd0OyAmZ3Q7IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRp c3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0PGJyPg0KJmd0OyAmZ3Q7 IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5v dCB0aGU8YnI+DQomZ3Q7IGludGVuZGVkPGJyPg0KJmd0OyAmZ3Q7IHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGw8YnI+DQom Z3Q7ICZndDsgY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3Jn PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwcmluZyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwcmluZzwvYT48YnI+DQomZ3Q7IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR03MB50560EA5D95C76F7501608FBEE4D0VI1PR03MB5056eurp_-- From nobody Mon Aug 3 15:03:13 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BD33A1111 for ; Mon, 3 Aug 2020 15:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 Y_1ixdjUidpY for ; Mon, 3 Aug 2020 15:03:08 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 EF8E73A1110 for ; Mon, 3 Aug 2020 15:03:07 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 073M25EO044886; Mon, 3 Aug 2020 18:03:07 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 32ptr3ragg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 18:03:06 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 073M35eI013937; Mon, 3 Aug 2020 18:03:06 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 073M2ws4013820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Aug 2020 18:02:59 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id B88D34009E72; Mon, 3 Aug 2020 22:02:58 +0000 (GMT) Received: from GAALPA1MSGEX1BA.ITServices.sbc.com (unknown [135.50.89.102]) by zlp30484.vci.att.com (Service) with ESMTPS id DDED94009E60; Mon, 3 Aug 2020 22:02:57 +0000 (GMT) Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BA.ITServices.sbc.com (135.50.89.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 3 Aug 2020 18:02:56 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.2044.004; Mon, 3 Aug 2020 18:02:56 -0400 From: "UTTARO, JAMES" To: Andrew Alston , "Joel M. Halpern" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfDxfCLv1oXF0SN42f+4ZUJZqkl/YsAgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgP//wUpw Date: Mon, 3 Aug 2020 22:02:56 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.145.138] x-tm-snts-smtp: D957722E445E5D8805193489F7D85412BE11883DA6E9669D447FEE39AAAE72A72 Content-Type: multipart/alternative; boundary="_000_b7823cae12cc4b999efdb1a01813edc8attcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-03_15:2020-08-03, 2020-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 clxscore=1011 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030151 Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 22:03:11 -0000 --_000_b7823cae12cc4b999efdb1a01813edc8attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KVGhhbmtzLA0KICAgICAgICAgICAgICBKaW0gVXR0YXJvDQoNCkZyb206IHNwcmluZyA8 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBbmRyZXcgQWxzdG9uDQpTZW50 OiBNb25kYXksIEF1Z3VzdCAwMywgMjAyMCA1OjQ2IFBNDQpUbzogSm9lbCBNLiBIYWxwZXJuIDxq bWhAam9lbGhhbHBlcm4uY29tPjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQpD Yzogc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rp b24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNClNvIOKAkw0KDQpPbmUgb2YgdGhlIHVz ZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2ZXJ5IG1ham9yIHVzZSBjYXNlcyBpbiBhbnkgc3ByaW5n IHRlY2hub2xvZ3kgZm9yIHVzIHJldm9sdmUgYXJvdW5kIHRoZSBmb2xsb3dpbmcNCg0KDQogIDEu ICBUaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9kZXMNCiAgMi4gIFRoZSBleHBs aWNpdCBhdm9pZGFuY2Ugb2YgY2VydGFpbiBzZWN0aW9ucyBvZiB0aGUgbmV0d29yaw0KDQpBbnl0 aGluZyB0aGF0IGNvdWxkIHJlc3VsdCBpbiB0aGF0IGV4cGxpY2l0IGF2b2lkYW5jZSBiZWluZyB2 aW9sYXRlZCDigJMgd291bGQgY3JlYXRlLCBzaGFsbCB3ZSBzYXkgc2lnbmlmaWNhbnQgcHJvYmxl bXMuDQoNCk11Y2ggb2YgdGhlIHVzZSBjYXNlIGlzIG5vdCBhIGNhc2Ugb2Ygd2hpY2ggbm9kZXMg dGhlIHBhY2tldHMgZmxvdyB0aHJvdWdoIOKAkyBidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAv IG5ldHdvcmsgc2VnbWVudHMgaXQgY2FuIG5ldmVyIHRvdWNoIG9yIGZsb3cgdGhyb3VnaC4gIEVm ZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9neSB0byBhdm9pZCBjZXJ0YWluIHRo aW5ncyBmb3Igc3BlY2lmaWMgcmVhc29ucy4NCg0KVGhpcyBpcyBhbHNvIG9uZSBvZiB0aGUgcmVh c29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwgc3RhY2tzIOKAkyB0aGlzIGtpbmQgb2Yg ZGV0YWlsZWQgcGF0aCBwcm9ncmFtbWluZyB0ZW5kcyB0byBkZWVwZW4gdGhlIHN0YWNrIGJlY2F1 c2UgeW91IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBleHBsaWNpdC4NCg0KSXQgaXMgYWJz b2x1dGVseSBjcml0aWNhbCB0byB1cyB0aGF0IHRoaXMgZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDi gJMgYW5kIHRoYXQgd2UgY2FuIGF2b2lkIHNpdHVhdGlvbnMgd2hpY2ggY291bGQgY2F1c2UgdHJh ZmZpYyB0byBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhwbGljaXRseSBhdm9pZGVkLg0KDQpJIHdp c2ggSSBjb3VsZCBiZSBtb3JlIHNwZWNpZmljIHRoYW4gdGhpcywgYnV0IGl0IGlzIHdoYXQgaXQg aXMuDQoNClRoYW5rcw0KDQpBbmRyZXcNCg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBK b2VsIE0uIEhhbHBlcm4NClNlbnQ6IE1vbmRheSwgMyBBdWd1c3QgMjAyMCAyMTozNg0KVG86IFJv YmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+ DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5 DQoNCihTaW5jZSB0aGUgdGhyZWFkIGhhcyBnb3R0ZW4gbG9uZyBlbm91Z2gsIHJlaXRlcmF0aW5n IHRoYXQgdGhpcyBpcyBhcyBhDQpwYXJ0aWNpcGFudCwgbm90IGEgV0cgY2hhaXIuKQ0KDQpZZXMs IHdlIGFyZSB0YWxraW5nIElQIG5ldHdvcmtzLiBBbmQgeWVzLCBJIGhhdmUgc2VlbiBJUCBuZXR3 b3JrcyB0aGF0DQpjaG9vc2UgdG8gZHJvcCBwYWNrZXRzLiBGb3IgYWxsIHNvcnRzIG9mIHJlYXNv bnMuDQpJIHRoaW5rIHRoZXJlIGFyZSBsaWtlbHkgb3RoZXIgcmVhc29ucyB3aHkgb25lIG1heSBu b3Qgd2FudCBhIHJhbmRvbQ0KcGF0aCByYXRoZXIgdGhhbiBhIGNob3NlbiBURSBwYXRoLiBJIHRo aW5rIGl0IGlzIGltcG9ydGFudCB3ZSBiZSBjbGVhcg0KYWJvdXQgd2hhdCBjb25zdHJhaW50cyBt YXkgYmUgLyBhcmUgdmlvbGF0ZWQgd2hlbiB3ZSB0ZWxsIHBlb3BsZSB0aGV5DQpoYXZlIHRoaXMg dG9vbCAocHJvdGVjdGl2ZSByZXJvdXRpbmcpIHRoYXQgaXMgaW50ZW5kZWQgdG8gcHJlc2VydmUg UW9TLg0KDQpMZXQncyBiZSBjbGVhci4gSSBhbSBub3QgYXJndWluZyB0aGF0IHRoaXMgaXMgbm90 IGEgZ29vZCBpZGVhLiBJdCBpcyBhDQpnb29kIGlkZWEuIEFuZCB1c2VmdWwuIEkgYW0gdHJ5aW5n IHRvIGZpZ3VyZSBvdHUgd2hhdCBjb21iaW5hdGlvbiBvZg0KYWRkaXRpb25hbCBtZWNoYW5pc21z IGFuZCBjbGVhciBkZXNjcmlwdGlvbnMgd2lsbCBsZWFkIHRvIGV2ZXJ5b25lDQpnZXR0aW5nIHRo ZSBiZWhhdmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5vdCBiZSB0aGUgYmVoYXZpb3IgdGhl eQ0KZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBiZXN0IHdlIGNhbiBkby4pDQoNCllvdXJz LA0KSm9lbA0KDQpPbiA4LzMvMjAyMCAyOjMwIFBNLCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KPiBK b2VsLA0KPg0KPiBBcmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JrcyBoZXJlID8g T3IgcGVyaGFwcyBzb21lIGhhcmQNCj4gc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2 YXRpb25zIG9yIGRldG5ldHMgPw0KPg0KPiBCZWNhdXNlIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0 IElQIG5ldHdvcmtpbmcgSSBoYXZlIHR3byBvYnNlcnZhdGlvbnM6DQo+DQo+IEEpIElmIHlvdSBu ZWVkIHRvIHRyYXZlcnNlIHZpYSBhIHNwZWNpZmljIG5vZGUgKGllLiBmaXJld2FsbCkgeW91IGJl dHRlcg0KPiBhcHBseSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4gSSBkb24ndCB0aGlu ayBJUCBlbmNhcHN1bGF0aW9uIGNhbg0KPiBiZSBoaWphY2tlZCB0b2RheSBzdWNoIHRoYXQgZGVz dGluYXRpb24gYWRkcmVzcyBvZiB0aGUgcGFja2V0IGlzIGlnbm9yZWQuDQo+DQo+IEIpIEhhdmUg eW91IHNlZW4gYW55IElQIG5ldHdvcmsgd2hlcmUgdXBvbiB0b3BvbG9neSBjaGFuZ2UgKGxpbmsg b3Igbm9kZQ0KPiBmYWlsdXJlKSB5b3Ugc3VkZGVubHkgc3RhcnQgZHJvcHBpbmcgZmxvd3MgaW4g c3BpdGUgb2YgU1BUIG9mZmVyaW5nDQo+IHBlcmhhcHMgZmV3IG1zIGxvbmdlciBwYXRoIHdpdGgg MTAgbXMgbW9yZSBqaXR0ZXIgPw0KPg0KPiBPciBhcmUgc29tZSBTUiBtYXJrZXRpbmcgc2xpZGVz IHByb21pc2UgdG8gdHVybiBJUCBuZXR3b3JrcyBpbg0KPiBzb21ldGhpbmcgbmV3ID8gV29yc2Ug Li4uIGRvIHRoZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3VhcmFudGVlcywNCj4gcmVzb3VyY2Ug cmVzZXJ2YXRpb25zID8gSSBob3BlIG5vdC4NCj4NCj4gVGh4LA0KPiBSLg0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KPiBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDg6MTAgUE0gSm9lbCBNLiBI YWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20l MjAlMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCj4NCj4gV2VsbCBs ZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90IHN1cmUgdGhlIHByb2JsZW0gaXMgcmVz dHJpY3RlZA0KPiB0byBqdXN0IHNlcnZpY2UgU0lEcy4NCj4NCj4gU3VwcG9zZSB0aGF0IHRoZSBQ Q0UgaGFzIHNwZWNpZmllZCB0aGUgcGF0aCB0byBtZWV0IHNvbWUgY29tcGxleCB0ZQ0KPiBvYmpl Y3RpdmUuICBUaGUgYnlwYXNzIG5vZGUgaGFzIG5vIHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2UN Cj4gY29uc3RyYWludHMNCj4gd2VyZS4gIEFuZCBmb3Igc29tZSBraW5kcyBvZiB0cmFmZmljLCBp dCBpcyBiZXR0ZXIgdG8gZHJvcCB0aGUgcGFja2V0DQo+IHRoYW4gdG8gZGVsaXZlciBpdCBvdXRz aWRlIHRoZSBlbnZlbG9wLiAgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0DQo+IGFuc3dlcg0KPiB0 byB0aGlzIGlzICJ0b28gYmFkIi4gIElmIHNvLCBhcyB3aXRoIHRoZSBkaXN0aW5jdGlvbiByZWdh cmRpbmcgc2VydmljZQ0KPiBub2Rlcywgd2Ugc2hvdWxkIHNheSBzbywgc2hvdWxkbid0IHdlPw0K Pg0KPiBZb3VycywNCj4gSm9lbA0KPg0KPiBPbiA4LzMvMjAyMCAyOjM2IEFNLCBBbGV4YW5kZXIg VmFpbnNodGVpbiB3cm90ZToNCj4gPiBNYWNoLCBKb2VsIGFuZCBhbGwsDQo+ID4NCj4gPiBJIHRo aW5rIHRoYXQgaW4gbW9zdCBjYXNlczoNCj4gPg0KPiA+IDEuVGhlcmUgaXMgY2xlYXIgZGlmZmVy ZW50aWF0aW9uIGJldHdlZW4gInRvcG9sb2dpY2FsIiBhbmQgInNlcnZpY2UiDQo+ID4gaW5zdHJ1 Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5nLjoNCj4gPg0KPiA+IG9JR1AgUHJlZml4 IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZpZWQgYXMgc3VjaCBpbiB0aGUNCj4gPiBj b3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50cykgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGlu c3RydWN0aW9ucw0KPiA+DQo+ID4gb1NlcnZpY2UgU0lEcyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQ LUJhc2VkIE92ZXJsYXkgU2VydmljZXMNCj4gPg0KPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNDxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmll dGYub3JnX2RvY19odG1sX2RyYWZ0LTJEaWV0Zi0yRGJlc3MtMkRzcnY2LTJEc2VydmljZXMtMkQw NCZkPUR3TUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1zN1p6QjRKYlB2M25ZdW9TeDVH eThRJm09Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5TSZzPU45OEI5 d3ZzX3FReEdOX1EtYnBjR0dCMHU4c0xleHFQZ05ETElNamx4azAmZT0+Pg0KPg0KPiA+IGRyYWZ0 KSB1bnN1cnByaXNpbmdseSByZXByZXNlbnQg4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnMNCj4g Pg0KPiA+IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb25z IGNhbiBiZSBieXBhc3NlZCwNCj4gPiB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2VudCBzZXJ2 aWNlIGluc3RydWN0aW9ucyByZXF1aXJlDQo+IGFsdGVybmF0aXZlDQo+ID4gcHJvdGVjdGlvbiBt ZWNoYW5pc21zLg0KPiA+DQo+ID4gVGhpcyB2aWV3IHNlZW1zIHRvIGJlIGFsaWduZWQgd2l0aCBS RkMgODQwMg0KPiA+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQwMjxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYu b3JnX2h0bWxfcmZjODQwMiZkPUR3TUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1zN1p6 QjRKYlB2M25ZdW9TeDVHeThRJm09Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHowY3Nu QkYxbEE5TSZzPTc5LVZZeWlRdnBjVk1OU0ZYQlJwSlFQajdSMkJqUld5SXg3TnJDR3IzNWMmZT0+ PiB0aGF0IHNheXMgaW4gU2VjdGlvbiAxOg0KPiA+DQo+ID4gICAgIEluIHRoZSBjb250ZXh0IG9m IGFuIElHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28NCj4gPg0KPiA+IHRv cG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgSUdQLUFkamFjZW5jeSBzZWdtZW50 IGFuZCB0aGUNCj4gPg0KPiA+ICAgICBJR1AtUHJlZml4IHNlZ21lbnQuDQo+ID4NCj4gPiAgICAg SW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwg dHdvDQo+ID4NCj4gPiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIEJHUCBw ZWVyaW5nIHNlZ21lbnQgYW5kIHRoZQ0KPiA+DQo+ID4gICAgIEJHUC1QcmVmaXggc2VnbWVudC4N Cj4gPg0KPiA+IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMgdGhpcyBkaWZmZXJlbnRpYXRpb24gaXMg YXNzdW1lZCBpbiBTZWN0aW9uDQo+IDMuNCBvZg0KPiA+IHRoZSBOb2RlIFByb3RlY3Rpb24gZm9y IFNSLVRFIFBhdGgNCj4gPg0KPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyNz ZWN0aW9uLTMuNDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19odG1sX2RyYWZ0LTJEaGVnZGUtMkRzcHJp bmctMkRub2RlLTJEcHJvdGVjdGlvbi0yRGZvci0yRHNyLTJEdGUtMkRwYXRocy0yRDA3LTIzc2Vj dGlvbi0yRDMuNCZkPUR3TUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1zN1p6QjRKYlB2 M25ZdW9TeDVHeThRJm09Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5 TSZzPVZVVXZiVGNsS1BBendDYUJqX3JBRWYwM19KYVhyOEo5ekVkOE9DdWlURHMmZT0+Pg0KPg0K PiA+IGRyYWZ0IHRoYXQgc2F5czoNCj4gPg0KPiA+ICAgICBUaGUgbm9kZSBwcm90ZWN0aW9uIG1l Y2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb25zDQo+ID4NCj4gPiAgICAg ZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBsYWJlbCBpbW1lZGlhdGVseSBiZWxv dw0KPiB0aGUgdG9wDQo+ID4NCj4gPiBsYWJlbCBpbiB0aGUgbGFiZWwgc3RhY2sgaXMgdW5kZXJz dG9vZCBpbiB0aGUgSUdQIGRvbWFpbi4gIFdoZW4gdGhlDQo+ID4NCj4gPiAgICAgcHJvdmlkZXIg ZWRnZSByb3V0ZXJzIGV4Y2hhbmdlIHNlcnZpY2UgbGFiZWxzIHZpYSBCR1Agb3Igc29tZQ0KPiBv dGhlcg0KPiA+DQo+ID4gICAgIG5vbi1JR1AgbWVjaGFuaXNtIHRoZSBib3R0b20gbGFiZWwgaXMg bm90IHVuZGVyc3Rvb2QgaW4gdGhlIElHUA0KPiA+DQo+ID4gICAgIGRvbWFpbi4NCj4gPg0KPiA+ ICAgICBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0 aGUgZHJhZnQNCj4gPg0KPiA+ICAgICBbUkZDODY3OSA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9yZmM4Njc5PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2h0bWxfcmZjODY3OSZk PUR3TUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1zN1p6QjRKYlB2M25ZdW9TeDVHeThR Jm09Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5TSZzPW1GcW1yMVVL R3RJLUVCWlpSWmZndVhRTkRwcEFaUTltSlB0Qk9YUFBvckkmZT0+Pl0gaXMNCj4gPiBhcHBsaWNh YmxlIHRvIHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdlcw0KPiA+DQo+ID4g ICAgIHdpbGwgYmUgcmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzDQo+ID4NCj4gPiBUaGUg c2NlbmFyaW9zIGluIHdoaWNoICBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiDigJx0b3BvbG9naWNh bOKAnSBhbmQNCj4gPiDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBicm9rZW4gYXJlIGlu ZGVlZCBwcm9ibGVtYXRpYy4gRS5nLiwNCj4gY29uc2lkZXINCj4gPiB0aGUgdXNlIGNhc2UgaW4g d2hpY2ggYSBOb2RlIFNJRCBpbiB0aGUgRVJPIG9mIGEgU1ItVEUgcGF0aA0KPiBpZGVudGlmaWVz IGENCj4gPiBub2RlIHRoYXQgYWN0cyBhcyBhIGZpcmV3YWxsIGZvciBhbGwgcGFja2V0cyBpdCBy ZWNlaXZlcywgaS5lLiwNCj4gcHJvdmlkZXMNCj4gPiB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRo b3V0IGFueSBkZWRpY2F0ZWQgc2VydmljZSBTSUQNCj4gaWRlbnRpZnlpbmcgaXQuDQo+ID4gT25l IGNvdWxkIHNheSB0aGF0IHRoZSBOb2RlIFNJRCBvZiBzdWNoIGEgbm9kZSB3b3VsZCBjb21iaW5l DQo+IHRvcG9sb2dpY2FsDQo+ID4gYW5kIHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHRodXMgYnJlYWtp bmcgdGhlIGRpZmZlcmVudGlhdGlvbg0KPiBiZXR3ZWVuIHRoZSB0d28uDQo+ID4NCj4gPiBJIGFt IG5vdCBzdXJlIGlmIHVzYWdlIG9mIHN1Y2gg4oCcY29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBw cmV2ZW50ZWQNCj4gb3IgYXQNCj4gPiBsZWFzdCBkaXNjb3VyYWdlZC4NCj4gPg0KPiA+IElmIG5v dCwgcHJvdmlkaW5nIGFuIGFiaWxpdHkgdG8gaWRlbnRpZnkgc3VjaCBTSURzIGluIHRoZQ0KPiBh ZHZlcnRpc2VtZW50DQo+ID4gbWVjaGFuaXNtcyB3b3VsZCBiZSB1c2VmdWwgSU1ITy4NCj4gPg0K PiA+IE15IDJjLA0KPiA+DQo+ID4gU2FzaGENCj4gPg0KPiA+IE9mZmljZTogKzk3Mi0zOTI2NjMw Mg0KPiA+DQo+ID4gQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPiA+DQo+ID4gRW1haWw6IEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbT4NCj4gPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc3ByaW5n IDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y ZyUwYj4+IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFj aCBDaGVuDQo+ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMwIEFNDQo+ID4gVG86 IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tJTBiPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj47IHNwcmluZ0BpZXRm Lm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4g PiBTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBh cHBsaWNhYmlsaXR5DQo+ID4NCj4gPiBIaSBKb2VsLA0KPiA+DQo+ID4gSSB0aGluayB0aGlzIGlz IGEgZ29vZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZQ0KPiBwYXN0LiBB bmQNCj4gPiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAiY2FuIGJlIGJ5cGFzc2VkIiBp bmRpY2F0aW9uIGluIHRoZQ0KPiA+IHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCBmb3Igbm93Lg0KPiA+ DQo+ID4gSU1ITywgdGhlIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgYnkgcm91dGluZyBpcyBuZXV0 cmFsLCBzdWNoDQo+IGluZm9ybWF0aW9uDQo+ID4gKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQp IGlzIG1vcmUgcGF0aCBzcGVjaWZpYywgdGh1cyBub3JtYWxseSB0aGUNCj4gPiBjb250cm9sbGVy IHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBTSUQNCj4g Y2FuIGJlDQo+ID4gYnlwYXNzZWQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4NCj4gPiBN YWNoDQo+ID4NCj4gPiAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+DQo+ID4gID4g RnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPG1haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBi JTNlJTIwJTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTNlPl0gT24gQmVoYWxmIE9m IEpvZWwgTS4NCj4gPg0KPiA+ICA+IEhhbHBlcm4NCj4gPg0KPiA+ICA+IFNlbnQ6IE1vbmRheSwg QXVndXN0IDMsIDIwMjAgNzo1MSBBTQ0KPiA+DQo+ID4gID4gVG86IHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4gPg0KPiA+ICA+IFN1Ympl Y3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eQ0KPiA+DQo+ID4gID4NCj4gPg0KPiA+ICA+IChXRyBDaGFpciBoYXQgT2ZmLCB0aGlzIGlzIG1l cmVseSBhIG5vdGUgZnJvbSBhIHNsaWdodGx5DQo+IGNvbmZ1c2VkIFdHDQo+ID4NCj4gPiAgPiBw YXJ0aWNpcGFudC4pDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gSSBoYXZlIGJlZW4gcmVhZGlu ZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXMNCj4gPg0KPiA+ICA+ IG5ldHdvcmtzIHByb2dyYW1taW5nIGFuZCBzZXJ2aWNlIHByb2dyYW1taW5nIGRyYWZ0LCBhbmQg SSBhbQ0KPiB0cnlpbmcgdG8NCj4gPg0KPiA+ICA+IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0 aGUgY29tYmluYXRpb24uDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gSG93IGRvZXMgYSBub2Rl IHRoYXQgaXMgZG9pbmcgc29tZSBmb3JtIG9mIGJ5cGFzcyAoc3VwcG9zZSwgZm9yDQo+ID4NCj4g PiAgPiBzaW1wbGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4 dCBTSUQgZm9yDQo+IGEgZmFpbGVkDQo+ID4NCj4gPiAgPiBub2RlIE4zKSBrbm93IHRoYXQgaXQg aXMgc2FmZSB0byBkbyBzbz8NCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBJZiB0aGUgcGF0aCB3 YXMganVzdCBmb3IgVEUsIHRoZW4gaXQgaXMgInNhZmUiIGlmIHRoZSBuZXcgcGF0aA0KPiBtZWV0 cw0KPiA+DQo+ID4gID4gdGhlIFRFIGNyaXRlcmlhLiAgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBp dCBpcyBldmVuIGNsb3NlLCBhcw0KPiBsb25nIGFzDQo+ID4NCj4gPiAgPiBpdCBpcyBub3QgdXNl ZCBmb3IgdG9vIGxvbmcuDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gQnV0IHdoYXQgaWYgdGhl IG5vZGUgd2VyZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsDQo+ID4gcmVxdWly ZW1lbnRzPw0KPiA+DQo+ID4gID4gT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1t YXRpYyB0cmFuc2Zvcm0gKHdpbmNlIHdlIGFyZQ0KPiA+DQo+ID4gID4gZGVsaWJlcmF0ZWx5IHZh Z3VlIGFib3V0IHdoYXQgbm9kZXMgY2FuIGRvIHdoZW4gYXNrZWQgc3VpdGFibHkuKQ0KPiA+DQo+ ID4gID4NCj4gPg0KPiA+ICA+IElzIHRoZXJlIHNvbWUgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNh dGlvbiBpbiB0aGUgcm91dGluZw0KPiA+DQo+ID4gID4gYWR2ZXJ0aXNlbWVudHMgdGhhdCBJIG1p c3NlZD8NCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBUaGFuayB5b3UsDQo+ID4NCj4gPiAgPiBZ b3VycywNCj4gPg0KPiA+ICA+IEpvZWwNCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gID4gc3By aW5nIG1haWxpbmcgbGlzdA0KPiA+DQo+ID4gID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiA8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIw JTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+Pg0KPiA+DQo+ID4gID4NCj4gPg0KPiBodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRw cyUzQSUyPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fY2xpY2t0aW1lLnN5bWFudGVjLmNvbV8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMi0zRnUt M0RodHRwcy0yNTNBLTI1MiZkPUR3TUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1zN1p6 QjRKYlB2M25ZdW9TeDVHeThRJm09Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHowY3Nu QkYxbEE5TSZzPTdJUm9kdWx4cUhZdnl2S0VLU1h4bFlGa2VfNnVvN0J4VmJjWDlrbGM3NTgmZT0+ DQo+ID4NCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVH QzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX2NsaWNrdGltZS5zeW1hbnRlYy5jb21fMzY3cWhVNEtpVWt6 Vzl1R0M0ZUF2UDQ2SDItM0Z1LTNEaHR0cHMtMjUzQS0yNTI1MiZkPUR3TUdhUSZjPUxGWVotbzlf SFVNZU1UU1FpY3ZqSWcmcj1zN1p6QjRKYlB2M25ZdW9TeDVHeThRJm09Rm9tTEJ1TVVjVlFmMnEy cm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5TSZzPUgwZkJqUFRseXJTeHpfaERJdUY3enE4eFRG X0hqeFFLMUgteTIwUktraFUmZT0+Pg0KPiA+DQo+ID4gID4gRiUyRnd3dy5pZXRmLm9yZzxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmlldGYu b3JnJmQ9RHdRR2FRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPXM3WnpCNEpiUHYzbll1b1N4 NUd5OFEmbT1Gb21MQnVNVWNWUWYycTJyb2hGQ2J4U29qcTBZSWVEejBjc25CRjFsQTlNJnM9NHgt c3MtSDVVdHJpRFpKTFdQQkYwOHVDa3JpX0h3aklPbnlvUmdjcnVjcyZlPT4NCj4gPGh0dHA6Ly8y Rnd3dy5pZXRmLm9yZzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fMkZ3d3cuaWV0Zi5vcmcmZD1Ed01HYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2akln JnI9czdaekI0SmJQdjNuWXVvU3g1R3k4USZtPUZvbUxCdU1VY1ZRZjJxMnJvaEZDYnhTb2pxMFlJ ZUR6MGNzbkJGMWxBOU0mcz1LQ25lNDV0SXFRdmY2MUgtSENtdU9yMWtrOU1Nd1RXcjdTaXlVbFlY ZUJNJmU9Pj4lMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcNCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBzcHJpbmcg bWFpbGluZyBsaXN0DQo+ID4NCj4gPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUwYj4+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCj4g Pg0KPiA+DQo+IGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVH QzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGc3ByaW5nPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fY2xpY2t0aW1lLnN5bWFudGVjLmNvbV8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZI Mi0zRnUtM0RodHRwcy0yNTNBLTI1MkYtMjUyRnd3dy5pZXRmLm9yZy0yNTJGbWFpbG1hbi0yNTJG bGlzdGluZm8tMjUyRnNwcmluZyZkPUR3TUdhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1z N1p6QjRKYlB2M25ZdW9TeDVHeThRJm09Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHow Y3NuQkYxbEE5TSZzPUJxRUVjT2ZoNkFnOTN5elQ3dWNuOGdfWHNfN1I4RWtHNEVSMHFOcnlyNU0m ZT0+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gTm90aWNlOiBU aGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0KPiA+ IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMgY29uZmlk ZW50aWFsDQo+IGFuZC9vcg0KPiA+IHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywNCj4gPiBkaXNjbG9zdXJlLCByZWxpYW5j ZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dA0KPiA+IGV4 cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0 aGUNCj4gaW50ZW5kZWQNCj4gPiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsDQo+ID4gY29waWVzLCBpbmNsdWRpbmcgYW55 IGF0dGFjaG1lbnRzLg0KPiA+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzcHJpbmcgbWFpbGlu ZyBsaXN0DQo+ID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWls dG86c3ByaW5nQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc3ByaW5nJmQ9RHdNR2FRJmM9 TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPXM3WnpCNEpiUHYzbll1b1N4NUd5OFEmbT1Gb21MQnVN VWNWUWYycTJyb2hGQ2J4U29qcTBZSWVEejBjc25CRjFsQTlNJnM9YlBtX3dQZWZVUlpiU1ZfZ3BW RmlEdk5qZlZJWVNiSHR4NFNSRllBSDNpZyZlPT4NCj4gPg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zcHJpbmcmZD1Ed01HYVEmYz1MRllaLW85X0hVTWVN VFNRaWN2aklnJnI9czdaekI0SmJQdjNuWXVvU3g1R3k4USZtPUZvbUxCdU1VY1ZRZjJxMnJvaEZD YnhTb2pxMFlJZUR6MGNzbkJGMWxBOU0mcz1iUG1fd1BlZlVSWmJTVl9ncFZGaUR2TmpmVklZU2JI dHg0U1JGWUFIM2lnJmU9Pg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NwcmluZyZkPUR3TUdhUSZjPUxGWVot bzlfSFVNZU1UU1FpY3ZqSWcmcj1zN1p6QjRKYlB2M25ZdW9TeDVHeThRJm09Rm9tTEJ1TVVjVlFm MnEycm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5TSZzPWJQbV93UGVmVVJaYlNWX2dwVkZpRHZO amZWSVlTYkh0eDRTUkZZQUgzaWcmZT0+DQo= --_000_b7823cae12cc4b999efdb1a01813edc8attcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7DQoJZm9u dC13ZWlnaHQ6Ym9sZDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9u ZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjE2OTA5OTcwMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzOTQ3 MjM3OTA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDox MTcyMzc4NTkyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxMDM3NzIyNjkyIC0xMjAyNTQzMTg4IDUzNjg3MDkzNyA1MzY4NzA5MzkgNTM2ODcwOTI3IDUz Njg3MDkzNyA1MzY4NzA5MzkgNTM2ODcwOTI3IDUzNjg3MDkzNyA1MzY4NzA5Mzk7fQ0KQGxpc3Qg bDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10ZXh0OiIlMVwuXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxl dmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3MDMwQTAi PiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjojNzAzMEEwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSmltIFV0dGFy bzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2I+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBzcHJpbmcgJmx0O3NwcmluZy1ib3VuY2VzQGll dGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5BbmRyZXcgQWxzdG9uPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXVndXN0IDAzLCAyMDIwIDU6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IEpv ZWwgTS4gSGFscGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7IFJvYmVydCBSYXN6dWsg Jmx0O3JvYmVydEByYXN6dWsubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gc3ByaW5nQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRl dGVybWluaW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvIOKAkyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG9mIHRoZSB1c2UgY2Fz ZXMsIGluIGZhY3QsIHNvbWUgdmVyeSBtYWpvciB1c2UgY2FzZXMgaW4gYW55IHNwcmluZyB0ZWNo bm9sb2d5IGZvciB1cyByZXZvbHZlIGFyb3VuZCB0aGUgZm9sbG93aW5nPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+ VGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIG5vZGVzPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMSBsZXZlbDEgbGZvMyI+VGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIHNlY3Rp b25zIG9mIHRoZSBuZXR3b3JrPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueXRoaW5n IHRoYXQgY291bGQgcmVzdWx0IGluIHRoYXQgZXhwbGljaXQgYXZvaWRhbmNlIGJlaW5nIHZpb2xh dGVkIOKAkyB3b3VsZCBjcmVhdGUsIHNoYWxsIHdlIHNheSBzaWduaWZpY2FudCBwcm9ibGVtcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXVjaCBvZiB0aGUgdXNlIGNhc2UgaXMgbm90IGEgY2Fz ZSBvZiB3aGljaCBub2RlcyB0aGUgcGFja2V0cyBmbG93IHRocm91Z2gg4oCTIGJ1dCByYXRoZXIg 4oCTIHdoaWNoIG5vZGVzIC8gbmV0d29yayBzZWdtZW50cyBpdCBjYW4gbmV2ZXIgdG91Y2ggb3Ig ZmxvdyB0aHJvdWdoLiZuYnNwOyBFZmZlY3RpdmVseSwgdG8gYmUgdXNlZCBhcyBhIHRlY2hub2xv Z3kgdG8gYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIG5lZWRp bmcgc3VjaCBkZWVwIGxhYmVsIHN0YWNrcyDigJMgdGhpcyBraW5kIG9mIGRldGFpbGVkIHBhdGgg cHJvZ3JhbW1pbmcgdGVuZHMgdG8gZGVlcGVuIHRoZSBzdGFjayBiZWNhdXNlIHlvdSBzb21ldGlt ZXMgaGF2ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IGlzIGFic29sdXRlbHkgY3JpdGljYWwgdG8gdXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMg dGhlcmUg4oCTIGFuZCB0aGF0IHdlIGNhbiBhdm9pZCBzaXR1YXRpb25zIHdoaWNoIGNvdWxkIGNh dXNlIHRyYWZmaWMgdG8gYWNjaWRlbnRseSBoaXQgdGhpbmdzIGV4cGxpY2l0bHkgYXZvaWRlZC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3aXNoIEkgY291bGQgYmUgbW9yZSBzcGVjaWZpYyB0 aGFuIHRoaXMsIGJ1dCBpdCBpcyB3aGF0IGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmV3PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj5Gcm9t OjwvYj4gc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmci PnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9l bCBNLiBIYWxwZXJuPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgMyBBdWd1c3QgMjAyMCAyMToz Njxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVy dEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWlu aW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KFNpbmNl IHRoZSB0aHJlYWQgaGFzIGdvdHRlbiBsb25nIGVub3VnaCwgcmVpdGVyYXRpbmcgdGhhdCB0aGlz IGlzIGFzIGENCjxicj4NCnBhcnRpY2lwYW50LCBub3QgYSBXRyBjaGFpci4pPGJyPg0KPGJyPg0K WWVzLCB3ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAg bmV0d29ya3MgdGhhdCA8YnI+DQpjaG9vc2UgdG8gZHJvcCBwYWNrZXRzLiBGb3IgYWxsIHNvcnRz IG9mIHJlYXNvbnMuPGJyPg0KSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMg d2h5IG9uZSBtYXkgbm90IHdhbnQgYSByYW5kb20gPGJyPg0KcGF0aCByYXRoZXIgdGhhbiBhIGNo b3NlbiBURSBwYXRoLiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB3ZSBiZSBjbGVhciA8YnI+DQph Ym91dCB3aGF0IGNvbnN0cmFpbnRzIG1heSBiZSAvIGFyZSB2aW9sYXRlZCB3aGVuIHdlIHRlbGwg cGVvcGxlIHRoZXkgPGJyPg0KaGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0 aGF0IGlzIGludGVuZGVkIHRvIHByZXNlcnZlIFFvUy48YnI+DQo8YnI+DQpMZXQncyBiZSBjbGVh ci4gSSBhbSBub3QgYXJndWluZyB0aGF0IHRoaXMgaXMgbm90IGEgZ29vZCBpZGVhLiBJdCBpcyBh IDxicj4NCmdvb2QgaWRlYS4gQW5kIHVzZWZ1bC4gSSBhbSB0cnlpbmcgdG8gZmlndXJlIG90dSB3 aGF0IGNvbWJpbmF0aW9uIG9mIDxicj4NCmFkZGl0aW9uYWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIg ZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVyeW9uZSA8YnI+DQpnZXR0aW5nIHRoZSBiZWhh dmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5vdCBiZSB0aGUgYmVoYXZpb3IgdGhleSA8YnI+ DQpkZXNpcmUsIGJ1dCBzb21ldGltZXMgaXMgdGhlIGJlc3Qgd2UgY2FuIGRvLik8YnI+DQo8YnI+ DQpZb3Vycyw8YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gOC8zLzIwMjAgMjozMCBQTSwgUm9iZXJ0 IFJhc3p1ayB3cm90ZTo8YnI+DQomZ3Q7IEpvZWwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFyZSB3 ZSBzdGlsbCB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtzJm5ic3A7aGVyZSA/IE9yIHBlcmhhcHMg c29tZSBoYXJkIDxicj4NCiZndDsgc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRp b25zIG9yIGRldG5ldHMgPzxicj4NCiZndDsgPGJyPg0KJmd0OyBCZWNhdXNlJm5ic3A7aWYgd2Ug YXJlIHRhbGtpbmcmbmJzcDthYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d28gb2JzZXJ2YXRp b25zOjxicj4NCiZndDsgPGJyPg0KJmd0OyBBKSBJZiB5b3UgbmVlZCB0byB0cmF2ZXJzZSB2aWEg YSBzcGVjaWZpYyBub2RlIChpZS4gZmlyZXdhbGwpIHlvdSBiZXR0ZXIgPGJyPg0KJmd0OyBhcHBs eSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4gSSBkb24ndCB0aGluayBJUCBlbmNhcHN1 bGF0aW9uJm5ic3A7Y2FuIDxicj4NCiZndDsgYmUgaGlqYWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRl c3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpcyBpZ25vcmVkLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBCKSBIYXZlIHlvdSBzZWVuIGFueSBJUCBuZXR3b3JrIHdoZXJlIHVwb24gdG9wb2xv Z3kgY2hhbmdlIChsaW5rIG9yIG5vZGUgPGJyPg0KJmd0OyBmYWlsdXJlKSB5b3Ugc3VkZGVubHkm bmJzcDtzdGFydCBkcm9wcGluZyZuYnNwO2Zsb3dzIGluIHNwaXRlIG9mIFNQVCBvZmZlcmluZyA8 YnI+DQomZ3Q7IHBlcmhhcHMgZmV3IG1zIGxvbmdlciBwYXRoIHdpdGggMTAgbXMgbW9yZSBqaXR0 ZXIgPzxicj4NCiZndDsgPGJyPg0KJmd0OyBPciBhcmUgc29tZSBTUiBtYXJrZXRpbmcgc2xpZGVz IHByb21pc2UgdG8gdHVybiBJUCBuZXR3b3JrcyBpbiA8YnI+DQomZ3Q7IHNvbWV0aGluZyZuYnNw O25ldyA/IFdvcnNlIC4uLiBkbyB0aGV5IG1lbnRpb24gcGF0aCBxdWFsaXR5IGd1YXJhbnRlZXMs IDxicj4NCiZndDsgcmVzb3VyY2UgcmVzZXJ2YXRpb25zJm5ic3A7PyBJIGhvcGUgbm90Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBUaHgsPGJyPg0KJmd0OyBSLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gTW9uLCBBdWcgMywgMjAyMCBhdCA4OjEw IFBNIEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20lMjAlMGIiPmptaEBqb2VsaGFscGVybi5jb20NCjxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208 L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlbGwgbGVzcyBzZXJpb3Vz IGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRoZSBwcm9ibGVtIGlzIHJlc3RyaWN0ZWQ8YnI+ DQomZ3Q7IHRvIGp1c3Qgc2VydmljZSBTSURzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdXBwb3Nl IHRoYXQgdGhlIFBDRSBoYXMgc3BlY2lmaWVkIHRoZSBwYXRoIHRvIG1lZXQgc29tZSBjb21wbGV4 IHRlPGJyPg0KJmd0OyBvYmplY3RpdmUuJm5ic3A7IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8gd2F5 IG9mIGtub3dpbmcgd2hhdCB0aG9zZTxicj4NCiZndDsgY29uc3RyYWludHM8YnI+DQomZ3Q7IHdl cmUuJm5ic3A7IEFuZCBmb3Igc29tZSBraW5kcyBvZiB0cmFmZmljLCBpdCBpcyBiZXR0ZXIgdG8g ZHJvcCB0aGUgcGFja2V0PGJyPg0KJmd0OyB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lkZSB0aGUg ZW52ZWxvcC4mbmJzcDsgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0PGJyPg0KJmd0OyBhbnN3ZXI8 YnI+DQomZ3Q7IHRvIHRoaXMgaXMgJnF1b3Q7dG9vIGJhZCZxdW90Oy4mbmJzcDsgSWYgc28sIGFz IHdpdGggdGhlIGRpc3RpbmN0aW9uIHJlZ2FyZGluZyBzZXJ2aWNlPGJyPg0KJmd0OyBub2Rlcywg d2Ugc2hvdWxkIHNheSBzbywgc2hvdWxkbid0IHdlPzxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3Vy cyw8YnI+DQomZ3Q7IEpvZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gOC8zLzIwMjAgMjozNiBB TSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IE1hY2gsIEpvZWwg YW5kIGFsbCw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGF0IGluIG1v c3QgY2FzZXM6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDEuVGhlcmUgaXMgY2xlYXIg ZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gJnF1b3Q7dG9wb2xvZ2ljYWwmcXVvdDsgYW5kICZxdW90 O3NlcnZpY2UmcXVvdDs8YnI+DQomZ3Q7ICZndDsgaW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRp c2VtZW50cy4gRS5nLjo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgb0lHUCBQcmVmaXgg Tm9kZSBTSURzIElHUCBBZGotU0lEcyAoaWRlbnRpZmllZCBhcyBzdWNoIGluIHRoZTxicj4NCiZn dDsgJmd0OyBjb3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50cykgcmVwcmVzZW50IHRvcG9s b2dpY2FsIGluc3RydWN0aW9uczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBvU2Vydmlj ZSBTSURzIGZvciBTUnY2IChzZWUgU1J2NiBCR1AtQmFzZWQgT3ZlcmxheSBTZXJ2aWNlczxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2h0 bWxfZHJhZnQtMkRpZXRmLTJEYmVzcy0yRHNydjYtMkRzZXJ2aWNlcy0yRDA0JmFtcDtkPUR3TUdh USZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPXM3WnpCNEpiUHYzbll1b1N4NUd5 OFEmYW1wO209Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5TSZhbXA7 cz1OOThCOXd2c19xUXhHTl9RLWJwY0dHQjB1OHNMZXhxUGdORExJTWpseGswJmFtcDtlPSI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1z ZXJ2aWNlcy0wNDwvYT4mZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgZHJhZnQpIHVuc3Vy cHJpc2luZ2x5IHJlcHJlc2VudCDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9uczxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAyLlNlZ21lbnRzIHRoYXQgcmVwcmVzZW50IHRvcG9sb2dpY2Fs IGluc3RydWN0aW9ucyBjYW4gYmUgYnlwYXNzZWQsPGJyPg0KJmd0OyAmZ3Q7IHdoaWxlIHNlZ21l bnRzIHRoYXQgcmVwcmVzZW50IHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHJlcXVpcmU8YnI+DQomZ3Q7 IGFsdGVybmF0aXZlPGJyPg0KJmd0OyAmZ3Q7IHByb3RlY3Rpb24gbWVjaGFuaXNtcy48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhpcyB2aWV3IHNlZW1zIHRvIGJlIGFsaWduZWQgd2l0 aCBSRkMgODQwMjxicj4NCiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3Jm Yzg0MDImYW1wO2Q9RHdNR2FRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9czda ekI0SmJQdjNuWXVvU3g1R3k4USZhbXA7bT1Gb21MQnVNVWNWUWYycTJyb2hGQ2J4U29qcTBZSWVE ejBjc25CRjFsQTlNJmFtcDtzPTc5LVZZeWlRdnBjVk1OU0ZYQlJwSlFQajdSMkJqUld5SXg3TnJD R3IzNWMmYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQwMjwvYT4mZ3Q7 DQogdGhhdCBzYXlzIGluIFNlY3Rpb24gMTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7Jm5ic3A7IEluIHRoZSBjb250ZXh0IG9mIGFuIElHUC1iYXNlZCBkaXN0cmli dXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgdG9w b2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNlZ21lbnQg YW5kIHRoZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsg SUdQLVByZWZpeCBzZWdtZW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm bmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQgZGlzdHJpYnV0ZWQgY29u dHJvbCBwbGFuZSwgdHdvPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHRvcG9sb2dpY2Fs IHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBhbmQgdGhlPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBCR1AtUHJlZml4 IHNlZ21lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEluIHRoZSBjYXNlIG9mIFNS LU1QTFMgdGhpcyBkaWZmZXJlbnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uPGJyPg0KJmd0 OyAzLjQgb2Y8YnI+DQomZ3Q7ICZndDsgdGhlIE5vZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0 aDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdf ZG9jX2h0bWxfZHJhZnQtMkRoZWdkZS0yRHNwcmluZy0yRG5vZGUtMkRwcm90ZWN0aW9uLTJEZm9y LTJEc3ItMkR0ZS0yRHBhdGhzLTJEMDctMjNzZWN0aW9uLTJEMy40JmFtcDtkPUR3TUdhUSZhbXA7 Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPXM3WnpCNEpiUHYzbll1b1N4NUd5OFEmYW1w O209Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5TSZhbXA7cz1WVVV2 YlRjbEtQQXp3Q2FCal9yQUVmMDNfSmFYcjhKOXpFZDhPQ3VpVERzJmFtcDtlPSI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90 ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyNzZWN0aW9uLTMuNDwvYT4mZ3Q7PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZndDsgZHJhZnQgdGhhdCBzYXlzOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgVGhlIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVz Y3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRo ZSBsYWJlbCBpbW1lZGlhdGVseSBiZWxvdzxicj4NCiZndDsgdGhlIHRvcDxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBsYWJlbCBpbiB0aGUgbGFiZWwgc3RhY2sgaXMgdW5kZXJzdG9vZCBp biB0aGUgSUdQIGRvbWFpbi4mbmJzcDsgV2hlbiB0aGU8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBleGNoYW5nZSBz ZXJ2aWNlIGxhYmVscyB2aWEgQkdQIG9yIHNvbWU8YnI+DQomZ3Q7IG90aGVyPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBub24tSUdQIG1lY2hhbmlzbSB0 aGUgYm90dG9tIGxhYmVsIGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1A8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGRvbWFpbi48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IFRoZSBlZ3Jlc3Mgbm9kZSBwcm90 ZWN0aW9uIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgW1JGQzg2NzkgJmx0OzxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRy YWNrZXIuaWV0Zi5vcmdfZG9jX2h0bWxfcmZjODY3OSZhbXA7ZD1Ed01HYVEmYW1wO2M9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZhbXA7cj1zN1p6QjRKYlB2M25ZdW9TeDVHeThRJmFtcDttPUZvbUxC dU1VY1ZRZjJxMnJvaEZDYnhTb2pxMFlJZUR6MGNzbkJGMWxBOU0mYW1wO3M9bUZxbXIxVUtHdEkt RUJaWlJaZmd1WFFORHBwQVpROW1KUHRCT1hQUG9ySSZhbXA7ZT0iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODY3OTwvYT4mZ3Q7XQ0KIGlzPGJyPg0KJmd0OyAmZ3Q7 IGFwcGxpY2FibGUgdG8gdGhpcyB1c2UgY2FzZSBhbmQgbm8gYWRkaXRpb25hbCBjaGFuZ2VzPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyB3aWxsIGJlIHJl cXVpcmVkIGZvciBTUiBiYXNlZCBuZXR3b3Jrczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBUaGUgc2NlbmFyaW9zIGluIHdoaWNoICZuYnNwO2RpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKA nHRvcG9sb2dpY2Fs4oCdIGFuZDxicj4NCiZndDsgJmd0OyDigJxzZXJ2aWNl4oCdIGluc3RydWN0 aW9ucyBpcyBicm9rZW4gYXJlIGluZGVlZCBwcm9ibGVtYXRpYy4gRS5nLiw8YnI+DQomZ3Q7IGNv bnNpZGVyPGJyPg0KJmd0OyAmZ3Q7IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUgU0lEIGlu IHRoZSBFUk8gb2YgYSBTUi1URSBwYXRoPGJyPg0KJmd0OyBpZGVudGlmaWVzIGE8YnI+DQomZ3Q7 ICZndDsgbm9kZSB0aGF0IGFjdHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVj ZWl2ZXMsIGkuZS4sPGJyPg0KJmd0OyBwcm92aWRlczxicj4NCiZndDsgJmd0OyB0aGUgZmlyZXdh bGwgc2VydmljZSB3aXRob3V0IGFueSBkZWRpY2F0ZWQgc2VydmljZSBTSUQ8YnI+DQomZ3Q7IGlk ZW50aWZ5aW5nIGl0Ljxicj4NCiZndDsgJmd0OyBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUg U0lEIG9mIHN1Y2ggYSBub2RlIHdvdWxkIGNvbWJpbmU8YnI+DQomZ3Q7IHRvcG9sb2dpY2FsPGJy Pg0KJmd0OyAmZ3Q7IGFuZCBzZXJ2aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBk aWZmZXJlbnRpYXRpb248YnI+DQomZ3Q7IGJldHdlZW4gdGhlIHR3by48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgSSBhbSBub3Qgc3VyZSBpZiB1c2FnZSBvZiBzdWNoIOKAnGNvbWJpbmVk 4oCdIFNJRHMgY291bGQgYmUgcHJldmVudGVkPGJyPg0KJmd0OyBvciBhdDxicj4NCiZndDsgJmd0 OyBsZWFzdCBkaXNjb3VyYWdlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgbm90 LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0byBpZGVudGlmeSBzdWNoIFNJRHMgaW4gdGhlPGJyPg0K Jmd0OyBhZHZlcnRpc2VtZW50PGJyPg0KJmd0OyAmZ3Q7IG1lY2hhbmlzbXMgd291bGQgYmUgdXNl ZnVsIElNSE8uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE15IDJjLDxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBTYXNoYTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBP ZmZpY2U6ICYjNDM7OTcyLTM5MjY2MzAyPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENl bGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTwvYT48YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20iPm1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4m Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnJTBiIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzxicj4NCjwvYT4m Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyBPbiBCZWhhbGYgT2YgTWFjaCBDaGVu PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMsIDIwMjAgNjozMCBBTTxicj4N CiZndDsgJmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSUwYiI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb208L2E+Jmd0OyZndDs7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPg0Kc3By aW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFp bHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBb c3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSGkgSm9lbCw8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgSSB0aGluayB0aGlzIGlzIGEgZ29vZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlz Y3Vzc2VkIGluIHRoZTxicj4NCiZndDsgcGFzdC4gQW5kPGJyPg0KJmd0OyAmZ3Q7IEkgYWxzbyBk b24ndCB0aGluayB0aGVyZSBpcyBhICZxdW90O2NhbiBiZSBieXBhc3NlZCZxdW90OyBpbmRpY2F0 aW9uIGluIHRoZTxicj4NCiZndDsgJmd0OyByb3V0aW5nIGFkdmVydGlzZW1lbnQgZm9yIG5vdy48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSU1ITywgdGhlIGluZm9ybWF0aW9uIGFkdmVy dGlzZWQgYnkgcm91dGluZyBpcyBuZXV0cmFsLCBzdWNoPGJyPg0KJmd0OyBpbmZvcm1hdGlvbjxi cj4NCiZndDsgJmd0OyAoY2FuIG9yIGNhbm5vdCBiZSBieXBhc3NlZCkgaXMgbW9yZSBwYXRoIHNw ZWNpZmljLCB0aHVzIG5vcm1hbGx5IHRoZTxicj4NCiZndDsgJmd0OyBjb250cm9sbGVyIHNob3Vs ZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBTSUQ8YnI+DQomZ3Q7 IGNhbiBiZTxicj4NCiZndDsgJmd0OyBieXBhc3NlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBNYWNoPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBGcm9tOiBz cHJpbmcgWzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUz Y21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUzZSI+bWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnPGJyPg0KJmd0OyAmbHQ7bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0 OzwvYT5dIE9uIEJlaGFsZiBPZiBKb2VsIE0uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgSGFscGVybjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMsIDIwMjAgNzo1MSBBTTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFp bHRvOnNwcmluZ0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IFN1YmplY3Q6IFtzcHJp bmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgKFdHIENoYWlyIGhhdCBPZmYsIHRoaXMgaXMgbWVyZWx5IGEgbm90 ZSBmcm9tIGEgc2xpZ2h0bHk8YnI+DQomZ3Q7IGNvbmZ1c2VkIFdHPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgcGFydGljaXBhbnQuKTxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQg dGhlIHZhcmlvdXM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBuZXR3 b3JrcyBwcm9ncmFtbWluZyBhbmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW08 YnI+DQomZ3Q7IHRyeWluZyB0bzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUgY29tYmluYXRpb24uPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2Yg YnlwYXNzIChzdXBwb3NlLCBmb3I8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0OyBzaW1wbGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4 dCBTSUQgZm9yPGJyPg0KJmd0OyBhIGZhaWxlZDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7IG5vZGUgTjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRvIHNvPzxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0 IGlzICZxdW90O3NhZmUmcXVvdDsgaWYgdGhlIG5ldyBwYXRoPGJyPg0KJmd0OyBtZWV0czxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IHRoZSBURSBjcml0ZXJpYS4mbmJz cDsgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBpdCBpcyBldmVuIGNsb3NlLCBhczxicj4NCiZndDsg bG9uZyBhczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGl0IGlzIG5v dCB1c2VkIGZvciB0b28gbG9uZy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEJ1dCB3aGF0IGlm IHRoZSBub2RlIHdlcmUgYSBGaXJld2FsbCwgaW5jbHVkZWQgdG8gbWVldCBsZWdhbDxicj4NCiZn dDsgJmd0OyByZXF1aXJlbWVudHM/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0cmFuc2Zvcm0g KHdpbmNlIHdlIGFyZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGRl bGliZXJhdGVseSB2YWd1ZSBhYm91dCB3aGF0IG5vZGVzIGNhbiBkbyB3aGVuIGFza2VkIHN1aXRh Ymx5Lik8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IElzIHRoZXJlIHNvbWUgJnF1b3Q7Y2FuIGJl IGJ5cGFzc2VkJnF1b3Q7IGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmc8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPzxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgVGhhbmsgeW91LDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7IFlvdXJzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmlu Z0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5n QGlldGYub3JnICZsdDttYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fY2xpY2t0aW1lLnN5bWFudGVjLmNvbV8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMi0z RnUtM0RodHRwcy0yNTNBLTI1MiZhbXA7ZD1Ed01HYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWlj dmpJZyZhbXA7cj1zN1p6QjRKYlB2M25ZdW9TeDVHeThRJmFtcDttPUZvbUxCdU1VY1ZRZjJxMnJv aEZDYnhTb2pxMFlJZUR6MGNzbkJGMWxBOU0mYW1wO3M9N0lSb2R1bHhxSFl2eXZLRUtTWHhsWUZr ZV82dW83QnhWYmNYOWtsYzc1OCZhbXA7ZT0iPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjwvYT48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2NsaWNrdGltZS5zeW1hbnRlYy5jb21fMzY3cWhVNEtp VWt6Vzl1R0M0ZUF2UDQ2SDItM0Z1LTNEaHR0cHMtMjUzQS0yNTI1MiZhbXA7ZD1Ed01HYVEmYW1w O2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1zN1p6QjRKYlB2M25ZdW9TeDVHeThRJmFt cDttPUZvbUxCdU1VY1ZRZjJxMnJvaEZDYnhTb2pxMFlJZUR6MGNzbkJGMWxBOU0mYW1wO3M9SDBm QmpQVGx5clN4el9oREl1Rjd6cTh4VEZfSGp4UUsxSC15MjBSS2toVSZhbXA7ZT0iPmh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBz JTNBJTI1MjwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg RiUyRjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX193d3cuaWV0Zi5vcmcmYW1wO2Q9RHdRR2FRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1Fp Y3ZqSWcmYW1wO3I9czdaekI0SmJQdjNuWXVvU3g1R3k4USZhbXA7bT1Gb21MQnVNVWNWUWYycTJy b2hGQ2J4U29qcTBZSWVEejBjc25CRjFsQTlNJmFtcDtzPTR4LXNzLUg1VXRyaURaSkxXUEJGMDh1 Q2tyaV9Id2pJT255b1JnY3J1Y3MmYW1wO2U9Ij53d3cuaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAm bHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfXzJGd3d3LmlldGYub3JnJmFtcDtkPUR3TUdhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNR aWN2aklnJmFtcDtyPXM3WnpCNEpiUHYzbll1b1N4NUd5OFEmYW1wO209Rm9tTEJ1TVVjVlFmMnEy cm9oRkNieFNvanEwWUllRHowY3NuQkYxbEE5TSZhbXA7cz1LQ25lNDV0SXFRdmY2MUgtSENtdU9y MWtrOU1Nd1RXcjdTaXlVbFlYZUJNJmFtcDtlPSI+aHR0cDovLzJGd3d3LmlldGYub3JnPC9hPiZn dDslMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5tYWls dG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmclMGIiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19jbGlja3Rp bWUuc3ltYW50ZWMuY29tXzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyLTNGdS0zRGh0dHBzLTI1 M0EtMjUyRi0yNTJGd3d3LmlldGYub3JnLTI1MkZtYWlsbWFuLTI1MkZsaXN0aW5mby0yNTJGc3By aW5nJmFtcDtkPUR3TUdhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPXM3WnpC NEpiUHYzbll1b1N4NUd5OFEmYW1wO209Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEwWUllRHow Y3NuQkYxbEE5TSZhbXA7cz1CcUVFY09maDZBZzkzeXpUN3VjbjhnX1hzXzdSOEVrRzRFUjBxTnJ5 cjVNJmFtcDtlPSI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6 Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZs aXN0aW5mbyUyRnNwcmluZzwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsgJmd0OyBOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRz IG1heSBjb250YWluPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5p Y2F0aW9ucyBJbmMuIHRoYXQgaXMgY29uZmlkZW50aWFsPGJyPg0KJmd0OyBhbmQvb3I8YnI+DQom Z3Q7ICZndDsgcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LiBBbnkgcmV2aWV3LDxicj4NCiZndDsgJmd0OyBkaXNjbG9zdXJlLCByZWxpYW5jZSBv ciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dDxicj4NCiZndDsg Jmd0OyBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFy ZSBub3QgdGhlPGJyPg0KJmd0OyBpbnRlbmRlZDxicj4NCiZndDsgJmd0OyByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsPGJy Pg0KJmd0OyAmZ3Q7IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgJmd0OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NwcmluZyZhbXA7 ZD1Ed01HYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1zN1p6QjRKYlB2M25Z dW9TeDVHeThRJmFtcDttPUZvbUxCdU1VY1ZRZjJxMnJvaEZDYnhTb2pxMFlJZUR6MGNzbkJGMWxB OU0mYW1wO3M9YlBtX3dQZWZVUlpiU1ZfZ3BWRmlEdk5qZlZJWVNiSHR4NFNSRllBSDNpZyZhbXA7 ZT0iPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8 L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5nQGll dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fc3ByaW5nJmFtcDtkPUR3TUdhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDty PXM3WnpCNEpiUHYzbll1b1N4NUd5OFEmYW1wO209Rm9tTEJ1TVVjVlFmMnEycm9oRkNieFNvanEw WUllRHowY3NuQkYxbEE5TSZhbXA7cz1iUG1fd1BlZlVSWmJTVl9ncFZGaUR2TmpmVklZU2JIdHg0 U1JGWUFIM2lnJmFtcDtlPSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZzwvYT48YnI+DQomZ3Q7IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NwcmluZyZhbXA7ZD1Ed01HYVEmYW1w O2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1zN1p6QjRKYlB2M25ZdW9TeDVHeThRJmFt cDttPUZvbUxCdU1VY1ZRZjJxMnJvaEZDYnhTb2pxMFlJZUR6MGNzbkJGMWxBOU0mYW1wO3M9YlBt X3dQZWZVUlpiU1ZfZ3BWRmlEdk5qZlZJWVNiSHR4NFNSRllBSDNpZyZhbXA7ZT0iPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_b7823cae12cc4b999efdb1a01813edc8attcom_-- From nobody Mon Aug 3 15:26:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A453A1110 for ; Mon, 3 Aug 2020 15:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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=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 25RGDS3Eocnr for ; Mon, 3 Aug 2020 15:26:51 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450: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 701593A1101 for ; Mon, 3 Aug 2020 15:26:51 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id i6so2759320edy.5 for ; Mon, 03 Aug 2020 15:26:51 -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=L3uyidW0+fc/OZ/SBPO4WLZhVoq5Py/ivYf/Ynu4mGs=; b=C1AMEiAgOn+L4r5gp9GBWvYbF3uvnaF3kTmLxFpqnK1aYYnh7EhCZTf1UvlC6KSLZj /V22QUPpSU+jUY6F3RU1EMf0o0+Cj9f/1RHE2dcLcrKmh42zJIidQsjF8KchzjQB7EmC nLjACEQM9IaD02xNrSfkhLSnvP88e64v+vz6weHfh1QiG1bLtHblEBGPy6EHo2FbDGIC 4+LKrLJWhlblCKgQLi6+vVtXHoIJkiPgN66EnwYfm5dWOdLfObJd2myV86Vx6JOJaUMk wF0XguDj2za42B6Eu6i9neqqKbSV1WtunDso2LGW0F+8EQgdPmLZfhLFwG9b9ewCozGL 2SMw== 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=L3uyidW0+fc/OZ/SBPO4WLZhVoq5Py/ivYf/Ynu4mGs=; b=ID9riRbe+D2+g1rm3qj0Hkj9XudZ6JeSteTGqvEyA6gTYnOqBBwOU7WprLrzX/SfL7 IVqK+2S06c/tLqLHxxBqI6Sq/aLQfyX+Y60Ang4iBHpk8dIU/MecPsBNnp8/ElqVsWqV qhIEQX584haIprRlzrq1yfAU1n1bOzu6EVFRigJiLlZwVDJ5SrBYVD146NSkG6NjCt5g THXDpGYq3fm2nlKM8qgfOhBhxTGTfCuEAdlvIIXNDd9yKjsUNsg/2HjC1IDL9JybiSmB Kq+GyTIpROR3yjTKiL9LYVYFPi4QKJZi9eTwYkOoLfSP7Sv3Aij5X4GNAUrfqBetxgVQ rU+Q== X-Gm-Message-State: AOAM5312K3gvURvqIIjcTH27SWW7h7w7qifwC1Jwnk4PpPmkSQKRHvaV loR3vbq1Q9BoY3oz9W5UexxAhRZy0fDMdHvSHLM4rkNJzhQ= X-Google-Smtp-Source: ABdhPJxVaNMTXjHuWvxagUUx6sMwSyKhq6Rt4Q1jRGX6ZfOz9bF0OJ7Vaw4AERBQl9+dSSsHHH2ZITCny5F1gsB+AKk= X-Received: by 2002:aa7:d585:: with SMTP id r5mr5860985edq.30.1596493609774; Mon, 03 Aug 2020 15:26:49 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Tue, 4 Aug 2020 00:26:39 +0200 Message-ID: To: Andrew Alston Cc: "Joel M. Halpern" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007f4c2a05ac00a290" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 22:26:55 -0000 --0000000000007f4c2a05ac00a290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is this a common use case ie. "but rather =E2=80=93 which nodes / network = segments it can never touch or flow through." If so perhaps its time to define notion of *negative-SID* ie. list in the packet resources which given packet MUST not ever traverse. Put in the packet set of nodes or links which the packet should never traverse. That goes in line of recent wave of negative routing implementations (RIFT) or discussions (LSR) Best, R. On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston < Andrew.Alston@liquidtelecom.com> wrote: > So =E2=80=93 > > > > One of the use cases, in fact, some very major use cases in any spring > technology for us revolve around the following > > > > 1. The explicit avoidance of certain nodes > 2. The explicit avoidance of certain sections of the network > > > > Anything that could result in that explicit avoidance being violated =E2= =80=93 > would create, shall we say significant problems. > > > > Much of the use case is not a case of which nodes the packets flow throug= h > =E2=80=93 but rather =E2=80=93 which nodes / network segments it can neve= r touch or flow > through. Effectively, to be used as a technology to avoid certain things > for specific reasons. > > > > This is also one of the reasons for needing such deep label stacks =E2=80= =93 this > kind of detailed path programming tends to deepen the stack because you > sometimes have to be pretty explicit. > > > > It is absolutely critical to us that this functionality is there =E2=80= =93 and > that we can avoid situations which could cause traffic to accidently hit > things explicitly avoided. > > > > I wish I could be more specific than this, but it is what it is. > > > > Thanks > > > > Andrew > > > > > > *From:* spring *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > (Since the thread has gotten long enough, reiterating that this is as a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks that > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clear > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve QoS. > > Let's be clear. I am not arguing that this is not a good idea. It is a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you bette= r > > apply IP encapsulation to that node. I don't think IP encapsulation can > > be hijacked today such that destination address of the packet is ignore= d. > > > > B) Have you seen any IP network where upon topology change (link or nod= e > > failure) you suddenly start dropping flows in spite of SPT offering > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > >> wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex te > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the packet > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instruction= s > > > > > > 2.Segments that represent topological instructions can be bypassed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, two > > > > > > topological segments are defined: the IGP-Adjacency segment and the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and the > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Section > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > < > https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-= for-sr-te-paths-07#section-3.4 > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When the > > > > > > provider edge routers exchange service labels via BGP or some > > other > > > > > > non-IGP mechanism the bottom label is not understood in the IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 ] is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between =E2=80=9Ctopological= =E2=80=9D and > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed problemat= ic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs could = be prevented > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > >> On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > >>; spring@ietf.org > > > > Subject: Re: [spring] Spring protection - determining applicability > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in the > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicability > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the various > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, for > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new path > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we are > > > > > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > >> > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%= 2 > > > > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2> > > > > > > > F%2Fwww.ietf.org > > %2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > < > mailto:spring@ietf.org > > >> > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > -----------------------------------------------------------------------= - > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any review, > > > disclosure, reliance or distribution by others or forwarding without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete all > > > copies, including any attachments. > > > > > -----------------------------------------------------------------------= - > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000007f4c2a05ac00a290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Is this a common use case ie.=C2=A0 "b= ut rather =E2=80=93 which nodes / network segments it can never touch or fl= ow through."

If so perhaps its time to define notio= n of negative-SID ie. list in the packet resources which given=C2=A0= packet MUST not ever traverse.=C2=A0

Put in the pa= cket set of nodes or links which the packet should never traverse.=C2=A0

That goes in line of recent wave of negative routing= implementations (RIFT) or discussions (LSR)

Best,=
R.





On = Mon, Aug 3, 2020 at 11:46 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:

So =E2=80=93

=C2=A0

One of the use cases, in fact, = some very major use cases in any spring technology for us revolve around th= e following

=C2=A0

  1. The explicit avoidance of certain nodes
  2. The explicit avoidance of= certain sections of the network

=C2=A0

Anything that could result in t= hat explicit avoidance being violated =E2=80=93 would create, shall we say = significant problems.

=C2=A0

Much of the use case is not a c= ase of which nodes the packets flow through =E2=80=93 but rather =E2=80=93 = which nodes / network segments it can never touch or flow through.=C2=A0 Ef= fectively, to be used as a technology to avoid certain things for specific reasons.

=C2=A0

This is also one of the reasons= for needing such deep label stacks =E2=80=93 this kind of detailed path pr= ogramming tends to deepen the stack because you sometimes have to be pretty= explicit.

=C2=A0

It is absolutely critical to us= that this functionality is there =E2=80=93 and that we can avoid situation= s which could cause traffic to accidently hit things explicitly avoided.=

=C2=A0

I wish I could be more specific= than this, but it is what it is.

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

F= rom: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: Monday, 3 August 2020 21:36
To: Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= u>

=C2=A0

(Since the thread has got= ten long enough, reiterating that this is as a
participant, not a WG chair.)

Yes, we are talking IP networks. And yes, I have seen IP networks that
choose to drop packets. For all sorts of reasons.
I think there are likely other reasons why one may not want a random
path rather than a chosen TE path. I think it is important we be clear
about what constraints may be / are violated when we tell people they
have this tool (protective rerouting) that is intended to preserve QoS.

Let's be clear. I am not arguing that this is not a good idea. It is a =
good idea. And useful. I am trying to figure otu what combination of
additional mechanisms and clear descriptions will lead to everyone
getting the behavior they expect (which may not be the behavior they
desire, but sometimes is the best we can do.)

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> Joel,
>
> Are we still talking about IP networks=C2=A0here ? Or perhaps some har= d
> slicing with real resource reservations or detnets ?
>
> Because=C2=A0if we are talking=C2=A0about IP networking I have two obs= ervations:
>
> A) If you need to traverse via a specific node (ie. firewall) you bett= er
> apply IP encapsulation to that node. I don't think IP encapsulatio= n=C2=A0can
> be hijacked today such that destination address of the packet is ignor= ed.
>
> B) Have you seen any IP network where upon topology change (link or no= de
> failure) you suddenly=C2=A0start dropping=C2=A0flows in spite of SPT o= ffering
> perhaps few ms longer path with 10 ms more jitter ?
>
> Or are some SR marketing slides promise to turn IP networks in
> something=C2=A0new ? Worse ... do they mention path quality guarantees= ,
> resource reservations=C2=A0? I hope not.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>> wrote:
>
> Well less serious for TE SIDs, I am not sure the problem is restricted=
> to just service SIDs.
>
> Suppose that the PCE has specified the path to meet some complex te > objective.=C2=A0 The bypass node has no way of knowing what those
> constraints
> were.=C2=A0 And for some kinds of traffic, it is better to drop the pa= cket
> than to deliver it outside the envelop.=C2=A0 I suspect that the right=
> answer
> to this is "too bad".=C2=A0 If so, as with the distinction r= egarding service
> nodes, we should say so, shouldn't we?
>
> Yours,
> Joel
>
> On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> > Mach, Joel and all,
> >
> > I think that in most cases:
> >
> > 1.There is clear differentiation between "topological" = and "service"
> > instructions in SID advertisements. E.g.:
> >
> > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
> > corresponding IGP advertisements) represent topological instructi= ons
> >
> > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
> >
> <https://datatracker.ietf.org/doc/html/dr= aft-ietf-bess-srv6-services-04>
>
> > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instruc= tions
> >
> > 2.Segments that represent topological instructions can be bypasse= d,
> > while segments that represent service instructions require
> alternative
> > protection mechanisms.
> >
> > This view seems to be aligned with RFC 8402
> > <https://tools.ietf.org/html/rfc8402> that says in Section 1: > >
> >=C2=A0 =C2=A0=C2=A0 In the context of an IGP-based distributed con= trol plane, two
> >
> > topological segments are defined: the IGP-Adjacency segment and t= he
> >
> >=C2=A0 =C2=A0=C2=A0 IGP-Prefix segment.
> >
> >=C2=A0 =C2=A0=C2=A0 In the context of a BGP-based distributed cont= rol plane, two
> >
> > topological segments are defined: the BGP peering segment and the=
> >
> >=C2=A0 =C2=A0=C2=A0 BGP-Prefix segment.
> >
> > In the case of SR-MPLS this differentiation is assumed in Section=
> 3.4 of
> > the Node Protection for SR-TE Path
> >
> <https:/= /datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te= -paths-07#section-3.4>
>
> > draft that says:
> >
> >=C2=A0 =C2=A0=C2=A0 The node protection mechanism described in the= previous sections
> >
> >=C2=A0 =C2=A0=C2=A0 depends on the assumption that the label immed= iately below
> the top
> >
> > label in the label stack is understood in the IGP domain.=C2=A0 W= hen the
> >
> >=C2=A0 =C2=A0=C2=A0 provider edge routers exchange service labels = via BGP or some
> other
> >
> >=C2=A0 =C2=A0=C2=A0 non-IGP mechanism the bottom label is not unde= rstood in the IGP
> >
> >=C2=A0 =C2=A0=C2=A0 domain.
> >
> >=C2=A0 =C2=A0=C2=A0 The egress node protection mechanisms describe= d in the draft
> >
> >=C2=A0 =C2=A0=C2=A0 [RFC8679 <https://datatracker.ietf.org/doc= /html/rfc8679>] is
> > applicable to this use case and no additional changes
> >
> >=C2=A0 =C2=A0=C2=A0 will be required for SR based networks
> >
> > The scenarios in which =C2=A0differentiation between =E2=80=9Ctop= ological=E2=80=9D and
> > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed probl= ematic. E.g.,
> consider
> > the use case in which a Node SID in the ERO of a SR-TE path
> identifies a
> > node that acts as a firewall for all packets it receives, i.e., > provides
> > the firewall service without any dedicated service SID
> identifying it.
> > One could say that the Node SID of such a node would combine
> topological
> > and service instructions thus breaking the differentiation
> between the two.
> >
> > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs co= uld be prevented
> or at
> > least discouraged.
> >
> > If not, providing an ability to identify such SIDs in the
> advertisement
> > mechanisms would be useful IMHO.
> >
> > My 2c,
> >
> > Sasha
> >
> > Office: +972-39266302
> >
> > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
> >
> > Email: Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>
> >
> > -----Original Message-----
> > From: spring <spring-bounces@ietf.org
> <m= ailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
> > Sent: Monday, August 3, 2020 6:30 AM
> > To: Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org <mailto:spring@ietf.org>
> > Subject: Re: [spring] Spring protection - determining applicabili= ty
> >
> > Hi Joel,
> >
> > I think this is a good point that may not be discussed in the
> past. And
> > I also don't think there is a "can be bypassed" ind= ication in the
> > routing advertisement for now.
> >
> > IMHO, the information advertised by routing is neutral, such
> information
> > (can or cannot be bypassed) is more path specific, thus normally = the
> > controller should be responsible for deciding whether/which SID > can be
> > bypassed.
> >
> > Best regards,
> >
> > Mach
> >
> >=C2=A0 > -----Original Message-----
> >
> >=C2=A0 > From: spring [mailto:sp= ring-bounces@ietf.org
> <mailto:spring-bounces@ietf.org>] On Behalf Of Joel M.
> >
> >=C2=A0 > Halpern
> >
> >=C2=A0 > Sent: Monday, August 3, 2020 7:51 AM
> >
> >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >=C2=A0 > Subject: [spring] Spring protection - determining appl= icability
> >
> >=C2=A0 >
> >
> >=C2=A0 > (WG Chair hat Off, this is merely a note from a slight= ly
> confused WG
> >
> >=C2=A0 > participant.)
> >
> >=C2=A0 >
> >
> >=C2=A0 > I have been reading the various repair drafts, and the= various
> >
> >=C2=A0 > networks programming and service programming draft, an= d I am
> trying to
> >
> >=C2=A0 > figure out one aspect of the combination.
> >
> >=C2=A0 >
> >
> >=C2=A0 > How does a node that is doing some form of bypass (sup= pose, for
> >
> >=C2=A0 > simplicity, it is Node N2 deciding to bypass the next = SID for
> a failed
> >
> >=C2=A0 > node N3) know that it is safe to do so?
> >
> >=C2=A0 >
> >
> >=C2=A0 > If the path was just for TE, then it is "safe&quo= t; if the new path
> meets
> >
> >=C2=A0 > the TE criteria.=C2=A0 or maybe it is safe if it is ev= en close, as
> long as
> >
> >=C2=A0 > it is not used for too long.
> >
> >=C2=A0 >
> >
> >=C2=A0 > But what if the node were a Firewall, included to meet= legal
> > requirements?
> >
> >=C2=A0 > Or was some other necessary programmatic transform (wi= nce we are
> >
> >=C2=A0 > deliberately vague about what nodes can do when asked = suitably.)
> >
> >=C2=A0 >
> >
> >=C2=A0 > Is there some "can be bypassed" indication i= n the routing
> >
> >=C2=A0 > advertisements that I missed?
> >
> >=C2=A0 >
> >
> >=C2=A0 > Thank you,
> >
> >=C2=A0 > Yours,
> >
> >=C2=A0 > Joel
> >
> >=C2=A0 >
> >
> >=C2=A0 > _______________________________________________
> >
> >=C2=A0 > spring mailing list
> >
> >=C2=A0 > s= pring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >=C2=A0 >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
> >
> <https://clicktime.symantec.com/367qh= U4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252>
> >
> >=C2=A0 > F%= 2Fwww.ietf.org
> <http://2Fwww.i= etf.org>%2Fmailman%2Flistinfo%2Fspring
> >
> > _______________________________________________
> >
> > spring mailing list
> >
> > spring@ietf.= org <mailto:spr= ing@ietf.org> <mailto:spring@ietf.org
> <mailto:sp= ring@ietf.org>>
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> >
> ----------------------------------------------------------------------= --
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. that is confidential > and/or
> > proprietary for the sole use of the intended recipient. Any revie= w,
> > disclosure, reliance or distribution by others or forwarding with= out
> > express permission is strictly prohibited. If you are not the
> intended
> > recipient, please notify the sender immediately and then delete a= ll
> > copies, including any attachments.
> >
> ----------------------------------------------------------------------= --
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.= org <mailto:spr= ing@ietf.org>
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@i= etf.org>
> https://www.ietf.org/mailman/listinfo/spring
>

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

--0000000000007f4c2a05ac00a290-- From nobody Mon Aug 3 15:40:17 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934653A112C for ; Mon, 3 Aug 2020 15:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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 ux27F30fKuTS for ; Mon, 3 Aug 2020 15:40:12 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 48F873A112B for ; Mon, 3 Aug 2020 15:40:12 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id x9so41459068ljc.5 for ; Mon, 03 Aug 2020 15:40:12 -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=/TLq4NE8HcbytsXQ3bjgrUr/YJ5twEtlFEce4XfPucc=; b=L417yWCyIsrOykRlMIkzcTrvct09cNTrO2EX1YST7mwQbtoygj+eE5NJFbrdlYZlKi 2WswY5Ew4YiZpcrsMpUp5TapG5FzHP1E7W8xeuInNlpuf5wkEZVnfVMJnz9uMjJuUIPB K5lfrHLczYjX/9My4K3GPa+PUcsM/ymAWlBqg2b8V7fBdS/1c9cKCJs3a9h69cLarZt6 fit7oNixn0HWwoMV9kBLp613k7UDJT9VJHT762+pCg4Jsh/p+eiU/k2Zh+9VHyHoV/HU VvxJxpzTulEfKZR+r8aOkgTKpQR8UuJXuOUVCJVbt8ilnqiViAyNxynp4Soqo1UQxQKe HcTA== 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=/TLq4NE8HcbytsXQ3bjgrUr/YJ5twEtlFEce4XfPucc=; b=eqPuCHWCmnjqNpuhOUceekX89dVvozqowd0ngDNOVu1lGLBMEHO0oNDkkcv2f2Fw7k WGIEW3pTAeBVgstFQNCo6A2oSQHzhOZH5Z8roWTr/UF7g0Wg5jg2cdRgkm+MPu/yqLT9 d/BQ9G9L96hNbbNwBHfkDrh3t0sy2usCtOBSWOrRyHo4MLm179LMlzeTlAVMWA2IjECX v0PbtN0/auM6SVDxLjRVtHH7L4+V7+L5mgYvHtGcCeSTSpiFnxORRg85JGik22d2xDaR nj0KAmrVUU6f2jmCmkYxyUcZQMz4hg2NTaZR3Kr2OCZVVAtQsb14z7oJXgauG9M+ybi8 9JLw== X-Gm-Message-State: AOAM531cJJr0e6Kr1LSaieWYaFvjU/0M909B0pxpgz/PMb1OpNWZ6EZw QUJPlBeZz+himM9/81XViWQDtDxUs9u/sACXTPWl1A== X-Google-Smtp-Source: ABdhPJxyEpjAsz/q0xceCRv1YqkXB/PY5Mo/0a/Rswn2N3odtYbOAv8hXxoiWBnPLxQgDxlP5dCOf/ameCnAnabnN5s= X-Received: by 2002:a2e:a28a:: with SMTP id k10mr8916536lja.110.1596494410371; Mon, 03 Aug 2020 15:40:10 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: From: Greg Mirsky Date: Mon, 3 Aug 2020 15:39:59 -0700 Message-ID: To: Andrew Alston Cc: "Joel M. Halpern" , Robert Raszuk , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000037617d05ac00d23b" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 22:40:16 -0000 --00000000000037617d05ac00d23b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, would such requirements support using e2e protection? Regards, Greg On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston < Andrew.Alston@liquidtelecom.com> wrote: > So =E2=80=93 > > > > One of the use cases, in fact, some very major use cases in any spring > technology for us revolve around the following > > > > 1. The explicit avoidance of certain nodes > 2. The explicit avoidance of certain sections of the network > > > > Anything that could result in that explicit avoidance being violated =E2= =80=93 > would create, shall we say significant problems. > > > > Much of the use case is not a case of which nodes the packets flow throug= h > =E2=80=93 but rather =E2=80=93 which nodes / network segments it can neve= r touch or flow > through. Effectively, to be used as a technology to avoid certain things > for specific reasons. > > > > This is also one of the reasons for needing such deep label stacks =E2=80= =93 this > kind of detailed path programming tends to deepen the stack because you > sometimes have to be pretty explicit. > > > > It is absolutely critical to us that this functionality is there =E2=80= =93 and > that we can avoid situations which could cause traffic to accidently hit > things explicitly avoided. > > > > I wish I could be more specific than this, but it is what it is. > > > > Thanks > > > > Andrew > > > > > > *From:* spring *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > (Since the thread has gotten long enough, reiterating that this is as a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks that > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clear > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve QoS. > > Let's be clear. I am not arguing that this is not a good idea. It is a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you bette= r > > apply IP encapsulation to that node. I don't think IP encapsulation can > > be hijacked today such that destination address of the packet is ignore= d. > > > > B) Have you seen any IP network where upon topology change (link or nod= e > > failure) you suddenly start dropping flows in spite of SPT offering > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > >> wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex te > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the packet > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instruction= s > > > > > > 2.Segments that represent topological instructions can be bypassed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, two > > > > > > topological segments are defined: the IGP-Adjacency segment and the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and the > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Section > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > < > https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-= for-sr-te-paths-07#section-3.4 > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When the > > > > > > provider edge routers exchange service labels via BGP or some > > other > > > > > > non-IGP mechanism the bottom label is not understood in the IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 ] is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between =E2=80=9Ctopological= =E2=80=9D and > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed problemat= ic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs could = be prevented > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > >> On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > >>; spring@ietf.org > > > > Subject: Re: [spring] Spring protection - determining applicability > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in the > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicability > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the various > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, for > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new path > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we are > > > > > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > >> > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%= 2 > > > > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2> > > > > > > > F%2Fwww.ietf.org > > %2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > < > mailto:spring@ietf.org > > >> > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > -----------------------------------------------------------------------= - > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any review, > > > disclosure, reliance or distribution by others or forwarding without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete all > > > copies, including any attachments. > > > > > -----------------------------------------------------------------------= - > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000037617d05ac00d23b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,
would such requirements support using e2e p= rotection?

Regards,
Greg

=
On Mon, Au= g 3, 2020 at 2:46 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:

So =E2=80=93

=C2=A0

One of the use cases, in fact, = some very major use cases in any spring technology for us revolve around th= e following

=C2=A0

  1. The explicit avoidance of certain nodes
  2. The explicit avoidance = of certain sections of the network

=C2=A0

Anything that could result in t= hat explicit avoidance being violated =E2=80=93 would create, shall we say = significant problems.

=C2=A0

Much of the use case is not a c= ase of which nodes the packets flow through =E2=80=93 but rather =E2=80=93 = which nodes / network segments it can never touch or flow through.=C2=A0 Ef= fectively, to be used as a technology to avoid certain things for specific reasons.

=C2=A0

This is also one of the reasons= for needing such deep label stacks =E2=80=93 this kind of detailed path pr= ogramming tends to deepen the stack because you sometimes have to be pretty= explicit.

=C2=A0

It is absolutely critical to us= that this functionality is there =E2=80=93 and that we can avoid situation= s which could cause traffic to accidently hit things explicitly avoided.=

=C2=A0

I wish I could be more specific= than this, but it is what it is.

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

F= rom: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: Monday, 3 August 2020 21:36
To: Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= u>

=C2=A0

(Since the thread has got= ten long enough, reiterating that this is as a
participant, not a WG chair.)

Yes, we are talking IP networks. And yes, I have seen IP networks that
choose to drop packets. For all sorts of reasons.
I think there are likely other reasons why one may not want a random
path rather than a chosen TE path. I think it is important we be clear
about what constraints may be / are violated when we tell people they
have this tool (protective rerouting) that is intended to preserve QoS.

Let's be clear. I am not arguing that this is not a good idea. It is a =
good idea. And useful. I am trying to figure otu what combination of
additional mechanisms and clear descriptions will lead to everyone
getting the behavior they expect (which may not be the behavior they
desire, but sometimes is the best we can do.)

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> Joel,
>
> Are we still talking about IP networks=C2=A0here ? Or perhaps some har= d
> slicing with real resource reservations or detnets ?
>
> Because=C2=A0if we are talking=C2=A0about IP networking I have two obs= ervations:
>
> A) If you need to traverse via a specific node (ie. firewall) you bett= er
> apply IP encapsulation to that node. I don't think IP encapsulatio= n=C2=A0can
> be hijacked today such that destination address of the packet is ignor= ed.
>
> B) Have you seen any IP network where upon topology change (link or no= de
> failure) you suddenly=C2=A0start dropping=C2=A0flows in spite of SPT o= ffering
> perhaps few ms longer path with 10 ms more jitter ?
>
> Or are some SR marketing slides promise to turn IP networks in
> something=C2=A0new ? Worse ... do they mention path quality guarantees= ,
> resource reservations=C2=A0? I hope not.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>> wrote:
>
> Well less serious for TE SIDs, I am not sure the problem is restricted=
> to just service SIDs.
>
> Suppose that the PCE has specified the path to meet some complex te > objective.=C2=A0 The bypass node has no way of knowing what those
> constraints
> were.=C2=A0 And for some kinds of traffic, it is better to drop the pa= cket
> than to deliver it outside the envelop.=C2=A0 I suspect that the right=
> answer
> to this is "too bad".=C2=A0 If so, as with the distinction r= egarding service
> nodes, we should say so, shouldn't we?
>
> Yours,
> Joel
>
> On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> > Mach, Joel and all,
> >
> > I think that in most cases:
> >
> > 1.There is clear differentiation between "topological" = and "service"
> > instructions in SID advertisements. E.g.:
> >
> > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
> > corresponding IGP advertisements) represent topological instructi= ons
> >
> > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
> >
> <https://datatracker.ietf.org/doc/html/dr= aft-ietf-bess-srv6-services-04>
>
> > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instruc= tions
> >
> > 2.Segments that represent topological instructions can be bypasse= d,
> > while segments that represent service instructions require
> alternative
> > protection mechanisms.
> >
> > This view seems to be aligned with RFC 8402
> > <https://tools.ietf.org/html/rfc8402> that says in Section 1: > >
> >=C2=A0 =C2=A0=C2=A0 In the context of an IGP-based distributed con= trol plane, two
> >
> > topological segments are defined: the IGP-Adjacency segment and t= he
> >
> >=C2=A0 =C2=A0=C2=A0 IGP-Prefix segment.
> >
> >=C2=A0 =C2=A0=C2=A0 In the context of a BGP-based distributed cont= rol plane, two
> >
> > topological segments are defined: the BGP peering segment and the=
> >
> >=C2=A0 =C2=A0=C2=A0 BGP-Prefix segment.
> >
> > In the case of SR-MPLS this differentiation is assumed in Section=
> 3.4 of
> > the Node Protection for SR-TE Path
> >
> <https:/= /datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te= -paths-07#section-3.4>
>
> > draft that says:
> >
> >=C2=A0 =C2=A0=C2=A0 The node protection mechanism described in the= previous sections
> >
> >=C2=A0 =C2=A0=C2=A0 depends on the assumption that the label immed= iately below
> the top
> >
> > label in the label stack is understood in the IGP domain.=C2=A0 W= hen the
> >
> >=C2=A0 =C2=A0=C2=A0 provider edge routers exchange service labels = via BGP or some
> other
> >
> >=C2=A0 =C2=A0=C2=A0 non-IGP mechanism the bottom label is not unde= rstood in the IGP
> >
> >=C2=A0 =C2=A0=C2=A0 domain.
> >
> >=C2=A0 =C2=A0=C2=A0 The egress node protection mechanisms describe= d in the draft
> >
> >=C2=A0 =C2=A0=C2=A0 [RFC8679 <https://datatracker.ietf.org/doc= /html/rfc8679>] is
> > applicable to this use case and no additional changes
> >
> >=C2=A0 =C2=A0=C2=A0 will be required for SR based networks
> >
> > The scenarios in which =C2=A0differentiation between =E2=80=9Ctop= ological=E2=80=9D and
> > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed probl= ematic. E.g.,
> consider
> > the use case in which a Node SID in the ERO of a SR-TE path
> identifies a
> > node that acts as a firewall for all packets it receives, i.e., > provides
> > the firewall service without any dedicated service SID
> identifying it.
> > One could say that the Node SID of such a node would combine
> topological
> > and service instructions thus breaking the differentiation
> between the two.
> >
> > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs co= uld be prevented
> or at
> > least discouraged.
> >
> > If not, providing an ability to identify such SIDs in the
> advertisement
> > mechanisms would be useful IMHO.
> >
> > My 2c,
> >
> > Sasha
> >
> > Office: +972-39266302
> >
> > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
> >
> > Email: Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>
> >
> > -----Original Message-----
> > From: spring <spring-bounces@ietf.org
> <m= ailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
> > Sent: Monday, August 3, 2020 6:30 AM
> > To: Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org <mailto:spring@ietf.org>
> > Subject: Re: [spring] Spring protection - determining applicabili= ty
> >
> > Hi Joel,
> >
> > I think this is a good point that may not be discussed in the
> past. And
> > I also don't think there is a "can be bypassed" ind= ication in the
> > routing advertisement for now.
> >
> > IMHO, the information advertised by routing is neutral, such
> information
> > (can or cannot be bypassed) is more path specific, thus normally = the
> > controller should be responsible for deciding whether/which SID > can be
> > bypassed.
> >
> > Best regards,
> >
> > Mach
> >
> >=C2=A0 > -----Original Message-----
> >
> >=C2=A0 > From: spring [mailto:sp= ring-bounces@ietf.org
> <mailto:spring-bounces@ietf.org>] On Behalf Of Joel M.
> >
> >=C2=A0 > Halpern
> >
> >=C2=A0 > Sent: Monday, August 3, 2020 7:51 AM
> >
> >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >=C2=A0 > Subject: [spring] Spring protection - determining appl= icability
> >
> >=C2=A0 >
> >
> >=C2=A0 > (WG Chair hat Off, this is merely a note from a slight= ly
> confused WG
> >
> >=C2=A0 > participant.)
> >
> >=C2=A0 >
> >
> >=C2=A0 > I have been reading the various repair drafts, and the= various
> >
> >=C2=A0 > networks programming and service programming draft, an= d I am
> trying to
> >
> >=C2=A0 > figure out one aspect of the combination.
> >
> >=C2=A0 >
> >
> >=C2=A0 > How does a node that is doing some form of bypass (sup= pose, for
> >
> >=C2=A0 > simplicity, it is Node N2 deciding to bypass the next = SID for
> a failed
> >
> >=C2=A0 > node N3) know that it is safe to do so?
> >
> >=C2=A0 >
> >
> >=C2=A0 > If the path was just for TE, then it is "safe&quo= t; if the new path
> meets
> >
> >=C2=A0 > the TE criteria.=C2=A0 or maybe it is safe if it is ev= en close, as
> long as
> >
> >=C2=A0 > it is not used for too long.
> >
> >=C2=A0 >
> >
> >=C2=A0 > But what if the node were a Firewall, included to meet= legal
> > requirements?
> >
> >=C2=A0 > Or was some other necessary programmatic transform (wi= nce we are
> >
> >=C2=A0 > deliberately vague about what nodes can do when asked = suitably.)
> >
> >=C2=A0 >
> >
> >=C2=A0 > Is there some "can be bypassed" indication i= n the routing
> >
> >=C2=A0 > advertisements that I missed?
> >
> >=C2=A0 >
> >
> >=C2=A0 > Thank you,
> >
> >=C2=A0 > Yours,
> >
> >=C2=A0 > Joel
> >
> >=C2=A0 >
> >
> >=C2=A0 > _______________________________________________
> >
> >=C2=A0 > spring mailing list
> >
> >=C2=A0 > s= pring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >=C2=A0 >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
> >
> <https://clicktime.symantec.com/367qh= U4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252>
> >
> >=C2=A0 > F%= 2Fwww.ietf.org
> <http://2Fwww.i= etf.org>%2Fmailman%2Flistinfo%2Fspring
> >
> > _______________________________________________
> >
> > spring mailing list
> >
> > spring@ietf.= org <mailto:spr= ing@ietf.org> <mailto:spring@ietf.org
> <mailto:sp= ring@ietf.org>>
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> >
> ----------------------------------------------------------------------= --
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. that is confidential > and/or
> > proprietary for the sole use of the intended recipient. Any revie= w,
> > disclosure, reliance or distribution by others or forwarding with= out
> > express permission is strictly prohibited. If you are not the
> intended
> > recipient, please notify the sender immediately and then delete a= ll
> > copies, including any attachments.
> >
> ----------------------------------------------------------------------= --
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.= org <mailto:spr= ing@ietf.org>
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@i= etf.org>
> https://www.ietf.org/mailman/listinfo/spring
>

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

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--00000000000037617d05ac00d23b-- From nobody Mon Aug 3 17:06:11 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A803A118B for ; Mon, 3 Aug 2020 17:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uDx4jKWMZjnd for ; Mon, 3 Aug 2020 17:06:06 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35F13A0D91 for ; Mon, 3 Aug 2020 17:05:39 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2051.outbound.protection.outlook.com [104.47.12.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-11-vFCKoUgAN_aKBt0hZLuhTg-1; Tue, 04 Aug 2020 01:05:32 +0100 X-MC-Unique: vFCKoUgAN_aKBt0hZLuhTg-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB6207.eurprd03.prod.outlook.com (2603:10a6:800:131::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Tue, 4 Aug 2020 00:05:30 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117%3]) with mapi id 15.20.3239.021; Tue, 4 Aug 2020 00:05:30 +0000 From: Andrew Alston To: Greg Mirsky CC: "Joel M. Halpern" , Robert Raszuk , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfFqqBapiFGQU+SeGw1le2xJKklun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADOyIIAAEIiAgAAW4uA= Date: Tue, 4 Aug 2020 00:05:30 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2c0f:fe40:3:2:1f5:9343:5fd4:b3ae] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8042ff0e-b747-487b-33fd-08d8380a19a5 x-ms-traffictypediagnostic: VI1PR03MB6207: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: p++eIVZrBDUwg9tkNI8rG5mFSdIkKq+v6LU77VY7VLFN8V2cHnPi2q8XlaK3oGcQSnBxVwqCoFrU9Kh/AYfnGMMKflVqFnOmcxOwQGv0KRBs3DC2634KsXTUQbel/oZ2bQTxXXKWhIXdtzBo3CpKhaqPYnbKS526eXRRRVw9e//k36KM/NuiGIlErQVw3kKOBDOTP+qy75ck0In+MplqiwfIcLFM1S4WtyMgyXjrNKpvKibq84ByJoE6M904qt3QzJJsdXw0mjuG6GxzKK2TDLaubD+uksKAB8mH0c4BNibGZOdt8pQPRoSlzXE0bQxnenTv12AsCGhtFtg9kt3B3/Q/KDrnd9Zd8MZe66+Ls7GtIGoEA9jwGKJhcUnxoof9peDfUiSLD68lzpAd/3+kTA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(346002)(39860400002)(366004)(376002)(71200400001)(54906003)(30864003)(5660300002)(76116006)(52536014)(64756008)(66556008)(186003)(66946007)(6506007)(83380400001)(53546011)(66476007)(33656002)(166002)(316002)(66446008)(966005)(8936002)(8676002)(9686003)(6916009)(86362001)(55016002)(2906002)(4326008)(7696005)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rUY6nzX6qRbAUywnY+bhQDs7hqrrLp4u8ix4QBiR5AVCjiQEYvqlRhT+Qz7u7sJW4C+mj0CnQ3MPwd7z4QWRHeV1uARizjluzvoKcxsGQ1fTo3S0uv8L2IzZQ3ZjBCd7u62GFdYEYXbP3rdl84pnF39fOS2Rp5LGmieFDUsMLJAJ6joG5vhKjX4T1ue5qBcGYiNMizvR5Sfl6eWNeDD/q7BPNOmEKhRI7ew88Sjva8LKep7kA58SjR40kSXPZnEEHcNsRb25gRlJEKts/kDbeFXVcSr0QVayPWBWW3/TaWo3tV+CEcTbLys7IvjtQIxUwCMWlxwP22WFZa4Fv5/s6CgkwaM3XtdC473Lt1VHCur1JGDLvGqvrtzGWod6e7NrD+ILDyvQve1e3klrp4pojSkIsYkf2ZTBtBiyIJE6Zc6b5f50uPZtJwyqsILXPeCaWhYmmoomsgRs6uQHRuLOzSyGonQZ55IvFmy13rtgEmG0AP3zPXmoMry20rO2wa36t2NHfwXp/qJ5fbEoHhKpgqy7oMO1NteFreNSdM+nzabgb7qG5x7D9puSoaaaunQG4mv3rPrh8mqiwdCq0n4jpz/Fji4vsUAmk/gpsV9zWqIIAPqJ6vvyWMkZTmG1plt7nJRIAx12fRB1QcNc+Jf4orQfFMWF1GmhcmaFHUexsEPvG9qwYCd9MSIPX5c1dzbN5ocIjBFe3LnayUUAiXWmpA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR03MB5056.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8042ff0e-b747-487b-33fd-08d8380a19a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 00:05:30.2651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Xj52y4sRJ3TIOlTClI51PPhjEo7mFeFHEhZ8dfIiwpb0t7mejgqKLjP1twklrcI9Ijl+s+z2Uo04fiBgYbflrS4She963AkBv6C4oE8xDhY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6207 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056B7BBAFE9BE2BD1BECDA2EE4A0VI1PR03MB5056eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 00:06:10 -0000 --_000_VI1PR03MB5056B7BBAFE9BE2BD1BECDA2EE4A0VI1PR03MB5056eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 R3JlZyB3ZSBlZmZlY3RpdmVseSBnZXQgdGhpcyB1c2luZyBzYmZkIGFuZCBmYWxsIGJhY2sgcGF0 aHMgYXQgdGhlIG1vbWVudCDigJMgZmFyIGZyb20gaWRlYWwg4oCTIGJ1dCBpdCBkb2VzIHdvcmsu DQoNClRoZXJlIGFyZSBhbHNvIG90aGVyIG1ldGhvZHMgb2YgZGV0ZWN0aW5nIGVuZCB0byBlbmQg cmVhY2hhYmlsaXR5IHRvIGRvIGJsYWNraG9sZSBkZXRlY3Rpb24gZXRjIOKAkyBwYXJ0aWN1bGFy bHkgaW4gdGhlIGZhY2Ugb2YgdGhlIGZhY3QgdGhhdCBJ4oCZdmUgeWV0IHRvIHNlZSBhIGZ1bmN0 aW9uYWwgaW1wbGljYXRpb24gb2YgdGhlIHNpZCB2ZXJpZmljYXRpb24gZmxhZy4NCg0KQ291bGQg dGhpbmdzIGJlIGltcHJvdmVkIHRoaXMgcmVnYXJkPyAxMDAlIGJ1dCBmb3Igbm93IOKAkyB0aGUg ZGVlcCBzZWF0ZWQgYW5kIGNyaXRpY2FsIG5lZWQgZm9yIHRoZSByZXF1aXJlbWVudCBvdmVycmlk ZXMgdGhlIGRyYXdiYWNrcyBvZiB0aGUgcHJvdGVjdGlvbiBtZWNoYW5pc21zIHdlIGFyZSBmb3Jj ZWQgdG8gdXNlIGF0IHRoaXMgcG9pbnQNCg0KQW5kcmV3DQoNCg0KRnJvbTogR3JlZyBNaXJza3kg PGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIDQgQXVndXN0IDIwMjAgMDE6 NDANClRvOiBBbmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPg0K Q2M6IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT47IFJvYmVydCBSYXN6dWsg PHJvYmVydEByYXN6dWsubmV0Pjsgc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Nwcmlu Z10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCkhpIEFu ZHJldywNCndvdWxkIHN1Y2ggcmVxdWlyZW1lbnRzIHN1cHBvcnQgdXNpbmcgZTJlIHByb3RlY3Rp b24/DQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgMjo0NiBQTSBB bmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpBbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPj4gd3JvdGU6DQpTbyDigJMNCg0KT25lIG9mIHRo ZSB1c2UgY2FzZXMsIGluIGZhY3QsIHNvbWUgdmVyeSBtYWpvciB1c2UgY2FzZXMgaW4gYW55IHNw cmluZyB0ZWNobm9sb2d5IGZvciB1cyByZXZvbHZlIGFyb3VuZCB0aGUgZm9sbG93aW5nDQoNCg0K YS4gICAgICBUaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9kZXMNCg0KYi4gICAg ICBUaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdv cmsNCg0KQW55dGhpbmcgdGhhdCBjb3VsZCByZXN1bHQgaW4gdGhhdCBleHBsaWNpdCBhdm9pZGFu Y2UgYmVpbmcgdmlvbGF0ZWQg4oCTIHdvdWxkIGNyZWF0ZSwgc2hhbGwgd2Ugc2F5IHNpZ25pZmlj YW50IHByb2JsZW1zLg0KDQpNdWNoIG9mIHRoZSB1c2UgY2FzZSBpcyBub3QgYSBjYXNlIG9mIHdo aWNoIG5vZGVzIHRoZSBwYWNrZXRzIGZsb3cgdGhyb3VnaCDigJMgYnV0IHJhdGhlciDigJMgd2hp Y2ggbm9kZXMgLyBuZXR3b3JrIHNlZ21lbnRzIGl0IGNhbiBuZXZlciB0b3VjaCBvciBmbG93IHRo cm91Z2guICBFZmZlY3RpdmVseSwgdG8gYmUgdXNlZCBhcyBhIHRlY2hub2xvZ3kgdG8gYXZvaWQg Y2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuDQoNClRoaXMgaXMgYWxzbyBvbmUg b2YgdGhlIHJlYXNvbnMgZm9yIG5lZWRpbmcgc3VjaCBkZWVwIGxhYmVsIHN0YWNrcyDigJMgdGhp cyBraW5kIG9mIGRldGFpbGVkIHBhdGggcHJvZ3JhbW1pbmcgdGVuZHMgdG8gZGVlcGVuIHRoZSBz dGFjayBiZWNhdXNlIHlvdSBzb21ldGltZXMgaGF2ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuDQoN Ckl0IGlzIGFic29sdXRlbHkgY3JpdGljYWwgdG8gdXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkg aXMgdGhlcmUg4oCTIGFuZCB0aGF0IHdlIGNhbiBhdm9pZCBzaXR1YXRpb25zIHdoaWNoIGNvdWxk IGNhdXNlIHRyYWZmaWMgdG8gYWNjaWRlbnRseSBoaXQgdGhpbmdzIGV4cGxpY2l0bHkgYXZvaWRl ZC4NCg0KSSB3aXNoIEkgY291bGQgYmUgbW9yZSBzcGVjaWZpYyB0aGFuIHRoaXMsIGJ1dCBpdCBp cyB3aGF0IGl0IGlzLg0KDQpUaGFua3MNCg0KQW5kcmV3DQoNCg0KRnJvbTogc3ByaW5nIDxzcHJp bmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBC ZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQpTZW50OiBNb25kYXksIDMgQXVndXN0IDIwMjAgMjE6 MzYNClRvOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJh c3p1ay5uZXQ+Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBw bGljYWJpbGl0eQ0KDQooU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCBy ZWl0ZXJhdGluZyB0aGF0IHRoaXMgaXMgYXMgYQ0KcGFydGljaXBhbnQsIG5vdCBhIFdHIGNoYWly LikNCg0KWWVzLCB3ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNl ZW4gSVAgbmV0d29ya3MgdGhhdA0KY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFsbCBzb3J0 cyBvZiByZWFzb25zLg0KSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5 IG9uZSBtYXkgbm90IHdhbnQgYSByYW5kb20NCnBhdGggcmF0aGVyIHRoYW4gYSBjaG9zZW4gVEUg cGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXINCmFib3V0IHdoYXQgY29u c3RyYWludHMgbWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUgdGhleQ0K aGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0aGF0IGlzIGludGVuZGVkIHRv IHByZXNlcnZlIFFvUy4NCg0KTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0 aGlzIGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQgaXMgYQ0KZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJ IGFtIHRyeWluZyB0byBmaWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2YNCmFkZGl0aW9uYWwg bWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVyeW9uZQ0K Z2V0dGluZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJl aGF2aW9yIHRoZXkNCmRlc2lyZSwgYnV0IHNvbWV0aW1lcyBpcyB0aGUgYmVzdCB3ZSBjYW4gZG8u KQ0KDQpZb3VycywNCkpvZWwNCg0KT24gOC8zLzIwMjAgMjozMCBQTSwgUm9iZXJ0IFJhc3p1ayB3 cm90ZToNCj4gSm9lbCwNCj4NCj4gQXJlIHdlIHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29y a3MgaGVyZSA/IE9yIHBlcmhhcHMgc29tZSBoYXJkDQo+IHNsaWNpbmcgd2l0aCByZWFsIHJlc291 cmNlIHJlc2VydmF0aW9ucyBvciBkZXRuZXRzID8NCj4NCj4gQmVjYXVzZSBpZiB3ZSBhcmUgdGFs a2luZyBhYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d28gb2JzZXJ2YXRpb25zOg0KPg0KPiBB KSBJZiB5b3UgbmVlZCB0byB0cmF2ZXJzZSB2aWEgYSBzcGVjaWZpYyBub2RlIChpZS4gZmlyZXdh bGwpIHlvdSBiZXR0ZXINCj4gYXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuIEkg ZG9uJ3QgdGhpbmsgSVAgZW5jYXBzdWxhdGlvbiBjYW4NCj4gYmUgaGlqYWNrZWQgdG9kYXkgc3Vj aCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpcyBpZ25vcmVkLg0KPg0K PiBCKSBIYXZlIHlvdSBzZWVuIGFueSBJUCBuZXR3b3JrIHdoZXJlIHVwb24gdG9wb2xvZ3kgY2hh bmdlIChsaW5rIG9yIG5vZGUNCj4gZmFpbHVyZSkgeW91IHN1ZGRlbmx5IHN0YXJ0IGRyb3BwaW5n IGZsb3dzIGluIHNwaXRlIG9mIFNQVCBvZmZlcmluZw0KPiBwZXJoYXBzIGZldyBtcyBsb25nZXIg cGF0aCB3aXRoIDEwIG1zIG1vcmUgaml0dGVyID8NCj4NCj4gT3IgYXJlIHNvbWUgU1IgbWFya2V0 aW5nIHNsaWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4NCj4gc29tZXRoaW5nIG5l dyA/IFdvcnNlIC4uLiBkbyB0aGV5IG1lbnRpb24gcGF0aCBxdWFsaXR5IGd1YXJhbnRlZXMsDQo+ IHJlc291cmNlIHJlc2VydmF0aW9ucyA/IEkgaG9wZSBub3QuDQo+DQo+IFRoeCwNCj4gUi4NCj4N Cj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gT24gTW9uLCBBdWcgMywgMjAyMCBhdCA4OjEwIFBN IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tJTIwJTBiPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQo+ DQo+IFdlbGwgbGVzcyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRoZSBwcm9i bGVtIGlzIHJlc3RyaWN0ZWQNCj4gdG8ganVzdCBzZXJ2aWNlIFNJRHMuDQo+DQo+IFN1cHBvc2Ug dGhhdCB0aGUgUENFIGhhcyBzcGVjaWZpZWQgdGhlIHBhdGggdG8gbWVldCBzb21lIGNvbXBsZXgg dGUNCj4gb2JqZWN0aXZlLiAgVGhlIGJ5cGFzcyBub2RlIGhhcyBubyB3YXkgb2Yga25vd2luZyB3 aGF0IHRob3NlDQo+IGNvbnN0cmFpbnRzDQo+IHdlcmUuICBBbmQgZm9yIHNvbWUga2luZHMgb2Yg dHJhZmZpYywgaXQgaXMgYmV0dGVyIHRvIGRyb3AgdGhlIHBhY2tldA0KPiB0aGFuIHRvIGRlbGl2 ZXIgaXQgb3V0c2lkZSB0aGUgZW52ZWxvcC4gIEkgc3VzcGVjdCB0aGF0IHRoZSByaWdodA0KPiBh bnN3ZXINCj4gdG8gdGhpcyBpcyAidG9vIGJhZCIuICBJZiBzbywgYXMgd2l0aCB0aGUgZGlzdGlu Y3Rpb24gcmVnYXJkaW5nIHNlcnZpY2UNCj4gbm9kZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3Vs ZG4ndCB3ZT8NCj4NCj4gWW91cnMsDQo+IEpvZWwNCj4NCj4gT24gOC8zLzIwMjAgMjozNiBBTSwg QWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+ID4gTWFjaCwgSm9lbCBhbmQgYWxsLA0KPiA+ DQo+ID4gSSB0aGluayB0aGF0IGluIG1vc3QgY2FzZXM6DQo+ID4NCj4gPiAxLlRoZXJlIGlzIGNs ZWFyIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuICJ0b3BvbG9naWNhbCIgYW5kICJzZXJ2aWNlIg0K PiA+IGluc3RydWN0aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46DQo+ID4NCj4gPiBv SUdQIFByZWZpeCBOb2RlIFNJRHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4g dGhlDQo+ID4gY29ycmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMpIHJlcHJlc2VudCB0b3Bv bG9naWNhbCBpbnN0cnVjdGlvbnMNCj4gPg0KPiA+IG9TZXJ2aWNlIFNJRHMgZm9yIFNSdjYgKHNl ZSBTUnY2IEJHUC1CYXNlZCBPdmVybGF5IFNlcnZpY2VzDQo+ID4NCj4gPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQ8 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2 Ni1zZXJ2aWNlcy0wND4+DQo+DQo+ID4gZHJhZnQpIHVuc3VycHJpc2luZ2x5IHJlcHJlc2VudCDi gJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucw0KPiA+DQo+ID4gMi5TZWdtZW50cyB0aGF0IHJlcHJl c2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5cGFzc2VkLA0KPiA+IHdoaWxl IHNlZ21lbnRzIHRoYXQgcmVwcmVzZW50IHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHJlcXVpcmUNCj4g YWx0ZXJuYXRpdmUNCj4gPiBwcm90ZWN0aW9uIG1lY2hhbmlzbXMuDQo+ID4NCj4gPiBUaGlzIHZp ZXcgc2VlbXMgdG8gYmUgYWxpZ25lZCB3aXRoIFJGQyA4NDAyDQo+ID4gPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4NDAyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAy Pj4gdGhhdCBzYXlzIGluIFNlY3Rpb24gMToNCj4gPg0KPiA+ICAgICBJbiB0aGUgY29udGV4dCBv ZiBhbiBJR1AtYmFzZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwgdHdvDQo+ID4NCj4gPiB0 b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIElHUC1BZGphY2VuY3kgc2VnbWVu dCBhbmQgdGhlDQo+ID4NCj4gPiAgICAgSUdQLVByZWZpeCBzZWdtZW50Lg0KPiA+DQo+ID4gICAg IEluIHRoZSBjb250ZXh0IG9mIGEgQkdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUs IHR3bw0KPiA+DQo+ID4gdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBCR1Ag cGVlcmluZyBzZWdtZW50IGFuZCB0aGUNCj4gPg0KPiA+ICAgICBCR1AtUHJlZml4IHNlZ21lbnQu DQo+ID4NCj4gPiBJbiB0aGUgY2FzZSBvZiBTUi1NUExTIHRoaXMgZGlmZmVyZW50aWF0aW9uIGlz IGFzc3VtZWQgaW4gU2VjdGlvbg0KPiAzLjQgb2YNCj4gPiB0aGUgTm9kZSBQcm90ZWN0aW9uIGZv ciBTUi1URSBQYXRoDQo+ID4NCj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDcj c2VjdGlvbi0zLjQ8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1o ZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyNzZWN0aW9uLTMu ND4+DQo+DQo+ID4gZHJhZnQgdGhhdCBzYXlzOg0KPiA+DQo+ID4gICAgIFRoZSBub2RlIHByb3Rl Y3Rpb24gbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbnMNCj4gPg0K PiA+ICAgICBkZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVsIGltbWVkaWF0 ZWx5IGJlbG93DQo+IHRoZSB0b3ANCj4gPg0KPiA+IGxhYmVsIGluIHRoZSBsYWJlbCBzdGFjayBp cyB1bmRlcnN0b29kIGluIHRoZSBJR1AgZG9tYWluLiAgV2hlbiB0aGUNCj4gPg0KPiA+ICAgICBw cm92aWRlciBlZGdlIHJvdXRlcnMgZXhjaGFuZ2Ugc2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBz b21lDQo+IG90aGVyDQo+ID4NCj4gPiAgICAgbm9uLUlHUCBtZWNoYW5pc20gdGhlIGJvdHRvbSBs YWJlbCBpcyBub3QgdW5kZXJzdG9vZCBpbiB0aGUgSUdQDQo+ID4NCj4gPiAgICAgZG9tYWluLg0K PiA+DQo+ID4gICAgIFRoZSBlZ3Jlc3Mgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgZGVzY3Jp YmVkIGluIHRoZSBkcmFmdA0KPiA+DQo+ID4gICAgIFtSRkM4Njc5IDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg2Nzk8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9yZmM4Njc5Pj5dIGlzDQo+ID4gYXBwbGljYWJsZSB0byB0aGlzIHVzZSBjYXNl IGFuZCBubyBhZGRpdGlvbmFsIGNoYW5nZXMNCj4gPg0KPiA+ICAgICB3aWxsIGJlIHJlcXVpcmVk IGZvciBTUiBiYXNlZCBuZXR3b3Jrcw0KPiA+DQo+ID4gVGhlIHNjZW5hcmlvcyBpbiB3aGljaCAg ZGlmZmVyZW50aWF0aW9uIGJldHdlZW4g4oCcdG9wb2xvZ2ljYWzigJ0gYW5kDQo+ID4g4oCcc2Vy dmljZeKAnSBpbnN0cnVjdGlvbnMgaXMgYnJva2VuIGFyZSBpbmRlZWQgcHJvYmxlbWF0aWMuIEUu Zy4sDQo+IGNvbnNpZGVyDQo+ID4gdGhlIHVzZSBjYXNlIGluIHdoaWNoIGEgTm9kZSBTSUQgaW4g dGhlIEVSTyBvZiBhIFNSLVRFIHBhdGgNCj4gaWRlbnRpZmllcyBhDQo+ID4gbm9kZSB0aGF0IGFj dHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4sDQo+IHBy b3ZpZGVzDQo+ID4gdGhlIGZpcmV3YWxsIHNlcnZpY2Ugd2l0aG91dCBhbnkgZGVkaWNhdGVkIHNl cnZpY2UgU0lEDQo+IGlkZW50aWZ5aW5nIGl0Lg0KPiA+IE9uZSBjb3VsZCBzYXkgdGhhdCB0aGUg Tm9kZSBTSUQgb2Ygc3VjaCBhIG5vZGUgd291bGQgY29tYmluZQ0KPiB0b3BvbG9naWNhbA0KPiA+ IGFuZCBzZXJ2aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRp b24NCj4gYmV0d2VlbiB0aGUgdHdvLg0KPiA+DQo+ID4gSSBhbSBub3Qgc3VyZSBpZiB1c2FnZSBv ZiBzdWNoIOKAnGNvbWJpbmVk4oCdIFNJRHMgY291bGQgYmUgcHJldmVudGVkDQo+IG9yIGF0DQo+ ID4gbGVhc3QgZGlzY291cmFnZWQuDQo+ID4NCj4gPiBJZiBub3QsIHByb3ZpZGluZyBhbiBhYmls aXR5IHRvIGlkZW50aWZ5IHN1Y2ggU0lEcyBpbiB0aGUNCj4gYWR2ZXJ0aXNlbWVudA0KPiA+IG1l Y2hhbmlzbXMgd291bGQgYmUgdXNlZnVsIElNSE8uDQo+ID4NCj4gPiBNeSAyYywNCj4gPg0KPiA+ IFNhc2hhDQo+ID4NCj4gPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gPg0KPiA+IENlbGw6ICAg ICAgKzk3Mi01NDkyNjYzMDINCj4gPg0KPiA+IEVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+IDxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ID4NCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmcNCjxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI+PiA8bWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1hY2ggQ2hlbg0KPiA+IFNlbnQ6IE1v bmRheSwgQXVndXN0IDMsIDIwMjAgNjozMCBBTQ0KPiA+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20NCjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYj4+IDxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtzcHJp bmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiA+DQo+ ID4gSGkgSm9lbCwNCj4gPg0KPiA+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgcG9pbnQgdGhhdCBt YXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0aGUNCj4gcGFzdC4gQW5kDQo+ID4gSSBhbHNvIGRvbid0 IHRoaW5rIHRoZXJlIGlzIGEgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBpbiB0aGUNCj4g PiByb3V0aW5nIGFkdmVydGlzZW1lbnQgZm9yIG5vdy4NCj4gPg0KPiA+IElNSE8sIHRoZSBpbmZv cm1hdGlvbiBhZHZlcnRpc2VkIGJ5IHJvdXRpbmcgaXMgbmV1dHJhbCwgc3VjaA0KPiBpbmZvcm1h dGlvbg0KPiA+IChjYW4gb3IgY2Fubm90IGJlIGJ5cGFzc2VkKSBpcyBtb3JlIHBhdGggc3BlY2lm aWMsIHRodXMgbm9ybWFsbHkgdGhlDQo+ID4gY29udHJvbGxlciBzaG91bGQgYmUgcmVzcG9uc2li bGUgZm9yIGRlY2lkaW5nIHdoZXRoZXIvd2hpY2ggU0lEDQo+IGNhbiBiZQ0KPiA+IGJ5cGFzc2Vk Lg0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+DQo+ID4gTWFjaA0KPiA+DQo+ID4gID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPg0KPiA+ICA+IEZyb206IHNwcmluZyBbbWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo+IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc+PG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUzY21haWx0bzpzcHJp bmctYm91bmNlc0BpZXRmLm9yZyUzZT5dIE9uIEJlaGFsZiBPZiBKb2VsIE0uDQo+ID4NCj4gPiAg PiBIYWxwZXJuDQo+ID4NCj4gPiAgPiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDc6NTEg QU0NCj4gPg0KPiA+ICA+IFRvOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9y Zz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnIDxt YWlsdG86c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86 c3ByaW5nQGlldGYub3JnPj4+DQo+ID4NCj4gPiAgPiBTdWJqZWN0OiBbc3ByaW5nXSBTcHJpbmcg cHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4gPg0KPiA+ICA+DQo+ID4N Cj4gPiAgPiAoV0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20gYSBz bGlnaHRseQ0KPiBjb25mdXNlZCBXRw0KPiA+DQo+ID4gID4gcGFydGljaXBhbnQuKQ0KPiA+DQo+ ID4gID4NCj4gPg0KPiA+ICA+IEkgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIHZhcmlvdXMgcmVwYWly IGRyYWZ0cywgYW5kIHRoZSB2YXJpb3VzDQo+ID4NCj4gPiAgPiBuZXR3b3JrcyBwcm9ncmFtbWlu ZyBhbmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW0NCj4gdHJ5aW5nIHRvDQo+ ID4NCj4gPiAgPiBmaWd1cmUgb3V0IG9uZSBhc3BlY3Qgb2YgdGhlIGNvbWJpbmF0aW9uLg0KPiA+ DQo+ID4gID4NCj4gPg0KPiA+ICA+IEhvdyBkb2VzIGEgbm9kZSB0aGF0IGlzIGRvaW5nIHNvbWUg Zm9ybSBvZiBieXBhc3MgKHN1cHBvc2UsIGZvcg0KPiA+DQo+ID4gID4gc2ltcGxpY2l0eSwgaXQg aXMgTm9kZSBOMiBkZWNpZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcg0KPiBhIGZhaWxl ZA0KPiA+DQo+ID4gID4gbm9kZSBOMykga25vdyB0aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/DQo+ ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVu IGl0IGlzICJzYWZlIiBpZiB0aGUgbmV3IHBhdGgNCj4gbWVldHMNCj4gPg0KPiA+ICA+IHRoZSBU RSBjcml0ZXJpYS4gIG9yIG1heWJlIGl0IGlzIHNhZmUgaWYgaXQgaXMgZXZlbiBjbG9zZSwgYXMN Cj4gbG9uZyBhcw0KPiA+DQo+ID4gID4gaXQgaXMgbm90IHVzZWQgZm9yIHRvbyBsb25nLg0KPiA+ DQo+ID4gID4NCj4gPg0KPiA+ICA+IEJ1dCB3aGF0IGlmIHRoZSBub2RlIHdlcmUgYSBGaXJld2Fs bCwgaW5jbHVkZWQgdG8gbWVldCBsZWdhbA0KPiA+IHJlcXVpcmVtZW50cz8NCj4gPg0KPiA+ICA+ IE9yIHdhcyBzb21lIG90aGVyIG5lY2Vzc2FyeSBwcm9ncmFtbWF0aWMgdHJhbnNmb3JtICh3aW5j ZSB3ZSBhcmUNCj4gPg0KPiA+ICA+IGRlbGliZXJhdGVseSB2YWd1ZSBhYm91dCB3aGF0IG5vZGVz IGNhbiBkbyB3aGVuIGFza2VkIHN1aXRhYmx5LikNCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBJ cyB0aGVyZSBzb21lICJjYW4gYmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmcN Cj4gPg0KPiA+ICA+IGFkdmVydGlzZW1lbnRzIHRoYXQgSSBtaXNzZWQ/DQo+ID4NCj4gPiAgPg0K PiA+DQo+ID4gID4gVGhhbmsgeW91LA0KPiA+DQo+ID4gID4gWW91cnMsDQo+ID4NCj4gPiAgPiBK b2VsDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPg0KPiA+ICA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4g Pg0KPiA+ICA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4NCj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+Pj4NCj4gPg0KPiA+ICA+DQo+ID4NCj4gaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjxodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUy Pg0KPiA+DQo+IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1 R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTI8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyPj4NCj4gPg0KPiA+ICA+ IEYlMkZ3d3cuaWV0Zi5vcmc8aHR0cDovLzJGd3d3LmlldGYub3JnPg0KPiA8aHR0cDovLzJGd3d3 LmlldGYub3JnPGh0dHA6Ly8yRnd3dy5pZXRmLm9yZz4+JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c3ByaW5nDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+DQo+ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiA+DQo+ID4gc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4+DQo+ID4NCj4gPg0KPiBodHRwczovL2NsaWNrdGltZS5zeW1h bnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5p ZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzxodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZz4NCj4gPg0KPiA+DQo+ID4N Cj4gPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVy IHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluDQo+ID4gaW5mb3JtYXRpb24gb2YgUmli Ym9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwNCj4gYW5kL29yDQo+ ID4gcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LiBBbnkgcmV2aWV3LA0KPiA+IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBi eSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0DQo+ID4gZXhwcmVzcyBwZXJtaXNzaW9uIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZQ0KPiBpbnRlbmRlZA0KPiA+ IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVu IGRlbGV0ZSBhbGwNCj4gPiBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuDQo+ID4N Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gPiBzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc+DQo+ID4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3ByaW5nIG1haWxp bmcgbGlzdA0KPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPg0K Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3By aW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZz4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3ByaW5nPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nPg0K --_000_VI1PR03MB5056B7BBAFE9BE2BD1BECDA2EE4A0VI1PR03MB5056eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLmdtYWlsLW0tNzExNzU5MjIxODcyNDM4MDMyMW1zb2xpc3RwYXJhZ3Jh cGgsIGxpLmdtYWlsLW0tNzExNzU5MjIxODcyNDM4MDMyMW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5n bWFpbC1tLTcxMTc1OTIyMTg3MjQzODAzMjFtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1u YW1lOmdtYWlsLW1fLTcxMTc1OTIyMTg3MjQzODAzMjFtc29saXN0cGFyYWdyYXBoOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwMTAxODM5OTY7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjIwNDMzMzA3NDY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUtFIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5HcmVnIHdlIGVmZmVjdGl2ZWx5IGdldCB0aGlzIHVzaW5nIHNiZmQgYW5kIGZhbGwgYmFj ayBwYXRocyBhdCB0aGUgbW9tZW50IOKAkyBmYXIgZnJvbSBpZGVhbCDigJMgYnV0IGl0IGRvZXMg d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSBhcmUgYWxzbyBvdGhl ciBtZXRob2RzIG9mIGRldGVjdGluZyBlbmQgdG8gZW5kIHJlYWNoYWJpbGl0eSB0byBkbyBibGFj a2hvbGUgZGV0ZWN0aW9uIGV0YyDigJMgcGFydGljdWxhcmx5IGluIHRoZSBmYWNlIG9mIHRoZSBm YWN0IHRoYXQgSeKAmXZlIHlldCB0byBzZWUgYSBmdW5jdGlvbmFsIGltcGxpY2F0aW9uIG9mDQog dGhlIHNpZCB2ZXJpZmljYXRpb24gZmxhZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5Db3VsZCB0aGluZ3MgYmUgaW1wcm92ZWQgdGhpcyByZWdhcmQ/IDEwMCUgYnV0IGZvciBub3cg 4oCTIHRoZSBkZWVwIHNlYXRlZCBhbmQgY3JpdGljYWwgbmVlZCBmb3IgdGhlIHJlcXVpcmVtZW50 IG92ZXJyaWRlcyB0aGUgZHJhd2JhY2tzIG9mIHRoZSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgd2Ug YXJlIGZvcmNlZCB0byB1c2UNCiBhdCB0aGlzIHBvaW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iZW4tS0UiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEdyZWcgTWlyc2t5ICZsdDtn cmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgNCBB dWd1c3QgMjAyMCAwMTo0MDxicj4NCjxiPlRvOjwvYj4gQW5kcmV3IEFsc3RvbiAmbHQ7QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEpvZWwgTS4gSGFs cGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7IFJvYmVydCBSYXN6dWsgJmx0O3JvYmVy dEByYXN6dWsubmV0Jmd0Ozsgc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIEFuZHJldyw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij53b3VsZCBzdWNoIHJlcXVpcmVtZW50cyBzdXBwb3J0IHVzaW5nIGUyZSBwcm90 ZWN0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+R3JlZzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDI6 NDYgUE0gQW5kcmV3IEFsc3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlx dWlkdGVsZWNvbS5jb20iPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+U28g4oCTIDwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj5PbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2ZXJ5 IG1ham9yIHVzZSBjYXNlcyBpbiBhbnkgc3ByaW5nIHRlY2hub2xvZ3kgZm9yIHVzIHJldm9sdmUg YXJvdW5kIHRoZSBmb2xsb3dpbmc8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNzExNzU5MjIxODcyNDM4MDMyMW1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBsYW5nPSJlbi1LRSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9kZXM8L3NwYW4+ PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tLTcxMTc1OTIyMTg3MjQzODAzMjFtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iZW4tS0UiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGV4cGxpY2l0IGF2b2lkYW5j ZSBvZiBjZXJ0YWluIHNlY3Rpb25zIG9mIHRoZSBuZXR3b3JrPC9zcGFuPjxzcGFuIGxhbmc9ImVu LUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkFueXRoaW5nIHRoYXQgY291 bGQgcmVzdWx0IGluIHRoYXQgZXhwbGljaXQgYXZvaWRhbmNlIGJlaW5nIHZpb2xhdGVkIOKAkyB3 b3VsZCBjcmVhdGUsIHNoYWxsIHdlIHNheSBzaWduaWZpY2FudCBwcm9ibGVtcy48L3NwYW4+PHNw YW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+TXVjaCBv ZiB0aGUgdXNlIGNhc2UgaXMgbm90IGEgY2FzZSBvZiB3aGljaCBub2RlcyB0aGUgcGFja2V0cyBm bG93IHRocm91Z2gg4oCTIGJ1dCByYXRoZXIg4oCTIHdoaWNoIG5vZGVzIC8gbmV0d29yayBzZWdt ZW50cyBpdCBjYW4gbmV2ZXIgdG91Y2ggb3IgZmxvdyB0aHJvdWdoLiZuYnNwOyBFZmZlY3RpdmVs eSwgdG8gYmUgdXNlZCBhcyBhIHRlY2hub2xvZ3kgdG8gYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9y IHNwZWNpZmljIHJlYXNvbnMuPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9y IG5lZWRpbmcgc3VjaCBkZWVwIGxhYmVsIHN0YWNrcyDigJMgdGhpcyBraW5kIG9mIGRldGFpbGVk IHBhdGggcHJvZ3JhbW1pbmcgdGVuZHMgdG8gZGVlcGVuIHRoZSBzdGFjayBiZWNhdXNlIHlvdSBz b21ldGltZXMgaGF2ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuPC9zcGFuPjxzcGFuIGxhbmc9ImVu LUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkl0IGlzIGFic29sdXRlbHkg Y3JpdGljYWwgdG8gdXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUg4oCTIGFuZCB0 aGF0IHdlIGNhbiBhdm9pZCBzaXR1YXRpb25zIHdoaWNoIGNvdWxkIGNhdXNlIHRyYWZmaWMgdG8g YWNjaWRlbnRseSBoaXQgdGhpbmdzIGV4cGxpY2l0bHkgYXZvaWRlZC48L3NwYW4+PHNwYW4gbGFu Zz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SSB3aXNoIEkgY291 bGQgYmUgbW9yZSBzcGVjaWZpYyB0aGFuIHRoaXMsIGJ1dCBpdCBpcyB3aGF0IGl0IGlzLjwvc3Bh bj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5U aGFua3M8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+QW5kcmV3PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K PHNwYW4gbGFuZz0iZW4tS0UiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6NzIuMHB0Ij4NCjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiPiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsN CjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgMyBBdWd1c3QgMjAyMCAyMTozNjxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFJhc3p1ayAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9i ZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5p bmcgYXBwbGljYWJpbGl0eTwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iZW4tS0UiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFu Zz0iZW4tS0UiPihTaW5jZSB0aGUgdGhyZWFkIGhhcyBnb3R0ZW4gbG9uZyBlbm91Z2gsIHJlaXRl cmF0aW5nIHRoYXQgdGhpcyBpcyBhcyBhDQo8YnI+DQpwYXJ0aWNpcGFudCwgbm90IGEgV0cgY2hh aXIuKTxicj4NCjxicj4NClllcywgd2UgYXJlIHRhbGtpbmcgSVAgbmV0d29ya3MuIEFuZCB5ZXMs IEkgaGF2ZSBzZWVuIElQIG5ldHdvcmtzIHRoYXQgPGJyPg0KY2hvb3NlIHRvIGRyb3AgcGFja2V0 cy4gRm9yIGFsbCBzb3J0cyBvZiByZWFzb25zLjxicj4NCkkgdGhpbmsgdGhlcmUgYXJlIGxpa2Vs eSBvdGhlciByZWFzb25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9tIDxicj4NCnBhdGgg cmF0aGVyIHRoYW4gYSBjaG9zZW4gVEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2Ug YmUgY2xlYXIgPGJyPg0KYWJvdXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlvbGF0 ZWQgd2hlbiB3ZSB0ZWxsIHBlb3BsZSB0aGV5IDxicj4NCmhhdmUgdGhpcyB0b29sIChwcm90ZWN0 aXZlIHJlcm91dGluZykgdGhhdCBpcyBpbnRlbmRlZCB0byBwcmVzZXJ2ZSBRb1MuPGJyPg0KPGJy Pg0KTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlzIGlzIG5vdCBhIGdv b2QgaWRlYS4gSXQgaXMgYSA8YnI+DQpnb29kIGlkZWEuIEFuZCB1c2VmdWwuIEkgYW0gdHJ5aW5n IHRvIGZpZ3VyZSBvdHUgd2hhdCBjb21iaW5hdGlvbiBvZiA8YnI+DQphZGRpdGlvbmFsIG1lY2hh bmlzbXMgYW5kIGNsZWFyIGRlc2NyaXB0aW9ucyB3aWxsIGxlYWQgdG8gZXZlcnlvbmUgPGJyPg0K Z2V0dGluZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJl aGF2aW9yIHRoZXkgPGJyPg0KZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBiZXN0IHdlIGNh biBkby4pPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCk9uIDgvMy8yMDIw IDI6MzAgUE0sIFJvYmVydCBSYXN6dWsgd3JvdGU6PGJyPg0KJmd0OyBKb2VsLDxicj4NCiZndDsg PGJyPg0KJmd0OyBBcmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JrcyZuYnNwO2hl cmUgPyBPciBwZXJoYXBzIHNvbWUgaGFyZCA8YnI+DQomZ3Q7IHNsaWNpbmcgd2l0aCByZWFsIHJl c291cmNlIHJlc2VydmF0aW9ucyBvciBkZXRuZXRzID88YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVj YXVzZSZuYnNwO2lmIHdlIGFyZSB0YWxraW5nJm5ic3A7YWJvdXQgSVAgbmV0d29ya2luZyBJIGhh dmUgdHdvIG9ic2VydmF0aW9uczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSkgSWYgeW91IG5lZWQg dG8gdHJhdmVyc2UgdmlhIGEgc3BlY2lmaWMgbm9kZSAoaWUuIGZpcmV3YWxsKSB5b3UgYmV0dGVy IDxicj4NCiZndDsgYXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuIEkgZG9uJ3Qg dGhpbmsgSVAgZW5jYXBzdWxhdGlvbiZuYnNwO2NhbiA8YnI+DQomZ3Q7IGJlIGhpamFja2VkIHRv ZGF5IHN1Y2ggdGhhdCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXMgaWdub3Jl ZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3 aGVyZSB1cG9uIHRvcG9sb2d5IGNoYW5nZSAobGluayBvciBub2RlIDxicj4NCiZndDsgZmFpbHVy ZSkgeW91IHN1ZGRlbmx5Jm5ic3A7c3RhcnQgZHJvcHBpbmcmbmJzcDtmbG93cyBpbiBzcGl0ZSBv ZiBTUFQgb2ZmZXJpbmcgPGJyPg0KJmd0OyBwZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRo IDEwIG1zIG1vcmUgaml0dGVyID88YnI+DQomZ3Q7IDxicj4NCiZndDsgT3IgYXJlIHNvbWUgU1Ig bWFya2V0aW5nIHNsaWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4gPGJyPg0KJmd0 OyBzb21ldGhpbmcmbmJzcDtuZXcgPyBXb3JzZSAuLi4gZG8gdGhleSBtZW50aW9uIHBhdGggcXVh bGl0eSBndWFyYW50ZWVzLCA8YnI+DQomZ3Q7IHJlc291cmNlIHJlc2VydmF0aW9ucyZuYnNwOz8g SSBob3BlIG5vdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGh4LDxicj4NCiZndDsgUi48YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIE1vbiwgQXVn IDMsIDIwMjAgYXQgODoxMCBQTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tJTIwJTBiIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJu LmNvbQ0KPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZn dDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlbGwgbGVzcyBzZXJpb3VzIGZvciBURSBT SURzLCBJIGFtIG5vdCBzdXJlIHRoZSBwcm9ibGVtIGlzIHJlc3RyaWN0ZWQ8YnI+DQomZ3Q7IHRv IGp1c3Qgc2VydmljZSBTSURzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdXBwb3NlIHRoYXQgdGhl IFBDRSBoYXMgc3BlY2lmaWVkIHRoZSBwYXRoIHRvIG1lZXQgc29tZSBjb21wbGV4IHRlPGJyPg0K Jmd0OyBvYmplY3RpdmUuJm5ic3A7IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dp bmcgd2hhdCB0aG9zZTxicj4NCiZndDsgY29uc3RyYWludHM8YnI+DQomZ3Q7IHdlcmUuJm5ic3A7 IEFuZCBmb3Igc29tZSBraW5kcyBvZiB0cmFmZmljLCBpdCBpcyBiZXR0ZXIgdG8gZHJvcCB0aGUg cGFja2V0PGJyPg0KJmd0OyB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lkZSB0aGUgZW52ZWxvcC4m bmJzcDsgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0PGJyPg0KJmd0OyBhbnN3ZXI8YnI+DQomZ3Q7 IHRvIHRoaXMgaXMgJnF1b3Q7dG9vIGJhZCZxdW90Oy4mbmJzcDsgSWYgc28sIGFzIHdpdGggdGhl IGRpc3RpbmN0aW9uIHJlZ2FyZGluZyBzZXJ2aWNlPGJyPg0KJmd0OyBub2Rlcywgd2Ugc2hvdWxk IHNheSBzbywgc2hvdWxkbid0IHdlPzxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3Vycyw8YnI+DQom Z3Q7IEpvZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gOC8zLzIwMjAgMjozNiBBTSwgQWxleGFu ZGVyIFZhaW5zaHRlaW4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IE1hY2gsIEpvZWwgYW5kIGFsbCw8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGF0IGluIG1vc3QgY2FzZXM6 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDEuVGhlcmUgaXMgY2xlYXIgZGlmZmVyZW50 aWF0aW9uIGJldHdlZW4gJnF1b3Q7dG9wb2xvZ2ljYWwmcXVvdDsgYW5kICZxdW90O3NlcnZpY2Um cXVvdDs8YnI+DQomZ3Q7ICZndDsgaW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4g RS5nLjo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgb0lHUCBQcmVmaXggTm9kZSBTSURz IElHUCBBZGotU0lEcyAoaWRlbnRpZmllZCBhcyBzdWNoIGluIHRoZTxicj4NCiZndDsgJmd0OyBj b3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50cykgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGlu c3RydWN0aW9uczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBvU2VydmljZSBTSURzIGZv ciBTUnY2IChzZWUgU1J2NiBCR1AtQmFzZWQgT3ZlcmxheSBTZXJ2aWNlczxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmVzcy1zcnY2 LXNlcnZpY2VzLTA0PC9hPiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBkcmFmdCkgdW5z dXJwcmlzaW5nbHkgcmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9wb2xvZ2lj YWwgaW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCw8YnI+DQomZ3Q7ICZndDsgd2hpbGUgc2Vn bWVudHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMgcmVxdWlyZTxicj4NCiZn dDsgYWx0ZXJuYXRpdmU8YnI+DQomZ3Q7ICZndDsgcHJvdGVjdGlvbiBtZWNoYW5pc21zLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlzIHZpZXcgc2VlbXMgdG8gYmUgYWxpZ25lZCB3 aXRoIFJGQyA4NDAyPGJyPg0KJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjODQwMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4NDAyPC9hPiZndDsgdGhhdCBzYXlzIGluIFNlY3Rpb24gMTo8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IEluIHRoZSBjb250ZXh0IG9m IGFuIElHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJ R1AtQWRqYWNlbmN5IHNlZ21lbnQgYW5kIHRoZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmbmJzcDsmbmJzcDsgSUdQLVByZWZpeCBzZWdtZW50Ljxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1At YmFzZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwgdHdvPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJp bmcgc2VnbWVudCBhbmQgdGhlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyZuYnNwOyBCR1AtUHJlZml4IHNlZ21lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMgdGhpcyBkaWZmZXJlbnRpYXRpb24gaXMgYXNzdW1l ZCBpbiBTZWN0aW9uPGJyPg0KJmd0OyAzLjQgb2Y8YnI+DQomZ3Q7ICZndDsgdGhlIE5vZGUgUHJv dGVjdGlvbiBmb3IgU1ItVEUgUGF0aDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmx0OzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGVnZGUtc3By aW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDcjc2VjdGlvbi0zLjQiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWhl Z2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3I3NlY3Rpb24tMy40 PC9hPiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBkcmFmdCB0aGF0IHNheXM6PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgbm9kZSBwcm90 ZWN0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb25zPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBkZXBlbmRzIG9uIHRo ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVsIGltbWVkaWF0ZWx5IGJlbG93PGJyPg0KJmd0OyB0 aGUgdG9wPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGxhYmVsIGluIHRoZSBsYWJlbCBz dGFjayBpcyB1bmRlcnN0b29kIGluIHRoZSBJR1AgZG9tYWluLiZuYnNwOyBXaGVuIHRoZTxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgcHJvdmlkZXIgZWRn ZSByb3V0ZXJzIGV4Y2hhbmdlIHNlcnZpY2UgbGFiZWxzIHZpYSBCR1Agb3Igc29tZTxicj4NCiZn dDsgb3RoZXI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7 IG5vbi1JR1AgbWVjaGFuaXNtIHRoZSBib3R0b20gbGFiZWwgaXMgbm90IHVuZGVyc3Rvb2QgaW4g dGhlIElHUDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsg ZG9tYWluLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsg VGhlIGVncmVzcyBub2RlIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhlIGRy YWZ0PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBbUkZD ODY3OSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9y ZmM4Njc5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9yZmM4Njc5PC9hPiZndDtdIGlzPGJyPg0KJmd0OyAmZ3Q7IGFwcGxpY2FibGUgdG8gdGhp cyB1c2UgY2FzZSBhbmQgbm8gYWRkaXRpb25hbCBjaGFuZ2VzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyB3aWxsIGJlIHJlcXVpcmVkIGZvciBTUiBiYXNl ZCBuZXR3b3Jrczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgc2NlbmFyaW9zIGlu IHdoaWNoICZuYnNwO2RpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs4oCdIGFu ZDxicj4NCiZndDsgJmd0OyDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBicm9rZW4gYXJl IGluZGVlZCBwcm9ibGVtYXRpYy4gRS5nLiw8YnI+DQomZ3Q7IGNvbnNpZGVyPGJyPg0KJmd0OyAm Z3Q7IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUgU0lEIGluIHRoZSBFUk8gb2YgYSBTUi1U RSBwYXRoPGJyPg0KJmd0OyBpZGVudGlmaWVzIGE8YnI+DQomZ3Q7ICZndDsgbm9kZSB0aGF0IGFj dHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4sPGJyPg0K Jmd0OyBwcm92aWRlczxicj4NCiZndDsgJmd0OyB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRob3V0 IGFueSBkZWRpY2F0ZWQgc2VydmljZSBTSUQ8YnI+DQomZ3Q7IGlkZW50aWZ5aW5nIGl0Ljxicj4N CiZndDsgJmd0OyBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2ggYSBub2Rl IHdvdWxkIGNvbWJpbmU8YnI+DQomZ3Q7IHRvcG9sb2dpY2FsPGJyPg0KJmd0OyAmZ3Q7IGFuZCBz ZXJ2aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRpb248YnI+ DQomZ3Q7IGJldHdlZW4gdGhlIHR3by48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBh bSBub3Qgc3VyZSBpZiB1c2FnZSBvZiBzdWNoIOKAnGNvbWJpbmVk4oCdIFNJRHMgY291bGQgYmUg cHJldmVudGVkPGJyPg0KJmd0OyBvciBhdDxicj4NCiZndDsgJmd0OyBsZWFzdCBkaXNjb3VyYWdl ZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgbm90LCBwcm92aWRpbmcgYW4gYWJp bGl0eSB0byBpZGVudGlmeSBzdWNoIFNJRHMgaW4gdGhlPGJyPg0KJmd0OyBhZHZlcnRpc2VtZW50 PGJyPg0KJmd0OyAmZ3Q7IG1lY2hhbmlzbXMgd291bGQgYmUgdXNlZnVsIElNSE8uPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE15IDJjLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBTYXNoYTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPZmZpY2U6ICs5NzItMzkyNjYz MDI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQ2VsbDombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKzk3Mi01NDkyNjYzMDI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg RW1haWw6IDxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPjxicj4N CiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnPC9hPiZndDsmZ3Q7IE9uIEJlaGFsZiBPZiBNYWNoIENoZW48YnI+DQomZ3Q7ICZndDsgU2Vu dDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMwIEFNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBKb2Vs IE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiIiB0 YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9 Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGll dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmlu ZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBIaSBKb2VsLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIHRo aW5rIHRoaXMgaXMgYSBnb29kIHBvaW50IHRoYXQgbWF5IG5vdCBiZSBkaXNjdXNzZWQgaW4gdGhl PGJyPg0KJmd0OyBwYXN0LiBBbmQ8YnI+DQomZ3Q7ICZndDsgSSBhbHNvIGRvbid0IHRoaW5rIHRo ZXJlIGlzIGEgJnF1b3Q7Y2FuIGJlIGJ5cGFzc2VkJnF1b3Q7IGluZGljYXRpb24gaW4gdGhlPGJy Pg0KJmd0OyAmZ3Q7IHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCBmb3Igbm93Ljxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBJTUhPLCB0aGUgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBieSByb3V0 aW5nIGlzIG5ldXRyYWwsIHN1Y2g8YnI+DQomZ3Q7IGluZm9ybWF0aW9uPGJyPg0KJmd0OyAmZ3Q7 IChjYW4gb3IgY2Fubm90IGJlIGJ5cGFzc2VkKSBpcyBtb3JlIHBhdGggc3BlY2lmaWMsIHRodXMg bm9ybWFsbHkgdGhlPGJyPg0KJmd0OyAmZ3Q7IGNvbnRyb2xsZXIgc2hvdWxkIGJlIHJlc3BvbnNp YmxlIGZvciBkZWNpZGluZyB3aGV0aGVyL3doaWNoIFNJRDxicj4NCiZndDsgY2FuIGJlPGJyPg0K Jmd0OyAmZ3Q7IGJ5cGFzc2VkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBCZXN0IHJl Z2FyZHMsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE1hY2g8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEZyb206IHNwcmluZyBbPGEgaHJl Zj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiJTNlJTIwJTNjbWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnJTNlIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPGJyPg0KJmd0OyAmbHQ7bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn Jmd0OzwvYT5dIE9uIEJlaGFsZiBPZiBKb2VsIE0uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgSGFscGVybjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMsIDIwMjAgNzo1MSBBTTxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNw cmluZ0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IFN1YmplY3Q6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgKFdHIENoYWlyIGhhdCBPZmYsIHRoaXMgaXMgbWVyZWx5IGEgbm90ZSBmcm9t IGEgc2xpZ2h0bHk8YnI+DQomZ3Q7IGNvbmZ1c2VkIFdHPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgcGFydGljaXBhbnQuKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg SSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZh cmlvdXM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBuZXR3b3JrcyBw cm9ncmFtbWluZyBhbmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW08YnI+DQom Z3Q7IHRyeWluZyB0bzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGZp Z3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUgY29tYmluYXRpb24uPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2YgYnlwYXNz IChzdXBwb3NlLCBmb3I8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBz aW1wbGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQg Zm9yPGJyPg0KJmd0OyBhIGZhaWxlZDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7IG5vZGUgTjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRvIHNvPzxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0IGlzICZx dW90O3NhZmUmcXVvdDsgaWYgdGhlIG5ldyBwYXRoPGJyPg0KJmd0OyBtZWV0czxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IHRoZSBURSBjcml0ZXJpYS4mbmJzcDsgb3Ig bWF5YmUgaXQgaXMgc2FmZSBpZiBpdCBpcyBldmVuIGNsb3NlLCBhczxicj4NCiZndDsgbG9uZyBh czxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGl0IGlzIG5vdCB1c2Vk IGZvciB0b28gbG9uZy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEJ1dCB3aGF0IGlmIHRoZSBu b2RlIHdlcmUgYSBGaXJld2FsbCwgaW5jbHVkZWQgdG8gbWVldCBsZWdhbDxicj4NCiZndDsgJmd0 OyByZXF1aXJlbWVudHM/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg T3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0cmFuc2Zvcm0gKHdpbmNl IHdlIGFyZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGRlbGliZXJh dGVseSB2YWd1ZSBhYm91dCB3aGF0IG5vZGVzIGNhbiBkbyB3aGVuIGFza2VkIHN1aXRhYmx5Lik8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IElzIHRoZXJlIHNvbWUgJnF1b3Q7Y2FuIGJlIGJ5cGFz c2VkJnF1b3Q7IGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmc8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPzxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgVGhhbmsgeW91LDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7IFlvdXJzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7IEpvZWw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnICZsdDtt YWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0 dHBzJTNBJTIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8L2E+PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0 NkgyP3U9aHR0cHMlM0ElMjUyPC9hPiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyBGJTxhIGhyZWY9Imh0dHA6Ly8yRnd3dy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjJGd3d3LmlldGYub3JnPC9hPjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly8yRnd3 dy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly8yRnd3dy5pZXRmLm9yZzwvYT4mZ3Q7 JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nQGlldGYub3JnPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9h PiZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2 SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2 N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQomZ3Q7ICZndDsgTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBh dHRhY2htZW50cyBtYXkgY29udGFpbjxicj4NCiZndDsgJmd0OyBpbmZvcm1hdGlvbiBvZiBSaWJi b24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbDxicj4NCiZndDsgYW5k L29yPGJyPg0KJmd0OyAmZ3Q7IHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldyw8YnI+DQomZ3Q7ICZndDsgZGlzY2xvc3VyZSwg cmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQ8 YnI+DQomZ3Q7ICZndDsgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu IElmIHlvdSBhcmUgbm90IHRoZTxicj4NCiZndDsgaW50ZW5kZWQ8YnI+DQomZ3Q7ICZndDsgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVs ZXRlIGFsbDxicj4NCiZndDsgJmd0OyBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMu PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGll dGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8 L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzcHJpbmcgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJp bmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nPC9hPjxicj4NCiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR03MB5056B7BBAFE9BE2BD1BECDA2EE4A0VI1PR03MB5056eurp_-- From nobody Mon Aug 3 17:11:21 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B5E3A0CEC for ; Mon, 3 Aug 2020 17:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WonZXvIi_FnX for ; Mon, 3 Aug 2020 17:11:16 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD24B3A0D91 for ; Mon, 3 Aug 2020 17:11:15 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2057.outbound.protection.outlook.com [104.47.13.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-137--MNbbi4UNLqaiE1WISQRDA-1; Tue, 04 Aug 2020 01:11:01 +0100 X-MC-Unique: -MNbbi4UNLqaiE1WISQRDA-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB6207.eurprd03.prod.outlook.com (2603:10a6:800:131::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Tue, 4 Aug 2020 00:10:59 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117%3]) with mapi id 15.20.3239.021; Tue, 4 Aug 2020 00:10:59 +0000 From: Andrew Alston To: Robert Raszuk CC: "Joel M. Halpern" , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfFqqBapiFGQU+SeGw1le2xJKklun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADOyIIAADM+AgAAb/iA= Date: Tue, 4 Aug 2020 00:10:59 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2c0f:fe40:3:2:1f5:9343:5fd4:b3ae] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e9d29cc2-e963-444d-60bc-08d8380adda8 x-ms-traffictypediagnostic: VI1PR03MB6207: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z1pSdmrs4+qcgVTnLWs/GiwQEdr3VQwUF3xjAyxL75ZqpBRj1ljW0g7mlnNTHdAxomdSSqtjtnYXrB5qQQ4S1zVRrdKhTwjzjHzV9RbcwUTyu0SMusLITzhw4MNiyo3W75wdEs2hk4DOUI0dlUbZcKoK48D2QYaUgspfu8ENJ1/klq+kShdqRI9u7W3yLUHiYP5zYkH2gB7RN3oSDOuHmXYCsZ6PZGYGmPGeaY/YX+S2yKMCunvxi2vn/kJ2kjJSCTmX6p7uxKEJFM7JX06wJNXTY3teR/ZMYLy3oyVf0bzk06wWA6IopjZMNShdKAw70LOrTCPpjzSwCOLJdWTzzKjaKTA+RFdRSMOHZuhuvAryg76mXzqmRrSzeSLNIku+20QmtdiyLGdM9DMUY7g+6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(8936002)(966005)(8676002)(55016002)(2906002)(7696005)(498600001)(4326008)(6916009)(9686003)(86362001)(5660300002)(76116006)(52536014)(64756008)(66556008)(54906003)(30864003)(71200400001)(166002)(33656002)(66476007)(186003)(83380400001)(53546011)(6506007)(66946007)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: jCvqHS4qurSu6fWiI6vkR5LJKeLadUL6LKhRXm6hJ/+2qJ1zVCn+cks51RfF2ebPhIEPSWdhytyGERbfVZ6YqYZsX8/UGk9Vc87PDGqkf+760Uhz6ap7O/LWRbvtZzfsU18OItZiXUGAGpp4TZ8jkMkFyHZQczTfyrZTCBo9R5xulvoUp/zU3HijwKYbS6h8aJLEcSO2XXfpkE/eGm+27WjQZ/08UkOYeVMH1oqFCBdoB20lW+y/4BodWPwZRady6rcpIO6TzX1WeHzhRrIkZDl3NEn9rnsg2TVj5QX951ftDl1FJIOEgzXLlbJLXz1D1e2z90+h2ag87joN0SXO3tbjbJ1Lwo5qc68LJq3AsiwLoRUNkVqSCk9wNBQFNMmOmnMdCopybF0iYqdaKwHq7CtC8Uh+u+mD6sZQ7YT40fZV25s7Op2q3DUOdIttvqNaDgZPdZodgK5L1HGIVl6zKDCg5SZm2urQeYeP0mf+AElBU703n77MAh9MRDDhPx8dXS1qjpaelqSiZes4yegVx/qWsqeRynFkeVesou11CJuZLspirnZ8WvEMLiZfA7/B9uZ8ysKXB1mqjUxSMEbOK25pXG1RhdjbUvXWYoqNL1ZRDrRUqujgUaBN/uzbFp6+AMqTajYvR3BGMPoW2l5hiFUoyYGqyz4CCcZGoA8+4yH+d0zt+Y5KiVwIX/ued3JW+n8ClA5zoktJMJgwLJrrLA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR03MB5056.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9d29cc2-e963-444d-60bc-08d8380adda8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 00:10:59.1933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9/Rqr/bYd5f3RdbrTddWU2XnifTTlIPBBjObSzkc1ehNhTEUNZfwCCFq56W9upXiXbkRI4PKClQb1XOf7QSvfyNuUmBRZbHUQitdt/mppWo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6207 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056610F42282B6883CED19EEE4A0VI1PR03MB5056eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 00:11:19 -0000 --_000_VI1PR03MB5056610F42282B6883CED19EEE4A0VI1PR03MB5056eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Um9iZXJ0IHRoaXMgaXMgYWN0dWFsbHkgZmFyIG1vcmUgZGlmZmljdWx0IHdoZW4g4oCTIGl0IGNh biBiZSBhbiBlbnRpcmUgKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0IG5lZWQgdG8gYmUgYXZv aWRlZC4NCg0KSXQgY291bGQgcG90ZW50aWFsbHkgYmUgbWFkZSB0byB3b3JrIGJ1dCBJ4oCZZCB3 b3JyeSB0aGF0IHRvIGRvIHRoaXMg4oCTIHlvdeKAmWQgaGF2ZSB0byBzdGFjayAxMCDigJMgMjAg 4oCTIDMwIG5lZ2F0aXZlIGxhYmVscyDigJMgYW5kIHRoYXQgd291bGRu4oCZdCBiZSB2aWFibGUu DQoNCkl04oCZcyBlYXNpZXIgdG8gdXNlIGFsZ29yaXRobXMgYW5kIGFkamFjZW5jeSBzaWRzIGFu ZCBvdGhlciBzdWNoIHRoaW5ncyB0byBjYWxjdWxhdGUgcGF0aHMg4oCTIHRoZSBiaWdnZXN0IHRy aWNrIGlzIGFib3V0IHRoZSBzdGFjayBkZXB0aC4gIFdoZW4geW91IGhhdmUgdGhpcyBuZWVkIGZv ciBub2RlIGF2b2lkYW5jZSDigJMgdGhlIG5lZWQgZm9yIDEwKyBsYWJlbCBkZXB0aCBpcyBjcml0 aWNhbCDigJMgdW5sZXNzIHlvdSB3YW5uYSBiZSBhcHBseWluZyBvbmUgaGVsbCBvZiBhIGxvdCBv ZiBiaW5kaW5nIGxhYmVscyBhbG9uZyB0aGUgd2F5IHdoaWNoIGlzIGEgbmlnaHRtYXJlLg0KDQpC dXQgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGlzIHRoaXMgYSBjb21tb24gdXNlIGNhc2Ug4oCT IGl04oCZcyBhIHVzZSBjYXNlIHRoYXQgbW9zdCBvZiB0aGUgcGVvcGxlIEkgZGlzY3VzcyB0aGlz IHdpdGggY2VydGFpbiBoYXZlIOKAkyBJIGNhbnQgIGNvbW1lbnQgb24gYSBnbG9iYWwgc2NhbGUs IG9yIGZvciBhbnlvbmUgZWxzZSwgYnV0IGV2ZXJ5IGluZGljYXRpb24gSSBoYXZlIGlzIHRoYXQg eWVzIOKAkyBpdHMgc29tZXRoaW5nIHBlb3BsZSBuZWVkLCBhbmQgd2FudA0KDQpBbmRyZXcNCg0K DQpGcm9tOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NClNlbnQ6IFR1ZXNkYXks IDQgQXVndXN0IDIwMjAgMDE6MjcNClRvOiBBbmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9uQGxp cXVpZHRlbGVjb20uY29tPg0KQ2M6IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNv bT47IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0 aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KDQoNCklzIHRoaXMgYSBjb21tb24gdXNl IGNhc2UgaWUuICAiYnV0IHJhdGhlciDigJMgd2hpY2ggbm9kZXMgLyBuZXR3b3JrIHNlZ21lbnRz IGl0IGNhbiBuZXZlciB0b3VjaCBvciBmbG93IHRocm91Z2guIg0KDQpJZiBzbyBwZXJoYXBzIGl0 cyB0aW1lIHRvIGRlZmluZSBub3Rpb24gb2YgbmVnYXRpdmUtU0lEIGllLiBsaXN0IGluIHRoZSBw YWNrZXQgcmVzb3VyY2VzIHdoaWNoIGdpdmVuIHBhY2tldCBNVVNUIG5vdCBldmVyIHRyYXZlcnNl Lg0KDQpQdXQgaW4gdGhlIHBhY2tldCBzZXQgb2Ygbm9kZXMgb3IgbGlua3Mgd2hpY2ggdGhlIHBh Y2tldCBzaG91bGQgbmV2ZXIgdHJhdmVyc2UuDQoNClRoYXQgZ29lcyBpbiBsaW5lIG9mIHJlY2Vu dCB3YXZlIG9mIG5lZ2F0aXZlIHJvdXRpbmcgaW1wbGVtZW50YXRpb25zIChSSUZUKSBvciBkaXNj dXNzaW9ucyAoTFNSKQ0KDQpCZXN0LA0KUi4NCg0KDQoNCg0KDQpPbiBNb24sIEF1ZyAzLCAyMDIw IGF0IDExOjQ2IFBNIEFuZHJldyBBbHN0b24gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5j b208bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PiB3cm90ZToNClNvIOKA kw0KDQpPbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2ZXJ5IG1ham9yIHVzZSBj YXNlcyBpbiBhbnkgc3ByaW5nIHRlY2hub2xvZ3kgZm9yIHVzIHJldm9sdmUgYXJvdW5kIHRoZSBm b2xsb3dpbmcNCg0KDQphLiAgICAgIFRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2YgY2VydGFpbiBu b2Rlcw0KDQpiLiAgICAgIFRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2YgY2VydGFpbiBzZWN0aW9u cyBvZiB0aGUgbmV0d29yaw0KDQpBbnl0aGluZyB0aGF0IGNvdWxkIHJlc3VsdCBpbiB0aGF0IGV4 cGxpY2l0IGF2b2lkYW5jZSBiZWluZyB2aW9sYXRlZCDigJMgd291bGQgY3JlYXRlLCBzaGFsbCB3 ZSBzYXkgc2lnbmlmaWNhbnQgcHJvYmxlbXMuDQoNCk11Y2ggb2YgdGhlIHVzZSBjYXNlIGlzIG5v dCBhIGNhc2Ugb2Ygd2hpY2ggbm9kZXMgdGhlIHBhY2tldHMgZmxvdyB0aHJvdWdoIOKAkyBidXQg cmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2VnbWVudHMgaXQgY2FuIG5ldmVyIHRv dWNoIG9yIGZsb3cgdGhyb3VnaC4gIEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5v bG9neSB0byBhdm9pZCBjZXJ0YWluIHRoaW5ncyBmb3Igc3BlY2lmaWMgcmVhc29ucy4NCg0KVGhp cyBpcyBhbHNvIG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwg c3RhY2tzIOKAkyB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgcGF0aCBwcm9ncmFtbWluZyB0ZW5kcyB0 byBkZWVwZW4gdGhlIHN0YWNrIGJlY2F1c2UgeW91IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0 eSBleHBsaWNpdC4NCg0KSXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1cyB0aGF0IHRoaXMg ZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDigJMgYW5kIHRoYXQgd2UgY2FuIGF2b2lkIHNpdHVhdGlv bnMgd2hpY2ggY291bGQgY2F1c2UgdHJhZmZpYyB0byBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhw bGljaXRseSBhdm9pZGVkLg0KDQpJIHdpc2ggSSBjb3VsZCBiZSBtb3JlIHNwZWNpZmljIHRoYW4g dGhpcywgYnV0IGl0IGlzIHdoYXQgaXQgaXMuDQoNClRoYW5rcw0KDQpBbmRyZXcNCg0KDQpGcm9t OiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IE1vbmRheSwgMyBB dWd1c3QgMjAyMCAyMTozNg0KVG86IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBk ZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCihTaW5jZSB0aGUgdGhyZWFkIGhhcyBnb3R0ZW4g bG9uZyBlbm91Z2gsIHJlaXRlcmF0aW5nIHRoYXQgdGhpcyBpcyBhcyBhDQpwYXJ0aWNpcGFudCwg bm90IGEgV0cgY2hhaXIuKQ0KDQpZZXMsIHdlIGFyZSB0YWxraW5nIElQIG5ldHdvcmtzLiBBbmQg eWVzLCBJIGhhdmUgc2VlbiBJUCBuZXR3b3JrcyB0aGF0DQpjaG9vc2UgdG8gZHJvcCBwYWNrZXRz LiBGb3IgYWxsIHNvcnRzIG9mIHJlYXNvbnMuDQpJIHRoaW5rIHRoZXJlIGFyZSBsaWtlbHkgb3Ro ZXIgcmVhc29ucyB3aHkgb25lIG1heSBub3Qgd2FudCBhIHJhbmRvbQ0KcGF0aCByYXRoZXIgdGhh biBhIGNob3NlbiBURSBwYXRoLiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB3ZSBiZSBjbGVhcg0K YWJvdXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlvbGF0ZWQgd2hlbiB3ZSB0ZWxs IHBlb3BsZSB0aGV5DQpoYXZlIHRoaXMgdG9vbCAocHJvdGVjdGl2ZSByZXJvdXRpbmcpIHRoYXQg aXMgaW50ZW5kZWQgdG8gcHJlc2VydmUgUW9TLg0KDQpMZXQncyBiZSBjbGVhci4gSSBhbSBub3Qg YXJndWluZyB0aGF0IHRoaXMgaXMgbm90IGEgZ29vZCBpZGVhLiBJdCBpcyBhDQpnb29kIGlkZWEu IEFuZCB1c2VmdWwuIEkgYW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdHUgd2hhdCBjb21iaW5hdGlvbiBv Zg0KYWRkaXRpb25hbCBtZWNoYW5pc21zIGFuZCBjbGVhciBkZXNjcmlwdGlvbnMgd2lsbCBsZWFk IHRvIGV2ZXJ5b25lDQpnZXR0aW5nIHRoZSBiZWhhdmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5 IG5vdCBiZSB0aGUgYmVoYXZpb3IgdGhleQ0KZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBi ZXN0IHdlIGNhbiBkby4pDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA4LzMvMjAyMCAyOjMwIFBNLCBS b2JlcnQgUmFzenVrIHdyb3RlOg0KPiBKb2VsLA0KPg0KPiBBcmUgd2Ugc3RpbGwgdGFsa2luZyBh Ym91dCBJUCBuZXR3b3JrcyBoZXJlID8gT3IgcGVyaGFwcyBzb21lIGhhcmQNCj4gc2xpY2luZyB3 aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5ldHMgPw0KPg0KPiBCZWNhdXNl IGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtpbmcgSSBoYXZlIHR3byBvYnNlcnZh dGlvbnM6DQo+DQo+IEEpIElmIHlvdSBuZWVkIHRvIHRyYXZlcnNlIHZpYSBhIHNwZWNpZmljIG5v ZGUgKGllLiBmaXJld2FsbCkgeW91IGJldHRlcg0KPiBhcHBseSBJUCBlbmNhcHN1bGF0aW9uIHRv IHRoYXQgbm9kZS4gSSBkb24ndCB0aGluayBJUCBlbmNhcHN1bGF0aW9uIGNhbg0KPiBiZSBoaWph Y2tlZCB0b2RheSBzdWNoIHRoYXQgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUgcGFja2V0IGlz IGlnbm9yZWQuDQo+DQo+IEIpIEhhdmUgeW91IHNlZW4gYW55IElQIG5ldHdvcmsgd2hlcmUgdXBv biB0b3BvbG9neSBjaGFuZ2UgKGxpbmsgb3Igbm9kZQ0KPiBmYWlsdXJlKSB5b3Ugc3VkZGVubHkg c3RhcnQgZHJvcHBpbmcgZmxvd3MgaW4gc3BpdGUgb2YgU1BUIG9mZmVyaW5nDQo+IHBlcmhhcHMg ZmV3IG1zIGxvbmdlciBwYXRoIHdpdGggMTAgbXMgbW9yZSBqaXR0ZXIgPw0KPg0KPiBPciBhcmUg c29tZSBTUiBtYXJrZXRpbmcgc2xpZGVzIHByb21pc2UgdG8gdHVybiBJUCBuZXR3b3JrcyBpbg0K PiBzb21ldGhpbmcgbmV3ID8gV29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkg Z3VhcmFudGVlcywNCj4gcmVzb3VyY2UgcmVzZXJ2YXRpb25zID8gSSBob3BlIG5vdC4NCj4NCj4g VGh4LA0KPiBSLg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBPbiBNb24sIEF1ZyAzLCAy MDIwIGF0IDg6MTAgUE0gSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20lMjAlMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+PiB3cm90ZToNCj4NCj4gV2VsbCBsZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90 IHN1cmUgdGhlIHByb2JsZW0gaXMgcmVzdHJpY3RlZA0KPiB0byBqdXN0IHNlcnZpY2UgU0lEcy4N Cj4NCj4gU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0aGUgcGF0aCB0byBtZWV0 IHNvbWUgY29tcGxleCB0ZQ0KPiBvYmplY3RpdmUuICBUaGUgYnlwYXNzIG5vZGUgaGFzIG5vIHdh eSBvZiBrbm93aW5nIHdoYXQgdGhvc2UNCj4gY29uc3RyYWludHMNCj4gd2VyZS4gIEFuZCBmb3Ig c29tZSBraW5kcyBvZiB0cmFmZmljLCBpdCBpcyBiZXR0ZXIgdG8gZHJvcCB0aGUgcGFja2V0DQo+ IHRoYW4gdG8gZGVsaXZlciBpdCBvdXRzaWRlIHRoZSBlbnZlbG9wLiAgSSBzdXNwZWN0IHRoYXQg dGhlIHJpZ2h0DQo+IGFuc3dlcg0KPiB0byB0aGlzIGlzICJ0b28gYmFkIi4gIElmIHNvLCBhcyB3 aXRoIHRoZSBkaXN0aW5jdGlvbiByZWdhcmRpbmcgc2VydmljZQ0KPiBub2Rlcywgd2Ugc2hvdWxk IHNheSBzbywgc2hvdWxkbid0IHdlPw0KPg0KPiBZb3VycywNCj4gSm9lbA0KPg0KPiBPbiA4LzMv MjAyMCAyOjM2IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gPiBNYWNoLCBKb2Vs IGFuZCBhbGwsDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgaW4gbW9zdCBjYXNlczoNCj4gPg0KPiA+ IDEuVGhlcmUgaXMgY2xlYXIgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gInRvcG9sb2dpY2FsIiBh bmQgInNlcnZpY2UiDQo+ID4gaW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5n LjoNCj4gPg0KPiA+IG9JR1AgUHJlZml4IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZp ZWQgYXMgc3VjaCBpbiB0aGUNCj4gPiBjb3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50cykg cmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9ucw0KPiA+DQo+ID4gb1NlcnZpY2UgU0lE cyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92ZXJsYXkgU2VydmljZXMNCj4gPg0KPiA8 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2 Ni1zZXJ2aWNlcy0wNDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0Pj4NCj4NCj4gPiBkcmFmdCkgdW5zdXJwcmlzaW5n bHkgcmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zDQo+ID4NCj4gPiAyLlNlZ21l bnRzIHRoYXQgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9ucyBjYW4gYmUgYnlwYXNz ZWQsDQo+ID4gd2hpbGUgc2VnbWVudHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlv bnMgcmVxdWlyZQ0KPiBhbHRlcm5hdGl2ZQ0KPiA+IHByb3RlY3Rpb24gbWVjaGFuaXNtcy4NCj4g Pg0KPiA+IFRoaXMgdmlldyBzZWVtcyB0byBiZSBhbGlnbmVkIHdpdGggUkZDIDg0MDINCj4gPiA8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDI8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzg0MDI+PiB0aGF0IHNheXMgaW4gU2VjdGlvbiAxOg0KPiA+DQo+ID4gICAgIElu IHRoZSBjb250ZXh0IG9mIGFuIElHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0 d28NCj4gPg0KPiA+IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgSUdQLUFk amFjZW5jeSBzZWdtZW50IGFuZCB0aGUNCj4gPg0KPiA+ICAgICBJR1AtUHJlZml4IHNlZ21lbnQu DQo+ID4NCj4gPiAgICAgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQgZGlzdHJpYnV0ZWQg Y29udHJvbCBwbGFuZSwgdHdvDQo+ID4NCj4gPiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVm aW5lZDogdGhlIEJHUCBwZWVyaW5nIHNlZ21lbnQgYW5kIHRoZQ0KPiA+DQo+ID4gICAgIEJHUC1Q cmVmaXggc2VnbWVudC4NCj4gPg0KPiA+IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMgdGhpcyBkaWZm ZXJlbnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uDQo+IDMuNCBvZg0KPiA+IHRoZSBOb2Rl IFByb3RlY3Rpb24gZm9yIFNSLVRFIFBhdGgNCj4gPg0KPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1z ci10ZS1wYXRocy0wNyNzZWN0aW9uLTMuNDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhz LTA3I3NlY3Rpb24tMy40Pj4NCj4NCj4gPiBkcmFmdCB0aGF0IHNheXM6DQo+ID4NCj4gPiAgICAg VGhlIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBz ZWN0aW9ucw0KPiA+DQo+ID4gICAgIGRlcGVuZHMgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUg bGFiZWwgaW1tZWRpYXRlbHkgYmVsb3cNCj4gdGhlIHRvcA0KPiA+DQo+ID4gbGFiZWwgaW4gdGhl IGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElHUCBkb21haW4uICBXaGVuIHRoZQ0K PiA+DQo+ID4gICAgIHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBleGNoYW5nZSBzZXJ2aWNlIGxhYmVs cyB2aWEgQkdQIG9yIHNvbWUNCj4gb3RoZXINCj4gPg0KPiA+ICAgICBub24tSUdQIG1lY2hhbmlz bSB0aGUgYm90dG9tIGxhYmVsIGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1ANCj4gPg0KPiA+ ICAgICBkb21haW4uDQo+ID4NCj4gPiAgICAgVGhlIGVncmVzcyBub2RlIHByb3RlY3Rpb24gbWVj aGFuaXNtcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0DQo+ID4NCj4gPiAgICAgW1JGQzg2NzkgPGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODY3OTxodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg2Nzk+Pl0gaXMNCj4gPiBhcHBsaWNhYmxlIHRv IHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdlcw0KPiA+DQo+ID4gICAgIHdp bGwgYmUgcmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzDQo+ID4NCj4gPiBUaGUgc2NlbmFy aW9zIGluIHdoaWNoICBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiDigJx0b3BvbG9naWNhbOKAnSBh bmQNCj4gPiDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBicm9rZW4gYXJlIGluZGVlZCBw cm9ibGVtYXRpYy4gRS5nLiwNCj4gY29uc2lkZXINCj4gPiB0aGUgdXNlIGNhc2UgaW4gd2hpY2gg YSBOb2RlIFNJRCBpbiB0aGUgRVJPIG9mIGEgU1ItVEUgcGF0aA0KPiBpZGVudGlmaWVzIGENCj4g PiBub2RlIHRoYXQgYWN0cyBhcyBhIGZpcmV3YWxsIGZvciBhbGwgcGFja2V0cyBpdCByZWNlaXZl cywgaS5lLiwNCj4gcHJvdmlkZXMNCj4gPiB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRob3V0IGFu eSBkZWRpY2F0ZWQgc2VydmljZSBTSUQNCj4gaWRlbnRpZnlpbmcgaXQuDQo+ID4gT25lIGNvdWxk IHNheSB0aGF0IHRoZSBOb2RlIFNJRCBvZiBzdWNoIGEgbm9kZSB3b3VsZCBjb21iaW5lDQo+IHRv cG9sb2dpY2FsDQo+ID4gYW5kIHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHRodXMgYnJlYWtpbmcgdGhl IGRpZmZlcmVudGlhdGlvbg0KPiBiZXR3ZWVuIHRoZSB0d28uDQo+ID4NCj4gPiBJIGFtIG5vdCBz dXJlIGlmIHVzYWdlIG9mIHN1Y2gg4oCcY29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2ZW50 ZWQNCj4gb3IgYXQNCj4gPiBsZWFzdCBkaXNjb3VyYWdlZC4NCj4gPg0KPiA+IElmIG5vdCwgcHJv dmlkaW5nIGFuIGFiaWxpdHkgdG8gaWRlbnRpZnkgc3VjaCBTSURzIGluIHRoZQ0KPiBhZHZlcnRp c2VtZW50DQo+ID4gbWVjaGFuaXNtcyB3b3VsZCBiZSB1c2VmdWwgSU1ITy4NCj4gPg0KPiA+IE15 IDJjLA0KPiA+DQo+ID4gU2FzaGENCj4gPg0KPiA+IE9mZmljZTogKzk3Mi0zOTI2NjMwMg0KPiA+ DQo+ID4gQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPiA+DQo+ID4gRW1haWw6IEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4NCj4gPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4g Pg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc3ByaW5nIDxzcHJp bmctYm91bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYj4+ IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFjaCBDaGVu DQo+ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMwIEFNDQo+ID4gVG86IEpvZWwg TS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tJTBiPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj47IHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPiBTdWJq ZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNh YmlsaXR5DQo+ID4NCj4gPiBIaSBKb2VsLA0KPiA+DQo+ID4gSSB0aGluayB0aGlzIGlzIGEgZ29v ZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZQ0KPiBwYXN0LiBBbmQNCj4g PiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAiY2FuIGJlIGJ5cGFzc2VkIiBpbmRpY2F0 aW9uIGluIHRoZQ0KPiA+IHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCBmb3Igbm93Lg0KPiA+DQo+ID4g SU1ITywgdGhlIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgYnkgcm91dGluZyBpcyBuZXV0cmFsLCBz dWNoDQo+IGluZm9ybWF0aW9uDQo+ID4gKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQpIGlzIG1v cmUgcGF0aCBzcGVjaWZpYywgdGh1cyBub3JtYWxseSB0aGUNCj4gPiBjb250cm9sbGVyIHNob3Vs ZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBTSUQNCj4gY2FuIGJl DQo+ID4gYnlwYXNzZWQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4NCj4gPiBNYWNoDQo+ ID4NCj4gPiAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+DQo+ID4gID4gRnJvbTog c3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPG1haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZz48bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiJTNlJTIw JTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTNlPl0gT24gQmVoYWxmIE9mIEpvZWwg TS4NCj4gPg0KPiA+ICA+IEhhbHBlcm4NCj4gPg0KPiA+ICA+IFNlbnQ6IE1vbmRheSwgQXVndXN0 IDMsIDIwMjAgNzo1MSBBTQ0KPiA+DQo+ID4gID4gVG86IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4gPg0KPiA+ICA+IFN1YmplY3Q6IFtz cHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiA+ DQo+ID4gID4NCj4gPg0KPiA+ICA+IChXRyBDaGFpciBoYXQgT2ZmLCB0aGlzIGlzIG1lcmVseSBh IG5vdGUgZnJvbSBhIHNsaWdodGx5DQo+IGNvbmZ1c2VkIFdHDQo+ID4NCj4gPiAgPiBwYXJ0aWNp cGFudC4pDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUg dmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXMNCj4gPg0KPiA+ICA+IG5ldHdv cmtzIHByb2dyYW1taW5nIGFuZCBzZXJ2aWNlIHByb2dyYW1taW5nIGRyYWZ0LCBhbmQgSSBhbQ0K PiB0cnlpbmcgdG8NCj4gPg0KPiA+ICA+IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUgY29t YmluYXRpb24uDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gSG93IGRvZXMgYSBub2RlIHRoYXQg aXMgZG9pbmcgc29tZSBmb3JtIG9mIGJ5cGFzcyAoc3VwcG9zZSwgZm9yDQo+ID4NCj4gPiAgPiBz aW1wbGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQg Zm9yDQo+IGEgZmFpbGVkDQo+ID4NCj4gPiAgPiBub2RlIE4zKSBrbm93IHRoYXQgaXQgaXMgc2Fm ZSB0byBkbyBzbz8NCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBJZiB0aGUgcGF0aCB3YXMganVz dCBmb3IgVEUsIHRoZW4gaXQgaXMgInNhZmUiIGlmIHRoZSBuZXcgcGF0aA0KPiBtZWV0cw0KPiA+ DQo+ID4gID4gdGhlIFRFIGNyaXRlcmlhLiAgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBpdCBpcyBl dmVuIGNsb3NlLCBhcw0KPiBsb25nIGFzDQo+ID4NCj4gPiAgPiBpdCBpcyBub3QgdXNlZCBmb3Ig dG9vIGxvbmcuDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gQnV0IHdoYXQgaWYgdGhlIG5vZGUg d2VyZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsDQo+ID4gcmVxdWlyZW1lbnRz Pw0KPiA+DQo+ID4gID4gT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0 cmFuc2Zvcm0gKHdpbmNlIHdlIGFyZQ0KPiA+DQo+ID4gID4gZGVsaWJlcmF0ZWx5IHZhZ3VlIGFi b3V0IHdoYXQgbm9kZXMgY2FuIGRvIHdoZW4gYXNrZWQgc3VpdGFibHkuKQ0KPiA+DQo+ID4gID4N Cj4gPg0KPiA+ICA+IElzIHRoZXJlIHNvbWUgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBp biB0aGUgcm91dGluZw0KPiA+DQo+ID4gID4gYWR2ZXJ0aXNlbWVudHMgdGhhdCBJIG1pc3NlZD8N Cj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBUaGFuayB5b3UsDQo+ID4NCj4gPiAgPiBZb3VycywN Cj4gPg0KPiA+ICA+IEpvZWwNCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gID4gc3ByaW5nIG1h aWxpbmcgbGlzdA0KPiA+DQo+ID4gID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4+Pg0KPiA+DQo+ID4gID4NCj4gPg0KPiBodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUy PGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZI Mj91PWh0dHBzJTNBJTI+DQo+ID4NCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MjxodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTI+ Pg0KPiA+DQo+ID4gID4gRiUyRnd3dy5pZXRmLm9yZzxodHRwOi8vMkZ3d3cuaWV0Zi5vcmc+DQo+ IDxodHRwOi8vMkZ3d3cuaWV0Zi5vcmc8aHR0cDovLzJGd3d3LmlldGYub3JnPj4lMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzcHJpbmcNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4N Cj4gPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyUwYj4+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCj4gPg0KPiA+DQo+IGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPGh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0 dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPg0K PiA+DQo+ID4NCj4gPg0KPiA+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IE5vdGljZTogVGhpcyBl LW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4NCj4gPiBpbmZv cm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlh bA0KPiBhbmQvb3INCj4gPiBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRl bmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsDQo+ID4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3Ig ZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQNCj4gPiBleHByZXNz IHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+ IGludGVuZGVkDQo+ID4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbA0KPiA+IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cy4NCj4gPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc3ByaW5nIG1haWxpbmcgbGlz dA0KPiA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZzxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZz4NCj4g Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHJpbmc8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmc+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPg0K --_000_VI1PR03MB5056610F42282B6883CED19EEE4A0VI1PR03MB5056eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLmdtYWlsLW04MzUxNjE3OTcxOTQzNTkzMzc2bXNvbGlzdHBhcmFncmFw aCwgbGkuZ21haWwtbTgzNTE2MTc5NzE5NDM1OTMzNzZtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21h aWwtbTgzNTE2MTc5NzE5NDM1OTMzNzZtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1l OmdtYWlsLW1fODM1MTYxNzk3MTk0MzU5MzM3Nm1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODgyMzcwMTE7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi04MDEyMDQwMTg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoz MjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUtFIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5S b2JlcnQgdGhpcyBpcyBhY3R1YWxseSBmYXIgbW9yZSBkaWZmaWN1bHQgd2hlbiDigJMgaXQgY2Fu IGJlIGFuIGVudGlyZSAobG9uZykgc2VyaWVzIG9mIG5vZGVzIHRoYXQgbmVlZCB0byBiZSBhdm9p ZGVkLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXQgY291bGQgcG90 ZW50aWFsbHkgYmUgbWFkZSB0byB3b3JrIGJ1dCBJ4oCZZCB3b3JyeSB0aGF0IHRvIGRvIHRoaXMg 4oCTIHlvdeKAmWQgaGF2ZSB0byBzdGFjayAxMCDigJMgMjAg4oCTIDMwIG5lZ2F0aXZlIGxhYmVs cyDigJMgYW5kIHRoYXQgd291bGRu4oCZdCBiZSB2aWFibGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5JdOKAmXMgZWFzaWVyIHRvIHVzZSBhbGdvcml0aG1zIGFuZCBhZGphY2Vu Y3kgc2lkcyBhbmQgb3RoZXIgc3VjaCB0aGluZ3MgdG8gY2FsY3VsYXRlIHBhdGhzIOKAkyB0aGUg YmlnZ2VzdCB0cmljayBpcyBhYm91dCB0aGUgc3RhY2sgZGVwdGguJm5ic3A7IFdoZW4geW91IGhh dmUgdGhpcyBuZWVkIGZvciBub2RlIGF2b2lkYW5jZSDigJMNCiB0aGUgbmVlZCBmb3IgMTArIGxh YmVsIGRlcHRoIGlzIGNyaXRpY2FsIOKAkyB1bmxlc3MgeW91IHdhbm5hIGJlIGFwcGx5aW5nIG9u ZSBoZWxsIG9mIGEgbG90IG9mIGJpbmRpbmcgbGFiZWxzIGFsb25nIHRoZSB3YXkgd2hpY2ggaXMg YSBuaWdodG1hcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QnV0IHRvIGFuc3dl ciB5b3VyIHF1ZXN0aW9uLCBpcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNlIOKAkyBpdOKAmXMgYSB1 c2UgY2FzZSB0aGF0IG1vc3Qgb2YgdGhlIHBlb3BsZSBJIGRpc2N1c3MgdGhpcyB3aXRoIGNlcnRh aW4gaGF2ZSDigJMgSSBjYW50Jm5ic3A7IGNvbW1lbnQgb24gYSBnbG9iYWwgc2NhbGUsIG9yIGZv ciBhbnlvbmUgZWxzZSwNCiBidXQgZXZlcnkgaW5kaWNhdGlvbiBJIGhhdmUgaXMgdGhhdCB5ZXMg 4oCTIGl0cyBzb21ldGhpbmcgcGVvcGxlIG5lZWQsIGFuZCB3YW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iZW4tS0UiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJvYmVydCBSYXN6 dWsgJmx0O3JvYmVydEByYXN6dWsubmV0Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IDQgQXVndXN0IDIwMjAgMDE6Mjc8YnI+DQo8Yj5Ubzo8L2I+IEFuZHJldyBBbHN0b24gJmx0O0Fu ZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb2VsIE0u IEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7OyBzcHJpbmdAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJt aW5pbmcgYXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JcyB0aGlzIGEgY29tbW9uIHVzZSBj YXNlIGllLiZuYnNwOyAmcXVvdDtidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsg c2VnbWVudHMgaXQgY2FuIG5ldmVyIHRvdWNoIG9yIGZsb3cgdGhyb3VnaC4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPklmIHNvIHBlcmhhcHMgaXRzIHRp bWUgdG8gZGVmaW5lIG5vdGlvbiBvZg0KPGI+bmVnYXRpdmUtU0lEPC9iPiBpZS4gbGlzdCBpbiB0 aGUgcGFja2V0IHJlc291cmNlcyB3aGljaCBnaXZlbiZuYnNwO3BhY2tldCBNVVNUIG5vdCBldmVy IHRyYXZlcnNlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5QdXQgaW4gdGhlIHBhY2tldCBzZXQgb2Ygbm9kZXMgb3IgbGlua3Mgd2hpY2gg dGhlIHBhY2tldCBzaG91bGQgbmV2ZXIgdHJhdmVyc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYXQgZ29lcyBpbiBsaW5lIG9mIHJl Y2VudCB3YXZlIG9mIG5lZ2F0aXZlIHJvdXRpbmcgaW1wbGVtZW50YXRpb25zIChSSUZUKSBvciBk aXNjdXNzaW9ucyAoTFNSKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5CZXN0LDxicj4NClIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gTW9uLCBBdWcgMywgMjAyMCBhdCAxMTo0NiBQTSBBbmRy ZXcgQWxzdG9uICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbSI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5TbyDi gJMgPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tVVMiPk9uZSBvZiB0aGUgdXNlIGNhc2VzLCBpbiBmYWN0LCBzb21lIHZlcnkgbWFqb3IgdXNl IGNhc2VzIGluIGFueSBzcHJpbmcgdGVjaG5vbG9neSBmb3IgdXMgcmV2b2x2ZSBhcm91bmQgdGhl IGZvbGxvd2luZzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTgzNTE2MTc5NzE5NDM1OTMzNzZtc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iZW4t S0UiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+ VGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIG5vZGVzPC9zcGFuPjxzcGFuIGxhbmc9 ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTgzNTE2MTc5 NzE5NDM1OTMzNzZtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gbGFuZz0iZW4tS0UiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWlu IHNlY3Rpb25zIG9mIHRoZSBuZXR3b3JrPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkFueXRoaW5nIHRoYXQgY291bGQgcmVzdWx0IGlu IHRoYXQgZXhwbGljaXQgYXZvaWRhbmNlIGJlaW5nIHZpb2xhdGVkIOKAkyB3b3VsZCBjcmVhdGUs IHNoYWxsIHdlIHNheSBzaWduaWZpY2FudCBwcm9ibGVtcy48L3NwYW4+PHNwYW4gbGFuZz0iZW4t S0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+TXVjaCBvZiB0aGUgdXNlIGNh c2UgaXMgbm90IGEgY2FzZSBvZiB3aGljaCBub2RlcyB0aGUgcGFja2V0cyBmbG93IHRocm91Z2gg 4oCTIGJ1dCByYXRoZXIg4oCTIHdoaWNoIG5vZGVzIC8gbmV0d29yayBzZWdtZW50cyBpdCBjYW4g bmV2ZXIgdG91Y2ggb3IgZmxvdyB0aHJvdWdoLiZuYnNwOyBFZmZlY3RpdmVseSwgdG8gYmUgdXNl ZCBhcyBhIHRlY2hub2xvZ3kgdG8gYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJl YXNvbnMuPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPlRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIG5lZWRpbmcgc3Vj aCBkZWVwIGxhYmVsIHN0YWNrcyDigJMgdGhpcyBraW5kIG9mIGRldGFpbGVkIHBhdGggcHJvZ3Jh bW1pbmcgdGVuZHMgdG8gZGVlcGVuIHRoZSBzdGFjayBiZWNhdXNlIHlvdSBzb21ldGltZXMgaGF2 ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkl0IGlzIGFic29sdXRlbHkgY3JpdGljYWwgdG8g dXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUg4oCTIGFuZCB0aGF0IHdlIGNhbiBh dm9pZCBzaXR1YXRpb25zIHdoaWNoIGNvdWxkIGNhdXNlIHRyYWZmaWMgdG8gYWNjaWRlbnRseSBo aXQgdGhpbmdzIGV4cGxpY2l0bHkgYXZvaWRlZC48L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1L RSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SSB3aXNoIEkgY291bGQgYmUgbW9yZSBz cGVjaWZpYyB0aGFuIHRoaXMsIGJ1dCBpdCBpcyB3aGF0IGl0IGlzLjwvc3Bhbj48c3BhbiBsYW5n PSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3M8L3NwYW4+ PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QW5k cmV3PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i ZW4tS0UiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4N CjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Sm9lbCBNLiBIYWxwZXJuPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgMyBBdWd1 c3QgMjAyMCAyMTozNjxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5u ZXQ8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJp bGl0eTwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0K PHNwYW4gbGFuZz0iZW4tS0UiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iZW4tS0UiPihT aW5jZSB0aGUgdGhyZWFkIGhhcyBnb3R0ZW4gbG9uZyBlbm91Z2gsIHJlaXRlcmF0aW5nIHRoYXQg dGhpcyBpcyBhcyBhDQo8YnI+DQpwYXJ0aWNpcGFudCwgbm90IGEgV0cgY2hhaXIuKTxicj4NCjxi cj4NClllcywgd2UgYXJlIHRhbGtpbmcgSVAgbmV0d29ya3MuIEFuZCB5ZXMsIEkgaGF2ZSBzZWVu IElQIG5ldHdvcmtzIHRoYXQgPGJyPg0KY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFsbCBz b3J0cyBvZiByZWFzb25zLjxicj4NCkkgdGhpbmsgdGhlcmUgYXJlIGxpa2VseSBvdGhlciByZWFz b25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9tIDxicj4NCnBhdGggcmF0aGVyIHRoYW4g YSBjaG9zZW4gVEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXIgPGJy Pg0KYWJvdXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlvbGF0ZWQgd2hlbiB3ZSB0 ZWxsIHBlb3BsZSB0aGV5IDxicj4NCmhhdmUgdGhpcyB0b29sIChwcm90ZWN0aXZlIHJlcm91dGlu ZykgdGhhdCBpcyBpbnRlbmRlZCB0byBwcmVzZXJ2ZSBRb1MuPGJyPg0KPGJyPg0KTGV0J3MgYmUg Y2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlzIGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQg aXMgYSA8YnI+DQpnb29kIGlkZWEuIEFuZCB1c2VmdWwuIEkgYW0gdHJ5aW5nIHRvIGZpZ3VyZSBv dHUgd2hhdCBjb21iaW5hdGlvbiBvZiA8YnI+DQphZGRpdGlvbmFsIG1lY2hhbmlzbXMgYW5kIGNs ZWFyIGRlc2NyaXB0aW9ucyB3aWxsIGxlYWQgdG8gZXZlcnlvbmUgPGJyPg0KZ2V0dGluZyB0aGUg YmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJlaGF2aW9yIHRoZXkg PGJyPg0KZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBiZXN0IHdlIGNhbiBkby4pPGJyPg0K PGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCk9uIDgvMy8yMDIwIDI6MzAgUE0sIFJv YmVydCBSYXN6dWsgd3JvdGU6PGJyPg0KJmd0OyBKb2VsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBB cmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JrcyZuYnNwO2hlcmUgPyBPciBwZXJo YXBzIHNvbWUgaGFyZCA8YnI+DQomZ3Q7IHNsaWNpbmcgd2l0aCByZWFsIHJlc291cmNlIHJlc2Vy dmF0aW9ucyBvciBkZXRuZXRzID88YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVjYXVzZSZuYnNwO2lm IHdlIGFyZSB0YWxraW5nJm5ic3A7YWJvdXQgSVAgbmV0d29ya2luZyBJIGhhdmUgdHdvIG9ic2Vy dmF0aW9uczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSkgSWYgeW91IG5lZWQgdG8gdHJhdmVyc2Ug dmlhIGEgc3BlY2lmaWMgbm9kZSAoaWUuIGZpcmV3YWxsKSB5b3UgYmV0dGVyIDxicj4NCiZndDsg YXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuIEkgZG9uJ3QgdGhpbmsgSVAgZW5j YXBzdWxhdGlvbiZuYnNwO2NhbiA8YnI+DQomZ3Q7IGJlIGhpamFja2VkIHRvZGF5IHN1Y2ggdGhh dCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXMgaWdub3JlZC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3aGVyZSB1cG9uIHRv cG9sb2d5IGNoYW5nZSAobGluayBvciBub2RlIDxicj4NCiZndDsgZmFpbHVyZSkgeW91IHN1ZGRl bmx5Jm5ic3A7c3RhcnQgZHJvcHBpbmcmbmJzcDtmbG93cyBpbiBzcGl0ZSBvZiBTUFQgb2ZmZXJp bmcgPGJyPg0KJmd0OyBwZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRoIDEwIG1zIG1vcmUg aml0dGVyID88YnI+DQomZ3Q7IDxicj4NCiZndDsgT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNs aWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4gPGJyPg0KJmd0OyBzb21ldGhpbmcm bmJzcDtuZXcgPyBXb3JzZSAuLi4gZG8gdGhleSBtZW50aW9uIHBhdGggcXVhbGl0eSBndWFyYW50 ZWVzLCA8YnI+DQomZ3Q7IHJlc291cmNlIHJlc2VydmF0aW9ucyZuYnNwOz8gSSBob3BlIG5vdC48 YnI+DQomZ3Q7IDxicj4NCiZndDsgVGh4LDxicj4NCiZndDsgUi48YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQg ODoxMCBQTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tJTIwJTBiIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbQ0KPGJyPg0K PC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFdlbGwgbGVzcyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5v dCBzdXJlIHRoZSBwcm9ibGVtIGlzIHJlc3RyaWN0ZWQ8YnI+DQomZ3Q7IHRvIGp1c3Qgc2Vydmlj ZSBTSURzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdXBwb3NlIHRoYXQgdGhlIFBDRSBoYXMgc3Bl Y2lmaWVkIHRoZSBwYXRoIHRvIG1lZXQgc29tZSBjb21wbGV4IHRlPGJyPg0KJmd0OyBvYmplY3Rp dmUuJm5ic3A7IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dpbmcgd2hhdCB0aG9z ZTxicj4NCiZndDsgY29uc3RyYWludHM8YnI+DQomZ3Q7IHdlcmUuJm5ic3A7IEFuZCBmb3Igc29t ZSBraW5kcyBvZiB0cmFmZmljLCBpdCBpcyBiZXR0ZXIgdG8gZHJvcCB0aGUgcGFja2V0PGJyPg0K Jmd0OyB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lkZSB0aGUgZW52ZWxvcC4mbmJzcDsgSSBzdXNw ZWN0IHRoYXQgdGhlIHJpZ2h0PGJyPg0KJmd0OyBhbnN3ZXI8YnI+DQomZ3Q7IHRvIHRoaXMgaXMg JnF1b3Q7dG9vIGJhZCZxdW90Oy4mbmJzcDsgSWYgc28sIGFzIHdpdGggdGhlIGRpc3RpbmN0aW9u IHJlZ2FyZGluZyBzZXJ2aWNlPGJyPg0KJmd0OyBub2Rlcywgd2Ugc2hvdWxkIHNheSBzbywgc2hv dWxkbid0IHdlPzxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3Vycyw8YnI+DQomZ3Q7IEpvZWw8YnI+ DQomZ3Q7IDxicj4NCiZndDsgT24gOC8zLzIwMjAgMjozNiBBTSwgQWxleGFuZGVyIFZhaW5zaHRl aW4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IE1hY2gsIEpvZWwgYW5kIGFsbCw8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGF0IGluIG1vc3QgY2FzZXM6PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IDEuVGhlcmUgaXMgY2xlYXIgZGlmZmVyZW50aWF0aW9uIGJldHdl ZW4gJnF1b3Q7dG9wb2xvZ2ljYWwmcXVvdDsgYW5kICZxdW90O3NlcnZpY2UmcXVvdDs8YnI+DQom Z3Q7ICZndDsgaW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5nLjo8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgb0lHUCBQcmVmaXggTm9kZSBTSURzIElHUCBBZGotU0lE cyAoaWRlbnRpZmllZCBhcyBzdWNoIGluIHRoZTxicj4NCiZndDsgJmd0OyBjb3JyZXNwb25kaW5n IElHUCBhZHZlcnRpc2VtZW50cykgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9uczxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBvU2VydmljZSBTSURzIGZvciBTUnY2IChzZWUg U1J2NiBCR1AtQmFzZWQgT3ZlcmxheSBTZXJ2aWNlczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmx0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0 PC9hPiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBkcmFmdCkgdW5zdXJwcmlzaW5nbHkg cmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rp b25zIGNhbiBiZSBieXBhc3NlZCw8YnI+DQomZ3Q7ICZndDsgd2hpbGUgc2VnbWVudHMgdGhhdCBy ZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMgcmVxdWlyZTxicj4NCiZndDsgYWx0ZXJuYXRp dmU8YnI+DQomZ3Q7ICZndDsgcHJvdGVjdGlvbiBtZWNoYW5pc21zLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBUaGlzIHZpZXcgc2VlbXMgdG8gYmUgYWxpZ25lZCB3aXRoIFJGQyA4NDAy PGJyPg0KJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODQwMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NDAyPC9hPiZndDsgdGhhdCBzYXlzIGluIFNlY3Rpb24gMTo8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IEluIHRoZSBjb250ZXh0IG9mIGFuIElHUC1iYXNl ZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5 IHNlZ21lbnQgYW5kIHRoZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgSUdQLVByZWZpeCBzZWdtZW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmbmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQgZGlzdHJp YnV0ZWQgY29udHJvbCBwbGFuZSwgdHdvPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHRv cG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBh bmQgdGhlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBC R1AtUHJlZml4IHNlZ21lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEluIHRoZSBj YXNlIG9mIFNSLU1QTFMgdGhpcyBkaWZmZXJlbnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9u PGJyPg0KJmd0OyAzLjQgb2Y8YnI+DQomZ3Q7ICZndDsgdGhlIE5vZGUgUHJvdGVjdGlvbiBmb3Ig U1ItVEUgUGF0aDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJv dGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDcjc2VjdGlvbi0zLjQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWhlZ2RlLXNwcmluZy1u b2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3I3NlY3Rpb24tMy40PC9hPiZndDs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBkcmFmdCB0aGF0IHNheXM6PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgbm9kZSBwcm90ZWN0aW9uIG1lY2hh bmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb25zPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBkZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9u IHRoYXQgdGhlIGxhYmVsIGltbWVkaWF0ZWx5IGJlbG93PGJyPg0KJmd0OyB0aGUgdG9wPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGxhYmVsIGluIHRoZSBsYWJlbCBzdGFjayBpcyB1bmRl cnN0b29kIGluIHRoZSBJR1AgZG9tYWluLiZuYnNwOyBXaGVuIHRoZTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgcHJvdmlkZXIgZWRnZSByb3V0ZXJzIGV4 Y2hhbmdlIHNlcnZpY2UgbGFiZWxzIHZpYSBCR1Agb3Igc29tZTxicj4NCiZndDsgb3RoZXI8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IG5vbi1JR1AgbWVj aGFuaXNtIHRoZSBib3R0b20gbGFiZWwgaXMgbm90IHVuZGVyc3Rvb2QgaW4gdGhlIElHUDxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgZG9tYWluLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgVGhlIGVncmVzcyBu b2RlIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBbUkZDODY3OSAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM4Njc5IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM4Njc5 PC9hPiZndDtdIGlzPGJyPg0KJmd0OyAmZ3Q7IGFwcGxpY2FibGUgdG8gdGhpcyB1c2UgY2FzZSBh bmQgbm8gYWRkaXRpb25hbCBjaGFuZ2VzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyZuYnNwOyB3aWxsIGJlIHJlcXVpcmVkIGZvciBTUiBiYXNlZCBuZXR3b3Jrczxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgc2NlbmFyaW9zIGluIHdoaWNoICZuYnNw O2RpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs4oCdIGFuZDxicj4NCiZndDsg Jmd0OyDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBicm9rZW4gYXJlIGluZGVlZCBwcm9i bGVtYXRpYy4gRS5nLiw8YnI+DQomZ3Q7IGNvbnNpZGVyPGJyPg0KJmd0OyAmZ3Q7IHRoZSB1c2Ug Y2FzZSBpbiB3aGljaCBhIE5vZGUgU0lEIGluIHRoZSBFUk8gb2YgYSBTUi1URSBwYXRoPGJyPg0K Jmd0OyBpZGVudGlmaWVzIGE8YnI+DQomZ3Q7ICZndDsgbm9kZSB0aGF0IGFjdHMgYXMgYSBmaXJl d2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4sPGJyPg0KJmd0OyBwcm92aWRl czxicj4NCiZndDsgJmd0OyB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRob3V0IGFueSBkZWRpY2F0 ZWQgc2VydmljZSBTSUQ8YnI+DQomZ3Q7IGlkZW50aWZ5aW5nIGl0Ljxicj4NCiZndDsgJmd0OyBP bmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2ggYSBub2RlIHdvdWxkIGNvbWJp bmU8YnI+DQomZ3Q7IHRvcG9sb2dpY2FsPGJyPg0KJmd0OyAmZ3Q7IGFuZCBzZXJ2aWNlIGluc3Ry dWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRpb248YnI+DQomZ3Q7IGJldHdl ZW4gdGhlIHR3by48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBhbSBub3Qgc3VyZSBp ZiB1c2FnZSBvZiBzdWNoIOKAnGNvbWJpbmVk4oCdIFNJRHMgY291bGQgYmUgcHJldmVudGVkPGJy Pg0KJmd0OyBvciBhdDxicj4NCiZndDsgJmd0OyBsZWFzdCBkaXNjb3VyYWdlZC48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgbm90LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0byBpZGVu dGlmeSBzdWNoIFNJRHMgaW4gdGhlPGJyPg0KJmd0OyBhZHZlcnRpc2VtZW50PGJyPg0KJmd0OyAm Z3Q7IG1lY2hhbmlzbXMgd291bGQgYmUgdXNlZnVsIElNSE8uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IE15IDJjLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTYXNoYTxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPZmZpY2U6ICs5NzItMzkyNjYzMDI8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgQ2VsbDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Kzk3Mi01NDkyNjYzMDI8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRW1haWw6IDxhIGhy ZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPjxicj4NCiZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyAmZ3Q7IEZyb206IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8 YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsm Z3Q7IE9uIEJlaGFsZiBPZiBNYWNoIENoZW48YnI+DQomZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBB dWd1c3QgMywgMjAyMCA2OjMwIEFNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm4g Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiIiB0YXJnZXQ9Il9ibGFu ayI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPC9hPiZndDsmZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZn dDs8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9u IC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBIaSBKb2VsLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIHRoaW5rIHRoaXMgaXMg YSBnb29kIHBvaW50IHRoYXQgbWF5IG5vdCBiZSBkaXNjdXNzZWQgaW4gdGhlPGJyPg0KJmd0OyBw YXN0LiBBbmQ8YnI+DQomZ3Q7ICZndDsgSSBhbHNvIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgJnF1 b3Q7Y2FuIGJlIGJ5cGFzc2VkJnF1b3Q7IGluZGljYXRpb24gaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7 IHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCBmb3Igbm93Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBJTUhPLCB0aGUgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBieSByb3V0aW5nIGlzIG5ldXRy YWwsIHN1Y2g8YnI+DQomZ3Q7IGluZm9ybWF0aW9uPGJyPg0KJmd0OyAmZ3Q7IChjYW4gb3IgY2Fu bm90IGJlIGJ5cGFzc2VkKSBpcyBtb3JlIHBhdGggc3BlY2lmaWMsIHRodXMgbm9ybWFsbHkgdGhl PGJyPg0KJmd0OyAmZ3Q7IGNvbnRyb2xsZXIgc2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciBkZWNp ZGluZyB3aGV0aGVyL3doaWNoIFNJRDxicj4NCiZndDsgY2FuIGJlPGJyPg0KJmd0OyAmZ3Q7IGJ5 cGFzc2VkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE1hY2g8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEZyb206IHNwcmluZyBbPGEgaHJlZj0ibWFpbHRvOnNw cmluZy1ib3VuY2VzQGlldGYub3JnJTBiJTNlJTIwJTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnJTNlIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn PGJyPg0KJmd0OyAmbHQ7bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0OzwvYT5dIE9u IEJlaGFsZiBPZiBKb2VsIE0uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgSGFscGVybjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IFNlbnQ6 IE1vbmRheSwgQXVndXN0IDMsIDIwMjAgNzo1MSBBTTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyAmbHQ7bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IFN1YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0 aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg KFdHIENoYWlyIGhhdCBPZmYsIHRoaXMgaXMgbWVyZWx5IGEgbm90ZSBmcm9tIGEgc2xpZ2h0bHk8 YnI+DQomZ3Q7IGNvbmZ1c2VkIFdHPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgcGFydGljaXBhbnQuKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSSBoYXZlIGJlZW4g cmVhZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXM8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBuZXR3b3JrcyBwcm9ncmFtbWluZyBh bmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW08YnI+DQomZ3Q7IHRyeWluZyB0 bzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGZpZ3VyZSBvdXQgb25l IGFzcGVjdCBvZiB0aGUgY29tYmluYXRpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBIb3cg ZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2YgYnlwYXNzIChzdXBwb3NlLCBm b3I8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBzaW1wbGljaXR5LCBp dCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQgZm9yPGJyPg0KJmd0 OyBhIGZhaWxlZDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IG5vZGUg TjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRvIHNvPzxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0IGlzICZxdW90O3NhZmUmcXVv dDsgaWYgdGhlIG5ldyBwYXRoPGJyPg0KJmd0OyBtZWV0czxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7IHRoZSBURSBjcml0ZXJpYS4mbmJzcDsgb3IgbWF5YmUgaXQgaXMg c2FmZSBpZiBpdCBpcyBldmVuIGNsb3NlLCBhczxicj4NCiZndDsgbG9uZyBhczxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9u Zy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEJ1dCB3aGF0IGlmIHRoZSBub2RlIHdlcmUgYSBG aXJld2FsbCwgaW5jbHVkZWQgdG8gbWVldCBsZWdhbDxicj4NCiZndDsgJmd0OyByZXF1aXJlbWVu dHM/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgT3Igd2FzIHNvbWUg b3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0cmFuc2Zvcm0gKHdpbmNlIHdlIGFyZTxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGRlbGliZXJhdGVseSB2YWd1ZSBh Ym91dCB3aGF0IG5vZGVzIGNhbiBkbyB3aGVuIGFza2VkIHN1aXRhYmx5Lik8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7IElzIHRoZXJlIHNvbWUgJnF1b3Q7Y2FuIGJlIGJ5cGFzc2VkJnF1b3Q7IGlu ZGljYXRpb24gaW4gdGhlIHJvdXRpbmc8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPzxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgVGhhbmsgeW91LDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 IFlvdXJzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEpvZWw8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgc3By aW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnICZsdDttYWlsdG86c3ByaW5n QGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTIiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lV a3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVr elc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMl M0ElMjUyPC9hPiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBG JTxhIGhyZWY9Imh0dHA6Ly8yRnd3dy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjJGd3d3Lmll dGYub3JnPC9hPjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly8yRnd3dy5pZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly8yRnd3dy5pZXRmLm9yZzwvYT4mZ3Q7JTJGbWFpbG1hbiUy Rmxpc3RpbmZvJTJGc3ByaW5nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5n QGlldGYub3JnPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2Ns aWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5 dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7 ICZndDsgTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBt YXkgY29udGFpbjxicj4NCiZndDsgJmd0OyBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNh dGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbDxicj4NCiZndDsgYW5kL29yPGJyPg0KJmd0 OyAmZ3Q7IHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lw aWVudC4gQW55IHJldmlldyw8YnI+DQomZ3Q7ICZndDsgZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3Ig ZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQ8YnI+DQomZ3Q7ICZn dDsgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUg bm90IHRoZTxicj4NCiZndDsgaW50ZW5kZWQ8YnI+DQomZ3Q7ICZndDsgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbDxicj4N CiZndDsgJmd0OyBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9h Pjxicj4NCiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR03MB5056610F42282B6883CED19EEE4A0VI1PR03MB5056eurp_-- From nobody Mon Aug 3 17:18:45 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958BF3A118D for ; Mon, 3 Aug 2020 17:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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 ehYqE9cuUJ0u for ; Mon, 3 Aug 2020 17:18:40 -0700 (PDT) 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 DC33D3A118B for ; Mon, 3 Aug 2020 17:18:39 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id x9so41647218ljc.5 for ; Mon, 03 Aug 2020 17:18:39 -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=9noS4MOGsARFGY4wNTKQntbZCa1TscH1f9mWvWpUrro=; b=OxlBy0VmnZxbxNFb2ZC5uZNc8UlkKVMJtaXhHyTjrS/PjL6SVv1shihswAYL57vMR9 N6vM5bvo2RG/22UvO9C39x+aHMV+lYK8omDq2iS+P+039RMEALDJiPfrbyw4540ukATW 2Bxj/i8/5JAOnpZ+l1oYZAvpqqUS/fs1XgeRyfd2trG5mZ37VmoQbBIzEpd0eoGVo3AS iap2N8vatYa8PElcnCN3PptlklIIGy6sCGZJTDmAuL3XzPJjcXkbnQ0uSgLKqTWEFTrk eXI9T5ed8bX4uExaLWS80CEsDvgT2QLuGe2re0+WgkhgOK2AcgRe1JmORq8kxhS/nTZy Ji/A== 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=9noS4MOGsARFGY4wNTKQntbZCa1TscH1f9mWvWpUrro=; b=bbIeXDC4kjlED+TBZcx6RQyF/lqjZ19PeltRJA54LTcLj9yydkxrw75CAFXiAaQMj3 EtcQTr9fFUmUVB2r4l4ctuEsRulmDlHwLz+CgSCfLz+8HHGHjjfUK8daB5/5Lty/YB41 gpnc0agBrgF/1OM3RkKLXQpEXNYEWInLBu/tz1mXnuzn5B7nBPKogDRBJ/Ik15gIvDxx GO/9J2oUY1lojRGca2tV1Z9q3ifgdA7j0DocML7/W76s0tS53KHFDo203K0oXglCigMX Psi1VnDrfcB15WgK9wTlOO/rkT4oZevaiHe682gdKGeyDiabgu3GTzQKfdaBDDNi7E8y BHaA== X-Gm-Message-State: AOAM5332YPeViZTdF2Nz+yR1xtu1+ykrRc9qDFjvil34eDlqDw3TVpz9 vse/AosN/3E2DqFBYQlxTp0duCBEW0aFJtug0kY= X-Google-Smtp-Source: ABdhPJzlN+fL5rjGdD08tjcl3WbTIb09acLSzS5L4ZXRybZBwkq90IUWe0F7AvpJU3HU8E9122oTUduWe/DV3n7vDlY= X-Received: by 2002:a2e:87c4:: with SMTP id v4mr8775187ljj.8.1596500317837; Mon, 03 Aug 2020 17:18:37 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: From: Greg Mirsky Date: Mon, 3 Aug 2020 17:18:26 -0700 Message-ID: To: Andrew Alston Cc: "Joel M. Halpern" , Robert Raszuk , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000541eed05ac023253" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 00:18:44 -0000 --000000000000541eed05ac023253 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, thank you for your expedient response. I understand why operators are using S-BFD to monitor the continuity of p2p SR-MPLS tunnel. But I'd note that S-BFD does not support monitoring of multicast trees, ones that now can be realized using the Replication SID defined in draft-voyer-spring-sr-replication-segment . But that can be achieved using RFC 8563 . Multicast and Composite polling methods might not provide the required defect detection by the head of the multicast tree. There's a faster option mentioned in RFC 8563, Unsolicited notification. Applicability of the Unsolicited mode to SR-MPLS is described in draft-mirsky-spring-bfd . Regards, Greg On Mon, Aug 3, 2020 at 5:05 PM Andrew Alston < Andrew.Alston@liquidtelecom.com> wrote: > Greg we effectively get this using sbfd and fall back paths at the moment > =E2=80=93 far from ideal =E2=80=93 but it does work. > > > > There are also other methods of detecting end to end reachability to do > blackhole detection etc =E2=80=93 particularly in the face of the fact th= at I=E2=80=99ve > yet to see a functional implication of the sid verification flag. > > > > Could things be improved this regard? 100% but for now =E2=80=93 the deep= seated > and critical need for the requirement overrides the drawbacks of the > protection mechanisms we are forced to use at this point > > > > Andrew > > > > > > *From:* Greg Mirsky > *Sent:* Tuesday, 4 August 2020 01:40 > *To:* Andrew Alston > *Cc:* Joel M. Halpern ; Robert Raszuk < > robert@raszuk.net>; spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi Andrew, > > would such requirements support using e2e protection? > > > > Regards, > > Greg > > > > On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston < > Andrew.Alston@liquidtelecom.com> wrote: > > So =E2=80=93 > > > > One of the use cases, in fact, some very major use cases in any spring > technology for us revolve around the following > > > > a. The explicit avoidance of certain nodes > > b. The explicit avoidance of certain sections of the network > > > > Anything that could result in that explicit avoidance being violated =E2= =80=93 > would create, shall we say significant problems. > > > > Much of the use case is not a case of which nodes the packets flow throug= h > =E2=80=93 but rather =E2=80=93 which nodes / network segments it can neve= r touch or flow > through. Effectively, to be used as a technology to avoid certain things > for specific reasons. > > > > This is also one of the reasons for needing such deep label stacks =E2=80= =93 this > kind of detailed path programming tends to deepen the stack because you > sometimes have to be pretty explicit. > > > > It is absolutely critical to us that this functionality is there =E2=80= =93 and > that we can avoid situations which could cause traffic to accidently hit > things explicitly avoided. > > > > I wish I could be more specific than this, but it is what it is. > > > > Thanks > > > > Andrew > > > > > > *From:* spring *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > (Since the thread has gotten long enough, reiterating that this is as a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks that > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clear > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve QoS. > > Let's be clear. I am not arguing that this is not a good idea. It is a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you bette= r > > apply IP encapsulation to that node. I don't think IP encapsulation can > > be hijacked today such that destination address of the packet is ignore= d. > > > > B) Have you seen any IP network where upon topology change (link or nod= e > > failure) you suddenly start dropping flows in spite of SPT offering > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > >> wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex te > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the packet > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instruction= s > > > > > > 2.Segments that represent topological instructions can be bypassed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, two > > > > > > topological segments are defined: the IGP-Adjacency segment and the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and the > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Section > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > < > https://datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-= for-sr-te-paths-07#section-3.4 > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When the > > > > > > provider edge routers exchange service labels via BGP or some > > other > > > > > > non-IGP mechanism the bottom label is not understood in the IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 ] is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between =E2=80=9Ctopological= =E2=80=9D and > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed problemat= ic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs could = be prevented > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > >> On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > >>; spring@ietf.org > > > > Subject: Re: [spring] Spring protection - determining applicability > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in the > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicability > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the various > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, for > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new path > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we are > > > > > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > >> > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%= 2 > > > > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2> > > > > > > > F%2Fwww.ietf.org > > %2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > < > mailto:spring@ietf.org > > >> > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > -----------------------------------------------------------------------= - > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any review, > > > disclosure, reliance or distribution by others or forwarding without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete all > > > copies, including any attachments. > > > > > -----------------------------------------------------------------------= - > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --000000000000541eed05ac023253 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,
thank you for your expedient response. I un= derstand why operators are using S-BFD to monitor the continuity of p2p SR-= MPLS=C2=A0tunnel. But I'd note that S-BFD does not support monitoring o= f multicast trees, ones that now can be realized using the Replication SID = defined in=C2=A0draft-voyer-spring-sr-replication-segment. Bu= t that can be achieved using RFC 8563. Multicast and Composite polling methods might not provide t= he required defect detection by the head of the multicast tree. There's= a faster option mentioned in RFC 8563, Unsolicited notification. Applicabi= lity of the Unsolicited mode to SR-MPLS is described in=C2=A0dr= aft-mirsky-spring-bfd.

Regards,
Greg=

On Mon, Aug 3, 2020 at 5:05 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrot= e:

Greg we effectively get this us= ing sbfd and fall back paths at the moment =E2=80=93 far from ideal =E2=80= =93 but it does work.

=C2=A0

There are also other methods of= detecting end to end reachability to do blackhole detection etc =E2=80=93 = particularly in the face of the fact that I=E2=80=99ve yet to see a functio= nal implication of the sid verification flag.

=C2=A0

Could things be improved this r= egard? 100% but for now =E2=80=93 the deep seated and critical need for the= requirement overrides the drawbacks of the protection mechanisms we are fo= rced to use at this point

=C2=A0

Andrew

=C2=A0

=C2=A0

F= rom: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, 4 August 2020 01:40
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Joel M. Halpern <jmh@joelhalpern.com>; Robert Raszuk <robert@raszuk.net>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= u>

=C2=A0

Hi Andrew,<= /p>

would such requirements s= upport using e2e protection?

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Aug 3, 2020 at 2:= 46 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:<= /u>

So =E2=80=93

=C2=A0

One of the use cases, in fact, some very major use cas= es in any spring technology for us revolve around the following

=C2=A0

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The explicit avoidance of = certain nodes

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The explicit avoidance of = certain sections of the network

=C2=A0

Anything that could result in that explicit avoidance = being violated =E2=80=93 would create, shall we say significant problems.

=C2=A0

Much of the use case is not a case of which nodes the = packets flow through =E2=80=93 but rather =E2=80=93 which nodes / network s= egments it can never touch or flow through.=C2=A0 Effectively, to be used a= s a technology to avoid certain things for specific reasons.

=C2=A0

This is also one of the reasons for needing such deep = label stacks =E2=80=93 this kind of detailed path programming tends to deep= en the stack because you sometimes have to be pretty explicit.

=C2=A0

It is absolutely critical to us that this functionalit= y is there =E2=80=93 and that we can avoid situations which could cause tra= ffic to accidently hit things explicitly avoided.

=C2=A0

I wish I could be more specific than this, but it is w= hat it is.

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

From: spring <spring-bounces@i= etf.org> On Behalf Of Joel M. Halpern
Sent: Monday, 3 August 2020 21:36
To: Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

(Since the thread has gotten long enough, reiterating = that this is as a
participant, not a WG chair.)

Yes, we are talking IP networks. And yes, I have seen IP networks that
choose to drop packets. For all sorts of reasons.
I think there are likely other reasons why one may not want a random
path rather than a chosen TE path. I think it is important we be clear
about what constraints may be / are violated when we tell people they
have this tool (protective rerouting) that is intended to preserve QoS.

Let's be clear. I am not arguing that this is not a good idea. It is a =
good idea. And useful. I am trying to figure otu what combination of
additional mechanisms and clear descriptions will lead to everyone
getting the behavior they expect (which may not be the behavior they
desire, but sometimes is the best we can do.)

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> Joel,
>
> Are we still talking about IP networks=C2=A0here ? Or perhaps some har= d
> slicing with real resource reservations or detnets ?
>
> Because=C2=A0if we are talking=C2=A0about IP networking I have two obs= ervations:
>
> A) If you need to traverse via a specific node (ie. firewall) you bett= er
> apply IP encapsulation to that node. I don't think IP encapsulatio= n=C2=A0can
> be hijacked today such that destination address of the packet is ignor= ed.
>
> B) Have you seen any IP network where upon topology change (link or no= de
> failure) you suddenly=C2=A0start dropping=C2=A0flows in spite of SPT o= ffering
> perhaps few ms longer path with 10 ms more jitter ?
>
> Or are some SR marketing slides promise to turn IP networks in
> something=C2=A0new ? Worse ... do they mention path quality guarantees= ,
> resource reservations=C2=A0? I hope not.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>> wrote:
>
> Well less serious for TE SIDs, I am not sure the problem is restricted=
> to just service SIDs.
>
> Suppose that the PCE has specified the path to meet some complex te > objective.=C2=A0 The bypass node has no way of knowing what those
> constraints
> were.=C2=A0 And for some kinds of traffic, it is better to drop the pa= cket
> than to deliver it outside the envelop.=C2=A0 I suspect that the right=
> answer
> to this is "too bad".=C2=A0 If so, as with the distinction r= egarding service
> nodes, we should say so, shouldn't we?
>
> Yours,
> Joel
>
> On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> > Mach, Joel and all,
> >
> > I think that in most cases:
> >
> > 1.There is clear differentiation between "topological" = and "service"
> > instructions in SID advertisements. E.g.:
> >
> > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
> > corresponding IGP advertisements) represent topological instructi= ons
> >
> > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
> >
> <https://datatracker.ietf.org/doc/html/dr= aft-ietf-bess-srv6-services-04>
>
> > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instruc= tions
> >
> > 2.Segments that represent topological instructions can be bypasse= d,
> > while segments that represent service instructions require
> alternative
> > protection mechanisms.
> >
> > This view seems to be aligned with RFC 8402
> > <https://tools.ietf.org/html/rfc8402> that says in Section 1: > >
> >=C2=A0 =C2=A0=C2=A0 In the context of an IGP-based distributed con= trol plane, two
> >
> > topological segments are defined: the IGP-Adjacency segment and t= he
> >
> >=C2=A0 =C2=A0=C2=A0 IGP-Prefix segment.
> >
> >=C2=A0 =C2=A0=C2=A0 In the context of a BGP-based distributed cont= rol plane, two
> >
> > topological segments are defined: the BGP peering segment and the=
> >
> >=C2=A0 =C2=A0=C2=A0 BGP-Prefix segment.
> >
> > In the case of SR-MPLS this differentiation is assumed in Section=
> 3.4 of
> > the Node Protection for SR-TE Path
> >
> <https:/= /datatracker.ietf.org/doc/html/draft-hegde-spring-node-protection-for-sr-te= -paths-07#section-3.4>
>
> > draft that says:
> >
> >=C2=A0 =C2=A0=C2=A0 The node protection mechanism described in the= previous sections
> >
> >=C2=A0 =C2=A0=C2=A0 depends on the assumption that the label immed= iately below
> the top
> >
> > label in the label stack is understood in the IGP domain.=C2=A0 W= hen the
> >
> >=C2=A0 =C2=A0=C2=A0 provider edge routers exchange service labels = via BGP or some
> other
> >
> >=C2=A0 =C2=A0=C2=A0 non-IGP mechanism the bottom label is not unde= rstood in the IGP
> >
> >=C2=A0 =C2=A0=C2=A0 domain.
> >
> >=C2=A0 =C2=A0=C2=A0 The egress node protection mechanisms describe= d in the draft
> >
> >=C2=A0 =C2=A0=C2=A0 [RFC8679 <https://datatracker.ietf.org/doc= /html/rfc8679>] is
> > applicable to this use case and no additional changes
> >
> >=C2=A0 =C2=A0=C2=A0 will be required for SR based networks
> >
> > The scenarios in which =C2=A0differentiation between =E2=80=9Ctop= ological=E2=80=9D and
> > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed probl= ematic. E.g.,
> consider
> > the use case in which a Node SID in the ERO of a SR-TE path
> identifies a
> > node that acts as a firewall for all packets it receives, i.e., > provides
> > the firewall service without any dedicated service SID
> identifying it.
> > One could say that the Node SID of such a node would combine
> topological
> > and service instructions thus breaking the differentiation
> between the two.
> >
> > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs co= uld be prevented
> or at
> > least discouraged.
> >
> > If not, providing an ability to identify such SIDs in the
> advertisement
> > mechanisms would be useful IMHO.
> >
> > My 2c,
> >
> > Sasha
> >
> > Office: +972-39266302
> >
> > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
> >
> > Email: Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>
> >
> > -----Original Message-----
> > From: spring <spring-bounces@ietf.org
> <m= ailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
> > Sent: Monday, August 3, 2020 6:30 AM
> > To: Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org &l= t;mailto:spring@ietf.o= rg>
> > Subject: Re: [spring] Spring protection - determining applicabili= ty
> >
> > Hi Joel,
> >
> > I think this is a good point that may not be discussed in the
> past. And
> > I also don't think there is a "can be bypassed" ind= ication in the
> > routing advertisement for now.
> >
> > IMHO, the information advertised by routing is neutral, such
> information
> > (can or cannot be bypassed) is more path specific, thus normally = the
> > controller should be responsible for deciding whether/which SID > can be
> > bypassed.
> >
> > Best regards,
> >
> > Mach
> >
> >=C2=A0 > -----Original Message-----
> >
> >=C2=A0 > From: spring [mailto:sp= ring-bounces@ietf.org
> <mailto:spring-bounces@ietf.org>] On Behalf Of Joel M.
> >
> >=C2=A0 > Halpern
> >
> >=C2=A0 > Sent: Monday, August 3, 2020 7:51 AM
> >
> >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >=C2=A0 > Subject: [spring] Spring protection - determining appl= icability
> >
> >=C2=A0 >
> >
> >=C2=A0 > (WG Chair hat Off, this is merely a note from a slight= ly
> confused WG
> >
> >=C2=A0 > participant.)
> >
> >=C2=A0 >
> >
> >=C2=A0 > I have been reading the various repair drafts, and the= various
> >
> >=C2=A0 > networks programming and service programming draft, an= d I am
> trying to
> >
> >=C2=A0 > figure out one aspect of the combination.
> >
> >=C2=A0 >
> >
> >=C2=A0 > How does a node that is doing some form of bypass (sup= pose, for
> >
> >=C2=A0 > simplicity, it is Node N2 deciding to bypass the next = SID for
> a failed
> >
> >=C2=A0 > node N3) know that it is safe to do so?
> >
> >=C2=A0 >
> >
> >=C2=A0 > If the path was just for TE, then it is "safe&quo= t; if the new path
> meets
> >
> >=C2=A0 > the TE criteria.=C2=A0 or maybe it is safe if it is ev= en close, as
> long as
> >
> >=C2=A0 > it is not used for too long.
> >
> >=C2=A0 >
> >
> >=C2=A0 > But what if the node were a Firewall, included to meet= legal
> > requirements?
> >
> >=C2=A0 > Or was some other necessary programmatic transform (wi= nce we are
> >
> >=C2=A0 > deliberately vague about what nodes can do when asked = suitably.)
> >
> >=C2=A0 >
> >
> >=C2=A0 > Is there some "can be bypassed" indication i= n the routing
> >
> >=C2=A0 > advertisements that I missed?
> >
> >=C2=A0 >
> >
> >=C2=A0 > Thank you,
> >
> >=C2=A0 > Yours,
> >
> >=C2=A0 > Joel
> >
> >=C2=A0 >
> >
> >=C2=A0 > _______________________________________________
> >
> >=C2=A0 > spring mailing list
> >
> >=C2=A0 > s= pring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >=C2=A0 >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
> >
> <https://clicktime.symantec.com/367qh= U4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252>
> >
> >=C2=A0 > F%= 2Fwww.ietf.org
> <http://2Fwww.i= etf.org>%2Fmailman%2Flistinfo%2Fspring
> >
> > _______________________________________________
> >
> > spring mailing list
> >
> > spring@ietf.= org <mailto:spr= ing@ietf.org> <mailto:spring@ietf.org
> <mailto:sp= ring@ietf.org>>
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> >
> ----------------------------------------------------------------------= --
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. that is confidential > and/or
> > proprietary for the sole use of the intended recipient. Any revie= w,
> > disclosure, reliance or distribution by others or forwarding with= out
> > express permission is strictly prohibited. If you are not the
> intended
> > recipient, please notify the sender immediately and then delete a= ll
> > copies, including any attachments.
> >
> ----------------------------------------------------------------------= --
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.= org <mailto:spr= ing@ietf.org>
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@i= etf.org>
> https://www.ietf.org/mailman/listinfo/spring
>

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

_________________________= ______________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

--000000000000541eed05ac023253-- From nobody Mon Aug 3 17:23:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2DA3A11A6 for ; Mon, 3 Aug 2020 17:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xQkvTJQiMHo4 for ; Mon, 3 Aug 2020 17:23:42 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204DE3A1198 for ; Mon, 3 Aug 2020 17:23:40 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2050.outbound.protection.outlook.com [104.47.9.50]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-79-DRson8PmPzOVoDazTTD4EA-1; Tue, 04 Aug 2020 01:23:36 +0100 X-MC-Unique: DRson8PmPzOVoDazTTD4EA-1 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB6144.eurprd03.prod.outlook.com (2603:10a6:800:141::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.18; Tue, 4 Aug 2020 00:23:34 +0000 Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::4d00:9161:93e0:d117%3]) with mapi id 15.20.3239.021; Tue, 4 Aug 2020 00:23:34 +0000 From: Andrew Alston To: Greg Mirsky CC: "Joel M. Halpern" , Robert Raszuk , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfFqqBapiFGQU+SeGw1le2xJKklun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADOyIIAAEIiAgAAW4uCAAASgAIAAAKBw Date: Tue, 4 Aug 2020 00:23:34 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2c0f:fe40:3:2:1f5:9343:5fd4:b3ae] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8990f3ba-1999-462d-2f1a-08d8380c9fda x-ms-traffictypediagnostic: VI1PR03MB6144: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DAqAfmyXUlFGNewosFLgtooVREjWrz/E9rPJUUOFE7dlQEfHl4SJyfVNnRNYgwIY7xsiocG1aICSSM77yMkylFWOg2nOEtxX6imAYOH39PHepq4Ua+QI8e/yidsrwUIrprU0lcBzzdYwgppu7QvnOWQucD58GwulrsTG7OLuLPfM6kYkWMO/NHg6Cfv48eobdu5tJxU41XJ4xQJ8gnk28PkelI2Zl/E09voUhe4NDxoKy2qHVEy/ZbZICJ7EbjtEcLCugY9Am2ZGdDiiXti5iDzt6MdqYHQcWTFX6NjIJNoszLeFIFs0NJGTeBJQp1dvABM9XCeL/Gmf1kliF4cfhZ7MI0vwG4fM0Q2kU1G+7Wcvy9VGCyRFAAl10IDF21C6v6zgbqiQM8D1AkE42XsLBA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(8676002)(8936002)(2906002)(966005)(66556008)(498600001)(66476007)(30864003)(4326008)(76116006)(6916009)(66446008)(64756008)(166002)(66946007)(52536014)(5660300002)(55016002)(71200400001)(9686003)(7696005)(53546011)(186003)(6506007)(54906003)(33656002)(83380400001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ORuZ4HYmlsGtHBKFeeP56Ol7KWyM1S5JYAd9OiecdrHHsvqb5FeSDuvxCTqdz7NPqCON2ToOQp8Qw7p+Nhr3oQs8rqaYNJgHaeLzwsmJyLJ7+ygT1cjvaG1ea5lIjG8XRL5lfQDvEVQITiyeTwsWWyD1sOyW52oW3qGF7gIuMLLL1rojPnxXntweO3g0IEtFluCl/F3OKu55uIymxtIv3YcShY8+sisuLcyzpSfgaQrbbiyrwF3+CEWl+7/L8chGJJ/anJ9FChL1HritKM8Y8s5Em/DsjJp6G6Fmt0HIjtCs7RLqA3Lhj4GZJkGqzrvIxZ7II++O0kxNE0WINVWhcoucHzrvOXOrmhB3d8jKBcsDmXlWg/AOhbqUzg/qvL3375PVuAJZC2HnH/0xvbEA4eLM9oc4bHBfKj7XMgL4g7TShroHBKyfAjALujh7KNdW+p/yIyEsoDia9BLl6wmaysAPHxyIatY8wVTYMKnDMAVPQ3AsS0kdwAAozWCJgCeH7PkZ2oZfvsfEzhR6mvZ+pc3Ry5zaIRI6I1vh9Jq6tX6ud2eDUK2R23zDQJM8s+qimPpTffPcXUtDr75BdXlLrP7jGbsk6dyiFjFi4lU4aOv6GW4HukxZP5yTrrqdF2RM4wYU30mXXkoXG0Q8/l4zdrsiA99WpLeAWvEfmyfaO4p64sGZnXd7gJxr1mvhqmNJamt4zdjZ2l8sU2Rbszc7mQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR03MB5056.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8990f3ba-1999-462d-2f1a-08d8380c9fda X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 00:23:34.3065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: scY+510+ktg/4AnJMZItGIfqB/2Th35M2do4YnEQSjXrjSUIez9vA7hby4+GaHlOdpFNHf/VK3xUqNcjUdMbopNVcmVArxS0jtgNjFtOv54= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6144 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Type: multipart/alternative; boundary="_000_VI1PR03MB5056A08F38488F43DD8298ACEE4A0VI1PR03MB5056eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 00:23:46 -0000 --_000_VI1PR03MB5056A08F38488F43DD8298ACEE4A0VI1PR03MB5056eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGF2ZSB0byBjb25mZXNzLA0KDQpXZeKAmXZlIGhhZCBubyBuZWVkIHdoYXQgc28gZXZlciB0byBj b25zaWRlciB0aGF0IGluIG91ciB1c2UgY2FzZSBwbGFubmluZyDigJMgYW5kIGRvbuKAmXQgc2Vl IG9uZSBpbiB0aGUgbmVhciBmdXR1cmUuICBOb3Qgc29tZXRoaW5nIHdl4oCZcmUgY29uY2VybmVk IGFib3V0IOKAkyB3aGljaCBkb2VzbuKAmXQgZGltaW5pc2ggdGhlIGZhY3QgdGhhdCBvdGhlcnMg bWF5IGJlIGFuZCB0aGVyZSBtYXkgd2VsbCBiZSBhIGNhc2UgdG8gYmUgbWFkZSBoZXJlLCBqdXN0 IOKAkyBraW5kYSBvdXQgb2Ygc2NvcGUgb2Ygd2hhdCB3ZeKAmXZlIGxvb2tlZCBhdCBkdWUgdG8g b3VyIHJhdGhlciB1cmdlbnQgbmVlZHMgdG8gZmlyc3QgbWVldCBvdXIgY3VycmVudCBjcml0aWNh bCByZXF1aXJlbWVudHMuICBUaGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyB3aHkgSSBoYXZlIHNh aWQgdGhhdCBpcnJlc3BlY3RpdmUgb2Ygd2hhdCBvY2N1cnMgd2l0aGluIHRoZSBJRVRGIGFzIHJl Z2FyZHMgQ1JIIOKAkyB3ZeKAmXJlIGdvaW5nIGFoZWFkIOKAkyB0aGUgbmVlZCBmb3IgZGVlcCBs YWJlbCBzdGFjayBhbmQgdGhlIG5lZWQgZm9yIHJ1bm5pbmcgcHJvZHVjdGlvbiByZWFkeSBjb2Rl IGlzIG9mIGFuIHVyZ2VuY3kgdGhhdCBubyBsb25nZXIgYWxsb3dzIHVzIHRvIHdhaXQgZm9yIG1v bnRocyDigJMgdGhhbmtmdWxseSB3ZSBnZXQgd2hhdCB3ZSBuZWVkIGFzIGEgcmVzdWx0IG9mIENS SCBhbmQgaXQgZG9lcyB3b3JrIOKAkyBhbmQgd29yayB3ZWxsDQoNClRoYW5rcw0KDQpBbmRyZXcN Cg0KDQpGcm9tOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KU2VudDogVHVl c2RheSwgNCBBdWd1c3QgMjAyMCAwMzoxOA0KVG86IEFuZHJldyBBbHN0b24gPEFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20+DQpDYzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBl cm4uY29tPjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+OyBzcHJpbmdAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5n IGFwcGxpY2FiaWxpdHkNCg0KSGkgQW5kcmV3LA0KdGhhbmsgeW91IGZvciB5b3VyIGV4cGVkaWVu dCByZXNwb25zZS4gSSB1bmRlcnN0YW5kIHdoeSBvcGVyYXRvcnMgYXJlIHVzaW5nIFMtQkZEIHRv IG1vbml0b3IgdGhlIGNvbnRpbnVpdHkgb2YgcDJwIFNSLU1QTFMgdHVubmVsLiBCdXQgSSdkIG5v dGUgdGhhdCBTLUJGRCBkb2VzIG5vdCBzdXBwb3J0IG1vbml0b3Jpbmcgb2YgbXVsdGljYXN0IHRy ZWVzLCBvbmVzIHRoYXQgbm93IGNhbiBiZSByZWFsaXplZCB1c2luZyB0aGUgUmVwbGljYXRpb24g U0lEIGRlZmluZWQgaW4gZHJhZnQtdm95ZXItc3ByaW5nLXNyLXJlcGxpY2F0aW9uLXNlZ21lbnQ8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZveWVyLXNwcmluZy1zci1yZXBsaWNh dGlvbi1zZWdtZW50LTAyPi4gQnV0IHRoYXQgY2FuIGJlIGFjaGlldmVkIHVzaW5nIFJGQyA4NTYz PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NTYzPi4gTXVsdGljYXN0IGFuZCBDb21w b3NpdGUgcG9sbGluZyBtZXRob2RzIG1pZ2h0IG5vdCBwcm92aWRlIHRoZSByZXF1aXJlZCBkZWZl Y3QgZGV0ZWN0aW9uIGJ5IHRoZSBoZWFkIG9mIHRoZSBtdWx0aWNhc3QgdHJlZS4gVGhlcmUncyBh IGZhc3RlciBvcHRpb24gbWVudGlvbmVkIGluIFJGQyA4NTYzLCBVbnNvbGljaXRlZCBub3RpZmlj YXRpb24uIEFwcGxpY2FiaWxpdHkgb2YgdGhlIFVuc29saWNpdGVkIG1vZGUgdG8gU1ItTVBMUyBp cyBkZXNjcmliZWQgaW4gZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQ8aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQvP2luY2x1ZGVfdGV4dD0xPi4N Cg0KUmVnYXJkcywNCkdyZWcNCg0KT24gTW9uLCBBdWcgMywgMjAyMCBhdCA1OjA1IFBNIEFuZHJl dyBBbHN0b24gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PiB3cm90ZToNCkdyZWcgd2UgZWZmZWN0aXZlbHkgZ2V0 IHRoaXMgdXNpbmcgc2JmZCBhbmQgZmFsbCBiYWNrIHBhdGhzIGF0IHRoZSBtb21lbnQg4oCTIGZh ciBmcm9tIGlkZWFsIOKAkyBidXQgaXQgZG9lcyB3b3JrLg0KDQpUaGVyZSBhcmUgYWxzbyBvdGhl ciBtZXRob2RzIG9mIGRldGVjdGluZyBlbmQgdG8gZW5kIHJlYWNoYWJpbGl0eSB0byBkbyBibGFj a2hvbGUgZGV0ZWN0aW9uIGV0YyDigJMgcGFydGljdWxhcmx5IGluIHRoZSBmYWNlIG9mIHRoZSBm YWN0IHRoYXQgSeKAmXZlIHlldCB0byBzZWUgYSBmdW5jdGlvbmFsIGltcGxpY2F0aW9uIG9mIHRo ZSBzaWQgdmVyaWZpY2F0aW9uIGZsYWcuDQoNCkNvdWxkIHRoaW5ncyBiZSBpbXByb3ZlZCB0aGlz IHJlZ2FyZD8gMTAwJSBidXQgZm9yIG5vdyDigJMgdGhlIGRlZXAgc2VhdGVkIGFuZCBjcml0aWNh bCBuZWVkIGZvciB0aGUgcmVxdWlyZW1lbnQgb3ZlcnJpZGVzIHRoZSBkcmF3YmFja3Mgb2YgdGhl IHByb3RlY3Rpb24gbWVjaGFuaXNtcyB3ZSBhcmUgZm9yY2VkIHRvIHVzZSBhdCB0aGlzIHBvaW50 DQoNCkFuZHJldw0KDQoNCkZyb206IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208 bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQpTZW50OiBUdWVzZGF5LCA0IEF1Z3VzdCAy MDIwIDAxOjQwDQpUbzogQW5kcmV3IEFsc3RvbiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbTxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+DQpDYzogSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t Pj47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldD4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxp dHkNCg0KSGkgQW5kcmV3LA0Kd291bGQgc3VjaCByZXF1aXJlbWVudHMgc3VwcG9ydCB1c2luZyBl MmUgcHJvdGVjdGlvbj8NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gTW9uLCBBdWcgMywgMjAyMCBh dCAyOjQ2IFBNIEFuZHJldyBBbHN0b24gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208 bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PiB3cm90ZToNClNvIOKAkw0K DQpPbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2ZXJ5IG1ham9yIHVzZSBjYXNl cyBpbiBhbnkgc3ByaW5nIHRlY2hub2xvZ3kgZm9yIHVzIHJldm9sdmUgYXJvdW5kIHRoZSBmb2xs b3dpbmcNCg0KDQphLiAgICAgIFRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2YgY2VydGFpbiBub2Rl cw0KDQpiLiAgICAgIFRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2YgY2VydGFpbiBzZWN0aW9ucyBv ZiB0aGUgbmV0d29yaw0KDQpBbnl0aGluZyB0aGF0IGNvdWxkIHJlc3VsdCBpbiB0aGF0IGV4cGxp Y2l0IGF2b2lkYW5jZSBiZWluZyB2aW9sYXRlZCDigJMgd291bGQgY3JlYXRlLCBzaGFsbCB3ZSBz YXkgc2lnbmlmaWNhbnQgcHJvYmxlbXMuDQoNCk11Y2ggb2YgdGhlIHVzZSBjYXNlIGlzIG5vdCBh IGNhc2Ugb2Ygd2hpY2ggbm9kZXMgdGhlIHBhY2tldHMgZmxvdyB0aHJvdWdoIOKAkyBidXQgcmF0 aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2VnbWVudHMgaXQgY2FuIG5ldmVyIHRvdWNo IG9yIGZsb3cgdGhyb3VnaC4gIEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9n eSB0byBhdm9pZCBjZXJ0YWluIHRoaW5ncyBmb3Igc3BlY2lmaWMgcmVhc29ucy4NCg0KVGhpcyBp cyBhbHNvIG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwgc3Rh Y2tzIOKAkyB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgcGF0aCBwcm9ncmFtbWluZyB0ZW5kcyB0byBk ZWVwZW4gdGhlIHN0YWNrIGJlY2F1c2UgeW91IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBl eHBsaWNpdC4NCg0KSXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1cyB0aGF0IHRoaXMgZnVu Y3Rpb25hbGl0eSBpcyB0aGVyZSDigJMgYW5kIHRoYXQgd2UgY2FuIGF2b2lkIHNpdHVhdGlvbnMg d2hpY2ggY291bGQgY2F1c2UgdHJhZmZpYyB0byBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhwbGlj aXRseSBhdm9pZGVkLg0KDQpJIHdpc2ggSSBjb3VsZCBiZSBtb3JlIHNwZWNpZmljIHRoYW4gdGhp cywgYnV0IGl0IGlzIHdoYXQgaXQgaXMuDQoNClRoYW5rcw0KDQpBbmRyZXcNCg0KDQpGcm9tOiBz cHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZz4+IE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IE1vbmRheSwgMyBBdWd1 c3QgMjAyMCAyMTozNg0KVG86IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0 bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRl cm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCihTaW5jZSB0aGUgdGhyZWFkIGhhcyBnb3R0ZW4gbG9u ZyBlbm91Z2gsIHJlaXRlcmF0aW5nIHRoYXQgdGhpcyBpcyBhcyBhDQpwYXJ0aWNpcGFudCwgbm90 IGEgV0cgY2hhaXIuKQ0KDQpZZXMsIHdlIGFyZSB0YWxraW5nIElQIG5ldHdvcmtzLiBBbmQgeWVz LCBJIGhhdmUgc2VlbiBJUCBuZXR3b3JrcyB0aGF0DQpjaG9vc2UgdG8gZHJvcCBwYWNrZXRzLiBG b3IgYWxsIHNvcnRzIG9mIHJlYXNvbnMuDQpJIHRoaW5rIHRoZXJlIGFyZSBsaWtlbHkgb3RoZXIg cmVhc29ucyB3aHkgb25lIG1heSBub3Qgd2FudCBhIHJhbmRvbQ0KcGF0aCByYXRoZXIgdGhhbiBh IGNob3NlbiBURSBwYXRoLiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB3ZSBiZSBjbGVhcg0KYWJv dXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlvbGF0ZWQgd2hlbiB3ZSB0ZWxsIHBl b3BsZSB0aGV5DQpoYXZlIHRoaXMgdG9vbCAocHJvdGVjdGl2ZSByZXJvdXRpbmcpIHRoYXQgaXMg aW50ZW5kZWQgdG8gcHJlc2VydmUgUW9TLg0KDQpMZXQncyBiZSBjbGVhci4gSSBhbSBub3QgYXJn dWluZyB0aGF0IHRoaXMgaXMgbm90IGEgZ29vZCBpZGVhLiBJdCBpcyBhDQpnb29kIGlkZWEuIEFu ZCB1c2VmdWwuIEkgYW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdHUgd2hhdCBjb21iaW5hdGlvbiBvZg0K YWRkaXRpb25hbCBtZWNoYW5pc21zIGFuZCBjbGVhciBkZXNjcmlwdGlvbnMgd2lsbCBsZWFkIHRv IGV2ZXJ5b25lDQpnZXR0aW5nIHRoZSBiZWhhdmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5v dCBiZSB0aGUgYmVoYXZpb3IgdGhleQ0KZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBiZXN0 IHdlIGNhbiBkby4pDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA4LzMvMjAyMCAyOjMwIFBNLCBSb2Jl cnQgUmFzenVrIHdyb3RlOg0KPiBKb2VsLA0KPg0KPiBBcmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91 dCBJUCBuZXR3b3JrcyBoZXJlID8gT3IgcGVyaGFwcyBzb21lIGhhcmQNCj4gc2xpY2luZyB3aXRo IHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5ldHMgPw0KPg0KPiBCZWNhdXNlIGlm IHdlIGFyZSB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtpbmcgSSBoYXZlIHR3byBvYnNlcnZhdGlv bnM6DQo+DQo+IEEpIElmIHlvdSBuZWVkIHRvIHRyYXZlcnNlIHZpYSBhIHNwZWNpZmljIG5vZGUg KGllLiBmaXJld2FsbCkgeW91IGJldHRlcg0KPiBhcHBseSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRo YXQgbm9kZS4gSSBkb24ndCB0aGluayBJUCBlbmNhcHN1bGF0aW9uIGNhbg0KPiBiZSBoaWphY2tl ZCB0b2RheSBzdWNoIHRoYXQgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUgcGFja2V0IGlzIGln bm9yZWQuDQo+DQo+IEIpIEhhdmUgeW91IHNlZW4gYW55IElQIG5ldHdvcmsgd2hlcmUgdXBvbiB0 b3BvbG9neSBjaGFuZ2UgKGxpbmsgb3Igbm9kZQ0KPiBmYWlsdXJlKSB5b3Ugc3VkZGVubHkgc3Rh cnQgZHJvcHBpbmcgZmxvd3MgaW4gc3BpdGUgb2YgU1BUIG9mZmVyaW5nDQo+IHBlcmhhcHMgZmV3 IG1zIGxvbmdlciBwYXRoIHdpdGggMTAgbXMgbW9yZSBqaXR0ZXIgPw0KPg0KPiBPciBhcmUgc29t ZSBTUiBtYXJrZXRpbmcgc2xpZGVzIHByb21pc2UgdG8gdHVybiBJUCBuZXR3b3JrcyBpbg0KPiBz b21ldGhpbmcgbmV3ID8gV29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3Vh cmFudGVlcywNCj4gcmVzb3VyY2UgcmVzZXJ2YXRpb25zID8gSSBob3BlIG5vdC4NCj4NCj4gVGh4 LA0KPiBSLg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBPbiBNb24sIEF1ZyAzLCAyMDIw IGF0IDg6MTAgUE0gSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lMjAlMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ PiB3cm90ZToNCj4NCj4gV2VsbCBsZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90IHN1 cmUgdGhlIHByb2JsZW0gaXMgcmVzdHJpY3RlZA0KPiB0byBqdXN0IHNlcnZpY2UgU0lEcy4NCj4N Cj4gU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0aGUgcGF0aCB0byBtZWV0IHNv bWUgY29tcGxleCB0ZQ0KPiBvYmplY3RpdmUuICBUaGUgYnlwYXNzIG5vZGUgaGFzIG5vIHdheSBv ZiBrbm93aW5nIHdoYXQgdGhvc2UNCj4gY29uc3RyYWludHMNCj4gd2VyZS4gIEFuZCBmb3Igc29t ZSBraW5kcyBvZiB0cmFmZmljLCBpdCBpcyBiZXR0ZXIgdG8gZHJvcCB0aGUgcGFja2V0DQo+IHRo YW4gdG8gZGVsaXZlciBpdCBvdXRzaWRlIHRoZSBlbnZlbG9wLiAgSSBzdXNwZWN0IHRoYXQgdGhl IHJpZ2h0DQo+IGFuc3dlcg0KPiB0byB0aGlzIGlzICJ0b28gYmFkIi4gIElmIHNvLCBhcyB3aXRo IHRoZSBkaXN0aW5jdGlvbiByZWdhcmRpbmcgc2VydmljZQ0KPiBub2Rlcywgd2Ugc2hvdWxkIHNh eSBzbywgc2hvdWxkbid0IHdlPw0KPg0KPiBZb3VycywNCj4gSm9lbA0KPg0KPiBPbiA4LzMvMjAy MCAyOjM2IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gPiBNYWNoLCBKb2VsIGFu ZCBhbGwsDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgaW4gbW9zdCBjYXNlczoNCj4gPg0KPiA+IDEu VGhlcmUgaXMgY2xlYXIgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gInRvcG9sb2dpY2FsIiBhbmQg InNlcnZpY2UiDQo+ID4gaW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5nLjoN Cj4gPg0KPiA+IG9JR1AgUHJlZml4IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZpZWQg YXMgc3VjaCBpbiB0aGUNCj4gPiBjb3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50cykgcmVw cmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9ucw0KPiA+DQo+ID4gb1NlcnZpY2UgU0lEcyBm b3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92ZXJsYXkgU2VydmljZXMNCj4gPg0KPiA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1z ZXJ2aWNlcy0wNDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0Pj4NCj4NCj4gPiBkcmFmdCkgdW5zdXJwcmlzaW5nbHkg cmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zDQo+ID4NCj4gPiAyLlNlZ21lbnRz IHRoYXQgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9ucyBjYW4gYmUgYnlwYXNzZWQs DQo+ID4gd2hpbGUgc2VnbWVudHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMg cmVxdWlyZQ0KPiBhbHRlcm5hdGl2ZQ0KPiA+IHByb3RlY3Rpb24gbWVjaGFuaXNtcy4NCj4gPg0K PiA+IFRoaXMgdmlldyBzZWVtcyB0byBiZSBhbGlnbmVkIHdpdGggUkZDIDg0MDINCj4gPiA8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzg0MDI+PiB0aGF0IHNheXMgaW4gU2VjdGlvbiAxOg0KPiA+DQo+ID4gICAgIEluIHRo ZSBjb250ZXh0IG9mIGFuIElHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28N Cj4gPg0KPiA+IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgSUdQLUFkamFj ZW5jeSBzZWdtZW50IGFuZCB0aGUNCj4gPg0KPiA+ICAgICBJR1AtUHJlZml4IHNlZ21lbnQuDQo+ ID4NCj4gPiAgICAgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQgZGlzdHJpYnV0ZWQgY29u dHJvbCBwbGFuZSwgdHdvDQo+ID4NCj4gPiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5l ZDogdGhlIEJHUCBwZWVyaW5nIHNlZ21lbnQgYW5kIHRoZQ0KPiA+DQo+ID4gICAgIEJHUC1QcmVm aXggc2VnbWVudC4NCj4gPg0KPiA+IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMgdGhpcyBkaWZmZXJl bnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uDQo+IDMuNCBvZg0KPiA+IHRoZSBOb2RlIFBy b3RlY3Rpb24gZm9yIFNSLVRFIFBhdGgNCj4gPg0KPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10 ZS1wYXRocy0wNyNzZWN0aW9uLTMuNDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3 I3NlY3Rpb24tMy40Pj4NCj4NCj4gPiBkcmFmdCB0aGF0IHNheXM6DQo+ID4NCj4gPiAgICAgVGhl IG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0 aW9ucw0KPiA+DQo+ID4gICAgIGRlcGVuZHMgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgbGFi ZWwgaW1tZWRpYXRlbHkgYmVsb3cNCj4gdGhlIHRvcA0KPiA+DQo+ID4gbGFiZWwgaW4gdGhlIGxh YmVsIHN0YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElHUCBkb21haW4uICBXaGVuIHRoZQ0KPiA+ DQo+ID4gICAgIHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBleGNoYW5nZSBzZXJ2aWNlIGxhYmVscyB2 aWEgQkdQIG9yIHNvbWUNCj4gb3RoZXINCj4gPg0KPiA+ICAgICBub24tSUdQIG1lY2hhbmlzbSB0 aGUgYm90dG9tIGxhYmVsIGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1ANCj4gPg0KPiA+ICAg ICBkb21haW4uDQo+ID4NCj4gPiAgICAgVGhlIGVncmVzcyBub2RlIHByb3RlY3Rpb24gbWVjaGFu aXNtcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0DQo+ID4NCj4gPiAgICAgW1JGQzg2NzkgPGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODY3OTxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg2Nzk+Pl0gaXMNCj4gPiBhcHBsaWNhYmxlIHRvIHRo aXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdlcw0KPiA+DQo+ID4gICAgIHdpbGwg YmUgcmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzDQo+ID4NCj4gPiBUaGUgc2NlbmFyaW9z IGluIHdoaWNoICBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiDigJx0b3BvbG9naWNhbOKAnSBhbmQN Cj4gPiDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBicm9rZW4gYXJlIGluZGVlZCBwcm9i bGVtYXRpYy4gRS5nLiwNCj4gY29uc2lkZXINCj4gPiB0aGUgdXNlIGNhc2UgaW4gd2hpY2ggYSBO b2RlIFNJRCBpbiB0aGUgRVJPIG9mIGEgU1ItVEUgcGF0aA0KPiBpZGVudGlmaWVzIGENCj4gPiBu b2RlIHRoYXQgYWN0cyBhcyBhIGZpcmV3YWxsIGZvciBhbGwgcGFja2V0cyBpdCByZWNlaXZlcywg aS5lLiwNCj4gcHJvdmlkZXMNCj4gPiB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRob3V0IGFueSBk ZWRpY2F0ZWQgc2VydmljZSBTSUQNCj4gaWRlbnRpZnlpbmcgaXQuDQo+ID4gT25lIGNvdWxkIHNh eSB0aGF0IHRoZSBOb2RlIFNJRCBvZiBzdWNoIGEgbm9kZSB3b3VsZCBjb21iaW5lDQo+IHRvcG9s b2dpY2FsDQo+ID4gYW5kIHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHRodXMgYnJlYWtpbmcgdGhlIGRp ZmZlcmVudGlhdGlvbg0KPiBiZXR3ZWVuIHRoZSB0d28uDQo+ID4NCj4gPiBJIGFtIG5vdCBzdXJl IGlmIHVzYWdlIG9mIHN1Y2gg4oCcY29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2ZW50ZWQN Cj4gb3IgYXQNCj4gPiBsZWFzdCBkaXNjb3VyYWdlZC4NCj4gPg0KPiA+IElmIG5vdCwgcHJvdmlk aW5nIGFuIGFiaWxpdHkgdG8gaWRlbnRpZnkgc3VjaCBTSURzIGluIHRoZQ0KPiBhZHZlcnRpc2Vt ZW50DQo+ID4gbWVjaGFuaXNtcyB3b3VsZCBiZSB1c2VmdWwgSU1ITy4NCj4gPg0KPiA+IE15IDJj LA0KPiA+DQo+ID4gU2FzaGENCj4gPg0KPiA+IE9mZmljZTogKzk3Mi0zOTI2NjMwMg0KPiA+DQo+ ID4gQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPiA+DQo+ID4gRW1haWw6IEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4NCj4gPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4gPg0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc3ByaW5nIDxzcHJpbmct Ym91bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYj4+IDxt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFjaCBDaGVuDQo+ ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMwIEFNDQo+ID4gVG86IEpvZWwgTS4g SGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t JTBiPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj47IHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0 OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmls aXR5DQo+ID4NCj4gPiBIaSBKb2VsLA0KPiA+DQo+ID4gSSB0aGluayB0aGlzIGlzIGEgZ29vZCBw b2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZQ0KPiBwYXN0LiBBbmQNCj4gPiBJ IGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAiY2FuIGJlIGJ5cGFzc2VkIiBpbmRpY2F0aW9u IGluIHRoZQ0KPiA+IHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCBmb3Igbm93Lg0KPiA+DQo+ID4gSU1I TywgdGhlIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgYnkgcm91dGluZyBpcyBuZXV0cmFsLCBzdWNo DQo+IGluZm9ybWF0aW9uDQo+ID4gKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQpIGlzIG1vcmUg cGF0aCBzcGVjaWZpYywgdGh1cyBub3JtYWxseSB0aGUNCj4gPiBjb250cm9sbGVyIHNob3VsZCBi ZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBTSUQNCj4gY2FuIGJlDQo+ ID4gYnlwYXNzZWQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4NCj4gPiBNYWNoDQo+ID4N Cj4gPiAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+DQo+ID4gID4gRnJvbTogc3By aW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPG1haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZz48bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiJTNlJTIwJTNj bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTNlPl0gT24gQmVoYWxmIE9mIEpvZWwgTS4N Cj4gPg0KPiA+ICA+IEhhbHBlcm4NCj4gPg0KPiA+ICA+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMs IDIwMjAgNzo1MSBBTQ0KPiA+DQo+ID4gID4gVG86IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3By aW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUy MCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4gPg0KPiA+ICA+IFN1YmplY3Q6IFtzcHJp bmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiA+DQo+ ID4gID4NCj4gPg0KPiA+ICA+IChXRyBDaGFpciBoYXQgT2ZmLCB0aGlzIGlzIG1lcmVseSBhIG5v dGUgZnJvbSBhIHNsaWdodGx5DQo+IGNvbmZ1c2VkIFdHDQo+ID4NCj4gPiAgPiBwYXJ0aWNpcGFu dC4pDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgdmFy aW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXMNCj4gPg0KPiA+ICA+IG5ldHdvcmtz IHByb2dyYW1taW5nIGFuZCBzZXJ2aWNlIHByb2dyYW1taW5nIGRyYWZ0LCBhbmQgSSBhbQ0KPiB0 cnlpbmcgdG8NCj4gPg0KPiA+ICA+IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUgY29tYmlu YXRpb24uDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gSG93IGRvZXMgYSBub2RlIHRoYXQgaXMg ZG9pbmcgc29tZSBmb3JtIG9mIGJ5cGFzcyAoc3VwcG9zZSwgZm9yDQo+ID4NCj4gPiAgPiBzaW1w bGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQgZm9y DQo+IGEgZmFpbGVkDQo+ID4NCj4gPiAgPiBub2RlIE4zKSBrbm93IHRoYXQgaXQgaXMgc2FmZSB0 byBkbyBzbz8NCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBJZiB0aGUgcGF0aCB3YXMganVzdCBm b3IgVEUsIHRoZW4gaXQgaXMgInNhZmUiIGlmIHRoZSBuZXcgcGF0aA0KPiBtZWV0cw0KPiA+DQo+ ID4gID4gdGhlIFRFIGNyaXRlcmlhLiAgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBpdCBpcyBldmVu IGNsb3NlLCBhcw0KPiBsb25nIGFzDQo+ID4NCj4gPiAgPiBpdCBpcyBub3QgdXNlZCBmb3IgdG9v IGxvbmcuDQo+ID4NCj4gPiAgPg0KPiA+DQo+ID4gID4gQnV0IHdoYXQgaWYgdGhlIG5vZGUgd2Vy ZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsDQo+ID4gcmVxdWlyZW1lbnRzPw0K PiA+DQo+ID4gID4gT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0cmFu c2Zvcm0gKHdpbmNlIHdlIGFyZQ0KPiA+DQo+ID4gID4gZGVsaWJlcmF0ZWx5IHZhZ3VlIGFib3V0 IHdoYXQgbm9kZXMgY2FuIGRvIHdoZW4gYXNrZWQgc3VpdGFibHkuKQ0KPiA+DQo+ID4gID4NCj4g Pg0KPiA+ICA+IElzIHRoZXJlIHNvbWUgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBpbiB0 aGUgcm91dGluZw0KPiA+DQo+ID4gID4gYWR2ZXJ0aXNlbWVudHMgdGhhdCBJIG1pc3NlZD8NCj4g Pg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBUaGFuayB5b3UsDQo+ID4NCj4gPiAgPiBZb3VycywNCj4g Pg0KPiA+ICA+IEpvZWwNCj4gPg0KPiA+ICA+DQo+ID4NCj4gPiAgPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gID4gc3ByaW5nIG1haWxp bmcgbGlzdA0KPiA+DQo+ID4gID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4+Pg0KPiA+DQo+ID4gID4NCj4gPg0KPiBodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyPGh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91 PWh0dHBzJTNBJTI+DQo+ID4NCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdx aFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MjxodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTI+Pg0K PiA+DQo+ID4gID4gRiUyRnd3dy5pZXRmLm9yZzxodHRwOi8vMkZ3d3cuaWV0Zi5vcmc+DQo+IDxo dHRwOi8vMkZ3d3cuaWV0Zi5vcmc8aHR0cDovLzJGd3d3LmlldGYub3JnPj4lMkZtYWlsbWFuJTJG bGlzdGluZm8lMkZzcHJpbmcNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4NCj4g PiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyUwYj4+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCj4gPg0KPiA+DQo+IGh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNB JTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IE5vdGljZTogVGhpcyBlLW1h aWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4NCj4gPiBpbmZvcm1h dGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbA0K PiBhbmQvb3INCj4gPiBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQuIEFueSByZXZpZXcsDQo+ID4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlz dHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQNCj4gPiBleHByZXNzIHBl cm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+IGlu dGVuZGVkDQo+ID4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIHRoZW4gZGVsZXRlIGFsbA0KPiA+IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cy4NCj4gPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0K PiA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nw cmluZzxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZz4NCj4gPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz cHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYu b3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmc8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxp c3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmc+DQo= --_000_VI1PR03MB5056A08F38488F43DD8298ACEE4A0VI1PR03MB5056eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLmdtYWlsLW0tODY3MDgwNjQzMTk5ODc4NDc2NWdtYWlsLW0tNzExNzU5 MjIxODcyNDM4MDMyMW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0tODY3MDgwNjQzMTk5ODc4 NDc2NWdtYWlsLW0tNzExNzU5MjIxODcyNDM4MDMyMW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFp bC1tLTg2NzA4MDY0MzE5OTg3ODQ3NjVnbWFpbC1tLTcxMTc1OTIyMTg3MjQzODAzMjFtc29saXN0 cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTg2NzA4MDY0MzE5OTg3ODQ3NjVn bWFpbC1tLTcxMTc1OTIyMTg3MjQzODAzMjFtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 ImVuLUtFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IYXZlIHRvIGNvbmZlc3MsDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5XZeKAmXZlIGhhZCBubyBuZWVkIHdoYXQgc28gZXZlciB0byBj b25zaWRlciB0aGF0IGluIG91ciB1c2UgY2FzZSBwbGFubmluZyDigJMgYW5kIGRvbuKAmXQgc2Vl IG9uZSBpbiB0aGUgbmVhciBmdXR1cmUuJm5ic3A7IE5vdCBzb21ldGhpbmcgd2XigJlyZSBjb25j ZXJuZWQgYWJvdXQg4oCTIHdoaWNoIGRvZXNu4oCZdCBkaW1pbmlzaCB0aGUgZmFjdA0KIHRoYXQg b3RoZXJzIG1heSBiZSBhbmQgdGhlcmUgbWF5IHdlbGwgYmUgYSBjYXNlIHRvIGJlIG1hZGUgaGVy ZSwganVzdCDigJMga2luZGEgb3V0IG9mIHNjb3BlIG9mIHdoYXQgd2XigJl2ZSBsb29rZWQgYXQg ZHVlIHRvIG91ciByYXRoZXIgdXJnZW50IG5lZWRzIHRvIGZpcnN0IG1lZXQgb3VyIGN1cnJlbnQg Y3JpdGljYWwgcmVxdWlyZW1lbnRzLiZuYnNwOyBUaGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyB3 aHkgSSBoYXZlIHNhaWQgdGhhdCBpcnJlc3BlY3RpdmUNCiBvZiB3aGF0IG9jY3VycyB3aXRoaW4g dGhlIElFVEYgYXMgcmVnYXJkcyBDUkgg4oCTIHdl4oCZcmUgZ29pbmcgYWhlYWQg4oCTIHRoZSBu ZWVkIGZvciBkZWVwIGxhYmVsIHN0YWNrIGFuZCB0aGUgbmVlZCBmb3IgcnVubmluZyBwcm9kdWN0 aW9uIHJlYWR5IGNvZGUgaXMgb2YgYW4gdXJnZW5jeSB0aGF0IG5vIGxvbmdlciBhbGxvd3MgdXMg dG8gd2FpdCBmb3IgbW9udGhzIOKAkyB0aGFua2Z1bGx5IHdlIGdldCB3aGF0IHdlIG5lZWQgYXMg YSByZXN1bHQgb2YgQ1JIDQogYW5kIGl0IGRvZXMgd29yayDigJMgYW5kIHdvcmsgd2VsbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9ImVuLUtFIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBHcmVnIE1pcnNreSAmbHQ7 Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIDQg QXVndXN0IDIwMjAgMDM6MTg8YnI+DQo8Yj5Ubzo8L2I+IEFuZHJldyBBbHN0b24gJmx0O0FuZHJl dy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb2VsIE0uIEhh bHBlcm4gJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDtyb2Jl cnRAcmFzenVrLm5ldCZndDs7IHNwcmluZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBBbmRyZXcsPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+dGhhbmsgeW91IGZvciB5b3VyIGV4cGVkaWVudCByZXNwb25zZS4gSSB1bmRl cnN0YW5kIHdoeSBvcGVyYXRvcnMgYXJlIHVzaW5nIFMtQkZEIHRvIG1vbml0b3IgdGhlIGNvbnRp bnVpdHkgb2YgcDJwIFNSLU1QTFMmbmJzcDt0dW5uZWwuIEJ1dCBJJ2Qgbm90ZSB0aGF0IFMtQkZE IGRvZXMgbm90IHN1cHBvcnQgbW9uaXRvcmluZyBvZiBtdWx0aWNhc3QgdHJlZXMsIG9uZXMgdGhh dA0KIG5vdyBjYW4gYmUgcmVhbGl6ZWQgdXNpbmcgdGhlIFJlcGxpY2F0aW9uIFNJRCBkZWZpbmVk IGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZveWVy LXNwcmluZy1zci1yZXBsaWNhdGlvbi1zZWdtZW50LTAyIj5kcmFmdC12b3llci1zcHJpbmctc3It cmVwbGljYXRpb24tc2VnbWVudDwvYT4uIEJ1dCB0aGF0IGNhbiBiZSBhY2hpZXZlZCB1c2luZw0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg1NjMiPg0KUkZDIDg1NjM8 L2E+LiBNdWx0aWNhc3QgYW5kIENvbXBvc2l0ZSBwb2xsaW5nIG1ldGhvZHMgbWlnaHQgbm90IHBy b3ZpZGUgdGhlIHJlcXVpcmVkIGRlZmVjdCBkZXRlY3Rpb24gYnkgdGhlIGhlYWQgb2YgdGhlIG11 bHRpY2FzdCB0cmVlLiBUaGVyZSdzIGEgZmFzdGVyIG9wdGlvbiBtZW50aW9uZWQgaW4gUkZDIDg1 NjMsIFVuc29saWNpdGVkIG5vdGlmaWNhdGlvbi4gQXBwbGljYWJpbGl0eSBvZiB0aGUgVW5zb2xp Y2l0ZWQgbW9kZSB0byBTUi1NUExTDQogaXMgZGVzY3JpYmVkIGluJm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LXNwcmluZy1iZmQvP2lu Y2x1ZGVfdGV4dD0xIj5kcmFmdC1taXJza3ktc3ByaW5nLWJmZDwvYT4uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5HcmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgNTowNSBQTSBBbmRyZXcgQWxzdG9uICZs dDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSI+QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5HcmVnIHdlIGVmZmVjdGl2 ZWx5IGdldCB0aGlzIHVzaW5nIHNiZmQgYW5kIGZhbGwgYmFjayBwYXRocyBhdCB0aGUgbW9tZW50 IOKAkyBmYXIgZnJvbSBpZGVhbCDigJMgYnV0IGl0IGRvZXMgd29yay48L3NwYW4+PHNwYW4gbGFu Zz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgYXJlIGFs c28gb3RoZXIgbWV0aG9kcyBvZiBkZXRlY3RpbmcgZW5kIHRvIGVuZCByZWFjaGFiaWxpdHkgdG8g ZG8gYmxhY2tob2xlIGRldGVjdGlvbiBldGMg4oCTIHBhcnRpY3VsYXJseSBpbiB0aGUgZmFjZSBv ZiB0aGUgZmFjdCB0aGF0IEnigJl2ZSB5ZXQgdG8gc2VlIGEgZnVuY3Rpb25hbCBpbXBsaWNhdGlv biBvZiB0aGUgc2lkIHZlcmlmaWNhdGlvbiBmbGFnLjwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVu LUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5Db3VsZCB0aGluZ3MgYmUgaW1wcm92 ZWQgdGhpcyByZWdhcmQ/IDEwMCUgYnV0IGZvciBub3cg4oCTIHRoZSBkZWVwIHNlYXRlZCBhbmQg Y3JpdGljYWwgbmVlZCBmb3IgdGhlIHJlcXVpcmVtZW50IG92ZXJyaWRlcyB0aGUgZHJhd2JhY2tz IG9mIHRoZSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgd2UgYXJlIGZvcmNlZCB0byB1c2UgYXQgdGhp cyBwb2ludDwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj5BbmRyZXc8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8c3BhbiBsYW5nPSJlbi1LRSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Ojcy LjBwdCI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0Ow0KPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIDQgQXVndXN0IDIwMjAgMDE6NDA8YnI+DQo8Yj5Ubzo8 L2I+IEFuZHJldyBBbHN0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0 QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7Ow0K PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0Bp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFNwcmluZyBwcm90 ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTwvc3Bhbj48c3BhbiBsYW5nPSJlbi1L RSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxhbmc9ImVuLUtFIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Ojcy LjBwdCI+DQo8c3BhbiBsYW5nPSJlbi1LRSI+SGkgQW5kcmV3LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxz cGFuIGxhbmc9ImVuLUtFIj53b3VsZCBzdWNoIHJlcXVpcmVtZW50cyBzdXBwb3J0IHVzaW5nIGUy ZSBwcm90ZWN0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iZW4tS0Ui PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iZW4tS0UiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJlbi1LRSI+R3JlZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxhbmc9ImVuLUtFIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iZW4tS0UiPk9uIE1vbiwgQXVnIDMsIDIwMjAgYXQg Mjo0NiBQTSBBbmRyZXcgQWxzdG9uICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj5TbyDigJMgPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPk9uZSBvZiB0aGUgdXNlIGNhc2VzLCBpbiBmYWN0LCBzb21l IHZlcnkgbWFqb3IgdXNlIGNhc2VzIGluIGFueSBzcHJpbmcgdGVjaG5vbG9neSBmb3IgdXMgcmV2 b2x2ZSBhcm91bmQgdGhlIGZvbGxvd2luZzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS04NjcwODA2NDMxOTk4Nzg0 NzY1Z21haWwtbS03MTE3NTkyMjE4NzI0MzgwMzIxbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEwOC4wcHQiPg0KPHNwYW4gbGFuZz0iZW4tS0UiPmEuPC9zcGFuPjxzcGFuIGxh bmc9ImVuLUtFIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2YgY2VydGFp biBub2Rlczwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9ImdtYWlsLW0tODY3MDgwNjQzMTk5ODc4NDc2NWdtYWlsLW0tNzExNzU5MjIxODcy NDM4MDMyMW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0Ij4NCjxz cGFuIGxhbmc9ImVuLUtFIj5iLjwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdv cms8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+QW55dGhpbmcgdGhhdCBjb3VsZCByZXN1bHQgaW4gdGhhdCBleHBsaWNpdCBhdm9pZGFu Y2UgYmVpbmcgdmlvbGF0ZWQg4oCTIHdvdWxkIGNyZWF0ZSwgc2hhbGwgd2Ugc2F5IHNpZ25pZmlj YW50IHByb2JsZW1zLjwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj5NdWNoIG9mIHRoZSB1c2UgY2FzZSBpcyBub3QgYSBjYXNlIG9mIHdo aWNoIG5vZGVzIHRoZSBwYWNrZXRzIGZsb3cgdGhyb3VnaCDigJMgYnV0IHJhdGhlciDigJMgd2hp Y2ggbm9kZXMgLyBuZXR3b3JrIHNlZ21lbnRzIGl0IGNhbiBuZXZlciB0b3VjaCBvciBmbG93IHRo cm91Z2guJm5ic3A7IEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9neSB0byBh dm9pZCBjZXJ0YWluIHRoaW5ncyBmb3Igc3BlY2lmaWMgcmVhc29ucy48L3NwYW4+PHNwYW4gbGFu Zz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBpcyBhbHNv IG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwgc3RhY2tzIOKA kyB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgcGF0aCBwcm9ncmFtbWluZyB0ZW5kcyB0byBkZWVwZW4g dGhlIHN0YWNrIGJlY2F1c2UgeW91IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBleHBsaWNp dC48L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+SXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1cyB0aGF0IHRoaXMgZnVuY3Rpb25h bGl0eSBpcyB0aGVyZSDigJMgYW5kIHRoYXQgd2UgY2FuIGF2b2lkIHNpdHVhdGlvbnMgd2hpY2gg Y291bGQgY2F1c2UgdHJhZmZpYyB0byBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhwbGljaXRseSBh dm9pZGVkLjwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIj5JIHdpc2ggSSBjb3VsZCBiZSBtb3JlIHNwZWNpZmljIHRoYW4gdGhpcywgYnV0 IGl0IGlzIHdoYXQgaXQgaXMuPC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtFIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iZW4tS0UiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rczwvc3Bhbj48c3BhbiBsYW5nPSJlbi1LRSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Ojcy LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9ImVuLUtF Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6NzIuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5BbmRyZXc8L3NwYW4+PHNwYW4gbGFuZz0i ZW4tS0UiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJlbi1LRSI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMDguMHB0Ij4NCjxiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBzcHJpbmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9lbCBNLiBIYWxw ZXJuPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgMyBBdWd1c3QgMjAyMCAyMTozNjxicj4NCjxi PlRvOjwvYj4gUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsu bmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkNj OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFNwcmlu ZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTwvc3Bhbj48c3BhbiBsYW5n PSJlbi1LRSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMDguMHB0Ij4NCjxzcGFuIGxhbmc9ImVuLUtFIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MTA4LjBwdCI+DQo8c3BhbiBsYW5nPSJlbi1LRSI+KFNpbmNlIHRoZSB0aHJlYWQgaGFz IGdvdHRlbiBsb25nIGVub3VnaCwgcmVpdGVyYXRpbmcgdGhhdCB0aGlzIGlzIGFzIGENCjxicj4N CnBhcnRpY2lwYW50LCBub3QgYSBXRyBjaGFpci4pPGJyPg0KPGJyPg0KWWVzLCB3ZSBhcmUgdGFs a2luZyBJUCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29ya3MgdGhhdCA8 YnI+DQpjaG9vc2UgdG8gZHJvcCBwYWNrZXRzLiBGb3IgYWxsIHNvcnRzIG9mIHJlYXNvbnMuPGJy Pg0KSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9uZSBtYXkgbm90 IHdhbnQgYSByYW5kb20gPGJyPg0KcGF0aCByYXRoZXIgdGhhbiBhIGNob3NlbiBURSBwYXRoLiBJ IHRoaW5rIGl0IGlzIGltcG9ydGFudCB3ZSBiZSBjbGVhciA8YnI+DQphYm91dCB3aGF0IGNvbnN0 cmFpbnRzIG1heSBiZSAvIGFyZSB2aW9sYXRlZCB3aGVuIHdlIHRlbGwgcGVvcGxlIHRoZXkgPGJy Pg0KaGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0aGF0IGlzIGludGVuZGVk IHRvIHByZXNlcnZlIFFvUy48YnI+DQo8YnI+DQpMZXQncyBiZSBjbGVhci4gSSBhbSBub3QgYXJn dWluZyB0aGF0IHRoaXMgaXMgbm90IGEgZ29vZCBpZGVhLiBJdCBpcyBhIDxicj4NCmdvb2QgaWRl YS4gQW5kIHVzZWZ1bC4gSSBhbSB0cnlpbmcgdG8gZmlndXJlIG90dSB3aGF0IGNvbWJpbmF0aW9u IG9mIDxicj4NCmFkZGl0aW9uYWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdp bGwgbGVhZCB0byBldmVyeW9uZSA8YnI+DQpnZXR0aW5nIHRoZSBiZWhhdmlvciB0aGV5IGV4cGVj dCAod2hpY2ggbWF5IG5vdCBiZSB0aGUgYmVoYXZpb3IgdGhleSA8YnI+DQpkZXNpcmUsIGJ1dCBz b21ldGltZXMgaXMgdGhlIGJlc3Qgd2UgY2FuIGRvLik8YnI+DQo8YnI+DQpZb3Vycyw8YnI+DQpK b2VsPGJyPg0KPGJyPg0KT24gOC8zLzIwMjAgMjozMCBQTSwgUm9iZXJ0IFJhc3p1ayB3cm90ZTo8 YnI+DQomZ3Q7IEpvZWwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFyZSB3ZSBzdGlsbCB0YWxraW5n IGFib3V0IElQIG5ldHdvcmtzJm5ic3A7aGVyZSA/IE9yIHBlcmhhcHMgc29tZSBoYXJkIDxicj4N CiZndDsgc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5ldHMg Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBCZWNhdXNlJm5ic3A7aWYgd2UgYXJlIHRhbGtpbmcmbmJz cDthYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d28gb2JzZXJ2YXRpb25zOjxicj4NCiZndDsg PGJyPg0KJmd0OyBBKSBJZiB5b3UgbmVlZCB0byB0cmF2ZXJzZSB2aWEgYSBzcGVjaWZpYyBub2Rl IChpZS4gZmlyZXdhbGwpIHlvdSBiZXR0ZXIgPGJyPg0KJmd0OyBhcHBseSBJUCBlbmNhcHN1bGF0 aW9uIHRvIHRoYXQgbm9kZS4gSSBkb24ndCB0aGluayBJUCBlbmNhcHN1bGF0aW9uJm5ic3A7Y2Fu IDxicj4NCiZndDsgYmUgaGlqYWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJl c3Mgb2YgdGhlIHBhY2tldCBpcyBpZ25vcmVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBCKSBIYXZl IHlvdSBzZWVuIGFueSBJUCBuZXR3b3JrIHdoZXJlIHVwb24gdG9wb2xvZ3kgY2hhbmdlIChsaW5r IG9yIG5vZGUgPGJyPg0KJmd0OyBmYWlsdXJlKSB5b3Ugc3VkZGVubHkmbmJzcDtzdGFydCBkcm9w cGluZyZuYnNwO2Zsb3dzIGluIHNwaXRlIG9mIFNQVCBvZmZlcmluZyA8YnI+DQomZ3Q7IHBlcmhh cHMgZmV3IG1zIGxvbmdlciBwYXRoIHdpdGggMTAgbXMgbW9yZSBqaXR0ZXIgPzxicj4NCiZndDsg PGJyPg0KJmd0OyBPciBhcmUgc29tZSBTUiBtYXJrZXRpbmcgc2xpZGVzIHByb21pc2UgdG8gdHVy biBJUCBuZXR3b3JrcyBpbiA8YnI+DQomZ3Q7IHNvbWV0aGluZyZuYnNwO25ldyA/IFdvcnNlIC4u LiBkbyB0aGV5IG1lbnRpb24gcGF0aCBxdWFsaXR5IGd1YXJhbnRlZXMsIDxicj4NCiZndDsgcmVz b3VyY2UgcmVzZXJ2YXRpb25zJm5ic3A7PyBJIGhvcGUgbm90Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaHgsPGJyPg0KJmd0OyBSLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgT24gTW9uLCBBdWcgMywgMjAyMCBhdCA4OjEwIFBNIEpvZWwgTS4gSGFs cGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMjAlMGIiIHRhcmdl dD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tDQo8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsg V2VsbCBsZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90IHN1cmUgdGhlIHByb2JsZW0g aXMgcmVzdHJpY3RlZDxicj4NCiZndDsgdG8ganVzdCBzZXJ2aWNlIFNJRHMuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFN1cHBvc2UgdGhhdCB0aGUgUENFIGhhcyBzcGVjaWZpZWQgdGhlIHBhdGggdG8g bWVldCBzb21lIGNvbXBsZXggdGU8YnI+DQomZ3Q7IG9iamVjdGl2ZS4mbmJzcDsgVGhlIGJ5cGFz cyBub2RlIGhhcyBubyB3YXkgb2Yga25vd2luZyB3aGF0IHRob3NlPGJyPg0KJmd0OyBjb25zdHJh aW50czxicj4NCiZndDsgd2VyZS4mbmJzcDsgQW5kIGZvciBzb21lIGtpbmRzIG9mIHRyYWZmaWMs IGl0IGlzIGJldHRlciB0byBkcm9wIHRoZSBwYWNrZXQ8YnI+DQomZ3Q7IHRoYW4gdG8gZGVsaXZl ciBpdCBvdXRzaWRlIHRoZSBlbnZlbG9wLiZuYnNwOyBJIHN1c3BlY3QgdGhhdCB0aGUgcmlnaHQ8 YnI+DQomZ3Q7IGFuc3dlcjxicj4NCiZndDsgdG8gdGhpcyBpcyAmcXVvdDt0b28gYmFkJnF1b3Q7 LiZuYnNwOyBJZiBzbywgYXMgd2l0aCB0aGUgZGlzdGluY3Rpb24gcmVnYXJkaW5nIHNlcnZpY2U8 YnI+DQomZ3Q7IG5vZGVzLCB3ZSBzaG91bGQgc2F5IHNvLCBzaG91bGRuJ3Qgd2U/PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFlvdXJzLDxicj4NCiZndDsgSm9lbDxicj4NCiZndDsgPGJyPg0KJmd0OyBP biA4LzMvMjAyMCAyOjM2IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZTo8YnI+DQomZ3Q7 ICZndDsgTWFjaCwgSm9lbCBhbmQgYWxsLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJ IHRoaW5rIHRoYXQgaW4gbW9zdCBjYXNlczo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg MS5UaGVyZSBpcyBjbGVhciBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiAmcXVvdDt0b3BvbG9naWNh bCZxdW90OyBhbmQgJnF1b3Q7c2VydmljZSZxdW90Ozxicj4NCiZndDsgJmd0OyBpbnN0cnVjdGlv bnMgaW4gU0lEIGFkdmVydGlzZW1lbnRzLiBFLmcuOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBvSUdQIFByZWZpeCBOb2RlIFNJRHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1 Y2ggaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7IGNvcnJlc3BvbmRpbmcgSUdQIGFkdmVydGlzZW1lbnRz KSByZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IG9TZXJ2aWNlIFNJRHMgZm9yIFNSdjYgKHNlZSBTUnY2IEJHUC1CYXNlZCBPdmVy bGF5IFNlcnZpY2VzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2 aWNlcy0wNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQ8L2E+Jmd0Ozxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0KSB1bnN1cnByaXNpbmdseSByZXByZXNlbnQg4oCcc2Vydmlj ZeKAnSBpbnN0cnVjdGlvbnM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgMi5TZWdtZW50 cyB0aGF0IHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5cGFzc2Vk LDxicj4NCiZndDsgJmd0OyB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2VudCBzZXJ2aWNlIGlu c3RydWN0aW9ucyByZXF1aXJlPGJyPg0KJmd0OyBhbHRlcm5hdGl2ZTxicj4NCiZndDsgJmd0OyBw cm90ZWN0aW9uIG1lY2hhbmlzbXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoaXMg dmlldyBzZWVtcyB0byBiZSBhbGlnbmVkIHdpdGggUkZDIDg0MDI8YnI+DQomZ3Q7ICZndDsgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDI8L2E+Jmd0OyB0aGF0IHNh eXMgaW4gU2VjdGlvbiAxOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRy b2wgcGxhbmUsIHR3bzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyB0b3BvbG9naWNhbCBz ZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIElHUC1BZGphY2VuY3kgc2VnbWVudCBhbmQgdGhlPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBJR1AtUHJlZml4 IHNlZ21lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNw OyBJbiB0aGUgY29udGV4dCBvZiBhIEJHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5l LCB0d288YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgdG9wb2xvZ2ljYWwgc2VnbWVudHMg YXJlIGRlZmluZWQ6IHRoZSBCR1AgcGVlcmluZyBzZWdtZW50IGFuZCB0aGU8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IEJHUC1QcmVmaXggc2VnbWVudC48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSW4gdGhlIGNhc2Ugb2YgU1ItTVBMUyB0aGlz IGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb248YnI+DQomZ3Q7IDMuNCBvZjxi cj4NCiZndDsgJmd0OyB0aGUgTm9kZSBQcm90ZWN0aW9uIGZvciBTUi1URSBQYXRoPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1w YXRocy0wNyNzZWN0aW9uLTMuNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3It c3ItdGUtcGF0aHMtMDcjc2VjdGlvbi0zLjQ8L2E+Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyAm Z3Q7IGRyYWZ0IHRoYXQgc2F5czo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IFRoZSBub2RlIHByb3RlY3Rpb24gbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0 aGUgcHJldmlvdXMgc2VjdGlvbnM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IGRlcGVuZHMgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgbGFiZWwgaW1t ZWRpYXRlbHkgYmVsb3c8YnI+DQomZ3Q7IHRoZSB0b3A8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElHUCBk b21haW4uJm5ic3A7IFdoZW4gdGhlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyZuYnNwOyBwcm92aWRlciBlZGdlIHJvdXRlcnMgZXhjaGFuZ2Ugc2VydmljZSBsYWJl bHMgdmlhIEJHUCBvciBzb21lPGJyPg0KJmd0OyBvdGhlcjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgbm9uLUlHUCBtZWNoYW5pc20gdGhlIGJvdHRvbSBs YWJlbCBpcyBub3QgdW5kZXJzdG9vZCBpbiB0aGUgSUdQPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBkb21haW4uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlvbiBtZWNo YW5pc21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQ8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7Jm5ic3A7IFtSRkM4Njc5ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg2NzkiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg2Nzk8L2E+Jmd0O10gaXM8YnI+DQom Z3Q7ICZndDsgYXBwbGljYWJsZSB0byB0aGlzIHVzZSBjYXNlIGFuZCBubyBhZGRpdGlvbmFsIGNo YW5nZXM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHdp bGwgYmUgcmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFRoZSBzY2VuYXJpb3MgaW4gd2hpY2ggJm5ic3A7ZGlmZmVyZW50aWF0aW9uIGJl dHdlZW4g4oCcdG9wb2xvZ2ljYWzigJ0gYW5kPGJyPg0KJmd0OyAmZ3Q7IOKAnHNlcnZpY2XigJ0g aW5zdHJ1Y3Rpb25zIGlzIGJyb2tlbiBhcmUgaW5kZWVkIHByb2JsZW1hdGljLiBFLmcuLDxicj4N CiZndDsgY29uc2lkZXI8YnI+DQomZ3Q7ICZndDsgdGhlIHVzZSBjYXNlIGluIHdoaWNoIGEgTm9k ZSBTSUQgaW4gdGhlIEVSTyBvZiBhIFNSLVRFIHBhdGg8YnI+DQomZ3Q7IGlkZW50aWZpZXMgYTxi cj4NCiZndDsgJmd0OyBub2RlIHRoYXQgYWN0cyBhcyBhIGZpcmV3YWxsIGZvciBhbGwgcGFja2V0 cyBpdCByZWNlaXZlcywgaS5lLiw8YnI+DQomZ3Q7IHByb3ZpZGVzPGJyPg0KJmd0OyAmZ3Q7IHRo ZSBmaXJld2FsbCBzZXJ2aWNlIHdpdGhvdXQgYW55IGRlZGljYXRlZCBzZXJ2aWNlIFNJRDxicj4N CiZndDsgaWRlbnRpZnlpbmcgaXQuPGJyPg0KJmd0OyAmZ3Q7IE9uZSBjb3VsZCBzYXkgdGhhdCB0 aGUgTm9kZSBTSUQgb2Ygc3VjaCBhIG5vZGUgd291bGQgY29tYmluZTxicj4NCiZndDsgdG9wb2xv Z2ljYWw8YnI+DQomZ3Q7ICZndDsgYW5kIHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHRodXMgYnJlYWtp bmcgdGhlIGRpZmZlcmVudGlhdGlvbjxicj4NCiZndDsgYmV0d2VlbiB0aGUgdHdvLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIGFtIG5vdCBzdXJlIGlmIHVzYWdlIG9mIHN1Y2gg4oCc Y29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2ZW50ZWQ8YnI+DQomZ3Q7IG9yIGF0PGJyPg0K Jmd0OyAmZ3Q7IGxlYXN0IGRpc2NvdXJhZ2VkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBJZiBub3QsIHByb3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50aWZ5IHN1Y2ggU0lEcyBpbiB0 aGU8YnI+DQomZ3Q7IGFkdmVydGlzZW1lbnQ8YnI+DQomZ3Q7ICZndDsgbWVjaGFuaXNtcyB3b3Vs ZCBiZSB1c2VmdWwgSU1ITy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTXkgMmMsPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNhc2hhPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IE9mZmljZTogKzk3Mi0zOTI2NjMwMjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBDZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArOTcyLTU0OTI2NjMwMjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb208L2E+PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTog c3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIiIHRh cmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzxicj4NCjwvYT4mZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgT24gQmVoYWxmIE9mIE1h Y2ggQ2hlbjxicj4NCiZndDsgJmd0OyBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDY6MzAg QU08YnI+DQomZ3Q7ICZndDsgVG86IEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20lMGIiIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4u Y29tPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDs7 DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBT dWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBs aWNhYmlsaXR5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpIEpvZWwsPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgcG9pbnQgdGhhdCBt YXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0aGU8YnI+DQomZ3Q7IHBhc3QuIEFuZDxicj4NCiZndDsg Jmd0OyBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAmcXVvdDtjYW4gYmUgYnlwYXNzZWQm cXVvdDsgaW5kaWNhdGlvbiBpbiB0aGU8YnI+DQomZ3Q7ICZndDsgcm91dGluZyBhZHZlcnRpc2Vt ZW50IGZvciBub3cuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElNSE8sIHRoZSBpbmZv cm1hdGlvbiBhZHZlcnRpc2VkIGJ5IHJvdXRpbmcgaXMgbmV1dHJhbCwgc3VjaDxicj4NCiZndDsg aW5mb3JtYXRpb248YnI+DQomZ3Q7ICZndDsgKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQpIGlz IG1vcmUgcGF0aCBzcGVjaWZpYywgdGh1cyBub3JtYWxseSB0aGU8YnI+DQomZ3Q7ICZndDsgY29u dHJvbGxlciBzaG91bGQgYmUgcmVzcG9uc2libGUgZm9yIGRlY2lkaW5nIHdoZXRoZXIvd2hpY2gg U0lEPGJyPg0KJmd0OyBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgYnlwYXNzZWQuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgTWFjaDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgRnJvbTogc3ByaW5nIFs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmclMGIlM2UlMjAlM2NtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclM2UiIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZsdDttYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9hPl0gT24gQmVoYWxmIE9mIEpvZWwgTS48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBIYWxwZXJuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMywg MjAyMCA3OjUxIEFNPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgVG86 IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnICZsdDttYWlsdG86c3ByaW5n QGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgU3ViamVjdDogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBh cHBsaWNhYmlsaXR5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAoV0cgQ2hhaXIgaGF0IE9mZiwg dGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20gYSBzbGlnaHRseTxicj4NCiZndDsgY29uZnVzZWQg V0c8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBwYXJ0aWNpcGFudC4p PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBJIGhhdmUgYmVlbiByZWFkaW5nIHRoZSB2YXJpb3Vz IHJlcGFpciBkcmFmdHMsIGFuZCB0aGUgdmFyaW91czxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7IG5ldHdvcmtzIHByb2dyYW1taW5nIGFuZCBzZXJ2aWNlIHByb2dyYW1t aW5nIGRyYWZ0LCBhbmQgSSBhbTxicj4NCiZndDsgdHJ5aW5nIHRvPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgZmlndXJlIG91dCBvbmUgYXNwZWN0IG9mIHRoZSBjb21i aW5hdGlvbi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEhvdyBkb2VzIGEgbm9kZSB0aGF0IGlz IGRvaW5nIHNvbWUgZm9ybSBvZiBieXBhc3MgKHN1cHBvc2UsIGZvcjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IHNpbXBsaWNpdHksIGl0IGlzIE5vZGUgTjIgZGVjaWRp bmcgdG8gYnlwYXNzIHRoZSBuZXh0IFNJRCBmb3I8YnI+DQomZ3Q7IGEgZmFpbGVkPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgbm9kZSBOMykga25vdyB0aGF0IGl0IGlz IHNhZmUgdG8gZG8gc28/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBJZiB0aGUgcGF0aCB3YXMg anVzdCBmb3IgVEUsIHRoZW4gaXQgaXMgJnF1b3Q7c2FmZSZxdW90OyBpZiB0aGUgbmV3IHBhdGg8 YnI+DQomZ3Q7IG1lZXRzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg dGhlIFRFIGNyaXRlcmlhLiZuYnNwOyBvciBtYXliZSBpdCBpcyBzYWZlIGlmIGl0IGlzIGV2ZW4g Y2xvc2UsIGFzPGJyPg0KJmd0OyBsb25nIGFzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgaXQgaXMgbm90IHVzZWQgZm9yIHRvbyBsb25nLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgQnV0IHdoYXQgaWYgdGhlIG5vZGUgd2VyZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0 byBtZWV0IGxlZ2FsPGJyPg0KJmd0OyAmZ3Q7IHJlcXVpcmVtZW50cz88YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBPciB3YXMgc29tZSBvdGhlciBuZWNlc3NhcnkgcHJv Z3JhbW1hdGljIHRyYW5zZm9ybSAod2luY2Ugd2UgYXJlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgZGVsaWJlcmF0ZWx5IHZhZ3VlIGFib3V0IHdoYXQgbm9kZXMgY2Fu IGRvIHdoZW4gYXNrZWQgc3VpdGFibHkuKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSXMgdGhl cmUgc29tZSAmcXVvdDtjYW4gYmUgYnlwYXNzZWQmcXVvdDsgaW5kaWNhdGlvbiBpbiB0aGUgcm91 dGluZzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGFkdmVydGlzZW1l bnRzIHRoYXQgSSBtaXNzZWQ/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBUaGFuayB5b3UsPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgWW91cnMsPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSm9lbDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3By aW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpzcHJpbmdAaWV0Zi5vcmcgJmx0O21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3Fo VTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9 aHR0cHMlM0ElMjwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1o dHRwcyUzQSUyNTIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTI8L2E+Jmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEYlPGEgaHJlZj0iaHR0cDovLzJG d3d3LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+MkZ3d3cuaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyAmbHQ7PGEgaHJlZj0iaHR0cDovLzJGd3d3LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovLzJGd3d3LmlldGYub3JnPC9hPiZndDslMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgc3ByaW5n IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8L2E+ Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzwvYT48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyBOb3RpY2U6IFRoaXMg ZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluPGJyPg0KJmd0 OyAmZ3Q7IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMg Y29uZmlkZW50aWFsPGJyPg0KJmd0OyBhbmQvb3I8YnI+DQomZ3Q7ICZndDsgcHJvcHJpZXRhcnkg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LDxi cj4NCiZndDsgJmd0OyBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3Ro ZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dDxicj4NCiZndDsgJmd0OyBleHByZXNzIHBlcm1pc3Np b24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlPGJyPg0KJmd0OyBp bnRlbmRlZDxicj4NCiZndDsgJmd0OyByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsPGJyPg0KJmd0OyAmZ3Q7IGNvcGllcywg aW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBzcHJpbmcgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNw cmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PGJyPg0KJmd0OyA8YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iZW4tS0UiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR03MB5056A08F38488F43DD8298ACEE4A0VI1PR03MB5056eurp_-- From nobody Mon Aug 3 21:13:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3C83A0772 for ; Mon, 3 Aug 2020 21:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, 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=pass (2048-bit key) header.d=hotmail.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 1juKDideWoQL for ; Mon, 3 Aug 2020 21:13:43 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255090.outbound.protection.outlook.com [40.92.255.90]) (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 BAD693A0763 for ; Mon, 3 Aug 2020 21:13:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NHv3oHu9LwvPIZ3Ws5nljX9RYweVdyV6aoP0HMk8IoG/wqd9MBcPGwa1tm3gtw+z7iuMhxj+80HBpB3HUiOJ6RLdcjVMkFf9DyB9DqrGesZfbV5HrX3RHhPhFMcu7XR7ctY4Xu0Xf8NvWlU82jjWqY5vVYuuQ7ZmFQ5BzUmXKfkrR3NVYToVJrRaINCHZUCgntM9ntAD2PktNu7P7LLf+0VmYhkqg97cB1jN/4shNnLno7/v0MVa6DRZiDTznVrcMUySFUvj+JO//JdR8h9ccu+ZzzKp8uI6u9Frz+koz/x7YnsFpQfpCgldCPQKv27/X2tB7G7YQZPX0+gzOn8jbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UpJmw5TmvVi1lz090REBu8on2i4FYt8q+DFobz+reXI=; b=dlk/sS2u7MzRxRnsNBlLjLVxuh1h8adeMU9DNnPayxpTkF7SlW2LkqA1U+tx7mR5HWcbNfRQOVT0xWqHZE9H0x63IahKnIk+vQhrU6euPoJBJQodgJUNiu0RmQhPCsd4OFXSDHz/UN1oIRYKbwuR1CZHRBgW3YFA906NK7AOeKdRRRBBcaX/YUeXATVW06bHGcYNWtFuyT/UGqdh0LZHjW7vFT6IFzB8se1wKNnNiKpQMVO+LKS2cxlliy/WhoNnqErPnnGEp3ksO2u8XLq0+mdqtWhzZYN41O2IwT7doSx6WOy35afcvfzQSu/DGG7SLgGUnJehYfQgbTlpr8NkmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UpJmw5TmvVi1lz090REBu8on2i4FYt8q+DFobz+reXI=; b=kFa74xN1+BgYQpyAsEZmwo/Jpm3esf6tRLeJx0EqPIZTcy69K1oRh5xSTKKmDSKu01uYb6tz33pme7yJJdZ84iPbYLt49sOnpikdHIfyEvY5ZCQls8XI1ZNGSYt3p8JBRq3mKFU7tErOHpKHqGYRayREpZ9It6nZ5IWJymrjJe0D/qWZB2qv7YX/UqfmdmjFSyk2zjZAjFIc4Zth1IIFUOr3CO8RhJCkBJ8HtsmNcTNdUw+2mlzDY7nJ2LfmwTsh0nGZIGZVgAh2YMsfgLQ4UkN5gpcvVWEf5n0Dttpp7PjXjth+Tabvd3fZ0Hsh7aeTTV28mbOiASaTJ1EM8RPlNA== Received: from PU1APC01FT115.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::45) by PU1APC01HT110.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::312) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Tue, 4 Aug 2020 04:13:34 +0000 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com (2a01:111:e400:7ebe::4e) by PU1APC01FT115.mail.protection.outlook.com (2a01:111:e400:7ebe::208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Tue, 4 Aug 2020 04:13:34 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:68AA529CDBC681AB35921BF988AC7C6B04326866AA045C00B4C206CC5B8256C8; UpperCasedChecksum:3ADA7FE855CD791125397E2213ECC3C116CAE27A68C539CE857B70548B0463AA; SizeAsReceived:9079; Count:50 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::4821:4bbe:ef2a:6dee]) by HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::4821:4bbe:ef2a:6dee%4]) with mapi id 15.20.3261.014; Tue, 4 Aug 2020 04:13:34 +0000 Date: Tue, 4 Aug 2020 12:14:09 +0800 From: "li_zhenqiang@hotmail.com" To: "Joel M. Halpern" , "Robert Raszuk" Cc: "spring@ietf.org" References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com>, , , , , <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart253104700535_=----" X-ClientProxiedBy: HK2PR02CA0196.apcprd02.prod.outlook.com (2603:1096:201:21::32) To HK0PR03MB4066.apcprd03.prod.outlook.com (2603:1096:203:9d::21) X-Microsoft-Original-Message-ID: <2020080412140795466530@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from cmcc-PC (183.243.248.23) by HK2PR02CA0196.apcprd02.prod.outlook.com (2603:1096:201:21::32) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3239.17 via Frontend Transport; Tue, 4 Aug 2020 04:13:33 +0000 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] X-Microsoft-Original-Message-ID: <2020080412140795466530@hotmail.com> X-TMN: [fhpIXxpD/yZdp1ZQ7P2Oe3YTsnau41gj] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 50 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 3b7e69f7-d9fb-4375-01c0-08d8382cc0c1 X-MS-TrafficTypeDiagnostic: PU1APC01HT110: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ycXhFQxwbk2D7sn4lTnDwBRQvGIdKIRqcC9tYWhZgUq7PXITAyql/i6mqs3KgO/BwUteyrNSaNHKa0IVR9YIypXhDjUM5zPY1jtUvhD0MEpyCSKqCiBeCPNVEI/zo6STWEwcqOXdZqSPUibAlVAyk6XiDJxyQeTYiA9gOVdgXJsjXRrjcgmYs4cZeEzFDNSCmBEL32bgRP5blk3LTSsVAfX2YCpQxYjgDJ82PYbfG/0S4FAq2HTqo0aK2XvGOlyh X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR03MB4066.apcprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; X-MS-Exchange-AntiSpam-MessageData: C6otJhRkIh79vdZZjfd3rFyKPF4pLl2MeQsB9Q4vTWxwVNkmQEsFLKFi9XLUZn0q9Y5t5CUyE76RJZGMRXljdILZwGXLYvko2bw9VJ72Dhrk6I0bvjcpq0LxYaDBvKRWp5WxSM2TTP4KQBeVcYOg/Q== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b7e69f7-d9fb-4375-01c0-08d8382cc0c1 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2020 04:13:34.6600 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT115.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT110 Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 04:13:46 -0000 ------=_001_NextPart253104700535_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgSm9lbCBhbmQgQWxsLA0KDQpJIHRoaW5rIFRFIHBhdGggc2hvdWxkIGJlIGNvdXBsZWQgd2l0 aCBlbmQgdG8gZW5kIHByb3RlY3Rpb24uIEl0IGlzIG5vdCBwcnVkZW50IHRvIGFsbG93IG5vZGUg b3IgbGluayBwcm90ZWN0aW9uIGluIGEgVEUgcGF0aCBzaW5jZSB0aGUgbG9jYWwgcHJvdGVjdGlv biBtYXkgbm90IHNhdGlzZnkgdGhlIFNMQSByZXF1aXJlbWVudHMgb3IgdGhlIHBhdGggY29uc3Ry YWlucy4gSW4gZmFjdCB0aGUgbm9kZSBlbi1yb3V0ZSBleGNlcHQgdGhlIGhlYWRlbmQgYW5kIHRo ZSBjb250cm9sbGVyIGhhcyBubyBpZGVhIGFib3V0IHRoZSBTTEEgcmVxdWlyZW1lbnRzIGFuZCB0 aGUgcGF0aCBjb25zdHJhaW5zLiBURSBwYXRoIG9ubHkgY2FuIGJlIHJlb3B0aW1pemVkIG9yIHJl YnVpbHQgZW5kIHRvIGVuZCBieSB0aGUgaGVhZGVuZCBvciB0aGUgY29udHJvbGxlciBpZiB5b3Ug d2FudCB5b3VyIFNMQSByZXF1aXJlbWVudHMgYW5kIHBhdGggY29udHJhaW5zIGJlIHNhdGlzZmll ZC4gDQoNCkluIG15IG9waW5pb24sIGl0IGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8gdXNlIGxvY2Fs IHByb3RlY3Rpb24gaW4gSVAgZm93YXJkaW5nIHNjZW5hcmlvcyByYXRoZXIgdGhhbiBURSBvciBw b2xpY3kgcGF0aHMuDQoNCkJlc3QgUmVnYXJkcywNClpoZW5xaWFuZyBMaQ0KDQoNCmxpX3poZW5x aWFuZ0Bob3RtYWlsLmNvbQ0KIA0KRnJvbTogSm9lbCBNLiBIYWxwZXJuDQpEYXRlOiAyMDIwLTA4 LTA0IDAyOjM1DQpUbzogUm9iZXJ0IFJhc3p1aw0KQ0M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJp bGl0eQ0KKFNpbmNlIHRoZSB0aHJlYWQgaGFzIGdvdHRlbiBsb25nIGVub3VnaCwgcmVpdGVyYXRp bmcgdGhhdCB0aGlzIGlzIGFzIGEgDQpwYXJ0aWNpcGFudCwgbm90IGEgV0cgY2hhaXIuKQ0KIA0K WWVzLCB3ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4gIEFuZCB5ZXMsIEkgaGF2ZSBzZWVuIElQ IG5ldHdvcmtzIHRoYXQgDQpjaG9vc2UgdG8gZHJvcCBwYWNrZXRzLiAgRm9yIGFsbCBzb3J0cyBv ZiByZWFzb25zLg0KSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9u ZSBtYXkgbm90IHdhbnQgYSByYW5kb20gDQpwYXRoIHJhdGhlciB0aGFuIGEgY2hvc2VuIFRFIHBh dGguICBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB3ZSBiZSBjbGVhciANCmFib3V0IHdoYXQgY29u c3RyYWludHMgbWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUgdGhleSAN CmhhdmUgdGhpcyB0b29sIChwcm90ZWN0aXZlIHJlcm91dGluZykgdGhhdCBpcyBpbnRlbmRlZCB0 byBwcmVzZXJ2ZSBRb1MuDQogDQpMZXQncyBiZSBjbGVhci4gIEkgYW0gbm90IGFyZ3VpbmcgdGhh dCB0aGlzIGlzIG5vdCBhIGdvb2QgaWRlYS4gIEl0IGlzIGEgDQpnb29kIGlkZWEuICBBbmQgdXNl ZnVsLiAgSSBhbSB0cnlpbmcgdG8gZmlndXJlIG90dSB3aGF0IGNvbWJpbmF0aW9uIG9mIA0KYWRk aXRpb25hbCBtZWNoYW5pc21zIGFuZCBjbGVhciBkZXNjcmlwdGlvbnMgd2lsbCBsZWFkIHRvIGV2 ZXJ5b25lIA0KZ2V0dGluZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3Qg YmUgdGhlIGJlaGF2aW9yIHRoZXkgDQpkZXNpcmUsIGJ1dCBzb21ldGltZXMgaXMgdGhlIGJlc3Qg d2UgY2FuIGRvLikNCiANCllvdXJzLA0KSm9lbA0KIA0KT24gOC8zLzIwMjAgMjozMCBQTSwgUm9i ZXJ0IFJhc3p1ayB3cm90ZToNCj4gSm9lbCwNCj4gDQo+IEFyZSB3ZSBzdGlsbCB0YWxraW5nIGFi b3V0IElQIG5ldHdvcmtzIGhlcmUgPyBPciBwZXJoYXBzIHNvbWUgaGFyZCANCj4gc2xpY2luZyB3 aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5ldHMgPw0KPiANCj4gQmVjYXVz ZSBpZiB3ZSBhcmUgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d28gb2JzZXJ2 YXRpb25zOg0KPiANCj4gQSkgSWYgeW91IG5lZWQgdG8gdHJhdmVyc2UgdmlhIGEgc3BlY2lmaWMg bm9kZSAoaWUuIGZpcmV3YWxsKSB5b3UgYmV0dGVyIA0KPiBhcHBseSBJUCBlbmNhcHN1bGF0aW9u IHRvIHRoYXQgbm9kZS4gSSBkb24ndCB0aGluayBJUCBlbmNhcHN1bGF0aW9uIGNhbiANCj4gYmUg aGlqYWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tl dCBpcyBpZ25vcmVkLg0KPiANCj4gQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3aGVy ZSB1cG9uIHRvcG9sb2d5IGNoYW5nZSAobGluayBvciBub2RlIA0KPiBmYWlsdXJlKSB5b3Ugc3Vk ZGVubHkgc3RhcnQgZHJvcHBpbmcgZmxvd3MgaW4gc3BpdGUgb2YgU1BUIG9mZmVyaW5nIA0KPiBw ZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRoIDEwIG1zIG1vcmUgaml0dGVyID8NCj4gDQo+ IE9yIGFyZSBzb21lIFNSIG1hcmtldGluZyBzbGlkZXMgcHJvbWlzZSB0byB0dXJuIElQIG5ldHdv cmtzIGluIA0KPiBzb21ldGhpbmcgbmV3ID8gV29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBwYXRo IHF1YWxpdHkgZ3VhcmFudGVlcywgDQo+IHJlc291cmNlIHJlc2VydmF0aW9ucyA/IEkgaG9wZSBu b3QuDQo+IA0KPiBUaHgsDQo+IFIuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgODoxMCBQTSBKb2VsIE0uIEhhbHBlcm4gPGptaEBq b2VsaGFscGVybi5jb20gDQo+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0K PiANCj4gICAgIFdlbGwgbGVzcyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRo ZSBwcm9ibGVtIGlzIHJlc3RyaWN0ZWQNCj4gICAgIHRvIGp1c3Qgc2VydmljZSBTSURzLg0KPiAN Cj4gICAgIFN1cHBvc2UgdGhhdCB0aGUgUENFIGhhcyBzcGVjaWZpZWQgdGhlIHBhdGggdG8gbWVl dCBzb21lIGNvbXBsZXggdGUNCj4gICAgIG9iamVjdGl2ZS4gIFRoZSBieXBhc3Mgbm9kZSBoYXMg bm8gd2F5IG9mIGtub3dpbmcgd2hhdCB0aG9zZQ0KPiAgICAgY29uc3RyYWludHMNCj4gICAgIHdl cmUuICBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywgaXQgaXMgYmV0dGVyIHRvIGRyb3Ag dGhlIHBhY2tldA0KPiAgICAgdGhhbiB0byBkZWxpdmVyIGl0IG91dHNpZGUgdGhlIGVudmVsb3Au ICBJIHN1c3BlY3QgdGhhdCB0aGUgcmlnaHQNCj4gICAgIGFuc3dlcg0KPiAgICAgdG8gdGhpcyBp cyAidG9vIGJhZCIuICBJZiBzbywgYXMgd2l0aCB0aGUgZGlzdGluY3Rpb24gcmVnYXJkaW5nIHNl cnZpY2UNCj4gICAgIG5vZGVzLCB3ZSBzaG91bGQgc2F5IHNvLCBzaG91bGRuJ3Qgd2U/DQo+IA0K PiAgICAgWW91cnMsDQo+ICAgICBKb2VsDQo+IA0KPiAgICAgT24gOC8zLzIwMjAgMjozNiBBTSwg QWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+ICAgICAgPiBNYWNoLCBKb2VsIGFuZCBhbGws DQo+ICAgICAgPg0KPiAgICAgID4gSSB0aGluayB0aGF0IGluIG1vc3QgY2FzZXM6DQo+ICAgICAg Pg0KPiAgICAgID4gMS5UaGVyZSBpcyBjbGVhciBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiAidG9w b2xvZ2ljYWwiIGFuZCAic2VydmljZSINCj4gICAgICA+IGluc3RydWN0aW9ucyBpbiBTSUQgYWR2 ZXJ0aXNlbWVudHMuIEUuZy46DQo+ICAgICAgPg0KPiAgICAgID4gb0lHUCBQcmVmaXggTm9kZSBT SURzIElHUCBBZGotU0lEcyAoaWRlbnRpZmllZCBhcyBzdWNoIGluIHRoZQ0KPiAgICAgID4gY29y cmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMpIHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0 cnVjdGlvbnMNCj4gICAgICA+DQo+ICAgICAgPiBvU2VydmljZSBTSURzIGZvciBTUnY2IChzZWUg U1J2NiBCR1AtQmFzZWQgT3ZlcmxheSBTZXJ2aWNlcw0KPiAgICAgID4NCj4gICAgIDxodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZp Y2VzLTA0Pg0KPiANCj4gICAgICA+IGRyYWZ0KSB1bnN1cnByaXNpbmdseSByZXByZXNlbnQg4oCc c2VydmljZeKAnSBpbnN0cnVjdGlvbnMNCj4gICAgICA+DQo+ICAgICAgPiAyLlNlZ21lbnRzIHRo YXQgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9ucyBjYW4gYmUgYnlwYXNzZWQsDQo+ ICAgICAgPiB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2VudCBzZXJ2aWNlIGluc3RydWN0aW9u cyByZXF1aXJlDQo+ICAgICBhbHRlcm5hdGl2ZQ0KPiAgICAgID4gcHJvdGVjdGlvbiBtZWNoYW5p c21zLg0KPiAgICAgID4NCj4gICAgICA+IFRoaXMgdmlldyBzZWVtcyB0byBiZSBhbGlnbmVkIHdp dGggUkZDIDg0MDINCj4gICAgICA+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQw Mj4gdGhhdCBzYXlzIGluIFNlY3Rpb24gMToNCj4gICAgICA+DQo+ICAgICAgPiAgICAgSW4gdGhl IGNvbnRleHQgb2YgYW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bw0K PiAgICAgID4NCj4gICAgICA+IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUg SUdQLUFkamFjZW5jeSBzZWdtZW50IGFuZCB0aGUNCj4gICAgICA+DQo+ICAgICAgPiAgICAgSUdQ LVByZWZpeCBzZWdtZW50Lg0KPiAgICAgID4NCj4gICAgICA+ICAgICBJbiB0aGUgY29udGV4dCBv ZiBhIEJHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28NCj4gICAgICA+DQo+ ICAgICAgPiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIEJHUCBwZWVyaW5n IHNlZ21lbnQgYW5kIHRoZQ0KPiAgICAgID4NCj4gICAgICA+ICAgICBCR1AtUHJlZml4IHNlZ21l bnQuDQo+ICAgICAgPg0KPiAgICAgID4gSW4gdGhlIGNhc2Ugb2YgU1ItTVBMUyB0aGlzIGRpZmZl cmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb24NCj4gICAgIDMuNCBvZg0KPiAgICAgID4g dGhlIE5vZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aA0KPiAgICAgID4NCj4gICAgIDxodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWhlZ2RlLXNwcmluZy1ub2Rl LXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3I3NlY3Rpb24tMy40Pg0KPiANCj4gICAgICA+ IGRyYWZ0IHRoYXQgc2F5czoNCj4gICAgICA+DQo+ICAgICAgPiAgICAgVGhlIG5vZGUgcHJvdGVj dGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0aW9ucw0KPiAgICAg ID4NCj4gICAgICA+ICAgICBkZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVs IGltbWVkaWF0ZWx5IGJlbG93DQo+ICAgICB0aGUgdG9wDQo+ICAgICAgPg0KPiAgICAgID4gbGFi ZWwgaW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElHUCBkb21haW4uICBX aGVuIHRoZQ0KPiAgICAgID4NCj4gICAgICA+ICAgICBwcm92aWRlciBlZGdlIHJvdXRlcnMgZXhj aGFuZ2Ugc2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBzb21lDQo+ICAgICBvdGhlcg0KPiAgICAg ID4NCj4gICAgICA+ICAgICBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90dG9tIGxhYmVsIGlzIG5v dCB1bmRlcnN0b29kIGluIHRoZSBJR1ANCj4gICAgICA+DQo+ICAgICAgPiAgICAgZG9tYWluLg0K PiAgICAgID4NCj4gICAgICA+ICAgICBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5p c21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQNCj4gICAgICA+DQo+ICAgICAgPiAgICAgW1JGQzg2 NzkgPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODY3OT5dIGlzDQo+ ICAgICAgPiBhcHBsaWNhYmxlIHRvIHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hh bmdlcw0KPiAgICAgID4NCj4gICAgICA+ICAgICB3aWxsIGJlIHJlcXVpcmVkIGZvciBTUiBiYXNl ZCBuZXR3b3Jrcw0KPiAgICAgID4NCj4gICAgICA+IFRoZSBzY2VuYXJpb3MgaW4gd2hpY2ggIGRp ZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs4oCdIGFuZA0KPiAgICAgID4g4oCc c2VydmljZeKAnSBpbnN0cnVjdGlvbnMgaXMgYnJva2VuIGFyZSBpbmRlZWQgcHJvYmxlbWF0aWMu IEUuZy4sDQo+ICAgICBjb25zaWRlcg0KPiAgICAgID4gdGhlIHVzZSBjYXNlIGluIHdoaWNoIGEg Tm9kZSBTSUQgaW4gdGhlIEVSTyBvZiBhIFNSLVRFIHBhdGgNCj4gICAgIGlkZW50aWZpZXMgYQ0K PiAgICAgID4gbm9kZSB0aGF0IGFjdHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMgaXQg cmVjZWl2ZXMsIGkuZS4sDQo+ICAgICBwcm92aWRlcw0KPiAgICAgID4gdGhlIGZpcmV3YWxsIHNl cnZpY2Ugd2l0aG91dCBhbnkgZGVkaWNhdGVkIHNlcnZpY2UgU0lEDQo+ICAgICBpZGVudGlmeWlu ZyBpdC4NCj4gICAgICA+IE9uZSBjb3VsZCBzYXkgdGhhdCB0aGUgTm9kZSBTSUQgb2Ygc3VjaCBh IG5vZGUgd291bGQgY29tYmluZQ0KPiAgICAgdG9wb2xvZ2ljYWwNCj4gICAgICA+IGFuZCBzZXJ2 aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRpb24NCj4gICAg IGJldHdlZW4gdGhlIHR3by4NCj4gICAgICA+DQo+ICAgICAgPiBJIGFtIG5vdCBzdXJlIGlmIHVz YWdlIG9mIHN1Y2gg4oCcY29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2ZW50ZWQNCj4gICAg IG9yIGF0DQo+ICAgICAgPiBsZWFzdCBkaXNjb3VyYWdlZC4NCj4gICAgICA+DQo+ICAgICAgPiBJ ZiBub3QsIHByb3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50aWZ5IHN1Y2ggU0lEcyBpbiB0aGUN Cj4gICAgIGFkdmVydGlzZW1lbnQNCj4gICAgICA+IG1lY2hhbmlzbXMgd291bGQgYmUgdXNlZnVs IElNSE8uDQo+ICAgICAgPg0KPiAgICAgID4gTXkgMmMsDQo+ICAgICAgPg0KPiAgICAgID4gU2Fz aGENCj4gICAgICA+DQo+ICAgICAgPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gICAgICA+DQo+ ICAgICAgPiBDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyDQo+ICAgICAgPg0KPiAgICAgID4gRW1h aWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ICAgICA8bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPiAgICAgID4NCj4gICAgICA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICAgPiBGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2Vz QGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVo YWxmIE9mIE1hY2ggQ2hlbg0KPiAgICAgID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2 OjMwIEFNDQo+ICAgICAgPiBUbzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29t DQo+ICAgICA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pjsgc3ByaW5nQGlldGYub3JnIDxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgID4gU3ViamVjdDogUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiAgICAgID4NCj4g ICAgICA+IEhpIEpvZWwsDQo+ICAgICAgPg0KPiAgICAgID4gSSB0aGluayB0aGlzIGlzIGEgZ29v ZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZQ0KPiAgICAgcGFzdC4gQW5k DQo+ICAgICAgPiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAiY2FuIGJlIGJ5cGFzc2Vk IiBpbmRpY2F0aW9uIGluIHRoZQ0KPiAgICAgID4gcm91dGluZyBhZHZlcnRpc2VtZW50IGZvciBu b3cuDQo+ICAgICAgPg0KPiAgICAgID4gSU1ITywgdGhlIGluZm9ybWF0aW9uIGFkdmVydGlzZWQg Ynkgcm91dGluZyBpcyBuZXV0cmFsLCBzdWNoDQo+ICAgICBpbmZvcm1hdGlvbg0KPiAgICAgID4g KGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQpIGlzIG1vcmUgcGF0aCBzcGVjaWZpYywgdGh1cyBu b3JtYWxseSB0aGUNCj4gICAgICA+IGNvbnRyb2xsZXIgc2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZv ciBkZWNpZGluZyB3aGV0aGVyL3doaWNoIFNJRA0KPiAgICAgY2FuIGJlDQo+ICAgICAgPiBieXBh c3NlZC4NCj4gICAgICA+DQo+ICAgICAgPiBCZXN0IHJlZ2FyZHMsDQo+ICAgICAgPg0KPiAgICAg ID4gTWFjaA0KPiAgICAgID4NCj4gICAgICA+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ICAgICAgPg0KPiAgICAgID4gID4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgSm9lbCBNLg0KPiAgICAgID4NCj4gICAgICA+ICA+IEhhbHBlcm4NCj4gICAgICA+ DQo+ICAgICAgPiAgPiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDc6NTEgQU0NCj4gICAg ICA+DQo+ICAgICAgPiAgPiBUbzogc3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYu b3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+Pg0KPiAgICAgID4NCj4gICAgICA+ICA+IFN1YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90 ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiAgICAgID4NCj4gICAgICA+ICA+ DQo+ICAgICAgPg0KPiAgICAgID4gID4gKFdHIENoYWlyIGhhdCBPZmYsIHRoaXMgaXMgbWVyZWx5 IGEgbm90ZSBmcm9tIGEgc2xpZ2h0bHkNCj4gICAgIGNvbmZ1c2VkIFdHDQo+ICAgICAgPg0KPiAg ICAgID4gID4gcGFydGljaXBhbnQuKQ0KPiAgICAgID4NCj4gICAgICA+ICA+DQo+ICAgICAgPg0K PiAgICAgID4gID4gSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRz LCBhbmQgdGhlIHZhcmlvdXMNCj4gICAgICA+DQo+ICAgICAgPiAgPiBuZXR3b3JrcyBwcm9ncmFt bWluZyBhbmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW0NCj4gICAgIHRyeWlu ZyB0bw0KPiAgICAgID4NCj4gICAgICA+ICA+IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUg Y29tYmluYXRpb24uDQo+ICAgICAgPg0KPiAgICAgID4gID4NCj4gICAgICA+DQo+ICAgICAgPiAg PiBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2YgYnlwYXNzIChzdXBw b3NlLCBmb3INCj4gICAgICA+DQo+ICAgICAgPiAgPiBzaW1wbGljaXR5LCBpdCBpcyBOb2RlIE4y IGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQgZm9yDQo+ICAgICBhIGZhaWxlZA0KPiAg ICAgID4NCj4gICAgICA+ICA+IG5vZGUgTjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRvIHNv Pw0KPiAgICAgID4NCj4gICAgICA+ICA+DQo+ICAgICAgPg0KPiAgICAgID4gID4gSWYgdGhlIHBh dGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0IGlzICJzYWZlIiBpZiB0aGUgbmV3IHBhdGgNCj4g ICAgIG1lZXRzDQo+ICAgICAgPg0KPiAgICAgID4gID4gdGhlIFRFIGNyaXRlcmlhLiAgb3IgbWF5 YmUgaXQgaXMgc2FmZSBpZiBpdCBpcyBldmVuIGNsb3NlLCBhcw0KPiAgICAgbG9uZyBhcw0KPiAg ICAgID4NCj4gICAgICA+ICA+IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy4NCj4gICAgICA+ DQo+ICAgICAgPiAgPg0KPiAgICAgID4NCj4gICAgICA+ICA+IEJ1dCB3aGF0IGlmIHRoZSBub2Rl IHdlcmUgYSBGaXJld2FsbCwgaW5jbHVkZWQgdG8gbWVldCBsZWdhbA0KPiAgICAgID4gcmVxdWly ZW1lbnRzPw0KPiAgICAgID4NCj4gICAgICA+ICA+IE9yIHdhcyBzb21lIG90aGVyIG5lY2Vzc2Fy eSBwcm9ncmFtbWF0aWMgdHJhbnNmb3JtICh3aW5jZSB3ZSBhcmUNCj4gICAgICA+DQo+ICAgICAg PiAgPiBkZWxpYmVyYXRlbHkgdmFndWUgYWJvdXQgd2hhdCBub2RlcyBjYW4gZG8gd2hlbiBhc2tl ZCBzdWl0YWJseS4pDQo+ICAgICAgPg0KPiAgICAgID4gID4NCj4gICAgICA+DQo+ICAgICAgPiAg PiBJcyB0aGVyZSBzb21lICJjYW4gYmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlIHJvdXRp bmcNCj4gICAgICA+DQo+ICAgICAgPiAgPiBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPw0K PiAgICAgID4NCj4gICAgICA+ICA+DQo+ICAgICAgPg0KPiAgICAgID4gID4gVGhhbmsgeW91LA0K PiAgICAgID4NCj4gICAgICA+ICA+IFlvdXJzLA0KPiAgICAgID4NCj4gICAgICA+ICA+IEpvZWwN Cj4gICAgICA+DQo+ICAgICAgPiAgPg0KPiAgICAgID4NCj4gICAgICA+ICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPg0KPiAgICAgID4g ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgID4NCj4gICAgICA+ICA+IHNwcmluZ0BpZXRm Lm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIDxtYWlsdG86c3ByaW5nQGlldGYu b3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCj4gICAgICA+DQo+ICAgICAgPiAgPg0KPiAg ICAgID4NCj4gICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pX OXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTINCj4gICAgICA+DQo+ICAgICA8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0El MjUyPg0KPiAgICAgID4NCj4gICAgICA+ICA+IEYlMkZ3d3cuaWV0Zi5vcmcNCj4gICAgIDxodHRw Oi8vMkZ3d3cuaWV0Zi5vcmc+JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+ICAgICAg Pg0KPiAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gICAgICA+DQo+ICAgICAgPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPg0KPiAg ICAgID4gc3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZw0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KPiAgICAgID4N Cj4gICAgICA+DQo+ICAgICBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtp VWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnNwcmluZw0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAg ID4NCj4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgID4gTm90aWNlOiBUaGlzIGUtbWFpbCB0 b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0KPiAgICAgID4gaW5mb3Jt YXRpb24gb2YgUmliYm9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwN Cj4gICAgIGFuZC9vcg0KPiAgICAgID4gcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LA0KPiAgICAgID4gZGlzY2xvc3VyZSwg cmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQN Cj4gICAgICA+IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5 b3UgYXJlIG5vdCB0aGUNCj4gICAgIGludGVuZGVkDQo+ICAgICAgPiByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsDQo+ICAg ICAgPiBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuDQo+ICAgICAgPg0KPiAgICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ICAgICAgPg0KPiAgICAgID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+IHNwcmluZyBtYWlsaW5nIGxpc3QN Cj4gICAgICA+IHNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAg ICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ICAgICAg Pg0KPiANCj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ICAgICBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICBzcHJpbmdAaWV0Zi5vcmcgPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZw0KPiANCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo= ------=_001_NextPart253104700535_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom:= 0px; margin-left: 0.5em; }body { font-size: 10.5pt; font-family: =E5=BE=AE= =E8=BD=AF=E9=9B=85=E9=BB=91; color: rgb(0, 0, 0); line-height: 1.5; }=0A=
Hi Joel and All,

I think TE path= should be coupled with end to end protection. It is not prudent to allow n= ode or link protection in a TE path since the local protection may not sati= sfy the SLA requirements or the path constrains. In fact the node en-route = except the headend and the controller has no idea about the SLA requirement= s and the path constrains. TE path only can be reoptimized or rebuilt end t= o end by the headend or the controller if you want your SLA requirements an= d path contrains be satisfied. 

In my opinion= , it is more appropriate to use local protection in IP fowarding scenarios = rather than TE or policy paths.
=0A=

Best Regards,
Zhenqiang Li
=0A=
li_zhenqiang@hotmail.com
=0A=
 
Date:&nbs= p;2020-08-04 02:35
Subject: Re: [spr= ing] Spring protection - determining applicability
(Since the thread has gotten long enough, reiterating that this is as a =
=0A=
participant, not a WG chair.)
=0A=
 
=0A=
Yes, we are talking IP networks.  And yes, I have seen IP network= s that
=0A=
choose to drop packets.  For all sorts of reasons.
=0A=
I think there are likely other reasons why one may not want a random <= /div>=0A=
path rather than a chosen TE path.  I think it is important we be= clear
=0A=
about what constraints may be / are violated when we tell people they =
=0A=
have this tool (protective rerouting) that is intended to preserve QoS= .
=0A=
 
=0A=
Let's be clear.  I am not arguing that this is not a good idea.&n= bsp; It is a
=0A=
good idea.  And useful.  I am trying to figure otu what comb= ination of
=0A=
additional mechanisms and clear descriptions will lead to everyone =0A=
getting the behavior they expect (which may not be the behavior they <= /div>=0A=
desire, but sometimes is the best we can do.)
=0A=
 
=0A=
Yours,
=0A=
Joel
=0A=
 
=0A=
On 8/3/2020 2:30 PM, Robert Raszuk wrote:
=0A=
> Joel,
=0A=
>
=0A=
> Are we still talking about IP networks here ? Or perhaps som= e hard
=0A=
> slicing with real resource reservations or detnets ?
=0A=
>
=0A=
> Because if we are talking about IP networking I have tw= o observations:
=0A=
>
=0A=
> A) If you need to traverse via a specific node (ie. firewall) you= better
=0A=
> apply IP encapsulation to that node. I don't think IP encapsulati= on can
=0A=
> be hijacked today such that destination address of the packet is = ignored.
=0A=
>
=0A=
> B) Have you seen any IP network where upon topology change (link = or node
=0A=
> failure) you suddenly start dropping flows in spite of = SPT offering
=0A=
> perhaps few ms longer path with 10 ms more jitter ?
=0A=
>
=0A=
> Or are some SR marketing slides promise to turn IP networks in =0A=
> something new ? Worse ... do they mention path quality guara= ntees,
=0A=
> resource reservations ? I hope not.
=0A=
>
=0A=
> Thx,
=0A=
> R.
=0A=
>
=0A=
>
=0A=
>
=0A=
>
=0A=
>
=0A=
>
=0A=
>
=0A=
>
=0A=
>
=0A=
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalper= n.com
=0A=
> <mailto:jmh@joelhalpern.com>> wrote:
=0A=
>
=0A=
>     Well less serious for TE SIDs, I am not s= ure the problem is restricted
=0A=
>     to just service SIDs.
=0A=
>
=0A=
>     Suppose that the PCE has specified the pa= th to meet some complex te
=0A=
>     objective.  The bypass node has no w= ay of knowing what those
=0A=
>     constraints
=0A=
>     were.  And for some kinds of traffic= , it is better to drop the packet
=0A=
>     than to deliver it outside the envelop.&n= bsp; I suspect that the right
=0A=
>     answer
=0A=
>     to this is "too bad".  If = so, as with the distinction regarding service
=0A=
>     nodes, we should say so, shouldn't we?=0A=
>
=0A=
>     Yours,
=0A=
>     Joel
=0A=
>
=0A=
>     On 8/3/2020 2:36 AM, Alexander Vainshtein= wrote:
=0A=
>      > Mach, Joel and all,
=0A=
>      >
=0A=
>      > I think that in most cases:=0A=
>      >
=0A=
>      > 1.There is clear differentiati= on between "topological" and "service"
=0A=
>      > instructions in SID advertisem= ents. E.g.:
=0A=
>      >
=0A=
>      > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
=0A=
>      > corresponding IGP advertisemen= ts) represent topological instructions
=0A=
>      >
=0A=
>      > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
=0A=
>      >
=0A=
>     <https://datatracker.ietf.org/doc/html= /draft-ietf-bess-srv6-services-04>
=0A=
>
=0A=
>      > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions
=0A=
>      >
=0A=
>      > 2.Segments that represent topo= logical instructions can be bypassed,
=0A=
>      > while segments that represent = service instructions require
=0A=
>     alternative
=0A=
>      > protection mechanisms.
= =0A=
>      >
=0A=
>      > This view seems to be aligned = with RFC 8402
=0A=
>      > <https://tools.ietf.org/htm= l/rfc8402> that says in Section 1:
=0A=
>      >
=0A=
>      >     In the cont= ext of an IGP-based distributed control plane, two
=0A=
>      >
=0A=
>      > topological segments are defin= ed: the IGP-Adjacency segment and the
=0A=
>      >
=0A=
>      >     IGP-Prefix = segment.
=0A=
>      >
=0A=
>      >     In the cont= ext of a BGP-based distributed control plane, two
=0A=
>      >
=0A=
>      > topological segments are defin= ed: the BGP peering segment and the
=0A=
>      >
=0A=
>      >     BGP-Prefix = segment.
=0A=
>      >
=0A=
>      > In the case of SR-MPLS this di= fferentiation is assumed in Section
=0A=
>     3.4 of
=0A=
>      > the Node Protection for SR-TE = Path
=0A=
>      >
=0A=
>     <https://datatracker.ietf.org/doc/html= /draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.4>=0A=
>
=0A=
>      > draft that says:
=0A=
>      >
=0A=
>      >     The node pr= otection mechanism described in the previous sections
=0A=
>      >
=0A=
>      >     depends on = the assumption that the label immediately below
=0A=
>     the top
=0A=
>      >
=0A=
>      > label in the label stack is un= derstood in the IGP domain.  When the
=0A=
>      >
=0A=
>      >     provider ed= ge routers exchange service labels via BGP or some
=0A=
>     other
=0A=
>      >
=0A=
>      >     non-IGP mec= hanism the bottom label is not understood in the IGP
=0A=
>      >
=0A=
>      >     domain.=0A=
>      >
=0A=
>      >     The egress = node protection mechanisms described in the draft
=0A=
>      >
=0A=
>      >     [RFC8679 &l= t;https://datatracker.ietf.org/doc/html/rfc8679>] is
=0A=
>      > applicable to this use case an= d no additional changes
=0A=
>      >
=0A=
>      >     will be req= uired for SR based networks
=0A=
>      >
=0A=
>      > The scenarios in which  d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and
=0A=
>      > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,
=0A=
>     consider
=0A=
>      > the use case in which a Node S= ID in the ERO of a SR-TE path
=0A=
>     identifies a
=0A=
>      > node that acts as a firewall f= or all packets it receives, i.e.,
=0A=
>     provides
=0A=
>      > the firewall service without a= ny dedicated service SID
=0A=
>     identifying it.
=0A=
>      > One could say that the Node SI= D of such a node would combine
=0A=
>     topological
=0A=
>      > and service instructions thus = breaking the differentiation
=0A=
>     between the two.
=0A=
>      >
=0A=
>      > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
=0A=
>     or at
=0A=
>      > least discouraged.
=0A=
>      >
=0A=
>      > If not, providing an ability t= o identify such SIDs in the
=0A=
>     advertisement
=0A=
>      > mechanisms would be useful IMH= O.
=0A=
>      >
=0A=
>      > My 2c,
=0A=
>      >
=0A=
>      > Sasha
=0A=
>      >
=0A=
>      > Office: +972-39266302
=0A=
>      >
=0A=
>      > Cell:    &= nbsp; +972-549266302
=0A=
>      >
=0A=
>      > Email: Alexander.Vainshtein@ec= itele.com
=0A=
>     <mailto:Alexander.Vainshtein@ecitele.c= om>
=0A=
>      >
=0A=
>      > -----Original Message-----=0A=
>      > From: spring <spring-bounce= s@ietf.org
=0A=
>     <mailto:spring-bounces@ietf.org>>= ; On Behalf Of Mach Chen
=0A=
>      > Sent: Monday, August 3, 2020 6= :30 AM
=0A=
>      > To: Joel M. Halpern <jmh@jo= elhalpern.com
=0A=
>     <mailto:jmh@joelhalpern.com>>; s= pring@ietf.org <mailto:spring@ietf.org>
=0A=
>      > Subject: Re: [spring] Spring p= rotection - determining applicability
=0A=
>      >
=0A=
>      > Hi Joel,
=0A=
>      >
=0A=
>      > I think this is a good point t= hat may not be discussed in the
=0A=
>     past. And
=0A=
>      > I also don't think there is a = "can be bypassed" indication in the
=0A=
>      > routing advertisement for now.=
=0A=
>      >
=0A=
>      > IMHO, the information advertis= ed by routing is neutral, such
=0A=
>     information
=0A=
>      > (can or cannot be bypassed) is= more path specific, thus normally the
=0A=
>      > controller should be responsib= le for deciding whether/which SID
=0A=
>     can be
=0A=
>      > bypassed.
=0A=
>      >
=0A=
>      > Best regards,
=0A=
>      >
=0A=
>      > Mach
=0A=
>      >
=0A=
>      >  > -----Original Messa= ge-----
=0A=
>      >
=0A=
>      >  > From: spring [mailt= o:spring-bounces@ietf.org
=0A=
>     <mailto:spring-bounces@ietf.org>] O= n Behalf Of Joel M.
=0A=
>      >
=0A=
>      >  > Halpern
=0A=
>      >
=0A=
>      >  > Sent: Monday, Augus= t 3, 2020 7:51 AM
=0A=
>      >
=0A=
>      >  > To: spring@ietf.org= <mailto:spring@ietf.org>
=0A=
>     <mailto:spring@ietf.org <mailto:spr= ing@ietf.org>>
=0A=
>      >
=0A=
>      >  > Subject: [spring] S= pring protection - determining applicability
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > (WG Chair hat Off, = this is merely a note from a slightly
=0A=
>     confused WG
=0A=
>      >
=0A=
>      >  > participant.)
= =0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > I have been reading= the various repair drafts, and the various
=0A=
>      >
=0A=
>      >  > networks programmin= g and service programming draft, and I am
=0A=
>     trying to
=0A=
>      >
=0A=
>      >  > figure out one aspe= ct of the combination.
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > How does a node tha= t is doing some form of bypass (suppose, for
=0A=
>      >
=0A=
>      >  > simplicity, it is N= ode N2 deciding to bypass the next SID for
=0A=
>     a failed
=0A=
>      >
=0A=
>      >  > node N3) know that = it is safe to do so?
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > If the path was jus= t for TE, then it is "safe" if the new path
=0A=
>     meets
=0A=
>      >
=0A=
>      >  > the TE criteria.&nb= sp; or maybe it is safe if it is even close, as
=0A=
>     long as
=0A=
>      >
=0A=
>      >  > it is not used for = too long.
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > But what if the nod= e were a Firewall, included to meet legal
=0A=
>      > requirements?
=0A=
>      >
=0A=
>      >  > Or was some other n= ecessary programmatic transform (wince we are
=0A=
>      >
=0A=
>      >  > deliberately vague = about what nodes can do when asked suitably.)
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > Is there some "= ;can be bypassed" indication in the routing
=0A=
>      >
=0A=
>      >  > advertisements that= I missed?
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > Thank you,
=0A=
>      >
=0A=
>      >  > Yours,
=0A=
>      >
=0A=
>      >  > Joel
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>      >  > ___________________= ____________________________
=0A=
>      >
=0A=
>      >  > spring mailing list=
=0A=
>      >
=0A=
>      >  > spring@ietf.org <= ;mailto:spring@ietf.org>
=0A=
>     <mailto:spring@ietf.org <mailto:spr= ing@ietf.org>>
=0A=
>      >
=0A=
>      >  >
=0A=
>      >
=0A=
>     https://clicktime.symantec.com/367qhU4KiU= kzW9uGC4eAvP46H2?u=3Dhttps%3A%2
=0A=
>      >
=0A=
>     <https://clicktime.symantec.com/367qhU= 4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252>
=0A=
>      >
=0A=
>      >  > F%2Fwww.ietf.org=0A=
>     <http://2Fwww.ietf.org>%2Fmailman%2= Flistinfo%2Fspring
=0A=
>      >
=0A=
>      > ______________________________= _________________
=0A=
>      >
=0A=
>      > spring mailing list
=0A=
>      >
=0A=
>      > spring@ietf.org <mailto:spr= ing@ietf.org> <mailto:spring@ietf.org
=0A=
>     <mailto:spring@ietf.org>>
= =0A=
>      >
=0A=
>      >
=0A=
>     https://clicktime.symantec.com/367qhU4KiU= kzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspri= ng
=0A=
>      >
=0A=
>      >
=0A=
>      >
=0A=
>      >
=0A=
>     -----------------------------------------= -------------------------------
=0A=
>      > Notice: This e-mail together w= ith any attachments may contain
=0A=
>      > information of Ribbon Communic= ations Inc. that is confidential
=0A=
>     and/or
=0A=
>      > proprietary for the sole use o= f the intended recipient. Any review,
=0A=
>      > disclosure, reliance or distri= bution by others or forwarding without
=0A=
>      > express permission is strictly= prohibited. If you are not the
=0A=
>     intended
=0A=
>      > recipient, please notify the s= ender immediately and then delete all
=0A=
>      > copies, including any attachme= nts.
=0A=
>      >
=0A=
>     -----------------------------------------= -------------------------------
=0A=
>      >
=0A=
>      > ______________________________= _________________
=0A=
>      > spring mailing list
=0A=
>      > spring@ietf.org <mailto:spr= ing@ietf.org>
=0A=
>      > https://www.ietf.org/mailman/l= istinfo/spring
=0A=
>      >
=0A=
>
=0A=
>     _________________________________________= ______
=0A=
>     spring mailing list
=0A=
>     spring@ietf.org <mailto:spring@ietf.or= g>
=0A=
>     https://www.ietf.org/mailman/listinfo/spr= ing
=0A=
>
=0A=
 
=0A=
_______________________________________________
=0A=
spring mailing list
=0A=
spring@ietf.org
=0A=
https://www.ietf.org/mailman/listinfo/spring
=0A=
=0A= = ------=_001_NextPart253104700535_=------ From nobody Mon Aug 3 22:17:15 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A213A0C6C; Mon, 3 Aug 2020 22:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fi-Epfej4YB; Mon, 3 Aug 2020 22:17:11 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 E3A273A0C68; Mon, 3 Aug 2020 22:17:10 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id o18so14461618eds.10; Mon, 03 Aug 2020 22:17:10 -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=SuH8mx//eCipaujB0AdLMWJ+m8HgosYI6mSDcjX9AZM=; b=U0wb3GPrzQ/Qcu0rf6NllIYLMOaNA7k83wbyN0UX62c6Wub3cpBg0Ch/BjwzpkLiVI 7VO5tVD0z6+U2w1i1S5BgDhJCQrbVLfX4u26wFlAt0cVSx1WYJHQ+2JWKsnVS9gtjBB9 nT+Q8zQudNLlS2qa2jdbz+pv8q+f49pNLDwbf0VZKUDKy/GY+bgiBSo5irTfKg9X5A78 MdbJGw9g5M98XfB0YfTma68ts0o8FW09jCYxm55DRHn0DkDFwqIChWrpDvpBTdTDRW7C VIhnMZq0u5VFiSrTw5KFQleGjpSjWdZ1N09REVCHkJpJdGtveik6NYP8Abz/xU5M8iqu M21A== 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=SuH8mx//eCipaujB0AdLMWJ+m8HgosYI6mSDcjX9AZM=; b=nUEy2PLybluVVG8H8Nq/gDtIBqEpGaxYbVLbmNErElnqBUXWj1oJwedQPFfA+Mx3/X L9eYULc8kL6IVUsR4Hpd6/KDSXwOofmgXqS5lgqnfZdvZxSTC6DRZErApUt27tmZ8ejx if63iXE5rRt8TY7lW7r0RWIp9KVNT6MZ1gMBM9k3UfgaFVYLoP36xhYg1yqQZ1rgtuF2 c5iVK/O6beNNH2peA7a2Mhw2OQDFlNY0167AfqJ+a5RyaJPYZsA7NTA00IWISncq5U19 r7WHIZaMvXH3TKns0XOpMbSEQpuNaRkiuNZQwD8MVdMOwPHtZjkElo+mMXqg65E5Y8hd 5ocg== X-Gm-Message-State: AOAM530Ssi5AkSKf82rWpUkp96vcfJIPN01b4y03p2XG+LH0koFO6ZN1 bQlaGkTpoNsuScsdLi2ZhyyEiNtsI7WQWZVSwhA= X-Google-Smtp-Source: ABdhPJyrZqnc4o4IKBqPIWW1yVCWx6n+fMCRn7QZrQNAkU/UbNbNJ/pt/mvZ+64PRq2vB5qosVwdyck8Naj2GcFKqh4= X-Received: by 2002:a05:6402:3199:: with SMTP id di25mr19075948edb.315.1596518229547; Mon, 03 Aug 2020 22:17:09 -0700 (PDT) MIME-Version: 1.0 References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Pushpasis Sarkar Date: Tue, 4 Aug 2020 10:46:58 +0530 Message-ID: To: Bruno Decraene Cc: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f320b705ac065d61" Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 05:17:14 -0000 --000000000000f320b705ac065d61 Content-Type: text/plain; charset="UTF-8" Hi WG, Support the adoption of this draft. However I think some text should be added to explain it's interaction with https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments. Authors, If you prefer, I can provide some text for your perusal. Thanks and regards, -Pushpasis On Thu, Jul 30, 2020 at 5:55 PM wrote: > Hi SPRING WG, > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have > asked for WG adoption. > > > > Please indicate your support, comments, or objection, for adopting this > draft as a working group item by August 20th 2020. (*) > > > > Could those who are willing to work on this document, please notify the > list. That gives us an indication of the energy level in the working group > to work on this. > > > > Thanks, > > Regards, > > Bruno, Jim, Joel > > > > [1] > https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 > > (*) 3 weeks to account for the IETF meeting week and the august/summer > period. > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000f320b705ac065d61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

Support the ado= ption of this draft. However I think some text should be added to explain i= t's interaction=C2=A0with https://datatracker.ietf.org/doc/dr= aft-ietf-spring-mpls-anycast-segments.=C2=A0

A= uthors,

If you prefer, I can provide some text for= your perusal.

Thanks and regards,
-Push= pasis


On Thu, Jul 30, 2020 at 5:55 PM <bruno.decraene@orange.com> wro= te:

Hi SPRING WG,

=C2=A0

Authors of draft-hegde-spring-node-protection-for-sr-te-paths =C2=A0[1] have asked for WG adoption.

=C2=A0

Please indicate your support, c= omments, or objection, for adopting this draft as a working group item by A= ugust 20th 2020. (*)

=C2=A0

Could those who are willing to = work on this document, please notify the list. That gives us an indication = of the energy level in the working group to work on this.

=C2=A0

Thanks,

Regards,

Bruno, Jim, Joel<= /span>

=C2=A0

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07

(*) 3 weeks to account for the = IETF meeting week and the august/summer period.

=C2=A0

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000f320b705ac065d61-- From nobody Mon Aug 3 23:40:48 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A91E3A0F0C for ; Mon, 3 Aug 2020 23:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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 header.b=XC4W9eym; dkim=pass (1024-bit key) header.d=juniper.net header.b=himtYWah 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 zuxP0j9Au5nO for ; Mon, 3 Aug 2020 23:40:42 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 B07693A0F08 for ; Mon, 3 Aug 2020 23:40:42 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0746XiNf008469; Mon, 3 Aug 2020 23:40:41 -0700 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 : mime-version; s=PPS1017; bh=sfWn9T5ah/snIbYJhXGcY33qy6exreexEfwdwdbGqKw=; b=XC4W9eymwtUBdHm41ZSuUYa3iayHR91N6eSYX1YIQMfZhBwS9wBH5hqYV6GgZAg+EAiU at/6jRtybZp5Q1C5GOKWuCNeXcjkEHw0dSWM6fI41aUAsQSpb/UExuUmwDa2xriMAfWg F6PhHvTsZ016+mbiISgv5BOH7ua4nziaDP+X1wPM4MvxTY/R+pDRTy9ema5T/FjHGZ+h Qf/qlkUjvHBFWPzEx0Rr2KU9FShLqbAb8ipnXxd3VnVZbCLtymY+jQw0Q6bLvFMnsrpK eR5oafzbV30gDVp3dKvUibEdrK4c34HDuFy/nsl0WClRN43SeovJA7DHVToG9gDnDP1m eg== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169]) by mx0b-00273201.pphosted.com with ESMTP id 32n6w5bt4r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 23:40:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LvTTkfST/U3tnjwrYZjhCdlwHcwU/HVaPdxCFOEanP3H8lcUdO3cQ49qmp3Pagfk/Mj+eiKsbthuHuHEHBLrU30v36ppUvxbshAP24WnlK56zEhCfUGh3af7Cej/icPrTZW3nLkdU2qSzBx2sBCcOGu4ex+po4ob8XFz3Lnb0Ato1HHQTWLRBdpGWtR5uula/d1snJyGllkGzhQok8kniliWIuoGuco9epi6cCB6Usul+BE/6dYzpP6N6IWLkqolSEvLeAnmoCwtgGu/f4yM1eAXCpD6Rzfl13lsRJaPHJ3RMAmE7UdQ/fPBHLge7t/VrKClAkzbeCIUlweQSvYMdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sfWn9T5ah/snIbYJhXGcY33qy6exreexEfwdwdbGqKw=; b=aSnHtKlngmtldVtMq1wTe8XfjRHNxEeVF7S1QaqcIjDYc2I8+ImQLoR1dYqlmT2dV2R4FbnlFU1siQF1SuZCsQclpbH2OpyacxvHWLWZM2fWM+nq7+9uCMnbfpUvoKtpg0xtq7fzqOrBH5/BxzD0lfN9VkX/xp2Q4/4J21MUozvcRQy7hpc4n03rBOPIWulc/Y09dTjq8KLjesjluxcgDuybHajQ7OmiqAIHvVeiNyzgzVkzHSKQA2lgaxje/rnMWmoHyWl0q2g8pka9c89cHikqm6J8z45o38/ENmERTDMgINU2EZ0zrZs5rqGBlo6OxF8qXf1tByW/xeHVE2zdwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sfWn9T5ah/snIbYJhXGcY33qy6exreexEfwdwdbGqKw=; b=himtYWah2EMyk4ZxLNED5kw6zR7lvcJqXLPKdd7s9Lm+jqj1hsQjecdr10Q1r9X36exo701mc3bbr2ZRVERwCuPmIJFTbFbpwJpU81L6E9I4ByH5BEivTFnn+pYr5IicTtTtAj/vam9skViIs7UIju4kL5yRquOfPRaTBw67SzI= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3510.namprd05.prod.outlook.com (2603:10b6:910:56::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.12; Tue, 4 Aug 2020 06:40:39 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3261.014; Tue, 4 Aug 2020 06:40:39 +0000 From: Shraddha Hegde To: "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "spring@ietf.org" , "Joel M. Halpern" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCmE9nDdjpckqZffxFoYFmAaklun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAD9EYA== Date: Tue, 4 Aug 2020 06:40:39 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-04T06:40:36Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=efc9000a-0c2d-4bf4-8276-2f037b420d11; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: liquidtelecom.com; dkim=none (message not signed) header.d=none;liquidtelecom.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [122.171.69.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 89590597-b688-401d-bbb5-08d838414d59 x-ms-traffictypediagnostic: CY4PR05MB3510: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uzytqkwb4rn5aoX9yGsMnUb1nYbR7h9Z7vclcuoukStiAV35gXS92QpeBHqwSttGGqrgBjhoUnTcPVEOcuJwLymqWenY23maEJ4BddiP6YPU3J1HiXfCiizr3m+I4nzNWwoAz/e5qZe9/6a3MlusQltEYJR5U8vI1aT1OK2aE8vR8RcSiEN3dkc6GMoEpKPOyBNRLxX7pXYTNjABlF1U48YjHIrtiUiyNFhHsxV2wWatMe7WnMACfZiCGzkGEb8lrDd9/3P82PLaJaORu9kOzyJjGFVD5GvQ/kcyk0YWmhZhd1rfIiSLoMkwpADBWQppgZORuqVd5tWTjtcxoNDdegwvYgHGwK8ThYNMA7O9Hc6Vw2fHjjincoIbgDOVKjMdrkwqxgu9anfrp7ghAyon/9C9BVb6V4kCklb/Rgih3PRGvwXiz8s4XMEHoFzdNiTq x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(478600001)(76116006)(8936002)(66446008)(66476007)(71200400001)(83380400001)(54906003)(66946007)(8676002)(64756008)(66556008)(316002)(30864003)(55016002)(110136005)(4326008)(86362001)(53546011)(166002)(9686003)(52536014)(7696005)(26005)(6506007)(2906002)(966005)(5660300002)(33656002)(186003)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: pP/is55b7RGaXZgCR1NV5YLGaeV9p/d7eU05SxeLVrbnj2Q7URodae5+t8mRnNXryio1OSbVmALlU6eoz9z72XzQsNvJGIJR8DZQ5N410O9hH9LdsB7W4NoTQhxkc/Jy+ql1Z350rnwz6EbpEZ9GaiWre3wwbWGH01ttusJITU2BGA5McbOEpr3qyKvjtgmzvq+80T5scf5yQwEZU7XHWXrkUVmpnwtL1ZHCTazjq2PsAKfDtuWfZKebzcYPE8O9eulpnHKdQTMP3F64VIMb+JRGujq7YjXDSpC3S5jHEixbuRa0oqkpLj4cq8LA3JkysYjH5l2HKRdDWKbBaFVZ9CYuAauSqhQrWur/lL0ARAZuOPY2UUw7P0KKWVqR1EdgIQlBs5fmkw5RHPH/1fsXrw8PLpsBQXD6Z2qj8G9DS3mhVTKs6aYiPEGOgPH6kdWpzEYkwSPKbCWVfhAlkqTMkkTU1tuE1JfpDpX8EyLJqlROWCLpfyuWIBIZbvxudBy0MKAWXERTk22E/BHYuRhsxDYeXTd1FbWK0y4XIPk3q9r+e+U6pQxjTVcxTqu3cg3uv54Dq3ITSqmvLyR8mFjOd1hqVmqfatg91Kpwg76p/c1W+2nC3WLm6WrycHQLBA3/oki40lZI378a84bdswnmeg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR05MB35769327315CBA84E8912D84D54A0CY4PR05MB3576namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89590597-b688-401d-bbb5-08d838414d59 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 06:40:39.3971 (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-CrossTenant-userprincipalname: 6bUdiHytVMQMt1BMoYL2YdBINtOzTFvjAUPDEZ57yVeQnMnNw4tA5eSGe8YW6P10JplCeqgVaKCy2jGx2jbTsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3510 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-04_02:2020-08-03, 2020-08-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 phishscore=0 clxscore=1011 suspectscore=0 spamscore=0 malwarescore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008040048 Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 06:40:46 -0000 --_000_CY4PR05MB35769327315CBA84E8912D84D54A0CY4PR05MB3576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This is a very interesting discussion and thanks to Joel for starting this = discussion. IMO, when there are strict requirements of avoiding certain nod= es/links it can be realized either by defining a flex-algo avoiding those Nodes and links or by using a stack of unprotected adj-sids that avoid rest= ricted nodes and links. When a stack of adj-sids is used to realize the pat= h, the head-end based (sBFD) protection mechanisms can be applied. If Node-sids/prefix-sid/anycast-sids are used to build the stack, the failu= re events may cause traffic to go through restricted nodes and links. This = would happen regardless of whether any kind of protection is in use or not. Rgds Shraddha Juniper Business Use Only From: spring On Behalf Of Andrew Alston Sent: Tuesday, August 4, 2020 5:41 AM To: Robert Raszuk Cc: spring@ietf.org; Joel M. Halpern Subject: Re: [spring] Spring protection - determining applicability [External Email. Be cautious of content] Robert this is actually far more difficult when - it can be an entire (long= ) series of nodes that need to be avoided. It could potentially be made to work but I'd worry that to do this - you'd = have to stack 10 - 20 - 30 negative labels - and that wouldn't be viable. It's easier to use algorithms and adjacency sids and other such things to c= alculate paths - the biggest trick is about the stack depth. When you have= this need for node avoidance - the need for 10+ label depth is critical - = unless you wanna be applying one hell of a lot of binding labels along the = way which is a nightmare. But to answer your question, is this a common use case - it's a use case th= at most of the people I discuss this with certain have - I cant comment on= a global scale, or for anyone else, but every indication I have is that ye= s - its something people need, and want Andrew From: Robert Raszuk > Sent: Tuesday, 4 August 2020 01:27 To: Andrew Alston > Cc: Joel M. Halpern >; spri= ng@ietf.org Subject: Re: [spring] Spring protection - determining applicability Is this a common use case ie. "but rather - which nodes / network segments= it can never touch or flow through." If so perhaps its time to define notion of negative-SID ie. list in the pac= ket resources which given packet MUST not ever traverse. Put in the packet set of nodes or links which the packet should never trave= rse. That goes in line of recent wave of negative routing implementations (RIFT)= or discussions (LSR) Best, R. On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > wrote: So - One of the use cases, in fact, some very major use cases in any spring tech= nology for us revolve around the following a. The explicit avoidance of certain nodes b. The explicit avoidance of certain sections of the network Anything that could result in that explicit avoidance being violated - woul= d create, shall we say significant problems. Much of the use case is not a case of which nodes the packets flow through = - but rather - which nodes / network segments it can never touch or flow th= rough. Effectively, to be used as a technology to avoid certain things for= specific reasons. This is also one of the reasons for needing such deep label stacks - this k= ind of detailed path programming tends to deepen the stack because you some= times have to be pretty explicit. It is absolutely critical to us that this functionality is there - and that= we can avoid situations which could cause traffic to accidently hit things= explicitly avoided. I wish I could be more specific than this, but it is what it is. Thanks Andrew From: spring > On B= ehalf Of Joel M. Halpern Sent: Monday, 3 August 2020 21:36 To: Robert Raszuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability (Since the thread has gotten long enough, reiterating that this is as a participant, not a WG chair.) Yes, we are talking IP networks. And yes, I have seen IP networks that choose to drop packets. For all sorts of reasons. I think there are likely other reasons why one may not want a random path rather than a chosen TE path. I think it is important we be clear about what constraints may be / are violated when we tell people they have this tool (protective rerouting) that is intended to preserve QoS. Let's be clear. I am not arguing that this is not a good idea. It is a good idea. And useful. I am trying to figure otu what combination of additional mechanisms and clear descriptions will lead to everyone getting the behavior they expect (which may not be the behavior they desire, but sometimes is the best we can do.) Yours, Joel On 8/3/2020 2:30 PM, Robert Raszuk wrote: > Joel, > > Are we still talking about IP networks here ? Or perhaps some hard > slicing with real resource reservations or detnets ? > > Because if we are talking about IP networking I have two observations: > > A) If you need to traverse via a specific node (ie. firewall) you better > apply IP encapsulation to that node. I don't think IP encapsulation can > be hijacked today such that destination address of the packet is ignored. > > B) Have you seen any IP network where upon topology change (link or node > failure) you suddenly start dropping flows in spite of SPT offering > perhaps few ms longer path with 10 ms more jitter ? > > Or are some SR marketing slides promise to turn IP networks in > something new ? Worse ... do they mention path quality guarantees, > resource reservations ? I hope not. > > Thx, > R. > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > wrote: > > Well less serious for TE SIDs, I am not sure the problem is restricted > to just service SIDs. > > Suppose that the PCE has specified the path to meet some complex te > objective. The bypass node has no way of knowing what those > constraints > were. And for some kinds of traffic, it is better to drop the packet > than to deliver it outside the envelop. I suspect that the right > answer > to this is "too bad". If so, as with the distinction regarding service > nodes, we should say so, shouldn't we? > > Yours, > Joel > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > Mach, Joel and all, > > > > I think that in most cases: > > > > 1.There is clear differentiation between "topological" and "service" > > instructions in SID advertisements. E.g.: > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > corresponding IGP advertisements) represent topological instructions > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > draft) unsurprisingly represent "service" instructions > > > > 2.Segments that represent topological instructions can be bypassed, > > while segments that represent service instructions require > alternative > > protection mechanisms. > > > > This view seems to be aligned with RFC 8402 > > > that says in Section 1: > > > > In the context of an IGP-based distributed control plane, two > > > > topological segments are defined: the IGP-Adjacency segment and the > > > > IGP-Prefix segment. > > > > In the context of a BGP-based distributed control plane, two > > > > topological segments are defined: the BGP peering segment and the > > > > BGP-Prefix segment. > > > > In the case of SR-MPLS this differentiation is assumed in Section > 3.4 of > > the Node Protection for SR-TE Path > > > > > > > draft that says: > > > > The node protection mechanism described in the previous sections > > > > depends on the assumption that the label immediately below > the top > > > > label in the label stack is understood in the IGP domain. When the > > > > provider edge routers exchange service labels via BGP or some > other > > > > non-IGP mechanism the bottom label is not understood in the IGP > > > > domain. > > > > The egress node protection mechanisms described in the draft > > > > [RFC8679 >] is > > applicable to this use case and no additional changes > > > > will be required for SR based networks > > > > The scenarios in which differentiation between "topological" and > > "service" instructions is broken are indeed problematic. E.g., > consider > > the use case in which a Node SID in the ERO of a SR-TE path > identifies a > > node that acts as a firewall for all packets it receives, i.e., > provides > > the firewall service without any dedicated service SID > identifying it. > > One could say that the Node SID of such a node would combine > topological > > and service instructions thus breaking the differentiation > between the two. > > > > I am not sure if usage of such "combined" SIDs could be prevented > or at > > least discouraged. > > > > If not, providing an ability to identify such SIDs in the > advertisement > > mechanisms would be useful IMHO. > > > > My 2c, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > -----Original Message----- > > From: spring > > On B= ehalf Of Mach Chen > > Sent: Monday, August 3, 2020 6:30 AM > > To: Joel M. Halpern > >; spring@ietf= .org > > Subject: Re: [spring] Spring protection - determining applicability > > > > Hi Joel, > > > > I think this is a good point that may not be discussed in the > past. And > > I also don't think there is a "can be bypassed" indication in the > > routing advertisement for now. > > > > IMHO, the information advertised by routing is neutral, such > information > > (can or cannot be bypassed) is more path specific, thus normally the > > controller should be responsible for deciding whether/which SID > can be > > bypassed. > > > > Best regards, > > > > Mach > > > > > -----Original Message----- > > > > > From: spring [mailto:spring-bounces@ietf.org > ] On Behalf Of Joel M. > > > > > Halpern > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > To: spring@ietf.org > >> > > > > > Subject: [spring] Spring protection - determining applicability > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > confused WG > > > > > participant.) > > > > > > > > > > I have been reading the various repair drafts, and the various > > > > > networks programming and service programming draft, and I am > trying to > > > > > figure out one aspect of the combination. > > > > > > > > > > How does a node that is doing some form of bypass (suppose, for > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > a failed > > > > > node N3) know that it is safe to do so? > > > > > > > > > > If the path was just for TE, then it is "safe" if the new path > meets > > > > > the TE criteria. or maybe it is safe if it is even close, as > long as > > > > > it is not used for too long. > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > requirements? > > > > > Or was some other necessary programmatic transform (wince we are > > > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > advertisements that I missed? > > > > > > > > > > Thank you, > > > > > Yours, > > > > > Joel > > > > > > > > > > _______________________________________________ > > > > > spring mailing list > > > > > spring@ietf.org > >> > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2<= https://urldefense.com/v3/__https:/clicktime.symantec.com/367qhU4KiUkzW9uGC= 4eAvP46H2?u=3Dhttps*3A*2__;JSU!!NEt6yMaO-gk!S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxq= guoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil$> > > > > > > > > > F%2Fwww.ietf.org > >%2Fmailman%2Flistinfo%2Fspring > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > ------------------------------------------------------------------------ > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential > and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the > intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CY4PR05MB35769327315CBA84E8912D84D54A0CY4PR05MB3576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

This is a very interesting discussion and thanks to = Joel for starting this discussion. IMO, when there are strict requirements = of avoiding certain nodes/links it can be realized  either by defining= a flex-algo avoiding those

Nodes and links or by using a stack of unprotected a= dj-sids that avoid restricted nodes and links. When a stack of adj-sids is = used to realize the path, the head-end based (sBFD) protection mechanisms c= an be applied.

 

If Node-sids/prefix-sid/anycast-sids are used to bui= ld the stack, the failure events may cause traffic to go through restricted= nodes and links. This would happen regardless of whether any kind of prote= ction is in use or not.

 

Rgds

Shraddha

        &nbs= p;            &= nbsp;

 

 


Juniper Business= Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of Andrew Alston
Sent: Tuesday, August 4, 2020 5:41 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Robert this is actually far more difficult when R= 11; it can be an entire (long) series of nodes that need to be avoided.&nbs= p;

 

It could potentially be made to work but I’d w= orry that to do this – you’d have to stack 10 – 20 –= ; 30 negative labels – and that wouldn’t be viable.

 

It’s easier to use algorithms and adjacency si= ds and other such things to calculate paths – the biggest trick is ab= out the stack depth.  When you have this need for node avoidance ̵= 1; the need for 10+ label depth is critical – unless you wanna be applying one hell of a lot of binding labels along the way which = is a nightmare.

 

But to answer your question, is this a common use ca= se – it’s a use case that most of the people I discuss this wit= h certain have – I cant  comment on a global scale, or for anyon= e else, but every indication I have is that yes – its something people need, and want

 

Andrew

 

 

From: Robert Raszu= k <robert@raszuk.net>
Sent: Tuesday, 4 August 2020 01:27
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Joel M. Halpern <jmh@j= oelhalpern.com>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

 

Is this a common use case= ie.  "but rather – which nodes / network segments it can n= ever touch or flow through."

 

If so perhaps its time to= define notion of negative-SID ie. list in the packet resources which given packe= t MUST not ever traverse. 

 

Put in the packet set of = nodes or links which the packet should never traverse. 

 

That goes in line of rece= nt wave of negative routing implementations (RIFT) or discussions (LSR)

 

Best,
R.

 

 

 

 

 

On Mon, Aug 3, 2020 at 11= :46 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:

So –

 

One of the use cases, in fact, some very major use cases in any spring tech= nology for us revolve around the following

 

a.       The explicit avoidance of certain nodes<= /p>

b.       The explicit avoidance of certain sections of the n= etwork

 

Anything that could result in that explicit avoidance being violated –= ; would create, shall we say significant problems.

 

Much of the use case is not a case of which nodes the packets flow through = – but rather – which nodes / network segments it can never touc= h or flow through.  Effectively, to be used as a technology to avoid c= ertain things for specific reasons.

 

This is also one of the reasons for needing such deep label stacks – = this kind of detailed path programming tends to deepen the stack because yo= u sometimes have to be pretty explicit.

 

It is absolutely critical to us that this functionality is there – an= d that we can avoid situations which could cause traffic to accidently hit = things explicitly avoided.

 

I wish I could be more specific than this, but it is what it is.=

 

Thanks

 

Andrew

 

 

From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: Monday, 3 August 2020 21:36
To: Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

(Since the thread has gotten long enough, reiterating that this is as a participant, not a WG chair.)

Yes, we are talking IP networks. And yes, I have seen IP networks that
choose to drop packets. For all sorts of reasons.
I think there are likely other reasons why one may not want a random
path rather than a chosen TE path. I think it is important we be clear
about what constraints may be / are violated when we tell people they
have this tool (protective rerouting) that is intended to preserve QoS.

Let's be clear. I am not arguing that this is not a good idea. It is a
good idea. And useful. I am trying to figure otu what combination of
additional mechanisms and clear descriptions will lead to everyone
getting the behavior they expect (which may not be the behavior they
desire, but sometimes is the best we can do.)

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> Joel,
>
> Are we still talking about IP networks here ? Or perhaps some har= d
> slicing with real resource reservations or detnets ?
>
> Because if we are talking about IP networking I have two obs= ervations:
>
> A) If you need to traverse via a specific node (ie. firewall) you bett= er
> apply IP encapsulation to that node. I don't think IP encapsulation&nb= sp;can
> be hijacked today such that destination address of the packet is ignor= ed.
>
> B) Have you seen any IP network where upon topology change (link or no= de
> failure) you suddenly start dropping flows in spite of SPT o= ffering
> perhaps few ms longer path with 10 ms more jitter ?
>
> Or are some SR marketing slides promise to turn IP networks in
> something new ? Worse ... do they mention path quality guarantees= ,
> resource reservations ? I hope not.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>> wrote:
>
> Well less serious for TE SIDs, I am not sure the problem is restricted=
> to just service SIDs.
>
> Suppose that the PCE has specified the path to meet some complex te > objective.  The bypass node has no way of knowing what those
> constraints
> were.  And for some kinds of traffic, it is better to drop the pa= cket
> than to deliver it outside the envelop.  I suspect that the right=
> answer
> to this is "too bad".  If so, as with the distinction r= egarding service
> nodes, we should say so, shouldn't we?
>
> Yours,
> Joel
>
> On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> > Mach, Joel and all,
> >
> > I think that in most cases:
> >
> > 1.There is clear differentiation between "topological" = and "service"
> > instructions in SID advertisements. E.g.:
> >
> > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
> > corresponding IGP advertisements) represent topological instructi= ons
> >
> > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
> >
> <https:= //datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-04> >
> > draft) unsurprisingly represent “service” instruction= s
> >
> > 2.Segments that represent topological instructions can be bypasse= d,
> > while segments that represent service instructions require
> alternative
> > protection mechanisms.
> >
> > This view seems to be aligned with RFC 8402
> > <https://tools.ietf.org/html/rfc8402<= /a>> that says in Section 1:
> >
> >     In the context of an IGP-based distributed con= trol plane, two
> >
> > topological segments are defined: the IGP-Adjacency segment and t= he
> >
> >     IGP-Prefix segment.
> >
> >     In the context of a BGP-based distributed cont= rol plane, two
> >
> > topological segments are defined: the BGP peering segment and the=
> >
> >     BGP-Prefix segment.
> >
> > In the case of SR-MPLS this differentiation is assumed in Section=
> 3.4 of
> > the Node Protection for SR-TE Path
> >
> <https://datatracker.ietf.org/doc/html/draft-he= gde-spring-node-protection-for-sr-te-paths-07#section-3.4>
>
> > draft that says:
> >
> >     The node protection mechanism described in the= previous sections
> >
> >     depends on the assumption that the label immed= iately below
> the top
> >
> > label in the label stack is understood in the IGP domain.  W= hen the
> >
> >     provider edge routers exchange service labels = via BGP or some
> other
> >
> >     non-IGP mechanism the bottom label is not unde= rstood in the IGP
> >
> >     domain.
> >
> >     The egress node protection mechanisms describe= d in the draft
> >
> >     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679>] is
> > applicable to this use case and no additional changes
> >
> >     will be required for SR based networks
> >
> > The scenarios in which  differentiation between “topol= ogical” and
> > “service” instructions is broken are indeed problemat= ic. E.g.,
> consider
> > the use case in which a Node SID in the ERO of a SR-TE path
> identifies a
> > node that acts as a firewall for all packets it receives, i.e., > provides
> > the firewall service without any dedicated service SID
> identifying it.
> > One could say that the Node SID of such a node would combine
> topological
> > and service instructions thus breaking the differentiation
> between the two.
> >
> > I am not sure if usage of such “combined” SIDs could = be prevented
> or at
> > least discouraged.
> >
> > If not, providing an ability to identify such SIDs in the
> advertisement
> > mechanisms would be useful IMHO.
> >
> > My 2c,
> >
> > Sasha
> >
> > Office: +972-39266302
> >
> > Cell:      +972-549266302
> >
> > Email: Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>
> >
> > -----Original Message-----
> > From: spring <spring-bounces@ietf.org
> <m= ailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
> > Sent: Monday, August 3, 2020 6:30 AM
> > To: Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org &l= t;mailto:spring@ietf.o= rg>
> > Subject: Re: [spring] Spring protection - determining applicabili= ty
> >
> > Hi Joel,
> >
> > I think this is a good point that may not be discussed in the
> past. And
> > I also don't think there is a "can be bypassed" indicat= ion in the
> > routing advertisement for now.
> >
> > IMHO, the information advertised by routing is neutral, such
> information
> > (can or cannot be bypassed) is more path specific, thus normally = the
> > controller should be responsible for deciding whether/which SID > can be
> > bypassed.
> >
> > Best regards,
> >
> > Mach
> >
> >  > -----Original Message-----
> >
> >  > From: spring [mailto:sp= ring-bounces@ietf.org
> <mailto:spring-bounces@ietf.org>] On Behalf Of Joel M.
> >
> >  > Halpern
> >
> >  > Sent: Monday, August 3, 2020 7:51 AM
> >
> >  > To: spring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >  > Subject: [spring] Spring protection - determining appl= icability
> >
> >  >
> >
> >  > (WG Chair hat Off, this is merely a note from a slight= ly
> confused WG
> >
> >  > participant.)
> >
> >  >
> >
> >  > I have been reading the various repair drafts, and the= various
> >
> >  > networks programming and service programming draft, an= d I am
> trying to
> >
> >  > figure out one aspect of the combination.
> >
> >  >
> >
> >  > How does a node that is doing some form of bypass (sup= pose, for
> >
> >  > simplicity, it is Node N2 deciding to bypass the next = SID for
> a failed
> >
> >  > node N3) know that it is safe to do so?
> >
> >  >
> >
> >  > If the path was just for TE, then it is "safe&quo= t; if the new path
> meets
> >
> >  > the TE criteria.  or maybe it is safe if it is ev= en close, as
> long as
> >
> >  > it is not used for too long.
> >
> >  >
> >
> >  > But what if the node were a Firewall, included to meet= legal
> > requirements?
> >
> >  > Or was some other necessary programmatic transform (wi= nce we are
> >
> >  > deliberately vague about what nodes can do when asked = suitably.)
> >
> >  >
> >
> >  > Is there some "can be bypassed" indication i= n the routing
> >
> >  > advertisements that I missed?
> >
> >  >
> >
> >  > Thank you,
> >
> >  > Yours,
> >
> >  > Joel
> >
> >  >
> >
> >  > _______________________________________________
> >
> >  > spring mailing list
> >
> >  > s= pring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >  >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
> >
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252= >
> >
> >  > F%2Fwww.ietf.org
> <http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fsp= ring
> >
> > _______________________________________________
> >
> > spring mailing list
> >
> > spring@ietf.= org <mailto:spr= ing@ietf.org> <mailto:spring@ietf.org
> <mailto:sp= ring@ietf.org>>
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> >
> ----------------------------------------------------------------------= --
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. that is confidential > and/or
> > proprietary for the sole use of the intended recipient. Any revie= w,
> > disclosure, reliance or distribution by others or forwarding with= out
> > express permission is strictly prohibited. If you are not the
> intended
> > recipient, please notify the sender immediately and then delete a= ll
> > copies, including any attachments.
> >
> ----------------------------------------------------------------------= --
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.= org <mailto:spr= ing@ietf.org>
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@i= etf.org>
> https://www.ietf.org/mailman/listinfo/spring
>

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spr= ing

--_000_CY4PR05MB35769327315CBA84E8912D84D54A0CY4PR05MB3576namp_-- From nobody Mon Aug 3 23:50:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3EE3A0F1F for ; Mon, 3 Aug 2020 23:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RrtrRLo_kfqr for ; Mon, 3 Aug 2020 23:50:43 -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 2805B3A0F20 for ; Mon, 3 Aug 2020 23:50:43 -0700 (PDT) Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D8452D2B45CE293DF03F; Tue, 4 Aug 2020 07:50:39 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 4 Aug 2020 07:50:38 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 4 Aug 2020 14:50:36 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Tue, 4 Aug 2020 14:50:36 +0800 From: "Dongjie (Jimmy)" To: "li_zhenqiang@hotmail.com" , "Joel M. Halpern" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfMmkgJsZ1580Gn7dLAcCrVYKklNGAAgAA0D4CAAMHVAIAABZ6AgAABgICAASfrmYAAIhaA Date: Tue, 4 Aug 2020 06:50:36 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com>, , , , , <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: multipart/alternative; boundary="_000_a5193b2356c745ac8bd56c1958631f16huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 06:50:46 -0000 --_000_a5193b2356c745ac8bd56c1958631f16huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUgb2JqZWN0aXZlIGFuZCBjb25zdHJh aW50IHdpdGggU1IgZXhwbGljaXQgcGF0aCAoYWthLiBURSkgYW5kIFNSIGxvb3NlIHBhdGggbWF5 IGJlIGRpZmZlcmVudC4NCg0KQXMgWmhlbnFpYW5nIG1lbnRpb25lZCwgYW4gU1ItVEUgcGF0aCB3 aXRoIGEgbGlzdCBvZiBhZGovRW5kLlggU0lEcyByZWZsZWN0cyB0aGUgcG9saWN5IG9mIHRoZSBj b250cm9sbGVyIG9yIHRoZSBoZWFkZW5kIG5vZGUsIHdoaWNoIG1heSBpbXBseSB0aGF0IGEgYmFj a3VwIHBhdGggdGhhdCBjYW4gbWVldCB0aGUgc2FtZSBwb2xpY3kgdXN1YWxseSBpcyBhbHNvIHBy b3ZpZGVkIGJ5IHRoZSBjb250cm9sbGVyIG9yIGhlYWRlbmQgbm9kZS4gV2hpbGUgZGVwZW5kcyBv biB0aGUgcG9saWN5LCBsb2NhbCBwcm90ZWN0aW9uIG1heSBzdGlsbCBiZSBoZWxwZnVsLg0KDQpJ ZiBhbiBTUiBwYXRoIGlzIGJ1aWx0IHdpdGggb25lIG9yIGEgbGlzdCBvZiBwcmVmaXgtU0lEcywg dGhlIHByZWZpeC9FbmQgU0lEcyBhcmUgdXNlZCB0byByZXByZXNlbnQgc29tZSBwb2xpY3kvY29u c3RyYWludHMgd2hpY2ggY2FuIGJlIHVuZGVyc3Rvb2QgYnkgYm90aCB0aGUgY29udHJvbGxlciwg dGhlIGhlYWRlbmQsIGFuZCBhdCBsZWFzdCBzb21lIGludGVybWVkaWF0ZSBub2RlcywgdGh1cyBp dCBpcyBwb3NzaWJsZSBhbiBpbnRlcm1lZGlhdGUgbm9kZSBjYW4gcHJvdmlkZSBhIGxvY2FsIHBy b3RlY3Rpb24gd2hpY2ggc3RpbGwgbWVldCB0aGUgcG9saWN5L2NvbnN0cmFpbnRzLg0KDQpCZXN0 IHJlZ2FyZHMsDQpKaWUNCg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBsaV96aGVucWlhbmdAaG90bWFpbC5jb20NClNlbnQ6IFR1ZXNk YXksIEF1Z3VzdCA0LCAyMDIwIDEyOjE0IFBNDQpUbzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9l bGhhbHBlcm4uY29tPjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQpDYzogc3By aW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBk ZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCkhpIEpvZWwgYW5kIEFsbCwNCg0KSSB0aGluayBU RSBwYXRoIHNob3VsZCBiZSBjb3VwbGVkIHdpdGggZW5kIHRvIGVuZCBwcm90ZWN0aW9uLiBJdCBp cyBub3QgcHJ1ZGVudCB0byBhbGxvdyBub2RlIG9yIGxpbmsgcHJvdGVjdGlvbiBpbiBhIFRFIHBh dGggc2luY2UgdGhlIGxvY2FsIHByb3RlY3Rpb24gbWF5IG5vdCBzYXRpc2Z5IHRoZSBTTEEgcmVx dWlyZW1lbnRzIG9yIHRoZSBwYXRoIGNvbnN0cmFpbnMuIEluIGZhY3QgdGhlIG5vZGUgZW4tcm91 dGUgZXhjZXB0IHRoZSBoZWFkZW5kIGFuZCB0aGUgY29udHJvbGxlciBoYXMgbm8gaWRlYSBhYm91 dCB0aGUgU0xBIHJlcXVpcmVtZW50cyBhbmQgdGhlIHBhdGggY29uc3RyYWlucy4gVEUgcGF0aCBv bmx5IGNhbiBiZSByZW9wdGltaXplZCBvciByZWJ1aWx0IGVuZCB0byBlbmQgYnkgdGhlIGhlYWRl bmQgb3IgdGhlIGNvbnRyb2xsZXIgaWYgeW91IHdhbnQgeW91ciBTTEEgcmVxdWlyZW1lbnRzIGFu ZCBwYXRoIGNvbnRyYWlucyBiZSBzYXRpc2ZpZWQuDQoNCkluIG15IG9waW5pb24sIGl0IGlzIG1v cmUgYXBwcm9wcmlhdGUgdG8gdXNlIGxvY2FsIHByb3RlY3Rpb24gaW4gSVAgZm93YXJkaW5nIHNj ZW5hcmlvcyByYXRoZXIgdGhhbiBURSBvciBwb2xpY3kgcGF0aHMuDQoNCkJlc3QgUmVnYXJkcywN ClpoZW5xaWFuZyBMaQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpX3poZW5x aWFuZ0Bob3RtYWlsLmNvbTxtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPg0KDQpGcm9t OiBKb2VsIE0uIEhhbHBlcm48bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+DQpEYXRlOiAyMDIw LTA4LTA0IDAyOjM1DQpUbzogUm9iZXJ0IFJhc3p1azxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+ DQpDQzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5 DQooU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCByZWl0ZXJhdGluZyB0 aGF0IHRoaXMgaXMgYXMgYQ0KcGFydGljaXBhbnQsIG5vdCBhIFdHIGNoYWlyLikNCg0KWWVzLCB3 ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4gIEFuZCB5ZXMsIEkgaGF2ZSBzZWVuIElQIG5ldHdv cmtzIHRoYXQNCmNob29zZSB0byBkcm9wIHBhY2tldHMuICBGb3IgYWxsIHNvcnRzIG9mIHJlYXNv bnMuDQpJIHRoaW5rIHRoZXJlIGFyZSBsaWtlbHkgb3RoZXIgcmVhc29ucyB3aHkgb25lIG1heSBu b3Qgd2FudCBhIHJhbmRvbQ0KcGF0aCByYXRoZXIgdGhhbiBhIGNob3NlbiBURSBwYXRoLiAgSSB0 aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXINCmFib3V0IHdoYXQgY29uc3RyYWludHMg bWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUgdGhleQ0KaGF2ZSB0aGlz IHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0aGF0IGlzIGludGVuZGVkIHRvIHByZXNlcnZl IFFvUy4uDQoNCkxldCdzIGJlIGNsZWFyLiAgSSBhbSBub3QgYXJndWluZyB0aGF0IHRoaXMgaXMg bm90IGEgZ29vZCBpZGVhLiAgSXQgaXMgYQ0KZ29vZCBpZGVhLiAgQW5kIHVzZWZ1bC4gIEkgYW0g dHJ5aW5nIHRvIGZpZ3VyZSBvdHUgd2hhdCBjb21iaW5hdGlvbiBvZg0KYWRkaXRpb25hbCBtZWNo YW5pc21zIGFuZCBjbGVhciBkZXNjcmlwdGlvbnMgd2lsbCBsZWFkIHRvIGV2ZXJ5b25lDQpnZXR0 aW5nIHRoZSBiZWhhdmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5vdCBiZSB0aGUgYmVoYXZp b3IgdGhleQ0KZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBiZXN0IHdlIGNhbiBkby4pDQoN CllvdXJzLA0KSm9lbA0KDQpPbiA4LzMvMjAyMCAyOjMwIFBNLCBSb2JlcnQgUmFzenVrIHdyb3Rl Og0KPiBKb2VsLA0KPg0KPiBBcmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JrcyBo ZXJlID8gT3IgcGVyaGFwcyBzb21lIGhhcmQNCj4gc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2Ug cmVzZXJ2YXRpb25zIG9yIGRldG5ldHMgPw0KPg0KPiBCZWNhdXNlIGlmIHdlIGFyZSB0YWxraW5n IGFib3V0IElQIG5ldHdvcmtpbmcgSSBoYXZlIHR3byBvYnNlcnZhdGlvbnM6DQo+DQo+IEEpIElm IHlvdSBuZWVkIHRvIHRyYXZlcnNlIHZpYSBhIHNwZWNpZmljIG5vZGUgKGllLiBmaXJld2FsbCkg eW91IGJldHRlcg0KPiBhcHBseSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4gSSBkb24n dCB0aGluayBJUCBlbmNhcHN1bGF0aW9uIGNhbg0KPiBiZSBoaWphY2tlZCB0b2RheSBzdWNoIHRo YXQgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUgcGFja2V0IGlzIGlnbm9yZWQuDQo+DQo+IEIp IEhhdmUgeW91IHNlZW4gYW55IElQIG5ldHdvcmsgd2hlcmUgdXBvbiB0b3BvbG9neSBjaGFuZ2Ug KGxpbmsgb3Igbm9kZQ0KPiBmYWlsdXJlKSB5b3Ugc3VkZGVubHkgc3RhcnQgZHJvcHBpbmcgZmxv d3MgaW4gc3BpdGUgb2YgU1BUIG9mZmVyaW5nDQo+IHBlcmhhcHMgZmV3IG1zIGxvbmdlciBwYXRo IHdpdGggMTAgbXMgbW9yZSBqaXR0ZXIgPw0KPg0KPiBPciBhcmUgc29tZSBTUiBtYXJrZXRpbmcg c2xpZGVzIHByb21pc2UgdG8gdHVybiBJUCBuZXR3b3JrcyBpbg0KPiBzb21ldGhpbmcgbmV3ID8g V29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3VhcmFudGVlcywNCj4gcmVz b3VyY2UgcmVzZXJ2YXRpb25zID8gSSBob3BlIG5vdC4NCj4NCj4gVGh4LA0KPiBSLg0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDg6MTAgUE0gSm9l bCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo+IDxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT4+IHdyb3RlOg0KPg0KPiAgICAgV2VsbCBsZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMs IEkgYW0gbm90IHN1cmUgdGhlIHByb2JsZW0gaXMgcmVzdHJpY3RlZA0KPiAgICAgdG8ganVzdCBz ZXJ2aWNlIFNJRHMuDQo+DQo+ICAgICBTdXBwb3NlIHRoYXQgdGhlIFBDRSBoYXMgc3BlY2lmaWVk IHRoZSBwYXRoIHRvIG1lZXQgc29tZSBjb21wbGV4IHRlDQo+ICAgICBvYmplY3RpdmUuICBUaGUg YnlwYXNzIG5vZGUgaGFzIG5vIHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2UNCj4gICAgIGNvbnN0 cmFpbnRzDQo+ICAgICB3ZXJlLiAgQW5kIGZvciBzb21lIGtpbmRzIG9mIHRyYWZmaWMsIGl0IGlz IGJldHRlciB0byBkcm9wIHRoZSBwYWNrZXQNCj4gICAgIHRoYW4gdG8gZGVsaXZlciBpdCBvdXRz aWRlIHRoZSBlbnZlbG9wLiAgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0DQo+ICAgICBhbnN3ZXIN Cj4gICAgIHRvIHRoaXMgaXMgInRvbyBiYWQiLiAgSWYgc28sIGFzIHdpdGggdGhlIGRpc3RpbmN0 aW9uIHJlZ2FyZGluZyBzZXJ2aWNlDQo+ICAgICBub2Rlcywgd2Ugc2hvdWxkIHNheSBzbywgc2hv dWxkbid0IHdlPw0KPg0KPiAgICAgWW91cnMsDQo+ICAgICBKb2VsDQo+DQo+ICAgICBPbiA4LzMv MjAyMCAyOjM2IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gICAgICA+IE1hY2gs IEpvZWwgYW5kIGFsbCwNCj4gICAgICA+DQo+ICAgICAgPiBJIHRoaW5rIHRoYXQgaW4gbW9zdCBj YXNlczoNCj4gICAgICA+DQo+ICAgICAgPiAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlv biBiZXR3ZWVuICJ0b3BvbG9naWNhbCIgYW5kICJzZXJ2aWNlIg0KPiAgICAgID4gaW5zdHJ1Y3Rp b25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5nLjoNCj4gICAgICA+DQo+ICAgICAgPiBvSUdQ IFByZWZpeCBOb2RlIFNJRHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4gdGhl DQo+ICAgICAgPiBjb3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50cykgcmVwcmVzZW50IHRv cG9sb2dpY2FsIGluc3RydWN0aW9ucw0KPiAgICAgID4NCj4gICAgICA+IG9TZXJ2aWNlIFNJRHMg Zm9yIFNSdjYgKHNlZSBTUnY2IEJHUC1CYXNlZCBPdmVybGF5IFNlcnZpY2VzDQo+ICAgICAgPg0K PiAgICAgPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1i ZXNzLXNydjYtc2VydmljZXMtMDQ+DQo+DQo+ICAgICAgPiBkcmFmdCkgdW5zdXJwcmlzaW5nbHkg cmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zDQo+ICAgICAgPg0KPiAgICAgID4g Mi5TZWdtZW50cyB0aGF0IHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJl IGJ5cGFzc2VkLA0KPiAgICAgID4gd2hpbGUgc2VnbWVudHMgdGhhdCByZXByZXNlbnQgc2Vydmlj ZSBpbnN0cnVjdGlvbnMgcmVxdWlyZQ0KPiAgICAgYWx0ZXJuYXRpdmUNCj4gICAgICA+IHByb3Rl Y3Rpb24gbWVjaGFuaXNtcy4NCj4gICAgICA+DQo+ICAgICAgPiBUaGlzIHZpZXcgc2VlbXMgdG8g YmUgYWxpZ25lZCB3aXRoIFJGQyA4NDAyDQo+ICAgICAgPiA8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzg0MDI+IHRoYXQgc2F5cyBpbiBTZWN0aW9uIDE6DQo+ICAgICAgPg0KPiAgICAg ID4gICAgIEluIHRoZSBjb250ZXh0IG9mIGFuIElHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9s IHBsYW5lLCB0d28NCj4gICAgICA+DQo+ICAgICAgPiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUg ZGVmaW5lZDogdGhlIElHUC1BZGphY2VuY3kgc2VnbWVudCBhbmQgdGhlDQo+ICAgICAgPg0KPiAg ICAgID4gICAgIElHUC1QcmVmaXggc2VnbWVudC4NCj4gICAgICA+DQo+ICAgICAgPiAgICAgSW4g dGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwgdHdv DQo+ICAgICAgPg0KPiAgICAgID4gdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRo ZSBCR1AgcGVlcmluZyBzZWdtZW50IGFuZCB0aGUNCj4gICAgICA+DQo+ICAgICAgPiAgICAgQkdQ LVByZWZpeCBzZWdtZW50Lg0KPiAgICAgID4NCj4gICAgICA+IEluIHRoZSBjYXNlIG9mIFNSLU1Q TFMgdGhpcyBkaWZmZXJlbnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uDQo+ICAgICAzLjQg b2YNCj4gICAgICA+IHRoZSBOb2RlIFByb3RlY3Rpb24gZm9yIFNSLVRFIFBhdGgNCj4gICAgICA+ DQo+ICAgICA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1oZWdk ZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyNzZWN0aW9uLTMuND4N Cj4NCj4gICAgICA+IGRyYWZ0IHRoYXQgc2F5czoNCj4gICAgICA+DQo+ICAgICAgPiAgICAgVGhl IG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0 aW9ucw0KPiAgICAgID4NCj4gICAgICA+ICAgICBkZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRo YXQgdGhlIGxhYmVsIGltbWVkaWF0ZWx5IGJlbG93DQo+ICAgICB0aGUgdG9wDQo+ICAgICAgPg0K PiAgICAgID4gbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElH UCBkb21haW4uICBXaGVuIHRoZQ0KPiAgICAgID4NCj4gICAgICA+ICAgICBwcm92aWRlciBlZGdl IHJvdXRlcnMgZXhjaGFuZ2Ugc2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBzb21lDQo+ICAgICBv dGhlcg0KPiAgICAgID4NCj4gICAgICA+ICAgICBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90dG9t IGxhYmVsIGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1ANCj4gICAgICA+DQo+ICAgICAgPiAg ICAgZG9tYWluLg0KPiAgICAgID4NCj4gICAgICA+ICAgICBUaGUgZWdyZXNzIG5vZGUgcHJvdGVj dGlvbiBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQNCj4gICAgICA+DQo+ICAgICAg PiAgICAgW1JGQzg2NzkgPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZj ODY3OT5dIGlzDQo+ICAgICAgPiBhcHBsaWNhYmxlIHRvIHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFk ZGl0aW9uYWwgY2hhbmdlcw0KPiAgICAgID4NCj4gICAgICA+ICAgICB3aWxsIGJlIHJlcXVpcmVk IGZvciBTUiBiYXNlZCBuZXR3b3Jrcw0KPiAgICAgID4NCj4gICAgICA+IFRoZSBzY2VuYXJpb3Mg aW4gd2hpY2ggIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs4oCdIGFuZA0K PiAgICAgID4g4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnMgaXMgYnJva2VuIGFyZSBpbmRlZWQg cHJvYmxlbWF0aWMuIEUuZy4sDQo+ICAgICBjb25zaWRlcg0KPiAgICAgID4gdGhlIHVzZSBjYXNl IGluIHdoaWNoIGEgTm9kZSBTSUQgaW4gdGhlIEVSTyBvZiBhIFNSLVRFIHBhdGgNCj4gICAgIGlk ZW50aWZpZXMgYQ0KPiAgICAgID4gbm9kZSB0aGF0IGFjdHMgYXMgYSBmaXJld2FsbCBmb3IgYWxs IHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4sDQo+ICAgICBwcm92aWRlcw0KPiAgICAgID4gdGhl IGZpcmV3YWxsIHNlcnZpY2Ugd2l0aG91dCBhbnkgZGVkaWNhdGVkIHNlcnZpY2UgU0lEDQo+ICAg ICBpZGVudGlmeWluZyBpdC4NCj4gICAgICA+IE9uZSBjb3VsZCBzYXkgdGhhdCB0aGUgTm9kZSBT SUQgb2Ygc3VjaCBhIG5vZGUgd291bGQgY29tYmluZQ0KPiAgICAgdG9wb2xvZ2ljYWwNCj4gICAg ICA+IGFuZCBzZXJ2aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRp YXRpb24NCj4gICAgIGJldHdlZW4gdGhlIHR3by4NCj4gICAgICA+DQo+ICAgICAgPiBJIGFtIG5v dCBzdXJlIGlmIHVzYWdlIG9mIHN1Y2gg4oCcY29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2 ZW50ZWQNCj4gICAgIG9yIGF0DQo+ICAgICAgPiBsZWFzdCBkaXNjb3VyYWdlZC4NCj4gICAgICA+ DQo+ICAgICAgPiBJZiBub3QsIHByb3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50aWZ5IHN1Y2gg U0lEcyBpbiB0aGUNCj4gICAgIGFkdmVydGlzZW1lbnQNCj4gICAgICA+IG1lY2hhbmlzbXMgd291 bGQgYmUgdXNlZnVsIElNSE8uDQo+ICAgICAgPg0KPiAgICAgID4gTXkgMmMsDQo+ICAgICAgPg0K PiAgICAgID4gU2FzaGENCj4gICAgICA+DQo+ICAgICAgPiBPZmZpY2U6ICs5NzItMzkyNjYzMDIN Cj4gICAgICA+DQo+ICAgICAgPiBDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyDQo+ICAgICAgPg0K PiAgICAgID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4gICAgIDxtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICAgPg0KPiAgICAgID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gICAgICA+IEZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmcNCj4gICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYg T2YgTWFjaCBDaGVuDQo+ICAgICAgPiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDY6MzAg QU0NCj4gICAgICA+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20NCj4g ICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiBTdWJq ZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNh YmlsaXR5DQo+ICAgICAgPg0KPiAgICAgID4gSGkgSm9lbCwNCj4gICAgICA+DQo+ICAgICAgPiBJ IHRoaW5rIHRoaXMgaXMgYSBnb29kIHBvaW50IHRoYXQgbWF5IG5vdCBiZSBkaXNjdXNzZWQgaW4g dGhlDQo+ICAgICBwYXN0LiBBbmQNCj4gICAgICA+IEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSBp cyBhICJjYW4gYmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlDQo+ICAgICAgPiByb3V0aW5n IGFkdmVydGlzZW1lbnQgZm9yIG5vdy4NCj4gICAgICA+DQo+ICAgICAgPiBJTUhPLCB0aGUgaW5m b3JtYXRpb24gYWR2ZXJ0aXNlZCBieSByb3V0aW5nIGlzIG5ldXRyYWwsIHN1Y2gNCj4gICAgIGlu Zm9ybWF0aW9uDQo+ICAgICAgPiAoY2FuIG9yIGNhbm5vdCBiZSBieXBhc3NlZCkgaXMgbW9yZSBw YXRoIHNwZWNpZmljLCB0aHVzIG5vcm1hbGx5IHRoZQ0KPiAgICAgID4gY29udHJvbGxlciBzaG91 bGQgYmUgcmVzcG9uc2libGUgZm9yIGRlY2lkaW5nIHdoZXRoZXIvd2hpY2ggU0lEDQo+ICAgICBj YW4gYmUNCj4gICAgICA+IGJ5cGFzc2VkLg0KPiAgICAgID4NCj4gICAgICA+IEJlc3QgcmVnYXJk cywNCj4gICAgICA+DQo+ICAgICAgPiBNYWNoDQo+ICAgICAgPg0KPiAgICAgID4gID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gICAgICA+DQo+ICAgICAgPiAgPiBGcm9tOiBzcHJpbmcg W21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZw0KPiAgICAgPG1haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb2VsIE0uDQo+ICAgICAgPg0KPiAgICAgID4g ID4gSGFscGVybg0KPiAgICAgID4NCj4gICAgICA+ICA+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMs IDIwMjAgNzo1MSBBTQ0KPiAgICAgID4NCj4gICAgICA+ICA+IFRvOiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3By aW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+Pg0KPiAgICAgID4NCj4g ICAgICA+ICA+IFN1YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5p bmcgYXBwbGljYWJpbGl0eQ0KPiAgICAgID4NCj4gICAgICA+ICA+DQo+ICAgICAgPg0KPiAgICAg ID4gID4gKFdHIENoYWlyIGhhdCBPZmYsIHRoaXMgaXMgbWVyZWx5IGEgbm90ZSBmcm9tIGEgc2xp Z2h0bHkNCj4gICAgIGNvbmZ1c2VkIFdHDQo+ICAgICAgPg0KPiAgICAgID4gID4gcGFydGljaXBh bnQuKQ0KPiAgICAgID4NCj4gICAgICA+ICA+DQo+ICAgICAgPg0KPiAgICAgID4gID4gSSBoYXZl IGJlZW4gcmVhZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXMN Cj4gICAgICA+DQo+ICAgICAgPiAgPiBuZXR3b3JrcyBwcm9ncmFtbWluZyBhbmQgc2VydmljZSBw cm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW0NCj4gICAgIHRyeWluZyB0bw0KPiAgICAgID4NCj4g ICAgICA+ICA+IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUgY29tYmluYXRpb24uDQo+ICAg ICAgPg0KPiAgICAgID4gID4NCj4gICAgICA+DQo+ICAgICAgPiAgPiBIb3cgZG9lcyBhIG5vZGUg dGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2YgYnlwYXNzIChzdXBwb3NlLCBmb3INCj4gICAgICA+ DQo+ICAgICAgPiAgPiBzaW1wbGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFz cyB0aGUgbmV4dCBTSUQgZm9yDQo+ICAgICBhIGZhaWxlZA0KPiAgICAgID4NCj4gICAgICA+ICA+ IG5vZGUgTjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRvIHNvPw0KPiAgICAgID4NCj4gICAg ICA+ICA+DQo+ICAgICAgPg0KPiAgICAgID4gID4gSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRF LCB0aGVuIGl0IGlzICJzYWZlIiBpZiB0aGUgbmV3IHBhdGgNCj4gICAgIG1lZXRzDQo+ICAgICAg Pg0KPiAgICAgID4gID4gdGhlIFRFIGNyaXRlcmlhLiAgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBp dCBpcyBldmVuIGNsb3NlLCBhcw0KPiAgICAgbG9uZyBhcw0KPiAgICAgID4NCj4gICAgICA+ICA+ IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy4NCj4gICAgICA+DQo+ICAgICAgPiAgPg0KPiAg ICAgID4NCj4gICAgICA+ICA+IEJ1dCB3aGF0IGlmIHRoZSBub2RlIHdlcmUgYSBGaXJld2FsbCwg aW5jbHVkZWQgdG8gbWVldCBsZWdhbA0KPiAgICAgID4gcmVxdWlyZW1lbnRzPw0KPiAgICAgID4N Cj4gICAgICA+ICA+IE9yIHdhcyBzb21lIG90aGVyIG5lY2Vzc2FyeSBwcm9ncmFtbWF0aWMgdHJh bnNmb3JtICh3aW5jZSB3ZSBhcmUNCj4gICAgICA+DQo+ICAgICAgPiAgPiBkZWxpYmVyYXRlbHkg dmFndWUgYWJvdXQgd2hhdCBub2RlcyBjYW4gZG8gd2hlbiBhc2tlZCBzdWl0YWJseS4pDQo+ICAg ICAgPg0KPiAgICAgID4gID4NCj4gICAgICA+DQo+ICAgICAgPiAgPiBJcyB0aGVyZSBzb21lICJj YW4gYmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmcNCj4gICAgICA+DQo+ICAg ICAgPiAgPiBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPw0KPiAgICAgID4NCj4gICAgICA+ ICA+DQo+ICAgICAgPg0KPiAgICAgID4gID4gVGhhbmsgeW91LA0KPiAgICAgID4NCj4gICAgICA+ ICA+IFlvdXJzLA0KPiAgICAgID4NCj4gICAgICA+ICA+IEpvZWwNCj4gICAgICA+DQo+ICAgICAg PiAgPg0KPiAgICAgID4NCj4gICAgICA+ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ICAgICAgPg0KPiAgICAgID4gID4gc3ByaW5nIG1haWxpbmcg bGlzdA0KPiAgICAgID4NCj4gICAgICA+ICA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIDxtYWlsdG86c3ByaW5n QGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcl MjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnPj4+DQo+ICAgICAgPg0KPiAgICAgID4gID4NCj4g ICAgICA+DQo+ICAgICBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6 Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1Mj4NCj4gICAgICA+DQo+ ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVB dlA0NkgyP3U9aHR0cHMlM0ElMjUyPg0KPiAgICAgID4NCj4gICAgICA+ICA+IEYlMkZ3d3cuaWV0 Zi5vcmcNCj4gICAgIDxodHRwOi8vMkZ3d3cuaWV0Zi5vcmc+JTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGc3ByaW5nDQo+ICAgICAgPg0KPiAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+DQo+ICAgICAgPiBzcHJpbmcgbWFpbGluZyBs aXN0DQo+ICAgICAgPg0KPiAgICAgID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0K PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAg ICBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2 SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZw0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiAgICAgID4gTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFu eSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0KPiAgICAgID4gaW5mb3JtYXRpb24gb2YgUmliYm9u IENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwNCj4gICAgIGFuZC9vcg0K PiAgICAgID4gcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LiBBbnkgcmV2aWV3LA0KPiAgICAgID4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlz dHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQNCj4gICAgICA+IGV4cHJl c3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUN Cj4gICAgIGludGVuZGVkDQo+ICAgICAgPiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsDQo+ICAgICAgPiBjb3BpZXMsIGlu Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMuDQo+ICAgICAgPg0KPiAgICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ICAgICAgPg0KPiAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gICAgICA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgICA+IHNwcmlu Z0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9y Zz4NCj4gICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n DQo+ICAgICAgPg0KPg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgIHNwcmluZ0BpZXRm Lm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4g ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFp bGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo= --_000_a5193b2356c745ac8bd56c1958631f16huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRh aG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7DQoJcGFu b3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDlvq7ova/pm4Xpu5EiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhpIGFsbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUgb2Jq ZWN0aXZlIGFuZCBjb25zdHJhaW50IHdpdGggU1IgZXhwbGljaXQgcGF0aCAoYWthLiBURSkgYW5k IFNSIGxvb3NlIHBhdGggbWF5IGJlIGRpZmZlcmVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBaaGVucWlh bmcgbWVudGlvbmVkLCBhbiBTUi1URSBwYXRoIHdpdGggYSBsaXN0IG9mIGFkai9FbmQuWCBTSURz IHJlZmxlY3RzIHRoZSBwb2xpY3kgb2YgdGhlIGNvbnRyb2xsZXIgb3IgdGhlIGhlYWRlbmQgbm9k ZSwgd2hpY2ggbWF5IGltcGx5IHRoYXQNCiBhIGJhY2t1cCBwYXRoIHRoYXQgY2FuIG1lZXQgdGhl IHNhbWUgcG9saWN5IHVzdWFsbHkgaXMgYWxzbyBwcm92aWRlZCBieSB0aGUgY29udHJvbGxlciBv ciBoZWFkZW5kIG5vZGUuIFdoaWxlIGRlcGVuZHMgb24gdGhlIHBvbGljeSwgbG9jYWwgcHJvdGVj dGlvbiBtYXkgc3RpbGwgYmUgaGVscGZ1bC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBhbiBTUiBwYXRoIGlz IGJ1aWx0IHdpdGggb25lIG9yIGEgbGlzdCBvZiBwcmVmaXgtU0lEcywgdGhlIHByZWZpeC9FbmQg U0lEcyBhcmUgdXNlZCB0byByZXByZXNlbnQgc29tZSBwb2xpY3kvY29uc3RyYWludHMgd2hpY2gg Y2FuIGJlIHVuZGVyc3Rvb2QNCiBieSBib3RoIHRoZSBjb250cm9sbGVyLCB0aGUgaGVhZGVuZCwg YW5kIGF0IGxlYXN0IHNvbWUgaW50ZXJtZWRpYXRlIG5vZGVzLCB0aHVzIGl0IGlzIHBvc3NpYmxl IGFuIGludGVybWVkaWF0ZSBub2RlIGNhbiBwcm92aWRlIGEgbG9jYWwgcHJvdGVjdGlvbiB3aGlj aCBzdGlsbCBtZWV0IHRoZSBwb2xpY3kvY29uc3RyYWludHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmllPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc3ByaW5nIFttYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmxpX3poZW5xaWFuZ0Bob3Rt YWlsLmNvbTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgNCwgMjAyMCAxMjoxNCBQ TTxicj4NCjxiPlRvOjwvYj4gSm9lbCBNLiBIYWxwZXJuICZsdDtqbWhAam9lbGhhbHBlcm4uY29t Jmd0OzsgUm9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJhc3p1ay5uZXQmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ SGkgSm9lbCBhbmQgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5JIHRoaW5rIFRFIHBhdGggc2hvdWxkIGJlIGNvdXBsZWQgd2l0aCBlbmQgdG8gZW5k IHByb3RlY3Rpb24uIEl0IGlzIG5vdCBwcnVkZW50IHRvIGFsbG93IG5vZGUgb3IgbGluayBwcm90 ZWN0aW9uIGluIGEgVEUgcGF0aCBzaW5jZSB0aGUgbG9jYWwgcHJvdGVjdGlvbg0KIG1heSBub3Qg c2F0aXNmeSB0aGUgU0xBIHJlcXVpcmVtZW50cyBvciB0aGUgcGF0aCBjb25zdHJhaW5zLiBJbiBm YWN0IHRoZSBub2RlIGVuLXJvdXRlIGV4Y2VwdCB0aGUgaGVhZGVuZCBhbmQgdGhlIGNvbnRyb2xs ZXIgaGFzIG5vIGlkZWEgYWJvdXQgdGhlIFNMQSByZXF1aXJlbWVudHMgYW5kIHRoZSBwYXRoIGNv bnN0cmFpbnMuIFRFIHBhdGggb25seSBjYW4gYmUgcmVvcHRpbWl6ZWQgb3IgcmVidWlsdCBlbmQg dG8gZW5kIGJ5IHRoZSBoZWFkZW5kDQogb3IgdGhlIGNvbnRyb2xsZXIgaWYgeW91IHdhbnQgeW91 ciBTTEEgcmVxdWlyZW1lbnRzIGFuZCBwYXRoIGNvbnRyYWlucyBiZSBzYXRpc2ZpZWQuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkluIG15IG9w aW5pb24sIGl0IGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8gdXNlIGxvY2FsIHByb3RlY3Rpb24gaW4g SVAgZm93YXJkaW5nIHNjZW5hcmlvcyByYXRoZXIgdGhhbiBURSBvciBwb2xpY3kgcGF0aHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkJlc3QgUmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlpoZW5x aWFuZyBMaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGhy IHNpemU9IjEiIHdpZHRoPSIyMTAiIHN0eWxlPSJ3aWR0aDoxNTcuNXB0IiBub3NoYWRlPSIiIHN0 eWxlPSJjb2xvcjojQjVDNERGIiBhbGlnbj0ibGVmdCI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ny41cHQ7bWFyZ2luLXRvcDo3LjVwdDttYXJnaW4tcmln aHQ6Ny41cHQ7bWFyZ2luLWJvdHRvbTo3LjVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFp bHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbSI+bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDo2LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VG RUZFRiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPkpvZWwNCiBNLiBIYWxwZXJuPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5EYXRlOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzIwMjAtMDgtMDQmbmJzcDswMjozNTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5U bzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiPlJvYmVydA0KIFJhc3p1azwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Q0M6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5n QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwO1JlOiBbc3ByaW5nXQ0KIFNwcmlu ZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4o U2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCByZWl0ZXJhdGluZyB0aGF0 IHRoaXMgaXMgYXMgYQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5wYXJ0aWNpcGFudCwgbm90IGEgV0cgY2hhaXIuKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5ZZXMsIHdlIGFyZSB0YWxraW5nIElQIG5ldHdv cmtzLiZuYnNwOyBBbmQgeWVzLCBJIGhhdmUgc2VlbiBJUCBuZXR3b3JrcyB0aGF0DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmNob29zZSB0byBkcm9w IHBhY2tldHMuJm5ic3A7IEZvciBhbGwgc29ydHMgb2YgcmVhc29ucy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgdGhpbmsgdGhlcmUgYXJlIGxpa2Vs eSBvdGhlciByZWFzb25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9tDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnBhdGggcmF0aGVyIHRoYW4g YSBjaG9zZW4gVEUgcGF0aC4mbmJzcDsgSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xl YXINCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YWJv dXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlvbGF0ZWQgd2hlbiB3ZSB0ZWxsIHBl b3BsZSB0aGV5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPmhhdmUgdGhpcyB0b29sIChwcm90ZWN0aXZlIHJlcm91dGluZykgdGhhdCBpcyBpbnRlbmRl ZCB0byBwcmVzZXJ2ZSBRb1MuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5MZXQncyBiZSBjbGVhci4mbmJzcDsgSSBhbSBub3QgYXJndWluZyB0aGF0IHRo aXMgaXMgbm90IGEgZ29vZCBpZGVhLiZuYnNwOyBJdCBpcyBhDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmdvb2QgaWRlYS4mbmJzcDsgQW5kIHVzZWZ1 bC4mbmJzcDsgSSBhbSB0cnlpbmcgdG8gZmlndXJlIG90dSB3aGF0IGNvbWJpbmF0aW9uIG9mDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmFkZGl0aW9u YWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVyeW9u ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5nZXR0 aW5nIHRoZSBiZWhhdmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5vdCBiZSB0aGUgYmVoYXZp b3IgdGhleQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5kZXNpcmUsIGJ1dCBzb21ldGltZXMgaXMgdGhlIGJlc3Qgd2UgY2FuIGRvLik8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+WW91cnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Kb2VsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9uIDgvMy8yMDIwIDI6MzAgUE0sIFJv YmVydCBSYXN6dWsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7IEpvZWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZndDsgQXJlIHdlIHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya3Mm bmJzcDtoZXJlID8gT3IgcGVyaGFwcyBzb21lIGhhcmQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBzbGljaW5nIHdpdGggcmVhbCByZXNvdXJj ZSByZXNlcnZhdGlvbnMgb3IgZGV0bmV0cyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsgQmVjYXVzZSZuYnNwO2lmIHdlIGFyZSB0YWxraW5nJm5i c3A7YWJvdXQgSVAgbmV0d29ya2luZyBJIGhhdmUgdHdvIG9ic2VydmF0aW9uczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyBBKSBJZiB5b3UgbmVl ZCB0byB0cmF2ZXJzZSB2aWEgYSBzcGVjaWZpYyBub2RlIChpZS4gZmlyZXdhbGwpIHlvdSBiZXR0 ZXINCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyBhcHBseSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4gSSBkb24ndCB0aGluayBJUCBl bmNhcHN1bGF0aW9uJm5ic3A7Y2FuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsgYmUgaGlqYWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRlc3RpbmF0 aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpcyBpZ25vcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IEIpIEhhdmUgeW91IHNlZW4gYW55IElQ IG5ldHdvcmsgd2hlcmUgdXBvbiB0b3BvbG9neSBjaGFuZ2UgKGxpbmsgb3Igbm9kZQ0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IGZhaWx1cmUp IHlvdSBzdWRkZW5seSZuYnNwO3N0YXJ0IGRyb3BwaW5nJm5ic3A7Zmxvd3MgaW4gc3BpdGUgb2Yg U1BUIG9mZmVyaW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsgcGVyaGFwcyBmZXcgbXMgbG9uZ2VyIHBhdGggd2l0aCAxMCBtcyBtb3JlIGpp dHRlciA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsgT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNsaWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0 d29ya3MgaW4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jmd0OyBzb21ldGhpbmcmbmJzcDtuZXcgPyBXb3JzZSAuLi4gZG8gdGhleSBtZW50aW9uIHBh dGggcXVhbGl0eSBndWFyYW50ZWVzLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IHJlc291cmNlIHJlc2VydmF0aW9ucyZuYnNwOz8gSSBob3Bl IG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyBUaHgsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7IFIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7IE9uIE1v biwgQXVnIDMsIDIwMjAgYXQgODoxMCBQTSBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFs cGVybi5jb20NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPm1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFdlbGwgbGVzcyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRoZSBwcm9ibGVt IGlzIHJlc3RyaWN0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8ganVzdCBzZXJ2aWNlIFNJRHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0 aGUgcGF0aCB0byBtZWV0IHNvbWUgY29tcGxleCB0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvYmpl Y3RpdmUuJm5ic3A7IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dpbmcgd2hhdCB0 aG9zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25zdHJhaW50czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB3ZXJlLiZuYnNwOyBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywgaXQgaXMgYmV0dGVy IHRvIGRyb3AgdGhlIHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGFuIHRvIGRlbGl2ZXIg aXQgb3V0c2lkZSB0aGUgZW52ZWxvcC4mbmJzcDsgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuc3dlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byB0aGlzIGlz ICZxdW90O3RvbyBiYWQmcXVvdDsuJm5ic3A7IElmIHNvLCBhcyB3aXRoIHRoZSBkaXN0aW5jdGlv biByZWdhcmRpbmcgc2VydmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub2Rlcywgd2Ugc2hvdWxk IHNheSBzbywgc2hvdWxkbid0IHdlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlvdXJzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gOC8zLzIwMjAgMjozNiBB TSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgTWFjaCwgSm9lbCBhbmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSSB0aGluayB0aGF0IGluIG1vc3QgY2Fz ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuICZxdW90 O3RvcG9sb2dpY2FsJnF1b3Q7IGFuZCAmcXVvdDtzZXJ2aWNlJnF1b3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgaW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5n Ljo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IG9JR1AgUHJlZml4IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZpZWQg YXMgc3VjaCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjb3JyZXNwb25k aW5nIElHUCBhZHZlcnRpc2VtZW50cykgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9u czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgb1NlcnZpY2UgU0lEcyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92ZXJs YXkgU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNDwvYT4mZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBkcmFmdCkgdW5zdXJwcmlzaW5nbHkgcmVw cmVzZW50DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKAnDxzcGFu IGxhbmc9IkVOLVVTIj5zZXJ2aWNlPC9zcGFuPuKAnTxzcGFuIGxhbmc9IkVOLVVTIj4gaW5zdHJ1 Y3Rpb25zPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgMi5TZWdtZW50cyB0aGF0IHJlcHJlc2VudCB0b3BvbG9naWNh bCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5cGFzc2VkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IHdoaWxlIHNlZ21lbnRzIHRoYXQgcmVwcmVzZW50IHNlcnZpY2UgaW5zdHJ1Y3Rpb25z IHJlcXVpcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWx0ZXJuYXRpdmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBwcm90ZWN0aW9uIG1lY2hhbmlzbXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBUaGlzIHZpZXcg c2VlbXMgdG8gYmUgYWxpZ25lZCB3aXRoIFJGQyA4NDAyPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAy Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQwMjwvYT4mZ3Q7IHRoYXQgc2F5cyBp biBTZWN0aW9uIDE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2Yg YW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG9wb2xv Z2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNlZ21lbnQgYW5k IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IElHUC1QcmVmaXggc2VnbWVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jm5ic3A7ICZuYnNwOyZuYnNwOyBJbiB0aGUgY29udGV4dCBvZiBhIEJHUC1iYXNlZCBkaXN0cmli dXRlZCBjb250cm9sIHBsYW5lLCB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBk ZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBhbmQgdGhlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgQkdQLVByZWZpeCBzZWdtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSW4gdGhlIGNhc2Ugb2YgU1ItTVBM UyB0aGlzIGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMy40IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhlIE5vZGUg UHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNy LXRlLXBhdGhzLTA3I3NlY3Rpb24tMy40Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhz LTA3I3NlY3Rpb24tMy40PC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGRy YWZ0IHRoYXQgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgbm9kZSBwcm90ZWN0 aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb25zPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZu YnNwOyAmbmJzcDsmbmJzcDsgZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBsYWJl bCBpbW1lZGlhdGVseSBiZWxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgdG9wPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBs YWJlbCBpbiB0aGUgbGFiZWwgc3RhY2sgaXMgdW5kZXJzdG9vZCBpbiB0aGUgSUdQIGRvbWFpbi4m bmJzcDsgV2hlbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBwcm92aWRlciBlZGdlIHJv dXRlcnMgZXhjaGFuZ2Ugc2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBzb21lPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG90aGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgbm9uLUlHUCBtZWNoYW5p c20gdGhlIGJvdHRvbSBsYWJlbCBpcyBub3QgdW5kZXJzdG9vZCBpbiB0aGUgSUdQPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZu YnNwOyAmbmJzcDsmbmJzcDsgZG9tYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IFRoZSBl Z3Jlc3Mgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IFtSRkM4Njc5ICZsdDs8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg2NzkiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvcmZjODY3OTwvYT4mZ3Q7XSBpczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IGFwcGxpY2FibGUgdG8gdGhpcyB1c2UgY2FzZSBhbmQgbm8gYWRkaXRpb25h bCBjaGFuZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgd2lsbCBiZSByZXF1aXJlZCBmb3Ig U1IgYmFzZWQgbmV0d29ya3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRoZSBzY2VuYXJpb3MgaW4gd2hpY2ggJm5ic3A7ZGlm ZmVyZW50aWF0aW9uIGJldHdlZW4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+4oCcPHNwYW4gbGFuZz0iRU4tVVMiPnRvcG9sb2dpY2FsPC9zcGFuPuKAnTxzcGFuIGxh bmc9IkVOLVVTIj4gYW5kPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKAnDxzcGFuIGxhbmc9IkVO LVVTIj5zZXJ2aWNlPC9zcGFuPuKAnTxzcGFuIGxhbmc9IkVOLVVTIj4gaW5zdHJ1Y3Rpb25zIGlz IGJyb2tlbiBhcmUgaW5kZWVkIHByb2JsZW1hdGljLiBFLmcuLDxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgY29uc2lkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0aGUgdXNl IGNhc2UgaW4gd2hpY2ggYSBOb2RlIFNJRCBpbiB0aGUgRVJPIG9mIGEgU1ItVEUgcGF0aDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpZGVudGlmaWVzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBub2RlIHRoYXQgYWN0cyBhcyBhIGZpcmV3YWxsIGZvciBhbGwgcGFja2V0cyBpdCByZWNl aXZlcywgaS5lLiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdmlkZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRob3V0IGFueSBkZWRpY2F0 ZWQgc2VydmljZSBTSUQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpZnlpbmcgaXQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgT25lIGNvdWxkIHNheSB0aGF0IHRoZSBOb2RlIFNJ RCBvZiBzdWNoIGEgbm9kZSB3b3VsZCBjb21iaW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvcG9s b2dpY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYW5kIHNlcnZpY2UgaW5zdHJ1 Y3Rpb25zIHRodXMgYnJlYWtpbmcgdGhlIGRpZmZlcmVudGlhdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBiZXR3ZWVuIHRoZSB0d28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJIGFtIG5vdCBzdXJlIGlmIHVzYWdlIG9mIHN1 Y2gNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCcPHNwYW4gbGFu Zz0iRU4tVVMiPmNvbWJpbmVkPC9zcGFuPuKAnTxzcGFuIGxhbmc9IkVOLVVTIj4gU0lEcyBjb3Vs ZCBiZSBwcmV2ZW50ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIGF0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbGVhc3QgZGlzY291cmFnZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJZiBub3Qs IHByb3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50aWZ5IHN1Y2ggU0lEcyBpbiB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYWR2ZXJ0aXNlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IG1lY2hhbmlzbXMgd291bGQgYmUgdXNlZnVsIElNSE8uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBNeSAyYyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IFNhc2hhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBPZmZpY2U6ICYjNDM7OTcyLTM5MjY2MzAyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBDZWxsOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOzk3Mi01NDkyNjYzMDI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEVtYWls Og0KPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSI+bWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgRnJvbTog c3ByaW5nICZsdDtzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgT24gQmVoYWxmIE9mIE1hY2ggQ2hlbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMsIDIwMjAg NjozMCBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRvOiBKb2VsIE0uIEhhbHBl cm4gJmx0O2ptaEBqb2VsaGFscGVybi5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bTwvYT4mZ3Q7Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0Bp ZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpz cHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFN1 YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxp Y2FiaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IEhpIEpvZWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIHBv aW50IHRoYXQgbWF5IG5vdCBiZSBkaXNjdXNzZWQgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHBhc3QuIEFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEkgYWxzbyBkb24ndCB0 aGluayB0aGVyZSBpcyBhICZxdW90O2NhbiBiZSBieXBhc3NlZCZxdW90OyBpbmRpY2F0aW9uIGlu IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHJvdXRpbmcgYWR2ZXJ0aXNlbWVu dCBmb3Igbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgSU1ITywgdGhlIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgYnkgcm91 dGluZyBpcyBuZXV0cmFsLCBzdWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQp IGlzIG1vcmUgcGF0aCBzcGVjaWZpYywgdGh1cyBub3JtYWxseSB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBjb250cm9sbGVyIHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgZGVj aWRpbmcgd2hldGhlci93aGljaCBTSUQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FuIGJlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYnlwYXNzZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBCZXN0IHJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBNYWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZuYnNwOyAmZ3Q7IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XSBP biBCZWhhbGYgT2YgSm9lbCBNLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsgJmd0OyBIYWxwZXJuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNw OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMsIDIwMjAgNzo1MSBBTTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsg Jmd0OyBUbzoNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdA aWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJp bmdAaWV0Zi5vcmcgJmx0O21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jm5ic3A7ICZndDsgU3ViamVjdDogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1p bmluZyBhcHBsaWNhYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmZ3Q7IChX RyBDaGFpciBoYXQgT2ZmLCB0aGlzIGlzIG1lcmVseSBhIG5vdGUgZnJvbSBhIHNsaWdodGx5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZ1c2VkIFdHPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmZ3Q7IHBhcnRpY2lw YW50Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDsgSSBoYXZlIGJlZW4gcmVh ZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5i c3A7ICZndDsgbmV0d29ya3MgcHJvZ3JhbW1pbmcgYW5kIHNlcnZpY2UgcHJvZ3JhbW1pbmcgZHJh ZnQsIGFuZCBJIGFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyeWluZyB0bzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsg Jmd0OyBmaWd1cmUgb3V0IG9uZSBhc3BlY3Qgb2YgdGhlIGNvbWJpbmF0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJz cDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmbmJzcDsgJmd0OyBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBz b21lIGZvcm0gb2YgYnlwYXNzIChzdXBwb3NlLCBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDsgc2ltcGxp Y2l0eSwgaXQgaXMgTm9kZSBOMiBkZWNpZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhIGZhaWxlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsgJmd0OyBub2RlIE4zKSBr bm93IHRoYXQgaXQgaXMgc2FmZSB0byBkbyBzbz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5i c3A7ICZndDsgSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0IGlzICZxdW90O3Nh ZmUmcXVvdDsgaWYgdGhlIG5ldyBwYXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lZXRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZuYnNwOyAmZ3Q7IHRoZSBURSBjcml0ZXJpYS4mbmJzcDsgb3IgbWF5YmUgaXQgaXMgc2FmZSBp ZiBpdCBpcyBldmVuIGNsb3NlLCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb25nIGFzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZuYnNwOyAmZ3Q7IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jm5ic3A7ICZndDsgQnV0IHdoYXQgaWYgdGhlIG5vZGUgd2VyZSBhIEZpcmV3YWxs LCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg cmVxdWlyZW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsgJmd0OyBPciB3YXMgc29tZSBvdGhlciBuZWNlc3Nh cnkgcHJvZ3JhbW1hdGljIHRyYW5zZm9ybSAod2luY2Ugd2UgYXJlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmZ3Q7 IGRlbGliZXJhdGVseSB2YWd1ZSBhYm91dCB3aGF0IG5vZGVzIGNhbiBkbyB3aGVuIGFza2VkIHN1 aXRhYmx5Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDsgSXMgdGhlcmUgc29t ZSAmcXVvdDtjYW4gYmUgYnlwYXNzZWQmcXVvdDsgaW5kaWNhdGlvbiBpbiB0aGUgcm91dGluZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmbmJzcDsgJmd0OyBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJz cDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmbmJzcDsgJmd0OyBUaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmZ3Q7IFlv dXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmbmJzcDsgJmd0OyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyAmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNw OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZuYnNwOyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDsNCjxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+ Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmcg Jmx0O21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVB dlA0NkgyP3U9aHR0cHMlM0ElMjUyIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0 dHBzJTNBJTI1MiI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5 dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7ICZndDsgRiUy Rnd3dy5pZXRmLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cDovLzJG d3d3LmlldGYub3JnIj5odHRwOi8vMkZ3d3cuaWV0Zi5vcmc8L2E+Jmd0OyUyRm1haWxtYW4lMkZs aXN0aW5mbyUyRnNwcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsg Jmx0O21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0 OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyI+DQpodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdp dGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBj b25maWRlbnRpYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kL29yPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2Fy ZGluZyB3aXRob3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgZXhwcmVzcyBwZXJt aXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpbnRlbmRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRl bGV0ZSBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjb3BpZXMsIGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0K PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwv YT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsNCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0 Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwcmluZyBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNw cmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5zcHJpbmcgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn Ij5zcHJpbmdAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a5193b2356c745ac8bd56c1958631f16huaweicom_-- From nobody Tue Aug 4 00:55:04 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D763A0C00 for ; Tue, 4 Aug 2020 00:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 qlWYf9I91s7y for ; Tue, 4 Aug 2020 00:54:58 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB313A0A09 for ; Tue, 4 Aug 2020 00:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1596527697; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mJ5n7eGsS165tsUvpHlDd30uOwosR1qa13hh/wMjjkk=; b=UjCtymRRncdoQiRnH4a83LOOOsxdxoLOnYnxAqoPizMZLkhYC3HoWfJ5FfXIo1L4SNL7vd 6g4+sx+B5rrd+FTFu3M3uQv84PF+I/K/4LtFXOTe1YVMpBSoB8Tf16aQWXU+GkKrzZzu9C KarNeCXpR7WU0LcvighDnMm/oOBdPxo= Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-4QSgWfEvNHCPtsK118uU7Q-3; Tue, 04 Aug 2020 03:54:55 -0400 X-MC-Unique: 4QSgWfEvNHCPtsK118uU7Q-3 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (104.47.9.58) by AZWPVEXEdge02.ecitele.com (10.0.2.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Tue, 4 Aug 2020 10:54:50 +0300 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR03MB4082.eurprd03.prod.outlook.com (2603:10a6:208:70::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Tue, 4 Aug 2020 07:54:48 +0000 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1]) by AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1%6]) with mapi id 15.20.3239.021; Tue, 4 Aug 2020 07:54:48 +0000 From: Alexander Vainshtein To: Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "spring@ietf.org" , "Joel M. Halpern" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JCAAMsLAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAD7UQ Date: Tue, 4 Aug 2020 07:54:48 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.183.63.9] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5362b2b1-9a7b-47fe-52b6-08d8384ba976 x-ms-traffictypediagnostic: AM0PR03MB4082: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /QtIyWmDBvs/n+4Xig0XCG2jQIXcPuqnfkyD+I+X/6PKIII6PIt/DndOQBU9kI2Qo9uEZyuLnEHGZqjI31swQM+h7qwNk67RpNdX60LKDoJ8r7WxlbPEcDmqI8oyS0Kx0xtjAOaOPfFUNYdKWdXNAhY5dFO9L1EM8kQXMyaIGmN4HbM6xKKYkpCIKOZOxumVfOh/ed2WuB1/kGElIf7xlqXRK4p6IebEyQ5g1va1YjgYYVhMW2fQCpOXfmMbYraxFs2Yj0TAZKlxNkGJuTnddlLPcNYeZfeyqQxqkRSnRrxmdXBeUdR2RqDL3tAOfAeEEzoh6QbGVTAs3iaUFqNCaZgbFPAG2tkJz7JONkAj5QxiBI1XntbMpU3EAIMTAmxgYmUX8R4+YAUWJfvUUl5yI86bfMP7HazH6cQH5+0NY/TS3zd5/x9IsuL9kyMKC6nZ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4499.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(136003)(376002)(366004)(316002)(110136005)(53546011)(7696005)(2906002)(33656002)(26005)(966005)(8676002)(6506007)(8936002)(71200400001)(54906003)(4326008)(186003)(478600001)(30864003)(86362001)(64756008)(83380400001)(66476007)(52536014)(5660300002)(55016002)(66446008)(66946007)(9686003)(66556008)(76116006)(166002)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: l1v0nZ85vMXDfE0sI+tE/Xk4EutkeQLooHRy6Csm73Pyz4OcmE2fVuDNtxvkNXEWPUXGkmoQXMzlCBlZIZBlHn67ij9foC7MF0DYn+xfoGm86I7X0aZ7HMwhzrQG5AwFORoHmh8oNrmShW3HO69Tdhoc6IwSbbszJySn5jaWzQsYMXR1frnhx+7dBCb74sqGx4s6SBl45VH9tqp0Q0VZ1Qi/iAakuMIqIHpiP6EomGk0wY0Se5JiN5ZkJT8HvQFwEN5UKqDVah6BFUzIAXxFZZihpbTrPxSpVrFiSQKTi1+aPNyZEJxF8SpzQsT2VS4b+T10Ls2HAG1q7blECKD6YHxiilmlDDp9ahz2aVGysTUBB4axiRCytX/Iot3zX1AZive/hPqxBzSbuDm8WTRB+FewfS+Gcs32cF4SdgK6jlPkwSvBpcvNNvUndz8ThWZ43iOyk1/fIwuVnR2C89oTnO0YxfcfOP1wB9fVS7pB04ifEYHC1WDbOd6Gultj4cj5g1Uy8N3RBYiNGYRloCtAlIGtBLYCsMyL09fM39Qv31L3fOtGruSPuan8D+g3AI7fh3jeDuGZ6csLvjY5wD7AO4Psr0THy/+/aK2L37sAeRvNVBSUGuihrj53GlKWXaP78kAlPAxfg+cVtZgnNeP8KQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4499.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5362b2b1-9a7b-47fe-52b6-08d8384ba976 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 07:54:48.9182 (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-CrossTenant-userprincipalname: 3ti1ObYjiPbdA5vUU8J9OdKfzaJ9HXGo7lBgXOvmQjPdcvgB2ALNW1mGGv6zigXhW7INjgFF0yZXi++fmVtsmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4082 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_AM0PR03MB449907B6175A572E73B6D0389D4A0AM0PR03MB4499eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 07:55:02 -0000 --_000_AM0PR03MB449907B6175A572E73B6D0389D4A0AM0PR03MB4499eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I am still not sure that the problem of bypass going thru undesirable links= /nodes exists in the case of topological SIDs. AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090) has been successfully deployed for many years before SR-MPLS= has been introduced. What's more, signaling of bypass tunnels he PLR usual= ly did not include any of the constraints used for computing of any specifi= c LSP that the bypass LSP would protect - because in the Facility Protectio= n mode the same bypass LSP would be used to protect multiple LSPs passing t= hru the failed link/node. >From my POV the only difference between this behavior and that introduced b= y the "bypassing" drafts in SR is that, in the case of RSVP-TE, the operato= r would explicitly indicate, as part of LSP signaling, whether it would or = would not use FRR; LSPs that would not use FRR would then drop traffic rath= er than delivering it the wrong way. Such an option indeed does not exist in SR-TE today, but would be easy to p= rovide if so desired IMHO. Did I miss something substantial? Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: spring On Behalf Of Shraddha Hegde Sent: Tuesday, August 4, 2020 9:41 AM To: EXT-Andrew.Alston@liquidtelecom.com ; = Robert Raszuk Cc: spring@ietf.org; Joel M. Halpern Subject: Re: [spring] Spring protection - determining applicability All, This is a very interesting discussion and thanks to Joel for starting this = discussion. IMO, when there are strict requirements of avoiding certain nod= es/links it can be realized either by defining a flex-algo avoiding those Nodes and links or by using a stack of unprotected adj-sids that avoid rest= ricted nodes and links. When a stack of adj-sids is used to realize the pat= h, the head-end based (sBFD) protection mechanisms can be applied. If Node-sids/prefix-sid/anycast-sids are used to build the stack, the failu= re events may cause traffic to go through restricted nodes and links. This = would happen regardless of whether any kind of protection is in use or not. Rgds Shraddha Juniper Business Use Only From: spring > On B= ehalf Of Andrew Alston Sent: Tuesday, August 4, 2020 5:41 AM To: Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability [External Email. Be cautious of content] Robert this is actually far more difficult when - it can be an entire (long= ) series of nodes that need to be avoided. It could potentially be made to work but I'd worry that to do this - you'd = have to stack 10 - 20 - 30 negative labels - and that wouldn't be viable. It's easier to use algorithms and adjacency sids and other such things to c= alculate paths - the biggest trick is about the stack depth. When you have= this need for node avoidance - the need for 10+ label depth is critical - = unless you wanna be applying one hell of a lot of binding labels along the = way which is a nightmare. But to answer your question, is this a common use case - it's a use case th= at most of the people I discuss this with certain have - I cant comment on= a global scale, or for anyone else, but every indication I have is that ye= s - its something people need, and want Andrew From: Robert Raszuk > Sent: Tuesday, 4 August 2020 01:27 To: Andrew Alston > Cc: Joel M. Halpern >; spri= ng@ietf.org Subject: Re: [spring] Spring protection - determining applicability Is this a common use case ie. "but rather - which nodes / network segments= it can never touch or flow through." If so perhaps its time to define notion of negative-SID ie. list in the pac= ket resources which given packet MUST not ever traverse. Put in the packet set of nodes or links which the packet should never trave= rse. That goes in line of recent wave of negative routing implementations (RIFT)= or discussions (LSR) Best, R. On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > wrote: So - One of the use cases, in fact, some very major use cases in any spring tech= nology for us revolve around the following a. The explicit avoidance of certain nodes b. The explicit avoidance of certain sections of the network Anything that could result in that explicit avoidance being violated - woul= d create, shall we say significant problems. Much of the use case is not a case of which nodes the packets flow through = - but rather - which nodes / network segments it can never touch or flow th= rough. Effectively, to be used as a technology to avoid certain things for= specific reasons. This is also one of the reasons for needing such deep label stacks - this k= ind of detailed path programming tends to deepen the stack because you some= times have to be pretty explicit. It is absolutely critical to us that this functionality is there - and that= we can avoid situations which could cause traffic to accidently hit things= explicitly avoided. I wish I could be more specific than this, but it is what it is. Thanks Andrew From: spring > On B= ehalf Of Joel M. Halpern Sent: Monday, 3 August 2020 21:36 To: Robert Raszuk > Cc: spring@ietf..org Subject: Re: [spring] Spring protection - determining applicability (Since the thread has gotten long enough, reiterating that this is as a participant, not a WG chair.) Yes, we are talking IP networks. And yes, I have seen IP networks that choose to drop packets. For all sorts of reasons. I think there are likely other reasons why one may not want a random path rather than a chosen TE path. I think it is important we be clear about what constraints may be / are violated when we tell people they have this tool (protective rerouting) that is intended to preserve QoS. Let's be clear. I am not arguing that this is not a good idea. It is a good idea. And useful. I am trying to figure otu what combination of additional mechanisms and clear descriptions will lead to everyone getting the behavior they expect (which may not be the behavior they desire, but sometimes is the best we can do.) Yours, Joel On 8/3/2020 2:30 PM, Robert Raszuk wrote: > Joel, > > Are we still talking about IP networks here ? Or perhaps some hard > slicing with real resource reservations or detnets ? > > Because if we are talking about IP networking I have two observations: > > A) If you need to traverse via a specific node (ie. firewall) you better > apply IP encapsulation to that node. I don't think IP encapsulation can > be hijacked today such that destination address of the packet is ignored. > > B) Have you seen any IP network where upon topology change (link or node > failure) you suddenly start dropping flows in spite of SPT offering > perhaps few ms longer path with 10 ms more jitter ? > > Or are some SR marketing slides promise to turn IP networks in > something new ? Worse ... do they mention path quality guarantees, > resource reservations ? I hope not. > > Thx, > R. > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > wrote: > > Well less serious for TE SIDs, I am not sure the problem is restricted > to just service SIDs. > > Suppose that the PCE has specified the path to meet some complex te > objective. The bypass node has no way of knowing what those > constraints > were. And for some kinds of traffic, it is better to drop the packet > than to deliver it outside the envelop. I suspect that the right > answer > to this is "too bad". If so, as with the distinction regarding service > nodes, we should say so, shouldn't we? > > Yours, > Joel > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > Mach, Joel and all, > > > > I think that in most cases: > > > > 1.There is clear differentiation between "topological" and "service" > > instructions in SID advertisements. E.g.: > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > corresponding IGP advertisements) represent topological instructions > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > draft) unsurprisingly represent "service" instructions > > > > 2.Segments that represent topological instructions can be bypassed, > > while segments that represent service instructions require > alternative > > protection mechanisms. > > > > This view seems to be aligned with RFC 8402 > > > that says in Section 1= : > > > > In the context of an IGP-based distributed control plane, two > > > > topological segments are defined: the IGP-Adjacency segment and the > > > > IGP-Prefix segment. > > > > In the context of a BGP-based distributed control plane, two > > > > topological segments are defined: the BGP peering segment and the > > > > BGP-Prefix segment. > > > > In the case of SR-MPLS this differentiation is assumed in Section > 3.4 of > > the Node Protection for SR-TE Path > > > > > > > draft that says: > > > > The node protection mechanism described in the previous sections > > > > depends on the assumption that the label immediately below > the top > > > > label in the label stack is understood in the IGP domain. When the > > > > provider edge routers exchange service labels via BGP or some > other > > > > non-IGP mechanism the bottom label is not understood in the IGP > > > > domain. > > > > The egress node protection mechanisms described in the draft > > > > [RFC8679 >] is > > applicable to this use case and no additional changes > > > > will be required for SR based networks > > > > The scenarios in which differentiation between "topological" and > > "service" instructions is broken are indeed problematic. E.g., > consider > > the use case in which a Node SID in the ERO of a SR-TE path > identifies a > > node that acts as a firewall for all packets it receives, i.e., > provides > > the firewall service without any dedicated service SID > identifying it. > > One could say that the Node SID of such a node would combine > topological > > and service instructions thus breaking the differentiation > between the two. > > > > I am not sure if usage of such "combined" SIDs could be prevented > or at > > least discouraged. > > > > If not, providing an ability to identify such SIDs in the > advertisement > > mechanisms would be useful IMHO. > > > > My 2c, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > -----Original Message----- > > From: spring > > On B= ehalf Of Mach Chen > > Sent: Monday, August 3, 2020 6:30 AM > > To: Joel M. Halpern > >; spring@ietf= .org > > Subject: Re: [spring] Spring protection - determining applicability > > > > Hi Joel, > > > > I think this is a good point that may not be discussed in the > past. And > > I also don't think there is a "can be bypassed" indication in the > > routing advertisement for now. > > > > IMHO, the information advertised by routing is neutral, such > information > > (can or cannot be bypassed) is more path specific, thus normally the > > controller should be responsible for deciding whether/which SID > can be > > bypassed. > > > > Best regards, > > > > Mach > > > > > -----Original Message----- > > > > > From: spring [mailto:spring-bounces@ietf.org > ] On Behalf Of Joel M. > > > > > Halpern > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > To: spring@ietf.org > >> > > > > > Subject: [spring] Spring protection - determining applicability > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > confused WG > > > > > participant.) > > > > > > > > > > I have been reading the various repair drafts, and the various > > > > > networks programming and service programming draft, and I am > trying to > > > > > figure out one aspect of the combination. > > > > > > > > > > How does a node that is doing some form of bypass (suppose, for > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > a failed > > > > > node N3) know that it is safe to do so? > > > > > > > > > > If the path was just for TE, then it is "safe" if the new path > meets > > > > > the TE criteria. or maybe it is safe if it is even close, as > long as > > > > > it is not used for too long. > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > requirements? > > > > > Or was some other necessary programmatic transform (wince we are > > > > > deliberately vague about what nodes can do when asked suitably.) > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > advertisements that I missed? > > > > > > > > > > Thank you, > > > > > Yours, > > > > > Joel > > > > > > > > > > _______________________________________________ > > > > > spring mailing list > > > > > spring@ietf.org > >> > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2<= https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2= Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9= uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_= R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24> > > > > > > > > > F%2Fwww.ietf.org > >%2Fmailman%2Flistinfo%2Fspring > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > ------------------------------------------------------------------------ > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential > and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the > intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ---------------------------------------------------------------------------= -------------------------------------------- Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipie= nt. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly= prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies,= including any attachments. ---------------------------------------------------------------------------= -------------------------------------------- --_000_AM0PR03MB449907B6175A572E73B6D0389D4A0AM0PR03MB4499eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi all,

I am still not sure th= at the problem of bypass going thru undesirable links/nodes exists in the c= ase of topological SIDs.

 

AFAIK, Facility Protec= tion in RSVP-TE FRR (RFC 40= 90) has been successfully deployed for many years before SR-MPLS has be= en introduced. What’s more, signaling of bypass tunnels he PLR usually did not include any of the constraints us= ed for computing of any specific LSP that the bypass LSP would protect R= 11; because in the Facility Protection mode the same bypass LSP would be us= ed to protect multiple LSPs passing thru the failed link/node.

 

From my POV the only d= ifference between this behavior and that introduced by the “bypassing= ” drafts in SR is that, in the case of RSVP-TE, the operator would ex= plicitly indicate, as part of LSP signaling, whether it would or would not use FRR; LSPs that would not use FRR would then drop= traffic rather than delivering it the wrong way.

 

Such an option indeed = does not exist in SR-TE today, but would be easy to provide if so desired I= MHO.

 

Did I miss something s= ubstantial?

 

Regards, and lots of t= hanks in advance,

Sasha

 

Office: +972-39266302<= o:p>

Cell:   = ;   +972-549266302

Email:   Ale= xander.Vainshtein@ecitele.com

 

From: spring <spring-bounces@ietf.org> = On Behalf Of Shraddha Hegde
Sent: Tuesday, August 4, 2020 9:41 AM
To: EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtele= com.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

All,

 

This is a very interesting discussion and thanks to = Joel for starting this discussion. IMO, when there are strict requirements = of avoiding certain nodes/links it can be realized  either by defining= a flex-algo avoiding those

Nodes and links or by using a stack of unprotected a= dj-sids that avoid restricted nodes and links. When a stack of adj-sids is = used to realize the path, the head-end based (sBFD) protection mechanisms c= an be applied.

 

If Node-sids/prefix-sid/anycast-sids are used to bui= ld the stack, the failure events may cause traffic to go through restricted= nodes and links. This would happen regardless of whether any kind of prote= ction is in use or not.

 

Rgds

Shraddha

        &nbs= p;            &= nbsp;

 

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> On Behalf Of Andrew Alston
Sent: Tuesday, August 4, 2020 5:41 AM
To: Robert Raszuk <robert@ra= szuk.net>
Cc: spring@ietf.org; Joel M. = Halpern <jmh@joelhalpern.com&= gt;
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

<= span style=3D"font-size:10.5pt;font-family:Lato;color:black">[External Emai= l. Be cautious of content]

 

Robert this is actually far more difficult when R= 11; it can be an entire (long) series of nodes that need to be avoided.&nbs= p;

 

It could potentially be made to work but I’d w= orry that to do this – you’d have to stack 10 – 20 –= ; 30 negative labels – and that wouldn’t be viable.

 

It’s easier to use algorithms and adjacency si= ds and other such things to calculate paths – the biggest trick is ab= out the stack depth.  When you have this need for node avoidance ̵= 1; the need for 10+ label depth is critical – unless you wanna be applying one hell of a lot of binding labels along the way which = is a nightmare.

 

But to answer your question, is this a common use ca= se – it’s a use case that most of the people I discuss this wit= h certain have – I cant  comment on a global scale, or for anyon= e else, but every indication I have is that yes – its something people need, and want

 

Andrew

 

 

From: Robert Ras= zuk <robert@raszuk.net>
Sent: Tuesday, 4 August 2020 01:27
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Joel M. Halpern <jmh@j= oelhalpern.com>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

 

Is this a common use ca= se ie.  "but rather – which nodes / network segments it can= never touch or flow through."

 

If so perhaps its time = to define notion of negative-SID ie. list in the packet resources which given packe= t MUST not ever traverse. 

 

Put in the packet set o= f nodes or links which the packet should never traverse. 

 

That goes in line of re= cent wave of negative routing implementations (RIFT) or discussions (LSR)

 

Best,
R.

 

 

 

 

 

On Mon, Aug 3, 2020 at = 11:46 PM Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:

So –

 

One of the use cases, in fact, some very major use cases in any spring tech= nology for us revolve around the following

 

a.       The explicit avoidance of = certain nodes

b.       The explicit avoidance of = certain sections of the network

 

Anything that could result in that explicit avoidance being violated –= ; would create, shall we say significant problems.

 

Much of the use case is not a case of which nodes the packets flow through = – but rather – which nodes / network segments it can never touc= h or flow through.  Effectively, to be used as a technology to avoid c= ertain things for specific reasons.

 

This is also one of the reasons for needing such deep label stacks – = this kind of detailed path programming tends to deepen the stack because yo= u sometimes have to be pretty explicit.

 

It is absolutely critical to us that this functionality is there – an= d that we can avoid situations which could cause traffic to accidently hit = things explicitly avoided.

 

I wish I could be more specific than this, but it is what it is.=

 

Thanks

 

Andrew

 

 

From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: Monday, 3 August 2020 21:36
To: Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= ..org
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

(Since the thread has gotten long enough, reiterating that this is as a participant, not a WG chair.)

Yes, we are talking IP networks. And yes, I have seen IP networks that
choose to drop packets. For all sorts of reasons.
I think there are likely other reasons why one may not want a random
path rather than a chosen TE path. I think it is important we be clear
about what constraints may be / are violated when we tell people they
have this tool (protective rerouting) that is intended to preserve QoS.

Let's be clear. I am not arguing that this is not a good idea. It is a
good idea. And useful. I am trying to figure otu what combination of
additional mechanisms and clear descriptions will lead to everyone
getting the behavior they expect (which may not be the behavior they
desire, but sometimes is the best we can do.)

Yours,
Joel

On 8/3/2020 2:30 PM, Robert Raszuk wrote:
> Joel,
>
> Are we still talking about IP networks here ? Or perhaps some har= d
> slicing with real resource reservations or detnets ?
>
> Because if we are talking about IP networking I have two obs= ervations:
>
> A) If you need to traverse via a specific node (ie. firewall) you bett= er
> apply IP encapsulation to that node. I don't think IP encapsulation&nb= sp;can
> be hijacked today such that destination address of the packet is ignor= ed.
>
> B) Have you seen any IP network where upon topology change (link or no= de
> failure) you suddenly start dropping flows in spite of SPT o= ffering
> perhaps few ms longer path with 10 ms more jitter ?
>
> Or are some SR marketing slides promise to turn IP networks in
> something new ? Worse ... do they mention path quality guarantees= ,
> resource reservations ? I hope not.
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>> wrote:
>
> Well less serious for TE SIDs, I am not sure the problem is restricted=
> to just service SIDs.
>
> Suppose that the PCE has specified the path to meet some complex te > objective.  The bypass node has no way of knowing what those
> constraints
> were.  And for some kinds of traffic, it is better to drop the pa= cket
> than to deliver it outside the envelop.  I suspect that the right=
> answer
> to this is "too bad".  If so, as with the distinction r= egarding service
> nodes, we should say so, shouldn't we?
>
> Yours,
> Joel
>
> On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
> > Mach, Joel and all,
> >
> > I think that in most cases:
> >
> > 1.There is clear differentiation between "topological" = and "service"
> > instructions in SID advertisements. E.g.:
> >
> > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
> > corresponding IGP advertisements) represent topological instructi= ons
> >
> > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
> >
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-serv= ices-04>
>
> > draft) unsurprisingly represent “service” instruction= s
> >
> > 2.Segments that represent topological instructions can be bypasse= d,
> > while segments that represent service instructions require
> alternative
> > protection mechanisms.
> >
> > This view seems to be aligned with RFC 8402
> > <https://tools.ietf.or= g/html/rfc8402> that says in Section 1:
> >
> >     In the context of an IGP-based distributed con= trol plane, two
> >
> > topological segments are defined: the IGP-Adjacency segment and t= he
> >
> >     IGP-Prefix segment.
> >
> >     In the context of a BGP-based distributed cont= rol plane, two
> >
> > topological segments are defined: the BGP peering segment and the=
> >
> >     BGP-Prefix segment.
> >
> > In the case of SR-MPLS this differentiation is assumed in Section=
> 3.4 of
> > the Node Protection for SR-TE Path
> >
> <https://datatracker.ietf.or= g/doc/html/draft-hegde-spring-node-protection-for-sr-te-paths-07#section-3.= 4>
>
> > draft that says:
> >
> >     The node protection mechanism described in the= previous sections
> >
> >     depends on the assumption that the label immed= iately below
> the top
> >
> > label in the label stack is understood in the IGP domain.  W= hen the
> >
> >     provider edge routers exchange service labels = via BGP or some
> other
> >
> >     non-IGP mechanism the bottom label is not unde= rstood in the IGP
> >
> >     domain.
> >
> >     The egress node protection mechanisms describe= d in the draft
> >
> >     [RFC8679 <https://datatracker.ietf.org/doc/html/rfc8679>] is
> > applicable to this use case and no additional changes
> >
> >     will be required for SR based networks
> >
> > The scenarios in which  differentiation between “topol= ogical” and
> > “service” instructions is broken are indeed problemat= ic. E.g.,
> consider
> > the use case in which a Node SID in the ERO of a SR-TE path
> identifies a
> > node that acts as a firewall for all packets it receives, i.e., > provides
> > the firewall service without any dedicated service SID
> identifying it.
> > One could say that the Node SID of such a node would combine
> topological
> > and service instructions thus breaking the differentiation
> between the two.
> >
> > I am not sure if usage of such “combined” SIDs could = be prevented
> or at
> > least discouraged.
> >
> > If not, providing an ability to identify such SIDs in the
> advertisement
> > mechanisms would be useful IMHO.
> >
> > My 2c,
> >
> > Sasha
> >
> > Office: +972-39266302
> >
> > Cell:      +972-549266302
> >
> > Email: Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>
> >
> > -----Original Message-----
> > From: spring <spring-bounces@ietf.org
> <m= ailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
> > Sent: Monday, August 3, 2020 6:30 AM
> > To: Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org &l= t;mailto:spring@ietf.o= rg>
> > Subject: Re: [spring] Spring protection - determining applicabili= ty
> >
> > Hi Joel,
> >
> > I think this is a good point that may not be discussed in the
> past. And
> > I also don't think there is a "can be bypassed" indicat= ion in the
> > routing advertisement for now.
> >
> > IMHO, the information advertised by routing is neutral, such
> information
> > (can or cannot be bypassed) is more path specific, thus normally = the
> > controller should be responsible for deciding whether/which SID > can be
> > bypassed.
> >
> > Best regards,
> >
> > Mach
> >
> >  > -----Original Message-----
> >
> >  > From: spring [mailto:sp= ring-bounces@ietf.org
> <mailto:spring-bounces@ietf.org>] On Behalf Of Joel M.
> >
> >  > Halpern
> >
> >  > Sent: Monday, August 3, 2020 7:51 AM
> >
> >  > To: spring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >  > Subject: [spring] Spring protection - determining appl= icability
> >
> >  >
> >
> >  > (WG Chair hat Off, this is merely a note from a slight= ly
> confused WG
> >
> >  > participant.)
> >
> >  >
> >
> >  > I have been reading the various repair drafts, and the= various
> >
> >  > networks programming and service programming draft, an= d I am
> trying to
> >
> >  > figure out one aspect of the combination.
> >
> >  >
> >
> >  > How does a node that is doing some form of bypass (sup= pose, for
> >
> >  > simplicity, it is Node N2 deciding to bypass the next = SID for
> a failed
> >
> >  > node N3) know that it is safe to do so?
> >
> >  >
> >
> >  > If the path was just for TE, then it is "safe&quo= t; if the new path
> meets
> >
> >  > the TE criteria.  or maybe it is safe if it is ev= en close, as
> long as
> >
> >  > it is not used for too long.
> >
> >  >
> >
> >  > But what if the node were a Firewall, included to meet= legal
> > requirements?
> >
> >  > Or was some other necessary programmatic transform (wi= nce we are
> >
> >  > deliberately vague about what nodes can do when asked = suitably.)
> >
> >  >
> >
> >  > Is there some "can be bypassed" indication i= n the routing
> >
> >  > advertisements that I missed?
> >
> >  >
> >
> >  > Thank you,
> >
> >  > Yours,
> >
> >  > Joel
> >
> >  >
> >
> >  > _______________________________________________
> >
> >  > spring mailing list
> >
> >  > s= pring@ietf.org <mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>= ;
> >
> >  >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
> >
> <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H= 2?u=3Dhttps%3A%252>
> >
> >  > F%2Fwww.ietf.org
> <http://2Fwww.ietf.org>%2Fmailman%2Fli= stinfo%2Fspring
> >
> > _______________________________________________
> >
> > spring mailing list
> >
> > spring@ietf.= org <mailto:spr= ing@ietf.org> <mailto:spring@ietf.org
> <mailto:sp= ring@ietf.org>>
> >
> >
> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> >
> >
> >
> ----------------------------------------------------------------------= --
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. that is confidential > and/or
> > proprietary for the sole use of the intended recipient. Any revie= w,
> > disclosure, reliance or distribution by others or forwarding with= out
> > express permission is strictly prohibited. If you are not the
> intended
> > recipient, please notify the sender immediately and then delete a= ll
> > copies, including any attachments.
> >
> ----------------------------------------------------------------------= --
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.= org <mailto:spr= ing@ietf.org>
> > https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@i= etf.org>
> https://www.ietf.org/mailman/listinfo/spring
>

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mai= lman/listinfo/spring



Notice: Th= is e-mail together with any attachments may contain information of Ribbon C= ommunications Inc. that is confidential and/or proprietary for the sole use= of the intended recipient. Any review, disclosure, reliance or distributi= on by others or forwarding without express permission is strictly prohibite= d. If you are not the intended recipient, please notify the sender immedia= tely and then delete all copies, including any attachments.
 --_000_AM0PR03MB449907B6175A572E73B6D0389D4A0AM0PR03MB4499eurp_-- From nobody Tue Aug 4 06:32:45 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D827A3A0B71 for ; Tue, 4 Aug 2020 06:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHRumwOpszDK for ; Tue, 4 Aug 2020 06:32:43 -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 676043A0B6B for ; Tue, 4 Aug 2020 06:32:43 -0700 (PDT) Received: from lhreml729-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 12F6A2D048052B120B20 for ; Tue, 4 Aug 2020 14:32:40 +0100 (IST) Received: from lhreml729-chm.china.huawei.com (10.201.108.80) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 14:32:39 +0100 Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 4 Aug 2020 14:32:39 +0100 Received: from DGGEMM509-MBX.china.huawei.com ([169.254.9.142]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0487.000; Tue, 4 Aug 2020 21:32:36 +0800 From: Huzhibo To: "Joel M. Halpern" , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfMvaROiWEXVU+aZWRNMojsJakn8pLg Date: Tue, 4 Aug 2020 13:32:36 +0000 Message-ID: <06CF729DA0D6854E8C1E5121AC3330DFAF728C2D@dggemm509-mbx.china.huawei.com> References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> In-Reply-To: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.202.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 13:32:45 -0000 Hi Joel and all: I think node protected is used when the SLA of a path cannot be quickly= repaired. E2E detection cannot be deployed in some scenarios. As a result,= the faulty path cannot be repaired at the headend.=20 To prevent SR policy from bypassing Service Sid, if the Per Sid forward= ing state is not introduced on other nodes, the advertise Sid Not Bypass Fl= ag is useless. Therefore, extending the Not Bypass Flag in the SRH Flag may= be an effective method. The following document is trying to solve such pro= blem.https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/?inclu= de_text=3D1 Thanks Zhibo -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, August 3, 2020 7:51 AM To: spring@ietf.org Subject: [spring] Spring protection - determining applicability (WG Chair hat Off, this is merely a note from a slightly confused WG participant.) I have been reading the various repair drafts, and the various networks pro= gramming and service programming draft, and I am trying to figure out one a= spect of the combination. How does a node that is doing some form of bypass (suppose, for simplicity,= it is Node N2 deciding to bypass the next SID for a failed node N3) know t= hat it is safe to do so? If the path was just for TE, then it is "safe" if the new path meets the TE= criteria. or maybe it is safe if it is even close, as long as it is not u= sed for too long. But what if the node were a Firewall, included to meet legal requirements? Or was some other necessary programmatic transform (wince we are deliberate= ly vague about what nodes can do when asked suitably.) Is there some "can be bypassed" indication in the routing advertisements th= at I missed? Thank you, Yours, Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Tue Aug 4 07:55:21 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEDE3A03F4 for ; Tue, 4 Aug 2020 07:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.497, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 6mUE6Bgi92j6 for ; Tue, 4 Aug 2020 07:55:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 7FBB33A0317 for ; Tue, 4 Aug 2020 07:55:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4BLd8j2GWTz1nvjY; Tue, 4 Aug 2020 07:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1596552917; bh=vlxBu6qTQCZavaZezUHxgeNxCi/V/OMf8IaUNggdpLY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZJ7HPohegEAht/iM4Vfbbjxu4ISMwIZKHSFfRLE2uQZoytejMON4M9hMSmQV5A/1m yBTEvguc+uLEXpTzEW9shUyp58lP2Wna33QXKUgh2Q/P2yJFCtfDtbD+mcytwfBcJB MXNUWar8nDZMPLgB8MV9WubPzTl5kK8LTHGeq1ZQ= X-Quarantine-ID: <4DTS-KYrzFqJ> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4BLd8g1F1Zz1nwHN; Tue, 4 Aug 2020 07:55:14 -0700 (PDT) To: Alexander Vainshtein , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk Cc: "spring@ietf.org" , "Joel M. Halpern" References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 4 Aug 2020 10:55:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 14:55:20 -0000 There are, as far as I can tell, a number of ways to address this family of related questions. What struck me, and prompted the starting question, was that none of them were spelled out. I see lots of interesting ideas / proposals. Some of them are compatible with others. Some are not. It would be good if we could reach agreement on how we thought it should be handled. Thank you, Joel On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > Hi all, > > I am still not sure that the problem of bypass going thru undesirable > links/nodes exists in the case of topological SIDs. > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > ) has been successfully deployed > for many years before SR-MPLS has been introduced. What’s more, > signaling of bypass tunnels he PLR usually did not include any of the > constraints used for computing of any specific LSP that the bypass LSP > would protect – because in the Facility Protection mode the same bypass > LSP would be used to protect multiple LSPs passing thru the failed > link/node. > > From my POV the only difference between this behavior and that > introduced by the “bypassing†drafts in SR is that, in the case of > RSVP-TE, the operator would explicitly indicate, as part of LSP > signaling, whether it would or would not use FRR; LSPs that would not > use FRR would then drop traffic rather than delivering it the wrong way. > > Such an option indeed does not exist in SR-TE today, but would be easy > to provide if so desired IMHO. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell:      +972-549266302 > > Email:   Alexander.Vainshtein@ecitele.com > > *From:* spring *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM > *To:* EXT-Andrew.Alston@liquidtelecom.com > ; Robert Raszuk > *Cc:* spring@ietf.org; Joel M. Halpern > *Subject:* Re: [spring] Spring protection - determining applicability > > All, > > This is a very interesting discussion and thanks to Joel for starting > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized  either by defining a flex-algo > avoiding those > > Nodes and links or by using a stack of unprotected adj-sids that avoid > restricted nodes and links. When a stack of adj-sids is used to realize > the path, the head-end based (sBFD) protection mechanisms can be applied. > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection is > in use or not. > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* spring > *On Behalf Of *Andrew Alston > *Sent:* Tuesday, August 4, 2020 5:41 AM > *To:* Robert Raszuk > > *Cc:* spring@ietf.org ; Joel M. Halpern > > > *Subject:* Re: [spring] Spring protection - determining applicability > > *[External Email. Be cautious of content]* > > Robert this is actually far more difficult when – it can be an entire > (long) series of nodes that need to be avoided. > > It could potentially be made to work but I’d worry that to do this – > you’d have to stack 10 – 20 – 30 negative labels – and that wouldn’t be > viable. > > It’s easier to use algorithms and adjacency sids and other such things > to calculate paths – the biggest trick is about the stack depth.  When > you have this need for node avoidance – the need for 10+ label depth is > critical – unless you wanna be applying one hell of a lot of binding > labels along the way which is a nightmare. > > But to answer your question, is this a common use case – it’s a use case > that most of the people I discuss this with certain have – I cant > comment on a global scale, or for anyone else, but every indication I > have is that yes – its something people need, and want > > Andrew > > *From:* Robert Raszuk > > *Sent:* Tuesday, 4 August 2020 01:27 > *To:* Andrew Alston > > *Cc:* Joel M. Halpern >; spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > Is this a common use case ie.  "but rather – which nodes / network > segments it can never touch or flow through." > > If so perhaps its time to define notion of *negative-SID* ie. list in > the packet resources which given packet MUST not ever traverse. > > Put in the packet set of nodes or links which the packet should never > traverse. > > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR) > > Best, > R. > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > wrote: > > So – > > One of the use cases, in fact, some very major use cases in any > spring technology for us revolve around the following > > a.The explicit avoidance of certain nodes > > b.The explicit avoidance of certain sections of the network > > Anything that could result in that explicit avoidance being violated > – would create, shall we say significant problems. > > Much of the use case is not a case of which nodes the packets flow > through – but rather – which nodes / network segments it can never > touch or flow through.  Effectively, to be used as a technology to > avoid certain things for specific reasons. > > This is also one of the reasons for needing such deep label stacks – > this kind of detailed path programming tends to deepen the stack > because you sometimes have to be pretty explicit. > > It is absolutely critical to us that this functionality is there – > and that we can avoid situations which could cause traffic to > accidently hit things explicitly avoided. > > I wish I could be more specific than this, but it is what it is. > > Thanks > > Andrew > > *From:* spring > *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > > *Cc:* spring@ietf..org > *Subject:* Re: [spring] Spring protection - determining applicability > > (Since the thread has gotten long enough, reiterating that this is as a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks that > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clear > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve QoS. > > Let's be clear. I am not arguing that this is not a good idea. It is a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two > observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you > better > > apply IP encapsulation to that node. I don't think IP > encapsulation can > > be hijacked today such that destination address of the packet is > ignored. > > > > B) Have you seen any IP network where upon topology change (link > or node > > failure) you suddenly start dropping flows in spite of SPT offering > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is > restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex te > > objective.  The bypass node has no way of knowing what those > > constraints > > were.  And for some kinds of traffic, it is better to drop the packet > > than to deliver it outside the envelop.  I suspect that the right > > answer > > to this is "too bad".  If so, as with the distinction regarding > service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and > "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological > instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > > > draft) unsurprisingly represent “service†instructions > > > > > > 2.Segments that represent topological instructions can be bypassed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > > > that says in Section 1: > > > > > >     In the context of an IGP-based distributed control plane, two > > > > > > topological segments are defined: the IGP-Adjacency segment and the > > > > > >     IGP-Prefix segment. > > > > > >     In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and the > > > > > >     BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Section > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > > > > > > > > draft that says: > > > > > >     The node protection mechanism described in the previous > sections > > > > > >     depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain.  When the > > > > > >     provider edge routers exchange service labels via BGP or some > > other > > > > > >     non-IGP mechanism the bottom label is not understood in the IGP > > > > > >     domain. > > > > > >     The egress node protection mechanisms described in the draft > > > > > >     [RFC8679 >] > is > > > applicable to this use case and no additional changes > > > > > >     will be required for SR based networks > > > > > > The scenarios in which  differentiation between “topological†and > > > “service†instructions is broken are indeed problematic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such “combined†SIDs could be prevented > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell:      +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > > > On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > >; > spring@ietf.org > > > Subject: Re: [spring] Spring protection - determining applicability > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in the > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus > normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > >  > -----Original Message----- > > > > > >  > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > >  > Halpern > > > > > >  > Sent: Monday, August 3, 2020 7:51 AM > > > > > >  > To: spring@ietf.org > > > >> > > > > > >  > Subject: [spring] Spring protection - determining applicability > > > > > >  > > > > > > >  > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > >  > participant.) > > > > > >  > > > > > > >  > I have been reading the various repair drafts, and the various > > > > > >  > networks programming and service programming draft, and I am > > trying to > > > > > >  > figure out one aspect of the combination. > > > > > >  > > > > > > >  > How does a node that is doing some form of bypass (suppose, for > > > > > >  > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > >  > node N3) know that it is safe to do so? > > > > > >  > > > > > > >  > If the path was just for TE, then it is "safe" if the new path > > meets > > > > > >  > the TE criteria.  or maybe it is safe if it is even close, as > > long as > > > > > >  > it is not used for too long. > > > > > >  > > > > > > >  > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > >  > Or was some other necessary programmatic transform (wince we are > > > > > >  > deliberately vague about what nodes can do when asked suitably.) > > > > > >  > > > > > > >  > Is there some "can be bypassed" indication in the routing > > > > > >  > advertisements that I missed? > > > > > >  > > > > > > >  > Thank you, > > > > > >  > Yours, > > > > > >  > Joel > > > > > >  > > > > > > >  > _______________________________________________ > > > > > >  > spring mailing list > > > > > >  > spring@ietf.org > > > >> > > > > > >  > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 > > > > > > > > > > > > > >  > F%2Fwww.ietf.org > > > >%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any review, > > > disclosure, reliance or distribution by others or forwarding > without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete all > > > copies, including any attachments. > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > > ------------------------------------------------------------------------ > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ------------------------------------------------------------------------ From nobody Tue Aug 4 10:48:29 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9923A0DDB; Tue, 4 Aug 2020 10:48:27 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=U2+OArhT; dkim=pass (1024-bit key) header.d=juniper.net header.b=XUtBQu9u 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 MXg5vkz2AWIS; Tue, 4 Aug 2020 10:48:26 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C0E373A0DB4; Tue, 4 Aug 2020 10:48:25 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 074HXcS2022275; Tue, 4 Aug 2020 10:48:24 -0700 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 : mime-version; s=PPS1017; bh=p6XMIobc+HdIfOEcQy3kvYhcSAzMzGi4WTjUGMwKgtA=; b=U2+OArhTU/xr8AG8pZ5C3CvdtDafy4vmP/LFsQNfEDMjlnAGHQeagp0b2odT0M/hVmkT zlPaq6nCoAhhDoJJ8ab6lexMfWBjjpiY9RIo+7XUOXWWMUx+XQoi4MF/yEMzKMW6iZ/Z RklmPaal8uNVqja+ByausuDm/daSSx7/cxyxeeJ6p5UtSLZvItj+V5xhH5IpM0o0sM2I wO9MdSvZEvgXBWSPLDDj6WkOgLOuY9ZHKqPkfMSF5v/s7o50p+Rn0AP2IJo9sEUtt2Ge YeQxnX6kOxyWq8zxqfK+JutHgyZAC1Ve/bWaVp23Bu8sqoqEEJpC/tFwzcAMRXyZkXbd +A== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2103.outbound.protection.outlook.com [104.47.58.103]) by mx0b-00273201.pphosted.com with ESMTP id 32n7gwmswm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Aug 2020 10:48:24 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bT5wTXyYKFBuvNVrtbO3vUoHIAwati6CIu8Ux1cEgtIHi3QtsTCtUxNqhsg2h6vUAHu6HTuG7ADU+D7QFFVjiekRGeloONOE0IJHWesfu80ga/K5bRgonlH5upDOHeARaCh6NWnQNgM/AyD2N05A7+YFKRItWboY1ACZ++dAdOiUjFJdJZYC4+jP/81Sem0sKCNicGBfCaswCQ3lSoYvmpqQ+QLPPrPoToitCmy+FxGZB8FvNmzgJkhIEGNK+3IkQPi9+IAdl8+avxH4ANnpTtzTdh5tCZXuRbCwpJfHOEeV73rak5VueXo6V3d1XBhg/r5X6wqu+2axr9JLoX023A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p6XMIobc+HdIfOEcQy3kvYhcSAzMzGi4WTjUGMwKgtA=; b=ANCbU/Zhh9n0U06zWRzmQ/Ak7ahsnwa4BKeZF3eZq2r1+7Z3as8UI8QXHtqWQbNo9ujpU0Hzvou9ypjuXLReN2OlH2cadpZbL2aWZZazMwUzYSztOY1TLmuzTOXaH8GS6R3dYpjBvAXO13VqBICCz1yUwv0zcDn/50Jaqv5rSiredtcm5XehWd6XdIho5pxyhD8BfX6f51zD7W3MLbX6+DmqvR+9gE5wy5+gq3Vj7t6MSpR4S/GUWeeYamwpzyb1O3EsFW/rKUjLHH4VrViLBeI3VAyZywvQwLOEq42UtA3czKIFSZ8i5UMZxYBIL3lHuQyDLJ8GoHOeZHuZOvLcGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p6XMIobc+HdIfOEcQy3kvYhcSAzMzGi4WTjUGMwKgtA=; b=XUtBQu9uxtkLa3mZtk/PvC5zq1pm4qb8LnPFQhjw6jVUAkY5sA7PDiKmj1Abyc+6vCaOynV5lXYLzVQye99i6evFVrfP1vzEFMzlz576qI8Wq1caIw2EOHL2TCJofii7lNOHJQIB2IKXoAY3Xj3T6X6VnbgjMKvaYQbxdFg11BE= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3510.namprd05.prod.outlook.com (2603:10b6:910:56::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.12; Tue, 4 Aug 2020 17:48:21 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3261.014; Tue, 4 Aug 2020 17:48:21 +0000 From: Shraddha Hegde To: Pushpasis Sarkar , Bruno Decraene CC: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Thread-Topic: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths Thread-Index: AdZmaxBja895PvK+QsirQTKFBBYlewDs2l4AABornUA= Date: Tue, 4 Aug 2020 17:48:21 +0000 Message-ID: References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-04T17:48:19Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=b3ec69ed-1642-476d-a02d-564f97af101e; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [116.197.184.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cac321e0-bf32-40a5-7343-08d8389e9460 x-ms-traffictypediagnostic: CY4PR05MB3510: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2MErPemcBelir79wut2u/ggCbVHS0LiqyeC54mTDzuM/1phSmjeuPoDvhLJV6nkuk4ikgRJLpTahYFtEkhACrwaJbJyB3Mn6w5JGfeorvoGphx2Ke4AOw7AbaxBqr5KcQ2dXrX5Z93N8zEqxg/q2IfQQ1TkDbNhKiu229MTvKkJ0bNi0HHSpaucMQxHwLQNPJnstW8V/Vg8Sc2WzP6wOhmlduCrZ1tIq8N6arvXmI6xc2CXtsa7YVKUksXV03hj0SLF9PHYH0CevAkdHqPMu9UCTDpQ5l7MbiBPxb1vuLU9f+5xaBmCACEhlaQYjZF0bB3R2KCFQ877/Dt0S1YfHMzk34xqo+4Jn0EMISP0MH4wIjWDs9gZkS9vgXx8uH/57HdPkPaGgbdSR18Hf/On4OQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(376002)(346002)(396003)(478600001)(76116006)(8936002)(66556008)(66946007)(66446008)(9326002)(66476007)(71200400001)(83380400001)(64756008)(316002)(8676002)(4326008)(110136005)(54906003)(55016002)(26005)(166002)(9686003)(53546011)(86362001)(7696005)(52536014)(6506007)(2906002)(33656002)(966005)(5660300002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: kbQEVsdBkUZOtiDqgTNkvGqPWqCOWQochIKbEfypTHbBhnPVXyCOkmZwzAorOgX2dhYyyzz42JqoBxG/3Re63JZS5l2D1b6ip2RwsWfNdKO3oB7pnSSXosQ/kW+BAgDwVEpU37E5kSqTjgvCJPEfxW/rcNVqAI/LY7kJb8L1t0K6QlTfc50LUE1oudbmqOeSeso6UZ+InAawNdkk7rmabfi9tVfc3W7ziqwSy6EQJKt1SvB6HccGXYUEdap67bxp5VcngBMxBSDsXu06io8/4PhTGUBBGmgm/emueDEv+KFUoDtrg6kcBB1Na3RC4tPh32uYw7nfJ02tvqnmKA+y+eXZqnoS5mFCX8mCn4rMlPa44+cRTa7BnPDTgbM6vRF9ElTjU6GRQorP7LVgtKWXZdFxry1XRoZfHU6fh5q7VdidnodsTW/GEN6ZPt4VYnNvdHdMCTAJiPI1yfyGUJw4nMAwUID8MVlTsc8qbYbS1e4BCja7ep9kH51NQEPlWWmn3yFTo0hHz39Ci4CcPbTR+kYNiVrTB5cCLeawA2qiTkzrJBYmn2vcdrEuajYJ/+hBp0GzkyE/GyTjAenrSC/keOQRAJ0l+E+Ys1Ip44c+udqU3lSB73cdL4vkLcbw0UNcQf4CS78e10RQTDQd9DMawQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR05MB35769433E121A1675DFF51DED54A0CY4PR05MB3576namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cac321e0-bf32-40a5-7343-08d8389e9460 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 17:48:21.7003 (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-CrossTenant-userprincipalname: TjNKSxvuRsMFrmF2Hq5FOro2/vKLfojtWESShHInZtLLrGvNdBwKTokIgSujWxDj6yRURGVrEv6Vfe05ptIb3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3510 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-04_04:2020-08-03, 2020-08-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 suspectscore=0 impostorscore=0 adultscore=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 spamscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008040130 Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 17:48:28 -0000 --_000_CY4PR05MB35769433E121A1675DFF51DED54A0CY4PR05MB3576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pushpasis, Thanks for the review and comments. Pls check if the below text looks good. " draft-ietf-spring-mpls-anycast-segments proposes a mechanism to allow the u= se of anycast SIDs in a network where all devices do not share a common SRGB. draft-ietf-spring-mpls-anyca= st-segments utilizes the concept of a virtual LFIB, which is an application of the concept of Context-Specific= Label Spaces [RFC5331]. The current draft uses the mechanism of context tables, a different application of Context-Sp= ecific Label Spaces, to facilitate node protection. The current draft does not make provisions to support the virt= ual LFIB mechanism together with node protection context tables. The use of anycast-SIDs together with anyc= ast-aware TI-LFA provides effective protection against node failure. Therefore, when SRTE paths are constructe= d using anycast-SIDs, the anycast-SIDs may not require node protection via context tables. " Rgds Shraddha Juniper Business Use Only From: Pushpasis Sarkar Sent: Tuesday, August 4, 2020 10:47 AM To: Bruno Decraene Cc: spring@ietf.org; draft-hegde-spring-node-protection-for-sr-te-paths@iet= f.org Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protecti= on-for-sr-te-paths [External Email. Be cautious of content] Hi WG, Support the adoption of this draft. However I think some text should be add= ed to explain it's interaction with https://datatracker.ietf.org/doc/draft-= ietf-spring-mpls-anycast-segments. Authors, If you prefer, I can provide some text for your perusal. Thanks and regards, -Pushpasis On Thu, Jul 30, 2020 at 5:55 PM > wrote: Hi SPRING WG, Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have ask= ed for WG adoption. Please indicate your support, comments, or objection, for adopting this dra= ft as a working group item by August 20th 2020. (*) Could those who are willing to work on this document, please notify the lis= t. That gives us an indication of the energy level in the working group to = work on this. Thanks, Regards, Bruno, Jim, Joel [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-t= e-paths-07 (*) 3 weeks to account for the IETF meeting week and the august/summer peri= od. ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CY4PR05MB35769433E121A1675DFF51DED54A0CY4PR05MB3576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pushpasis,

 

Thanks for the review and comments.

 

Pls check if the below text looks good.

 

“

draft-ietf-spring-mpls-anycast-segments proposes a m= echanism to allow the use of anycast SIDs in a network

where all devices do not share a common SRGB.  = draft-ietf-spring-mpls-anycast-segments utilizes the concept of

a virtual LFIB, which is an application of  the= concept of Context-Specific Label Spaces [RFC5331].  The current draf= t

uses the mechanism of context tables, a different ap= plication of Context-Specific Label Spaces, to facilitate node

protection.  The current draft does not make pr= ovisions to support the virtual LFIB mechanism together with

node protection context tables.  The use of any= cast-SIDs together with anycast-aware TI-LFA provides effective<= /p>

protection against node failure.  Therefore, wh= en SRTE paths are constructed using anycast-SIDs, the anycast-SIDs

may not require node protection via context tables.&= nbsp;“

 

 

Rgds

Shraddha

 

 

 

Juniper Business Use Only

From: Pushpasis Sarkar <pushpasis.ietf@gma= il.com>
Sent: Tuesday, August 4, 2020 10:47 AM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: spring@ietf.org; draft-hegde-spring-node-protection-for-sr-te-pa= ths@ietf.org
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-p= rotection-for-sr-te-paths

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

 

Hi SPRING WG,

 

Authors of draft-hegde-spring-node-protection= -for-sr-te-paths  [1] have asked for WG adoption.

 

Please indicate your support, comments, or ob= jection, for adopting this draft as a working group item by August 20th 202= 0. (*)

 

Could those who are willing to work on this d= ocument, please notify the list. That gives us an indication of the energy = level in the working group to work on this.

 

Thanks,

Regards,<= /span>

Bruno, Jim, Joel

 

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07

(*) 3 weeks to account for the IETF meeting w= eek and the august/summer period.

 

____________________________________________________=
_____________________________________________________________________<=
/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.

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spr= ing

--_000_CY4PR05MB35769433E121A1675DFF51DED54A0CY4PR05MB3576namp_-- From nobody Tue Aug 4 21:52:14 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABB63A1182; Tue, 4 Aug 2020 21:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRasGY9lxlJE; Tue, 4 Aug 2020 21:52:11 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 0DB7B3A0B3F; Tue, 4 Aug 2020 21:52:10 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id i92so2577580pje.0; Tue, 04 Aug 2020 21:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=O8+acY9iykV0GLU9mJ6ghJsQX73Rac4SqrnGkr9eqtc=; b=JqABcLTh+MLuk8YKPdH+tmyRRm6V7PB/7Y6YbBYRuwRLTGkNuztlcre/bixrI7KSvf t8Hr5bSRdlsdfX++RGR4+FNroCbXIg75XiFYAxT+z3j5bQXYY2uwPQdv5BiqKxANpTTu 4kQDH0ZfpIS9CfmCM0VjUVX+35YtvqQeWFYdnb1S8O3UcboOlbBascxYuLA2fFVrTAmQ zJmXbrhstnHsG1dx/JFRfhyPiPNpCIrm7xQfJheqaZn2q048GAHkE1QAPwNc0H0fLhR+ /jIYSILNHCSVYGMumpxQ3Vf1hsqynzXKIt4GNjPj3e8HosZFfo0ogeCqDFFpvLkKUtRv Ij+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=O8+acY9iykV0GLU9mJ6ghJsQX73Rac4SqrnGkr9eqtc=; b=PdHPvS/zPISF0NpaYjH0Cdk1ohDihXd7O45h0EklgOlbIeoAgcwENZxPVp1LIZHLtH gCMsCoVvOtAk5Tv9afuYMEmF3a0IE5AcqOBzmTR61FzpIBjIwHAoKkLTEsN4gIYW3mg+ J4vhDXFnSvYEXurx5gbEWUf3VpdGclYSVRfoaUdxkVxTV5IJkDzjwNWSqA3Gd1c9IDNs Xq4Wkw6jM7dlNVZKqrihbhnX+8SuLUhsYIfKOVk9VrocKMSQfTWv8XEq+fXejUvxOt7l 4nK2ErSPwLvDllA5jBJSYD9rxv8RPBJglXKzIMAzSrP/bcRQ0Gry0GCmECpr0epXUdWV vRAA== X-Gm-Message-State: AOAM531AVejeEO2d2I2AP4QpcVg4j2hfl66mJygE0siKxmtr5fMLAChE W7CW1SEIxh3qzzvX8+AA5n8= X-Google-Smtp-Source: ABdhPJzzvcP1sC5II55gIokbZxbVmdfExEVv23igzRUHGAZLsLKIK55jjO8j1w92OwuLBZrxPxwRhA== X-Received: by 2002:a17:90a:950a:: with SMTP id t10mr1459754pjo.107.1596603130397; Tue, 04 Aug 2020 21:52:10 -0700 (PDT) Received: from kaula-mbp.jnpr.net ([116.197.188.14]) by smtp.gmail.com with ESMTPSA id na14sm1033288pjb.6.2020.08.04.21.52.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2020 21:52:09 -0700 (PDT) From: Aditya Kaul Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_881616D0-38C5-4C1E-ACB3-F790030F635F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Wed, 5 Aug 2020 12:52:06 +0800 In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Cc: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" To: bruno.decraene@orange.com References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 04:52:13 -0000 --Apple-Mail=_881616D0-38C5-4C1E-ACB3-F790030F635F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Support the WG adoption. Regards, Aditya > On Jul 30, 2020, at 8:24 PM, bruno.decraene@orange.com wrote: >=20 > Hi SPRING WG, > =20 > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] = have asked for WG adoption. > =20 > Please indicate your support, comments, or objection, for adopting = this draft as a working group item by August 20th 2020. (*) > =20 > Could those who are willing to work on this document, please notify = the list. That gives us an indication of the energy level in the working = group to work on this. > =20 > Thanks, > Regards, > Bruno, Jim, Joel > =20 > [1] = https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-p= aths-07 = > (*) 3 weeks to account for the IETF meeting week and the august/summer = period. > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_881616D0-38C5-4C1E-ACB3-F790030F635F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Support the WG adoption.

Regards,
Aditya

On Jul 30, 2020, at 8:24 PM, bruno.decraene@orange.com wrote:

Hi SPRING WG,
 
Authors = of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked for WG adoption.
 
Please = indicate your support, comments, or objection, for adopting this draft = as a working group item by August 20th 2020. (*)
 
Could = those who are willing to work on this document, please notify the list. = That gives us an indication of the energy level in the working group to = work on this.
 
Thanks,
Regards,
Bruno, = Jim, Joel
 
(*) 3 weeks to account for = the IETF meeting week and the august/summer period.
 
_______________________________________________________________=
__________________________________________________________

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

This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_881616D0-38C5-4C1E-ACB3-F790030F635F-- From nobody Wed Aug 5 01:32:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025AB3A13CF; Wed, 5 Aug 2020 01:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 GCVLQy5XqOAK; Wed, 5 Aug 2020 01:32:53 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253056.outbound.protection.outlook.com [40.92.253.56]) (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 4360E3A13D0; Wed, 5 Aug 2020 01:32:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eDlSd+SC7stKCWUx058qH+Blnqz59cs3x/4IeyADc48bq48mTaRM8UlWuASRssVB5SlQaWTGai+hvQCRVsyYGh+8x1hZoqj9t4coOt0uppaZRDjtHLWd+r6ak/bHw2mg4WPBI4gONjkdg9kn9f9A+2+Y/5JeZgjfJrtsvykw0pe86t/vkIkO17NBs2TZbbKr3nH2XtDYCMSAkLEmdfHWQ4p1OJGec/D0j51Db82ZlALkbGYM3aAx1C6jZrzcxaPKVqifsS5sE51qC3JHfKReG2ctLjwelZMcB+FIKaosOC0DhydMxPSzie1KkkimUJqi3qd9mBDNe6xAZQmWTWYqEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w/l8e4IyGfe0cKrJ8YqcVCEjH2QzXU9UOCzC38kVWfE=; b=eWpVOu2Y2PUK4lMGZ54Y/6plzoDFHayL8fEo05Dt37553ZtuPEa53hxbg2Ilk9Yko1gqWP5AF2WBwbuftfLEeWym/jP1p7aLjAWVJzbHEv3O6IDd7taBvbhAeBtMI6duq2XQMoaZtBm1/XZGtp5GVkOJVYki+PwZRJuuiT+WDcp9d6V2gcJBlh3dJWtHRS+jGfxO6XZJ9koF7B2sK9D8RFsHRoxgG4DNwMpig58HDxODLx4FXUyiBolVOy5jerLvislBnU+m9+kZLefSjC2psax/iQVj9sKOSSApYv25PJPrBTV3H7NuME4mvn3VrFKGgGTz+6wkgh5aWcwxJzWF+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w/l8e4IyGfe0cKrJ8YqcVCEjH2QzXU9UOCzC38kVWfE=; b=fg7rdg1SP/HMr+HrzGcumzKlQ1S03yWu/2AJ+B1rOsnrRZvO3tsY3sioudsn+jW0n5WFABCNyeZiQxBwi4xqOF2dDTTJRvLc7uEtePPUwvmNPu1deqDvwso68ySZ+oSrXUKdnRh1X6sGqD/o07NpmjWshZ8caWs7gKGogRl7qR+isNnADLq53quW40nGuRwzdaNYDM3mA9mWeGg84GoivESCUoyMseKKxtrwqzwdEsMo0jfcZLUlmnpGcERjAM4h9RYjZJ5ssroho+U+GQElqRs1AkyPl+PAgIyUl6OimzDboERsGTxJf61L3BkrFXGCgW5AW161nC6PLgnAK//qSw== Received: from HK2APC01FT011.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::53) by HK2APC01HT102.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::291) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Wed, 5 Aug 2020 08:32:45 +0000 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com (2a01:111:e400:7ebc::4a) by HK2APC01FT011.mail.protection.outlook.com (2a01:111:e400:7ebc::153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16 via Frontend Transport; Wed, 5 Aug 2020 08:32:45 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:51DD923BE0DA75858A52836F0198DE5342815E85157AA219368846284E8FFFFE; UpperCasedChecksum:CA9D4D66E493ADF3F439F34836FB789A159A5654E5F898DE15374CD98AB2ACBB; SizeAsReceived:7607; Count:48 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::4821:4bbe:ef2a:6dee]) by HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::4821:4bbe:ef2a:6dee%4]) with mapi id 15.20.3261.015; Wed, 5 Aug 2020 08:32:45 +0000 Date: Wed, 5 Aug 2020 16:33:19 +0800 From: "li_zhenqiang@hotmail.com" To: "spring@ietf.org" , draft-ietf-spring-segment-routing-policy X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart262517546157_=----" X-ClientProxiedBy: HK2PR03CA0065.apcprd03.prod.outlook.com (2603:1096:202:17::35) To HK0PR03MB4066.apcprd03.prod.outlook.com (2603:1096:203:9d::21) X-Microsoft-Original-Message-ID: <202008051055480596899@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from cmcc-PC (183.243.251.88) by HK2PR03CA0065.apcprd03.prod.outlook.com (2603:1096:202:17::35) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3261.13 via Frontend Transport; Wed, 5 Aug 2020 08:32:44 +0000 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] X-Microsoft-Original-Message-ID: <202008051055480596899@hotmail.com> X-TMN: [+nBg8BP271Zs411+XiZyfJT+GgEHuxAq] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 4c6d0c5a-7912-4a94-a8cb-08d8391a209c X-MS-TrafficTypeDiagnostic: HK2APC01HT102: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KxlC1QRuzUpF0tcN8dVaWc2QRpphIa8cJ+TqBtHv7nm/EXNbpb1pMMdTXiElS0du7gM87BLXqL245YxJ8nlJyP1Aaby2EzBn4iY9apT2ytFDhxqnbIujj00MBxEHBVhVUxCYHlzEb/MpLr/6I4Dh2hCo1tpQXAa9p1x6TxMdYk1bTuXmXftCjF0EafeusjDsnIGzQCqS/00jBX3ZF7JaoA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR03MB4066.apcprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; X-MS-Exchange-AntiSpam-MessageData: 6StB2E7FejFrEHm0QSUwc+P/CQ2cyEZkUE8fobX8dkHPgVYZmce+/1RIIUvShtYPXLjSkGVVhor4cVaodbKvczrbRvuGLxhgeAqMV2hbmVolHv+jHrEsL8VzSU+k2zGCQ0LQ1yV4Eed/hnQ8s9RGKQ== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c6d0c5a-7912-4a94-a8cb-08d8391a209c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2020 08:32:45.7332 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT011.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT102 Archived-At: Subject: [spring] Comments on SR policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 08:32:55 -0000 ------=_001_NextPart262517546157_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzIGFuZCBhbGwsDQoNClBsZWFzZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIGNv bW1lbnRzLg0KMS4gRG8geW91IHRoaW5rIGl0IGlzIG9rIHRvIGFkZCBvbmUgbW9yZSBzZWdtZW50 IHR5cGUgZm9yIHRoZSBzZWdtZW50IGxpc3QgdG8gaW5jb3Jwb3JhdGUgdGhlIHNlZ21lbnQgZm9y IExheWVyIDIgYnVuZGxlIG1lbWJlcnM/IFBsZWFzZSByZWZlciB0byByZmM4NjY4Lg0KMi4gRm9y IHBlciBmbG93IHN0ZWVyaW5nIHRvIGEgcG9saWN5LCB3aHkgZG8gd2UgbGltaXQgdGhlIGFycmF5 IGluZGV4IHRvIDAgdG8gNz8gIEkgdGhpbmsgdGhpcyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp YyBhbmQgdGhlIG51bWJlciBvZiBwYXRocyBpbiBhbiBhcnJheSBkZXBlbmRzIG9uIHRoZSBhcHBs aWNhdGlvbiBzY2VuYXJpby4gSSBhbSBub3Qgc3VyZSB3aGV0aGVyIG9yIG5vdCA4IHBhdGhzIGlz IGVub3VnaCBmb3IgYWxsIHNjZW5hcmlvcy4NCjMuIEZvciBwcm90ZWN0aW9uIGluIHNlY3Rpb24g OS4xLCBpdCBpcyBiZXR0ZXIgdG8gYWRkIHNvbWUgdGV4dCBsaWtlICJ0aGUgbG9jYWwgcHJvdGVj dGlvbiBtYXkgbm90IHNhdGlzZnkgdGhlIFNMQSByZXF1aXJlbWVudHMgb3IgdGhlIHBhdGggY29u c3RyYWlucyBmb3IgdGhlIHBvbGljeSIgd2hlbiBhbiBTUiBQb2xpY3kgaXMgYnVpbHQgb24gdGhl IGJhc2lzIG9mIFRJLUxGQSBwcm90ZWN0ZWQgSUdQIHNlZ21lbnRzLg0KDQpCZXN0IFJlZ2FyZHMs DQpaaGVucWlhbmcgTGkNCg0KDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb20NCg== ------=_001_NextPart262517546157_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A=
Dear authors and all,

Please con= sider the following comments.
1. Do you think it is ok to add one= more segment type for the segment list to incorporate the segment for Laye= r 2 bundle members? Please refer to rfc8668.
=0A=
2. For per flow steering to a policy, why do we limit the array index = to 0 to 7?  I think this is implementation specific and the number of = paths in an array depends on the application scenario. I am not sure whethe= r or not 8 paths is enough for all scenarios.
3. For protection i= n section 9.1, it is better to add some text like "the local protectio= n may not satisfy the SLA requirements or the path constrains for the polic= y" when an SR Poli= cy is built on the basis of TI-LFA protected IGP segme= nts.

Best Regards,
Zhenqiang Li
=0A=
li_zhenqiang@hotmail.com
=0A= = ------=_001_NextPart262517546157_=------ From nobody Thu Aug 6 00:56:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4CB3A0FFE; Thu, 6 Aug 2020 00:56:40 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ78JN6yz1BW; Thu, 6 Aug 2020 00:56:38 -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 0C8BF3A0A38; Thu, 6 Aug 2020 00:56:38 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4477556593E715AB7848; Thu, 6 Aug 2020 08:56:35 +0100 (IST) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 6 Aug 2020 08:56:34 +0100 Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 6 Aug 2020 15:56:32 +0800 Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1913.007; Thu, 6 Aug 2020 15:56:32 +0800 From: Zhuangshunwan To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang Thread-Index: AdZZKaSGxpyazIbbQ8apsNd5+9RdDgLn0T7wAb9jekA= Date: Thu, 6 Aug 2020 07:56:32 +0000 Message-ID: <09f37448345c46829cdfa70a09c99a80@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.202.109] Content-Type: multipart/alternative; boundary="_000_09f37448345c46829cdfa70a09c99a80huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 07:56:40 -0000 --_000_09f37448345c46829cdfa70a09c99a80huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Joel & Bruno, As a co-author I am not aware of any undisclosed IPR related to this docume= nt. Thanks, Shunwan From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Tuesday, July 28, 2020 6:34 PM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption Call for draft-raza-spring-sr-policy-yang Dear WG: The 2-week adoption call for draft-raza-spring-sr-policy-yang has now close= d. There is strong support for adoption of this document into the WG and th= erefore authors please publish a new version as draft-ietf-spring-sr-policy= -yang-00. The chairs note that several comments were received during the ad= option call and we expect to see those resolved as part of the WG process; = authors please work with the people that commented to resolve any open issu= es and/or comments. Authors, please indicate on the mailing list whether you are aware of any u= ndisclosed relevant IPR. Thanks! Jim, Joel & Bruno From: James Guichard Sent: Monday, July 13, 2020 11:38 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: WG Adoption Call for draft-raza-spring-sr-policy-yang Dear WG: This email begins a 2 week WG adoption call for https://datatracker.ietf.or= g/doc/draft-raza-spring-sr-policy-yang/ ending Monday 27th July 2020. Please speak up if you support or oppose adopting this document into the WG= . Please also provide comments/reasons for that support (or lack thereof). = Silence will not be considered consent. Thanks! Jim, Joel & Bruno --_000_09f37448345c46829cdfa70a09c99a80huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim, Joel & Bruno,<= /o:p>

 

As a co-author I am not aware o= f any undisclosed IPR related to this document.

 

Thanks,

Shunwan

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, July 28, 2020 6:34 PM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-raza-spring-sr-poli= cy-yang

 

Dear WG:

 

The 2-week adoption call for dr= aft-raza-spring-sr-policy-yang has now closed. There is strong support for = adoption of this document into the WG and therefore authors please publish = a new version as draft-ietf-spring-sr-policy-yang-00. The chairs note that several comments were received during the adoption ca= ll and we expect to see those resolved as part of the WG process; authors p= lease work with the people that commented to resolve any open issues and/or= comments.

 

Authors, please indicate on the= mailing list whether you are aware of any undisclosed relevant IPR.

 

Thanks!

 

Jim, Joel & Bruno

 

 

From: James Guichard
Sent: Monday, July 13, 2020 11:38 AM
To: spring@ietf.org
Cc: spring-chairs@ietf.org=
Subject: WG Adoption Call for draft-raza-spring-sr-policy-yang =

 

Dear WG:

 

This email begins a 2 week WG a= doption call for https://datatracker.ietf.org/doc/draft-raza-spring-sr-policy-yang/ = ending Monday 27th July 2020.

 

Please speak up if you support = or oppose adopting this document into the WG. Please also provide comments/= reasons for that support (or lack thereof). Silence will not be considered = consent.

 

Thanks!

 

Jim, Joel & Bruno

 

 

 

--_000_09f37448345c46829cdfa70a09c99a80huaweicom_-- From nobody Thu Aug 6 01:02:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EFF3A100E; Thu, 6 Aug 2020 01:02: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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8feGW5-JnPLg; Thu, 6 Aug 2020 01:02:25 -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 AE8E53A1009; Thu, 6 Aug 2020 01:02:24 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4F9552AE2527CA8F5466; Thu, 6 Aug 2020 09:02:23 +0100 (IST) Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 6 Aug 2020 09:02:23 +0100 Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 6 Aug 2020 09:02:22 +0100 Received: from DGGEMM509-MBX.china.huawei.com ([169.254.9.142]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0487.000; Thu, 6 Aug 2020 16:02:18 +0800 From: Huzhibo To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption Call for draft-raza-spring-srv6-yang Thread-Index: AdZZX0QDXPWnj1oGQQKGYsZR37MSlgLa3ezQAb9GVHA= Date: Thu, 6 Aug 2020 08:02:17 +0000 Message-ID: <06CF729DA0D6854E8C1E5121AC3330DFAF72E0E6@dggemm509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.202.126] Content-Type: multipart/alternative; boundary="_000_06CF729DA0D6854E8C1E5121AC3330DFAF72E0E6dggemm509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 08:02:26 -0000 --_000_06CF729DA0D6854E8C1E5121AC3330DFAF72E0E6dggemm509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Joel & Bruno, As a co-author I am not aware of any undisclosed IPR related to this docume= nt. Thanks, Zhibo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Tuesday, July 28, 2020 6:43 PM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang Dear WG: The 2-week adoption call for draft-raza-spring-srv6-yang has now closed. Th= ere is strong support for adoption of this document into the WG and therefo= re authors please publish a new version as draft-ietf-spring-srv6-yang-00. = The chairs note that several comments were received during the adoption cal= l to help improve the structure and quality of the document; authors please= work with the people that provided these comments to incorporate them as a= ppropriate into the document. Authors, please indicate on the mailing list whether you are aware of any u= ndisclosed relevant IPR. Thanks! Jim, Joel & Bruno From: James Guichard Sent: Monday, July 13, 2020 5:52 PM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: WG Adoption Call for draft-raza-spring-srv6-yang Dear WG: This email begins a 2 week WG adoption call for https://datatracker.ietf.or= g/doc/draft-raza-spring-srv6-yang/ ending Monday 27th July 2020. Please speak up if you support or oppose adopting this document into the WG= . Please also provide comments/reasons for that support (or lack thereof). = Silence will not be considered consent. Thanks! Jim, Joel & Bruno --_000_06CF729DA0D6854E8C1E5121AC3330DFAF72E0E6dggemm509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim, Joel & Bruno,<= /o:p>

 

As a co-author I am not aware o= f any undisclosed IPR related to this document.

 

Thanks,

Zhibo

 

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, July 28, 2020 6:43 PM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-ya= ng

 

Dear WG:

 

The 2-week adoption call for dr= aft-raza-spring-srv6-yang has now closed. There is strong support for adopt= ion of this document into the WG and therefore authors please publish a new= version as draft-ietf-spring-srv6-yang-00. The chairs note that several comments were received during the adoption ca= ll to help improve the structure and quality of the document; authors pleas= e work with the people that provided these comments to incorporate them as = appropriate into the document.

 

Authors, please indicate on the= mailing list whether you are aware of any undisclosed relevant IPR.

 

Thanks!

 

Jim, Joel & Bruno

 

 

<= o:p> 

 

 

From: James Guichard
Sent: Monday, July 13, 2020 5:52 PM
To: spring@ietf.org
Cc: spring-chairs@ietf.org=
Subject: WG Adoption Call for draft-raza-spring-srv6-yang=

 

Dear WG:

 

This email begins a 2 week WG a= doption call for https://datatracker.ietf.or= g/doc/draft-raza-spring-srv6-yang/ e= nding Monday 27th July 2020.

 

Please speak up if you support = or oppose adopting this document into the WG. Please also provide comments/= reasons for that support (or lack thereof). Silence will not be considered = consent.

 

Thanks!

 

Jim, Joel & Bruno

 

 

 

 

 

--_000_06CF729DA0D6854E8C1E5121AC3330DFAF72E0E6dggemm509mbxchi_-- From nobody Thu Aug 6 21:03:42 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA5F3A0E05 for ; Thu, 6 Aug 2020 21:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=wn/RqOiR; dkim=pass (1024-bit key) header.d=juniper.net header.b=HiqP6rU8 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 vCpgV8Dc7mJr for ; Thu, 6 Aug 2020 21:03:40 -0700 (PDT) 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 108C43A0E04 for ; Thu, 6 Aug 2020 21:03:39 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07743bM7010273; Thu, 6 Aug 2020 21:03:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=AJcXcYq9qZZkJnBH5nwuc88/ss983ujS2Nc9ipQQnew=; b=wn/RqOiRWiXe/GrPWiQT1r/Jr9N/Yb4r1XHddyPH13EtuYXj0szFi8gi0cMOYx5Qau/Z 28pm8AXrKg2XjS/dnC5HDksHy3j+mf9/0JnimhHAmZW4lA/WiCj2NuBagryitgFzWPbZ moPZr4qufxcEihoYU+nsi3pJVgJetXFyFldI+ApFAn2GG03AgbZ2UZUr1yyaBstrKLDq QgAB+GwIfE7nBlYmZ2xB3QWZCEoPD57A06RPRsB41sE8PHiPux+fRVGQq5IrCpSbkpOv a/KQvUdzupW62XO5a/OEtleiEo/OMVoJQFfzNEyjvi4l+nMyfcHGWocrz/lwO3QUO3B0 uQ== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2044.outbound.protection.outlook.com [104.47.74.44]) by mx0a-00273201.pphosted.com with ESMTP id 32n6cq1mqx-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Aug 2020 21:03:38 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bUxuc9u4N0qXRndlMq+rcU8NILTrsqtMe111GmZndtnItYGHKoDrJfaCdBtNtvW0i52DGtlKz4Frr9vAt3dZigLaBkk2FqVYp77eLjXU22281/JuwTgO+7C5WAqEb3ZVk9+i4JsGI2Cfrcpz0ey5KEBOAYNY3y6B/3a8vGM6rDB6XXJ1ed3sL4vPcm2i3GlzOlwEmWykKnLsAyksYd9K72SUWZ19kudtglT9fcj7QxXGhk1eGcWnq+AIhOEU2MMS9EvJJ1jdPc+T7j+BYAe4w403aRBl+ss+fi2xQ3PIJknCexOEagosDvE3C5AtDrik8YAM0lsIeIVPocR/X6eJmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJcXcYq9qZZkJnBH5nwuc88/ss983ujS2Nc9ipQQnew=; b=awcncrSq4iqy6cozlnGyx6WZzTZ6njE7OmlXXJVsUCNYk/WhlWGxnsawkOjzl5njwtibvSj5DBwLolWHELrxjhV8BXRuKgJVq1Zc+syHnl+bxEZQyKawsrbt7I+w+DZPb70S2eW2R2RSGqjtbTHYyTD+Qs4Yofs3d2h3JGsDn48FbDSMJWm5a/MHIwA+8aYDAlDUC/s/jn0ROAwBOWHV3GzgiTRYH/JTZvQI4JQbSoHZG0IJi0rlZTIw/gwabi3WKXsRgWlGxaHKUMot7CSVtL/MOHZBt9MS8+n+XTDv9ugTFV00hGLmg1mD9VvibFMg7GBXTjvE+WxFEgy14820AQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJcXcYq9qZZkJnBH5nwuc88/ss983ujS2Nc9ipQQnew=; b=HiqP6rU8oCOXdabaUS2aOZ2MShcv7Fgnv2DrZUzhO+tUrNG+2KsyMVPpot6uNywZ1rot0GSBPB4NMzig10d4WUqmXr0FZKHB0uhx8siWSHTEYbF0c4MbmSf53CbF3NVcf71G9cosbl9+OoHhtKcE6kzLxgFrgMVNwX9dcwA7doQ= Received: from MN2PR05MB6080.namprd05.prod.outlook.com (2603:10b6:208:c4::21) by MN2PR05MB6606.namprd05.prod.outlook.com (2603:10b6:208:e6::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.7; Fri, 7 Aug 2020 04:03:35 +0000 Received: from MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::409:6521:1e51:f8f5]) by MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::409:6521:1e51:f8f5%4]) with mapi id 15.20.3261.016; Fri, 7 Aug 2020 04:03:35 +0000 From: Rajesh M To: Peter Psenak , Shraddha Hegde , "cfilsfil@cisco.com" , "ketant@cisco.com" , "Gulko, Arkadiy (Refinitiv)" CC: SPRING WG Thread-Topic: https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-08 (OSPFv2 flex algo) Thread-Index: AdZsb7FCx7n0n1puTvue8MZUiX5E5w== Date: Fri, 7 Aug 2020 04:03:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-07T04:02:14Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5bb61b8a-4a8c-4987-a07c-88fa32413e16; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [106.201.60.119] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b6d54d9c-83f1-4ffe-5018-08d83a86db30 x-ms-traffictypediagnostic: MN2PR05MB6606: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6080.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(346002)(366004)(39860400002)(396003)(4326008)(52536014)(2906002)(4744005)(5660300002)(66476007)(66556008)(66946007)(6506007)(66446008)(64756008)(76116006)(478600001)(8676002)(33656002)(7696005)(71200400001)(110136005)(86362001)(316002)(8936002)(186003)(9686003)(55016002)(26005); DIR:OUT; SFP:1102; Content-Type: multipart/alternative; boundary="_000_MN2PR05MB6080774E4DDE496BBC39B6FBBE490MN2PR05MB6080namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6080.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6d54d9c-83f1-4ffe-5018-08d83a86db30 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 04:03:34.7581 (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-CrossTenant-userprincipalname: to5JgmbYpcOTNSE8KaGJ8jqWlQNdXt/12lVgrWg36GV8OaaSJlggdlSZ7tb+A/70xK9vBJpCl1QvGHbgCUFmVg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6606 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-07_01:2020-08-06, 2020-08-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 priorityscore=1501 mlxlogscore=922 adultscore=0 clxscore=1011 impostorscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008070029 Archived-At: Subject: [spring] https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-08 (OSPFv2 flex algo) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 04:03:42 -0000 --_000_MN2PR05MB6080774E4DDE496BBC39B6FBBE490MN2PR05MB6080namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note : Discussion is not about FAPM. For flex algorithm (example take it as 128) OSPF Prefix (For summary/extern= al prefixes), how to get the prefix cost ? there is no prefix cost field i= n OSPFv2 Extended Prefix TLV. Currently only way I can see is prefix needs to be advertised in flex algo = zero(as summary or external prefixes in legacy ospf) as well as in flex alg= o 128 (OSPFv2 Extended Prefix TLV) Thanks Rajesh Juniper Business Use Only --_000_MN2PR05MB6080774E4DDE496BBC39B6FBBE490MN2PR05MB6080namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Note : Discussion is not about FAPM.

 

For flex algorithm (example take it as 128) OSPF Prefix (For summary/external prefixes), &n= bsp;how to get the prefix cost ? there is no prefix cost field in OSPFv2 Extended Prefix TLV.

Currently only way I can see is prefix needs to be adverti= sed in flex algo zero(as summary or external prefixes in legacy ospf) as we= ll as in flex algo 128 (OSPFv2 Extended Prefix TLV)

 

Thanks

Rajesh

 

 

 

Juniper Business Use Only

--_000_MN2PR05MB6080774E4DDE496BBC39B6FBBE490MN2PR05MB6080namp_-- From nobody Fri Aug 7 05:31:51 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414AB3A0BD4; Fri, 7 Aug 2020 05:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=djQVUDMl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=D4ncDf6L 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 H-Kfr4WkLWZt; Fri, 7 Aug 2020 05:31:48 -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 640D13A0BD2; Fri, 7 Aug 2020 05:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15303; q=dns/txt; s=iport; t=1596803508; x=1598013108; h=from:to:cc:subject:date:message-id:mime-version; bh=CsgPyBGSanGWtXq+W5fqdzyXUpE36/iC0kgKHw1e+IQ=; b=djQVUDMlbexGTNWGa+kg9GISEdAq+FcbWtZYjOy4vrl3RpdVSYe72OIR AUb/O9zMGfzpfB7UXhp3zG/qFC8r1NutuKtf15cNM3+Cf16WvMl52g2CS BHkWirvcqVokv1zi0MTX9hpQSJpDKnglGsV/3MjHGjZZrdNUZkmXd7yLu s=; IronPort-PHdr: =?us-ascii?q?9a23=3A++MF+h/eermm1f9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCCADdSC1f/49dJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBIy9RB29YLywKhCqDRgONUJN3hGyBQoERA1ULAQEBDAEBIwoCBAE?= =?us-ascii?q?BhEwCF4IfAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQQSCwYdAQEsCwE?= =?us-ascii?q?RAQgRAwEBASgDAgQwFAkKBAENBSKDBAGBfk0DLgEOqUQCgTmIYXaBMoMBAQE?= =?us-ascii?q?FgUdBgzYYgg4DBoE4gnCDX4ZAGoFBP4E4HIJNPoJcAgMBgSEFARIBQQ0JgmE?= =?us-ascii?q?zgi2Sf4Zgi1uQbAqCYohhkTUDHoJ8iVeTOpIrijqUdwIEAgQFAg4BAQWBaiN?= =?us-ascii?q?ncHAVOyoBgj5QFwINjh+DcYUUhUJ0AjUCBggBAQMJfI8OAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,445,1589241600"; d="scan'208,217";a="523506423" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2020 12:31:47 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 077CVlZS013917 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Aug 2020 12:31:47 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.1497.2; Fri, 7 Aug 2020 07:31:46 -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.1497.2; Fri, 7 Aug 2020 08:31:45 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 7 Aug 2020 07:31:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GQwNP5JTZ4pWngjG20NDDo+bWFjFBjTrDzl6DygaT/OSOz34AlrLS9WPmI9vBtMPMrVlH4mBBLQn7OsBWE4wgTLgmveo7BHmSHJPGZxm0+utPbGH7KwM1PG/ghJDkWO8+LlMF1+1UUJOfRDn8iGAdC5fvqWg22VFGoqpYS5lv+qH5vH3tqSLwstwQSLsk5feAkWhib4g1KNvIMr6gJvy9bfloStbaBR6AScMKW1omhOMhxYYh1SRfhavAY5EMmL4A6c0f1NLgb2mknh1VlfwWMtKmu08B0hrtzK9SZGFsYdv5pIIMXnepq1cmIZWFTby48vCtrm/aPJcCW250mj4+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CsgPyBGSanGWtXq+W5fqdzyXUpE36/iC0kgKHw1e+IQ=; b=APYlLQiKei1YI+Uz+aXbuTyJvFLitcC7qLEji1qzaVlaNac7zVc9ztFyZMrmDKw4Ah+qBLR68mhGtpB49VCKn81CsAWogWxypuU3Sc6q4Oj7zqmL0ZO2tePnp6zawx5gbQAwMsxbcL6KXp801RQdlX7s43CzwI+ZvuviCNR0Yh+qM3G0Ovu/ku7tep4brBJ1eIiF5+wVSosGvkbTQxxWNmkrJUGkvtA6DW+oAq9L020MkXApZfqJ1bUiceEUzHe/ICaCr1Q8u9eQ36a/6qyPnYTwCeVghIGa7dmQty7gbfLuFqv6CObqnsT6m1Ubxmh4mZrnd09uLfaDQNhzdJliTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CsgPyBGSanGWtXq+W5fqdzyXUpE36/iC0kgKHw1e+IQ=; b=D4ncDf6LcFBDr3aNw0kv06l6ZmjAH/aJVLrFRwPo43Y250lF0wnhKC2/7NdDvMciiaGbt6E0rrLNq1RuQCPruod+0Om5XI5DBQoTq2ew9ZgFKRChrxW6ECqQhO0ET+b4UYREWF7YzINZTXfbeE7B+DBy/beUs4xGb2ekamm5rk8= Received: from DM6PR11MB3626.namprd11.prod.outlook.com (2603:10b6:5:146::17) by DM5PR1101MB2251.namprd11.prod.outlook.com (2603:10b6:4:53::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Fri, 7 Aug 2020 12:31:45 +0000 Received: from DM6PR11MB3626.namprd11.prod.outlook.com ([fe80::7016:b776:e029:37d7]) by DM6PR11MB3626.namprd11.prod.outlook.com ([fe80::7016:b776:e029:37d7%7]) with mapi id 15.20.3261.019; Fri, 7 Aug 2020 12:31:45 +0000 From: "Ahmed Abdelsalam (ahabdels)" To: Huzhibo , James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption Call for draft-raza-spring-srv6-yang Thread-Index: AQHWbLa1VlfgygjvekS13AgBGii9LA== Date: Fri, 7 Aug 2020 12:31:44 +0000 Message-ID: <00684B14-C207-4CDB-B1EE-7895BBD69FE7@cisco.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [192.135.27.141] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9dd5dd0-d21d-4ead-78d2-08d83acdd8a1 x-ms-traffictypediagnostic: DM5PR1101MB2251: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iiSqlAGyoJLbjIt7V5szRdic5WVwr/46MS+awtafdReNSvz7hnOZZm8zflxXyFkOc6/oIodMSTN6+he5kbeChSFT4V3vPyB0oVQVVxHDjdIDm36SdY5euJOzuSlG9qbnEYdN/e7uQq2k7JxcWQ+Q6GTB+Po2fRtsbFdBKy3GlPA6FMAyGYTRyctK5iALP0NECdLJSgB/xOADHpc33SFP+8zE+17SvEvEVIaJwMTHE2ttag7Wjmwjg02D4b7Iltfa9fBnMaTfrOTm8A0xB7Z7+tQR4/bSR+mToV2wvqwLGpWiDcslo1Bg4hckJwk1ob4ev0psxP7c5u9/A7+lqO6a0oyNm+HKd7Mk9sumB/F/uvU14zKPdsfURDF/ArrRlOUZIzlYsolosfkP8jH6QK6dqg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3626.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(4326008)(166002)(36756003)(316002)(71200400001)(2906002)(966005)(86362001)(8676002)(110136005)(2616005)(6486002)(91956017)(8936002)(53546011)(6506007)(66446008)(76116006)(64756008)(66556008)(66476007)(478600001)(66946007)(83380400001)(5660300002)(26005)(186003)(6512007)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qlYfbiYer2vC3TohZhRHxvzPziYAzH/zvCGVG7Pqh1iQ1hW33rgS7vE3/W0H3+OAr/AzF0l5T8axpoMaexQdXgllKHZ2AMKdiD3cuc1WDQCWCWWLcViDiPRfPvL8gZLygiurvgZwCLH1ol6NUPdSuSx/iKRRKfv6VV1LtHnof8ft+Wb9z5RX8wacGKam5UjOyLXYaldy0e0/iEHfq6ZzLHERKpekMK8MkoWK+6pbe4/T2d8Gr5JaGqs/wlJ96HAiIkGvPgg8CA68auEPZ7nYuA8UNwNDi8c/Dihw2JDSOVda+fRTFRqPVwzWFdMN5LpSpAE8DLOADqrwp1hcMbumTLaOGkyjRk/RGzaT8nBeFRDQJbMiWvVUwOUYtLimSZ64EkUsj7n35VBdYSGy9321uRtgyplju+SNYiN1qTW3vUcEZQ/kplxsGAme/4BA+JTIm376u4ffTJ9qA8gNr6V5IVvisG4G7YMGANL8oy6F41ml1f6E3vlcfBurTsWW7RVWDsenYbNgw92Ye0r4w2yDQppcx9SnQb5Q0reZ+JlVh9lM2sIgGrtwHP09qYcAH+HcJbUkUB1Jk6BZfzIvnUah8DxyTkSNsv7jLeWal7mnt2AFyirdYgHn5aqlEuUoOUsy6LnW8BL4h2+ki99pxtWyVA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_00684B14C2074CDBB1EE7895BBD69FE7ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3626.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9dd5dd0-d21d-4ead-78d2-08d83acdd8a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2020 12:31:44.8963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I5L+yC01b6P0dATN9NFs2/B6SGoKrBtAEx04aVdjscF0wc5jv0tjZjtZhBkSFzDCtVr/CHeWzfTXuy2AroOjug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2251 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 12:31:50 -0000 --_000_00684B14C2074CDBB1EE7895BBD69FE7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBcyBhIGNvLWF1dGhvciwgSSBhbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIElQUiBy ZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rcw0KQWhtZWQNCg0KRnJvbTogc3ByaW5n IDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEh1emhpYm8gPGh1emhpYm9A aHVhd2VpLmNvbT4NCkRhdGU6IFRodXJzZGF5LCA2IEF1Z3VzdCAyMDIwIGF0IDEwOjAyDQpUbzog SmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4sICJzcHJpbmdA aWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQpDYzogInNwcmluZy1jaGFpcnNAaWV0Zi5vcmci IDxzcHJpbmctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIFdHIEFkb3B0 aW9uIENhbGwgZm9yIGRyYWZ0LXJhemEtc3ByaW5nLXNydjYteWFuZw0KDQpIaSBKaW0sIEpvZWwg JiBCcnVubywNCg0KQXMgYSBjby1hdXRob3IgSSBhbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xv c2VkIElQUiByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rcywNClpoaWJvDQoNCg0K RnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBKYW1lcyBHdWljaGFyZA0KU2VudDogVHVlc2RheSwgSnVseSAyOCwgMjAyMCA2OjQzIFBNDQpU bzogc3ByaW5nQGlldGYub3JnDQpDYzogc3ByaW5nLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtzcHJpbmddIFdHIEFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0LXJhemEtc3ByaW5nLXNydjYt eWFuZw0KDQpEZWFyIFdHOg0KDQpUaGUgMi13ZWVrIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXJh emEtc3ByaW5nLXNydjYteWFuZyBoYXMgbm93IGNsb3NlZC4gVGhlcmUgaXMgc3Ryb25nIHN1cHBv cnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgaW50byB0aGUgV0cgYW5kIHRoZXJlZm9y ZSBhdXRob3JzIHBsZWFzZSBwdWJsaXNoIGEgbmV3IHZlcnNpb24gYXMgZHJhZnQtaWV0Zi1zcHJp bmctc3J2Ni15YW5nLTAwLiBUaGUgY2hhaXJzIG5vdGUgdGhhdCBzZXZlcmFsIGNvbW1lbnRzIHdl cmUgcmVjZWl2ZWQgZHVyaW5nIHRoZSBhZG9wdGlvbiBjYWxsIHRvIGhlbHAgaW1wcm92ZSB0aGUg c3RydWN0dXJlIGFuZCBxdWFsaXR5IG9mIHRoZSBkb2N1bWVudDsgYXV0aG9ycyBwbGVhc2Ugd29y ayB3aXRoIHRoZSBwZW9wbGUgdGhhdCBwcm92aWRlZCB0aGVzZSBjb21tZW50cyB0byBpbmNvcnBv cmF0ZSB0aGVtIGFzIGFwcHJvcHJpYXRlIGludG8gdGhlIGRvY3VtZW50Lg0KDQpBdXRob3JzLCBw bGVhc2UgaW5kaWNhdGUgb24gdGhlIG1haWxpbmcgbGlzdCB3aGV0aGVyIHlvdSBhcmUgYXdhcmUg b2YgYW55IHVuZGlzY2xvc2VkIHJlbGV2YW50IElQUi4NCg0KVGhhbmtzIQ0KDQpKaW0sIEpvZWwg JiBCcnVubw0KDQoNCg0KDQoNCkZyb206IEphbWVzIEd1aWNoYXJkDQpTZW50OiBNb25kYXksIEp1 bHkgMTMsIDIwMjAgNTo1MiBQTQ0KVG86IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPg0KQ2M6IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1jaGFpcnNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBXRyBBZG9wdGlvbiBDYWxsIGZvciBkcmFmdC1yYXphLXNwcmlu Zy1zcnY2LXlhbmcNCg0KRGVhciBXRzoNCg0KVGhpcyBlbWFpbCBiZWdpbnMgYSAyIHdlZWsgV0cg YWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cmF6YS1zcHJpbmctc3J2Ni15YW5nLyBlbmRpbmcgTW9uZGF5IDI3dGggSnVseSAyMDIwLg0KDQpQ bGVhc2Ugc3BlYWsgdXAgaWYgeW91IHN1cHBvcnQgb3Igb3Bwb3NlIGFkb3B0aW5nIHRoaXMgZG9j dW1lbnQgaW50byB0aGUgV0cuIFBsZWFzZSBhbHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBm b3IgdGhhdCBzdXBwb3J0IChvciBsYWNrIHRoZXJlb2YpLiBTaWxlbmNlIHdpbGwgbm90IGJlIGNv bnNpZGVyZWQgY29uc2VudC4NCg0KVGhhbmtzIQ0KDQpKaW0sIEpvZWwgJiBCcnVubw0KDQoNCg0K DQoNCg== --_000_00684B14C2074CDBB1EE7895BBD69FE7ciscocom_ 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 YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iZW4tSVQiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBhIGNvLWF1dGhvciwgSSBhbSBu b3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIElQUiByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFobWVkIDxvOnA+DQo8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNwcmluZyAm bHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBIdXpoaWJvICZsdDto dXpoaWJvQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCA2IEF1Z3Vz dCAyMDIwIGF0IDEwOjAyPGJyPg0KPGI+VG86IDwvYj5KYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMu bi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0OywgJnF1b3Q7c3ByaW5nQGlldGYub3JnJnF1b3Q7 ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtzcHJpbmctY2hh aXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmctY2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW3NwcmluZ10gV0cgQWRvcHRpb24gQ2FsbCBmb3IgZHJhZnQtcmF6 YS1zcHJpbmctc3J2Ni15YW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBKaW0sIEpvZWwgJmFtcDsgQnJ1bm8s PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5BcyBhIGNvLWF1dGhvciBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgdW5k aXNjbG9zZWQgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+WmhpYm88L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbWVzIEd1aWNoYXJkPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEp1bHkgMjgsIDIwMjAgNjo0MyBQTTxicj4NCjxiPlRvOjwvYj4gc3ByaW5n QGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmctY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBDYWxsIGZvciBkcmFmdC1yYXph LXNwcmluZy1zcnY2LXlhbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIFdH Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIDItd2VlayBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1yYXph LXNwcmluZy1zcnY2LXlhbmcgaGFzIG5vdyBjbG9zZWQuIFRoZXJlIGlzIHN0cm9uZyBzdXBwb3J0 IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGludG8gdGhlIFdHIGFuZCB0aGVyZWZvcmUg YXV0aG9ycyBwbGVhc2UgcHVibGlzaCBhIG5ldyB2ZXJzaW9uDQogYXMgZHJhZnQtaWV0Zi1zcHJp bmctc3J2Ni15YW5nLTAwLiBUaGUgY2hhaXJzIG5vdGUgdGhhdCBzZXZlcmFsIGNvbW1lbnRzIHdl cmUgcmVjZWl2ZWQgZHVyaW5nIHRoZSBhZG9wdGlvbiBjYWxsIHRvIGhlbHAgaW1wcm92ZSB0aGUg c3RydWN0dXJlIGFuZCBxdWFsaXR5IG9mIHRoZSBkb2N1bWVudDsgYXV0aG9ycyBwbGVhc2Ugd29y ayB3aXRoIHRoZSBwZW9wbGUgdGhhdCBwcm92aWRlZCB0aGVzZSBjb21tZW50cyB0byBpbmNvcnBv cmF0ZSB0aGVtDQogYXMgYXBwcm9wcmlhdGUgaW50byB0aGUgZG9jdW1lbnQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5BdXRob3JzLCBwbGVhc2UgaW5kaWNhdGUgb24gdGhlIG1haWxpbmcgbGlzdCB3aGV0aGVy IHlvdSBhcmUgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIHJlbGV2YW50IElQUi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoYW5rcyE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkppbSwgSm9lbCAmYW1wOyBCcnVubw0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gSmFtZXMgR3VpY2hhcmQNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkg MTMsIDIwMjAgNTo1MiBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmciPnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFdHIEFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0LXJhemEtc3ByaW5n LXNydjYteWFuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkRlYXIgV0c6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLUNBIj5UaGlzIGVtYWlsIGJlZ2lucyBhIDIgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZv cg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1yYXphLXNwcmluZy1zcnY2LXlhbmcvIj48c3BhbiBsYW5nPSJF Ti1DQSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmF6YS1zcHJpbmct c3J2Ni15YW5nLzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj4gZW5kaW5nIE1v bmRheSAyNzxzdXA+dGg8L3N1cD4gSnVseSAyMDIwLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5QbGVhc2Ug c3BlYWsgdXAgaWYgeW91IHN1cHBvcnQgb3Igb3Bwb3NlIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQg aW50byB0aGUgV0cuIFBsZWFzZSBhbHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBmb3IgdGhh dCBzdXBwb3J0IChvciBsYWNrIHRoZXJlb2YpLiBTaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVy ZWQgY29uc2VudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoYW5rcyE8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkppbSwg Sm9lbCAmYW1wOyBCcnVubzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGk+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvaT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_00684B14C2074CDBB1EE7895BBD69FE7ciscocom_-- From nobody Fri Aug 7 12:28:05 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6A13A0F6D; Fri, 7 Aug 2020 12:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5rPVkn0cN4w; Fri, 7 Aug 2020 12:28:02 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 1F1543A0F32; Fri, 7 Aug 2020 12:28:02 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id l1so3016430ioh.5; Fri, 07 Aug 2020 12:28:02 -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=+g37kLAxMzvO2NSgxz8Nw1TESf2NIUJuHMxkDIzKVic=; b=eLwWRR9qdm0E0g6UjZ/U72XpYzlLzTz/2Q9fybb5nc3EJNTPAJIuPRxNf+SdcK/N4n CUGTE4tyl7yFal+EAkfvQL0B1miedbM3vFSeHkKXUOmSWBBgV5KhXt4qMn8hTf3pIkD1 TijgK8qabih07OT/hs8psGEchW9DU7NDYTL4U3mQiV3qVx6yION/6mruPCVFSDQkeqmX P/1Yvua4iStoWNrU9xZgXc6Lwb2jUYCtl0+ZMwQeKM8GsDtA6GNDo7Xak54rrAHDZVIO tOeZfy99OukRq7jJdge8g2LIsI+SvLOcXtRKk0rGFyzqQEMvNT7vng+8Tlj7p73LN+Y0 QrjA== 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=+g37kLAxMzvO2NSgxz8Nw1TESf2NIUJuHMxkDIzKVic=; b=cnRcr2v0cpJmvwJKnPnOrqjUI73+jOoN3PF4r6AUgvPMaVZgg9wgPsmKwzu8Ly+HsU XpqB0LiV+qtexalkxhLmRB4FiGKZHRUfixCKrDiGJktfeC/gygy1Js5gDhC/XjJv+W+M 4b6C1wQszn3Mziczwp6qzevD/xu4wB0ApHOK65egOMevYJU/yQioF4ZNIIGnqGsJV2ON SJ1sK9mvrmfNT4qF7cwrkNsvyMEixi3td4cZwMgf+446O9Wgrors/g7BFxydp44/g8yh OJpnxtyHmsIg7jNdA1xJfxqPzUN2+JBAmf7yEIPYVqF9IEnWYD83WvDBz/RVBYLzTf5z VLPA== X-Gm-Message-State: AOAM530hSgef1K6a8KRvwK1svBfBSlkz14wbhc9XDFgKHq+ymCI7zEVF BFyKhtQ0OopMd1SRf0X2vMen3b6PW3WQMKccT4g= X-Google-Smtp-Source: ABdhPJyMIj9EPrjSUaCDyoZ9XAJmp8AZDsHqKMohiL2P89mZ2hVbFbsaRyqcF1YP840tgVWo7QMytrQEPIAk95t6lj0= X-Received: by 2002:a05:6638:2604:: with SMTP id m4mr6612037jat.76.1596828481230; Fri, 07 Aug 2020 12:28:01 -0700 (PDT) MIME-Version: 1.0 References: <00684B14-C207-4CDB-B1EE-7895BBD69FE7@cisco.com> In-Reply-To: <00684B14-C207-4CDB-B1EE-7895BBD69FE7@cisco.com> From: Xufeng Liu Date: Fri, 7 Aug 2020 15:27:50 -0400 Message-ID: To: "Ahmed Abdelsalam (ahabdels)" Cc: Huzhibo , James Guichard , "spring@ietf.org" , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000641b8505ac4e9a1d" Archived-At: Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 19:28:04 -0000 --000000000000641b8505ac4e9a1d Content-Type: text/plain; charset="UTF-8" I am not aware of any undisclosed relevant IPR. Thanks, - Xufeng On Fri, Aug 7, 2020 at 8:32 AM Ahmed Abdelsalam (ahabdels) wrote: > > > As a co-author, I am not aware of any undisclosed IPR related to this > document. > > > > Thanks > > Ahmed > > > > *From: *spring on behalf of Huzhibo < > huzhibo@huawei.com> > *Date: *Thursday, 6 August 2020 at 10:02 > *To: *James Guichard , "spring@ietf.org" < > spring@ietf.org> > *Cc: *"spring-chairs@ietf.org" > *Subject: *Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang > > > > Hi Jim, Joel & Bruno, > > > > As a co-author I am not aware of any undisclosed IPR related to this > document. > > > > Thanks, > > Zhibo > > > > > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *James > Guichard > *Sent:* Tuesday, July 28, 2020 6:43 PM > *To:* spring@ietf.org > *Cc:* spring-chairs@ietf.org > *Subject:* Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang > > > > Dear WG: > > > > The 2-week adoption call for draft-raza-spring-srv6-yang has now closed. > There is strong support for adoption of this document into the WG and > therefore authors please publish a new version as > draft-ietf-spring-srv6-yang-00. The chairs note that several comments were > received during the adoption call to help improve the structure and quality > of the document; authors please work with the people that provided these > comments to incorporate them as appropriate into the document. > > > > Authors, please indicate on the mailing list whether you are aware of any > undisclosed relevant IPR. > > > > Thanks! > > > > Jim, Joel & Bruno > > > > > > > > > > > > *From:* James Guichard > *Sent:* Monday, July 13, 2020 5:52 PM > *To:* spring@ietf.org > *Cc:* spring-chairs@ietf.org > *Subject:* WG Adoption Call for draft-raza-spring-srv6-yang > > > > Dear WG: > > > > This email begins a 2 week WG adoption call for > https://datatracker.ietf.org/doc/draft-raza-spring-srv6-yang/ ending > Monday 27th July 2020. > > > > Please speak up if you support or oppose adopting this document into the > WG. Please also provide comments/reasons for that support (or lack > thereof). Silence will not be considered consent. > > > > Thanks! > > > > Jim, Joel & Bruno > > > > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000641b8505ac4e9a1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any undisclose= d relevant IPR.

Thanks,
- Xufen= g

On Fri, Aug 7, 2020 at 8:32 AM Ahmed Abdelsalam (ahabdels= ) <ahabdels=3D40cisco.com@= dmarc.ietf.org> wrote:

=C2=A0

As a co-author, I am not aware = of any undisclosed IPR related to this document.

=C2=A0

Thanks

Ahmed

=C2=A0

From: spring <spring-bounces@ietf.org<= /a>> on behalf of Huzhibo <huzhibo@huawei.com>
Date: Thursday, 6 August 2020 at 10:02
To: James Guichard <james.n.guichard@futurewei.com>, "spring@ietf.org" &l= t;spring@ietf.org&= gt;
Cc: "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-ya= ng

=C2=A0

Hi J= im, Joel & Bruno,

=C2= =A0

As a= co-author I am not aware of any undisclosed IPR related to this document.<= /span>

=C2= =A0

Than= ks,

Zhib= o

=C2=A0

=C2=A0

F= rom: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
Sent: Tuesday, July 28, 2020 6:43 PM
To: spring@ietf= .org
Cc: spri= ng-chairs@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-ya= ng

=C2= =A0

Dear= WG:

=C2= =A0

The = 2-week adoption call for draft-raza-spring-srv6-yang has now closed. There = is strong support for adoption of this document into the WG and therefore a= uthors please publish a new version as draft-ietf-spring-srv6-yang-00. The chairs note that several comments w= ere received during the adoption call to help improve the structure and qua= lity of the document; authors please work with the people that provided the= se comments to incorporate them as appropriate into the document.

=C2= =A0

Auth= ors, please indicate on the mailing list whether you are aware of any undis= closed relevant IPR.

=C2= =A0

Than= ks!

=C2= =A0

Jim,= Joel & Bruno

=C2= =A0

=C2= =A0

=C2=A0

=C2= =A0

=C2= =A0

F= rom: James Guichard
Sent: Monday, July 13, 2020 5:52 PM
To: spring@ietf= .org
Cc: spri= ng-chairs@ietf.org
Subject: WG Adoption Call for draft-raza-spring-srv6-yang<= /u>

=C2= =A0

Dear= WG:

=C2= =A0

This= email begins a 2 week WG adoption call for https://d= atatracker.ietf.org/doc/draft-raza-spring-srv6-yang/ ending Monday 27th July 2020.

=C2= =A0

Plea= se speak up if you support or oppose adopting this document into the WG. Pl= ease also provide comments/reasons for that support (or lack thereof). Sile= nce will not be considered consent.

=C2= =A0

Than= ks!

=C2= =A0

Jim,= Joel & Bruno

=C2= =A0

=C2= =A0

=C2= =A0

=C2= =A0

=C2= =A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000641b8505ac4e9a1d-- From nobody Sat Aug 8 19:02:11 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FE23A0B68; Sat, 8 Aug 2020 19:02:09 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tencent.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 n306EFYpjNH0; Sat, 8 Aug 2020 19:02:07 -0700 (PDT) Received: from mail3.tencent.com (mail3.tencent.com [203.205.248.63]) (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 40D8E3A0B65; Sat, 8 Aug 2020 19:02:05 -0700 (PDT) Received: from EX-SZ022.tencent.com (unknown [10.28.6.88]) by mail3.tencent.com (Postfix) with ESMTP id D80B394230; Sun, 9 Aug 2020 10:02:03 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tencent.com; s=s202002; t=1596938523; bh=CnBq5wVWzR+ceVSY/Q1A26fP2Y5rYHge8GAI4lxOjOg=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=aYXGPFFQl44EwX62ochtY9X1WOTxmUXJrB6vSg46JtB56si3kJ4A7ld2YbKZjOB8J DJi/L7KPXPdMi7tRxNzyctEu2Yd7QY2hMD2JyIckht9Ht5vANwS3Dj7YEGFYFpa2Bq LtLE1EPkNiODWWoIaxgN1J+B0ePxyZM+u4ez6vqo= Received: from EX-SZ013.tencent.com (10.28.6.37) by EX-SZ022.tencent.com (10.28.6.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Sun, 9 Aug 2020 10:02:03 +0800 Received: from EX-SZ001.tencent.com (10.28.6.13) by EX-SZ013.tencent.com (10.28.6.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Sun, 9 Aug 2020 10:02:03 +0800 Received: from EX-SZ001.tencent.com ([::1]) by EX-SZ001.tencent.com ([fe80::2d53:13c5:4658:be7c%3]) with mapi id 15.01.1847.007; Sun, 9 Aug 2020 10:02:03 +0800 From: =?utf-8?B?b2xpdmVyeHUo6K646ZSLKQ==?= To: "bruno.decraene@orange.com" CC: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Thread-Topic: IPR call for draft-hegde-spring-node-protection-for-sr-te-paths (Internet mail) Thread-Index: AdZma5H21rW/nBxlQ0eIj3Dz1SvK1QDHpGpgARm6PwA= Date: Sun, 9 Aug 2020 02:02:03 +0000 Message-ID: <6B3C68B0-4179-4D32-8246-F97CAEE93D39@tencent.com> References: <20504_1596111876_5F22BC04_20504_97_1_53C29892C857584299CBF5D05346208A48F028FC@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.2.27] Content-Type: multipart/alternative; boundary="_000_6B3C68B041794D328246F97CAEE93D39tencentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] IPR call for draft-hegde-spring-node-protection-for-sr-te-paths (Internet mail) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 02:02:09 -0000 --_000_6B3C68B041794D328246F97CAEE93D39tencentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSDQoNClJnZHMNCg0KT2xpdmVyDQoNCg0KDQoNCg0K SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KRnJvbTogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bSA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAy MDIwIDU6NTUgUE0NClRvOiBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2Rl LXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzQGlldGYub3JnDQpTdWJqZWN0OiBJUFIgY2FsbCBm b3IgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMNCg0K W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KDQpIaSBBdXRob3JzLCBT UFJJTkcgV0csDQoNCkF1dGhvcnMgb2YgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlv bi1mb3Itc3ItdGUtcGF0aHMgWzFdIGhhdmUgYXNrZWQgZm9yIFdHIGFkb3B0aW9uLg0KDQpUaGlz IGVtYWlsIHN0YXJ0cyBhIHBvbGwgZm9yIElQUi4NCg0KSWYgeW91IGFyZSBhd2FyZSBvZiBJUFIg dGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNy LXRlLXBhdGhzIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwuDQpJZiB5b3UgYXJlIGF3YXJl IG9mIElQUiwgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkIGlu IGFjY29yZGFuY2UgdG8gdGhlIElFVEYgSVBSIHJ1bGVzIChkZXRhaWxlZCBhcmUgZGVzY3JpYmVk IGluIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCkuDQoNCklmIHlvdSBhcmUgYW4gKmF1 dGhvciBvciBjb250cmlidXRvciogcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCwgb24gdGhl IFNQUklORyBtYWlsaW5nIGxpc3QsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91J3Jl IGF3YXJlIG9mIGFueSBJUFIuDQpJZiB5b3UgYXJlIG5vdCBhbiBhdXRob3Igb3IgY29udHJpYnV0 b3IsIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UncmUgYXdhcmUgb2YgSVBS IHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQuDQoNClRoYW5rcywNClJlZ2FyZHMsDQpC cnVubywgSmltLCBKb2VsDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDc8aHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlZ2Rl LXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3X187ISFORXQ2eU1hTy1n ayFReDhFRjFNbF9qV1lxZTdUYjV0TklZX09LRUNzUC1wUXVLNFcyTEV0MXM0a1VBNFYxakhOcWly WHR2NDh3Uzl4JD4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0K T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u DQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz Lg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoN ClRoYW5rIHlvdS4NCg== --_000_6B3C68B041794D328246F97CAEE93D39tencentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <532AE99759C44C42967750E3DBD8E6B9@tencent.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TGF0bzsNCglwYW5vc2UtMToyIDExIDYgNCAy IDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOetiee6vyI7DQoJcGFu b3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+ 5qC85byPIOWtl+espiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN TA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8g5a2X56ymIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNpcGZvb3RlcjMwYjNkNTM4LCBsaS5tc2lw Zm9vdGVyMzBiM2Q1MzgsIGRpdi5tc2lwZm9vdGVyMzBiM2Q1MzgNCgl7bXNvLXN0eWxlLW5hbWU6 bXNpcGZvb3RlcjMwYjNkNTM4Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGlu az0iIzA1NjNDMSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFt IG5vdCBhd2FyZSBvZiBhbnkgSVBSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZ2RzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5PbGl2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkRlbmdYaWFuIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0ibXNpcGZvb3RlcjMwYjNkNTM4IiBhbGlnbj0iY2VudGVyIiBz dHlsZT0ibWFyZ2luOjBjbTt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+SnVuaXBlciBCdXNpbmVzcyBVc2Ug T25seTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tICZsdDticnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tJmd0Ow0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDMwLCAyMDIwIDU6NTUgUE08YnI+DQo8 Yj5Ubzo8L2I+IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVj dGlvbi1mb3Itc3ItdGUtcGF0aHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSVBSIGNh bGwgZm9yIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhz IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0O2JhY2tncm91bmQ6 I0ZGRUI5QyI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkxhdG87Y29sb3I6YmxhY2siPltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2Yg Y29udGVudF08L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkhpIEF1dGhvcnMsIFNQUklORyBXRyw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj5BdXRob3JzIG9mIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24t Zm9yLXNyLXRlLXBhdGhzIFsxXSBoYXZlIGFza2VkIGZvciBXRyBhZG9wdGlvbi48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj5UaGlzIGVtYWlsIHN0YXJ0cyBhIHBvbGwgZm9yIElQUi48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JZiB5 b3UgYXJlIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaGVnZGUtc3ByaW5nLW5v ZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JZiB5b3UgYXJlIGF3YXJlIG9mIElQ UiwgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGFjY29y ZGFuY2UgdG8gdGhlIElFVEYgSVBSIHJ1bGVzIChkZXRhaWxlZCBhcmUgZGVzY3JpYmVkIGluIFJG Q3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SWYgeW91IGFyZSBh biAqYXV0aG9yIG9yIGNvbnRyaWJ1dG9yKiBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsLCBv biB0aGUgU1BSSU5HIG1haWxpbmcgbGlzdCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5 b3UncmUgYXdhcmUgb2YgYW55IElQUi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5J ZiB5b3UgYXJlIG5vdCBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSBleHBsaWNpdGx5 IHJlc3BvbmQgb25seSBpZiB5b3UncmUgYXdhcmUgb2YgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVl biBkaXNjbG9zZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhhbmtzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+QnJ1bm8s IEppbSwgSm9lbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlsxXSA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wN19f OyEhTkV0NnlNYU8tZ2shUXg4RUYxTWxfaldZcWU3VGI1dE5JWV9PS0VDc1AtcFF1SzRXMkxFdDFz NGtVQTRWMWpITnFpclh0djQ4d1M5eCQiPjxzcGFuIGxhbmc9IkVOLUdCIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3It dGUtcGF0aHMtMDc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHBy ZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_6B3C68B041794D328246F97CAEE93D39tencentcom_-- From nobody Sun Aug 9 17:59:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95CA3A12E3; Sun, 9 Aug 2020 17:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Fe64euxnVapM; Sun, 9 Aug 2020 17:59:54 -0700 (PDT) Received: from out0-150.mail.aliyun.com (out0-150.mail.aliyun.com [140.205.0.150]) (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 5232D3A12E2; Sun, 9 Aug 2020 17:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1597021189; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=vxGB5hXUSAeyGVdDQxRbX5JSZ6oN1Cgl1aGbcFjYo2U=; b=bqNS5lKEBWsXmoafoiTqPTHbid6IcFQ2PLF7jQTeXfGJwKJtIArtWunTV5biqAnpbMantNpuAsU9h80IZ5yeFn+V2yFzih9vsO0gy8l+d41Wo9XGuiQjZA41Yob+AHDrlwMit9sSIzWwa2QrSHAwl/NVgRQbVgM6cfkO70cgIw0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R321e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03268; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=3; SR=0; TI=dingding_ios.COREAPI360f9f686c024f3fb623b8904015a2de; Received: from WS-web (xiaohu.xxh@alibaba-inc.com[dingding_ios.COREAPI360f9f686c024f3fb623b8904015a2de]) by e01l07447.eu6 at Mon, 10 Aug 2020 08:59:47 +0800 Date: Mon, 10 Aug 2020 08:59:47 +0800 From: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" To: "spring" , "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Message-ID: <9f5d71b2-3f32-4b64-a8a4-440e3239d506.xiaohu.xxh@alibaba-inc.com> X-Priority: 0 X-Mailer: [Alimail-Mailagent] MIME-Version: 1.0 In-Reply-To: <20504_1596111876_5F22BC04_20504_97_1_53C29892C857584299CBF5D05346208A48F028FC@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <20504_1596111876_5F22BC04_20504_97_1_53C29892C857584299CBF5D05346208A48F028FC@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_26720_4d96c940_5f309c03_4a917" Archived-At: Subject: [spring] =?utf-8?b?5Zue5aSN77yaIElQUiBjYWxsIGZvciBkcmFmdC1oZWdk?= =?utf-8?q?e-spring-node-protection-for-sr-te-paths?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 00:59:56 -0000 ------=ALIBOUNDARY_26720_4d96c940_5f309c03_4a917 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IAoKSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuCgp4aWFv aHUKCgoKCgrmnaXoh6rpkonpkonkuJPlsZ7llYbliqHpgq7nrrEtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K5Y+R5Lu25Lq6 77yaPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+CuaXpeOAgOacn++8mjIwMjDlubQwN+aciDMw 5pelIDIwOjI0OjM1CuaUtuS7tuS6uu+8mnNwcmluZ0BpZXRmLm9yZzxzcHJpbmdAaWV0Zi5vcmc+ OyBkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRoc0BpZXRm Lm9yZzxkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRoc0Bp ZXRmLm9yZz4K5Li744CA6aKY77yaW3NwcmluZ10gSVBSIGNhbGwgZm9yIGRyYWZ0LWhlZ2RlLXNw cmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzCgogICAgICAgIApIaSBBdXRob3Jz LCBTUFJJTkcgV0csCiAKQXV0aG9ycyBvZiBkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0 aW9uLWZvci1zci10ZS1wYXRocyBbMV0gaGF2ZSBhc2tlZCBmb3IgV0cgYWRvcHRpb24uCiAKVGhp cyBlbWFpbCBzdGFydHMgYSBwb2xsIGZvciBJUFIuCiAKSWYgeW91IGFyZSBhd2FyZSBvZiBJUFIg dGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNy LXRlLXBhdGhzIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwuCklmIHlvdSBhcmUgYXdhcmUg b2YgSVBSLCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQgaW4g YWNjb3JkYW5jZSB0byB0aGUgSUVURiBJUFIgcnVsZXMgKGRldGFpbGVkIGFyZSBkZXNjcmliZWQg aW4gUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4KS4KIApJZiB5b3UgYXJlIGFuICphdXRo b3Igb3IgY29udHJpYnV0b3IqIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwsIG9uIHRoZSBT UFJJTkcgbWFpbGluZyBsaXN0LCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSdyZSBh d2FyZSBvZiBhbnkgSVBSLgpJZiB5b3UgYXJlIG5vdCBhbiBhdXRob3Igb3IgY29udHJpYnV0b3Is IHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UncmUgYXdhcmUgb2YgSVBSIHRo YXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQuCiAKVGhhbmtzLApSZWdhcmRzLApCcnVubywg SmltLCBKb2VsCiAKWzFdICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGVnZGUt c3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDcKICAKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4NClRoYW5rIHlvdS4NCiAgCg== ------=ALIBOUNDARY_26720_4d96c940_5f309c03_4a917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 IDxicj48YnI+SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQu PGJyPjxicj54aWFvaHU8YnI+PGJyPjxicj48YnI+PGJyPjxicj48ZGl2IGlkPSJiYWxpLXNpZ24i PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OlBpbmdGYW5nU0MtUmVndWxhcjtmb250LXNpemU6MTRw eDtjb2xvcjojNjY2OyI+PGEgc3R5bGU9ImNvbG9yOiMzOGFkZmY7IHRleHQtZGVjb3JhdGlvbjpu b25lOyIgaHJlZj0iKG51bGwpIj7mnaXoh6rpkonpkonkuJPlsZ7llYbliqHpgq7nrrE8L2E+PC9k aXY+PC9kaXY+PGJsb2NrcXVvdGU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIC8+5Y+R5Lu25Lq677yaJmx0O2JydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20mZ3Q7PGJyIC8+5pel44CA5pyf77yaMjAyMOW5tDA35pyIMzDm l6UgMjA6MjQ6MzU8YnIgLz7mlLbku7bkurrvvJpzcHJpbmdAaWV0Zi5vcmcmbHQ7c3ByaW5nQGll dGYub3JnJmd0OzsgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUt cGF0aHNAaWV0Zi5vcmcmbHQ7ZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3It c3ItdGUtcGF0aHNAaWV0Zi5vcmcmZ3Q7PGJyIC8+5Li744CA6aKY77yaW3NwcmluZ10gSVBSIGNh bGwgZm9yIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhz PGJyIC8+PGJyIC8+PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFz Lm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMu b3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+DQo8bWV0YSBuYW1lPSJQ cm9nSWQiIGNvbnRlbnQ9IldvcmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNSI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iY2lk OmZpbGVsaXN0LnhtbEAwMUQ2NjY3RC4yNUZCRUE2MCI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPG86UmVseU9uVk1MLz4NCjxvOkFsbG93UE5H Lz4NCjwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8dzpXb3JkRG9jdW1lbnQ+DQo8dzpTcGVsbGluZ1N0YXRlPkNs ZWFuPC93OlNwZWxsaW5nU3RhdGU+DQo8dzpUcmFja01vdmVzLz4NCjx3OlRyYWNrRm9ybWF0dGlu Zy8+DQo8dzpIeXBoZW5hdGlvblpvbmU+MjE8L3c6SHlwaGVuYXRpb25ab25lPg0KPHc6RW52ZWxv cGVWaXMvPg0KPHc6UHVuY3R1YXRpb25LZXJuaW5nLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVt YXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6 SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5 c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4N Cjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RlI8L3c6TGlkVGhlbWVPdGhl cj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpMaWRUaGVt ZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBh dGliaWxpdHk+DQo8dzpCcmVha1dyYXBwZWRUYWJsZXMvPg0KPHc6U25hcFRvR3JpZEluQ2VsbC8+ DQo8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQo8dzpVc2VBc2lhbkJyZWFrUnVsZXMvPg0KPHc6RG9u dEdyb3dBdXRvZml0Lz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkVuYWJsZU9w ZW5UeXBlS2VybmluZy8+DQo8dzpEb250RmxpcE1pcnJvckluZGVudHMvPg0KPHc6T3ZlcnJpZGVU YWJsZVN0eWxlSHBzLz4NCjwvdzpDb21wYXRpYmlsaXR5Pg0KPG06bWF0aFByPg0KPG06bWF0aEZv bnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxt OmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0K PG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIw Ii8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9 IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1 bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRl PSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBEZWZTZW1pSGlkZGVuPSJmYWxzZSIg RGVmUUZvcm1hdD0iZmFsc2UiIERlZlByaW9yaXR5PSI5OSIgTGF0ZW50U3R5bGVDb3VudD0iMzcx Ij4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iTm9ybWFsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Imlu ZGV4IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJpbmRleCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaW5kZXggNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA4Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJ0b2MgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i dG9jIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0idG9jIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIElu ZGVudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290bm90ZSB0ZXh0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImFubm90YXRpb24gdGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJoZWFkZXIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Imlu ZGV4IGhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzUiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJjYXB0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRhYmxlIG9mIGZpZ3VyZXMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgYWRkcmVzcyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJlbnZlbG9wZSByZXR1cm4iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUg cmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gcmVmZXJlbmNlIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9ImxpbmUgbnVtYmVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InBhZ2UgbnVtYmVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVuZG5vdGUgcmVmZXJlbmNlIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9ImVuZG5vdGUgdGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0YWJsZSBvZiBhdXRob3JpdGllcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJtYWNybyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2EgaGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJM aXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9Ikxpc3QgTnVtYmVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IEJ1bGxldCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IEJ1bGxldCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkNsb3NpbmciLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjEiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJE ZWZhdWx0IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9Ikxpc3QgQ29udGludWUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51 ZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBD b250aW51ZSA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik1lc3NhZ2UgSGVhZGVyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJTdWJ0aXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTYWx1dGF0aW9uIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IkRhdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEZp cnN0IEluZGVudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgRmlyc3QgSW5kZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm90ZSBIZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IkJvZHkgVGV4dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmxvY2sg VGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIeXBlcmxpbmsiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iRm9sbG93ZWRIeXBlcmxpbmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMjIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i RW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRG9jdW1lbnQgTWFwIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlBsYWluIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRS1tYWlsIFNp Z25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFRvcCBvZiBGb3JtIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IkhUTUwgQm90dG9tIG9mIEZvcm0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iTm9ybWFsIChXZWIpIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQWNyb255bSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFkZHJlc3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i SFRNTCBDaXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ29kZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJIVE1MIERlZmluaXRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBL ZXlib2FyZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFByZWZvcm1hdHRlZCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFNhbXBsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1M IFR5cGV3cml0ZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBWYXJpYWJsZSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJOb3JtYWwgVGFibGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5u b3RhdGlvbiBzdWJqZWN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vIExpc3QiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iT3V0bGluZSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iT3V0 bGluZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iT3V0bGluZSBMaXN0IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU2ltcGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgU2ltcGxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU2ltcGxlIDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIENsYXNzaWMgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2lj IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg Q29sb3JmdWwgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBDb2x1bW5zIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2x1bW5zIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3Jp ZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBHcmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBHcmlkIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA3Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBMaXN0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBMaXN0IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA4Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSAzRCBlZmZlY3RzIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0 cyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbnRlbXBvcmFyeSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBFbGVnYW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IFByb2Zlc3Npb25hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTdWJ0bGUgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTdWJ0bGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBXZWIgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBXZWIgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBXZWIgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCYWxs b29uIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzki IE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgVGhlbWUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJQ bGFjZWhvbGRlciBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExp c3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9 IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1 bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjci IE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGln aHQgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIE5hbWU9IlJldmlzaW9u Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM0IiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIyOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFFGb3JtYXQ9InRydWUiIE5h bWU9IkludGVuc2UgUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFt ZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwg R3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQg R3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFt ZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQg MSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBM aXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJD b2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1l PSJMaWdodCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRp dW0gR3JpZCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1l PSJEYXJrIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3Qg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMi IE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExp c3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5h bWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlk IDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3Jm dWwgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0i TGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExp c3QgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVk aXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1l PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5n IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx IiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJN ZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBO YW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRp bmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTkiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIyMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBFbXBoYXNpcyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzMiIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBSZWZlcmVu Y2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFFGb3Jt YXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMzciIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0MSIgTmFtZT0iUGxhaW4gVGFibGUgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MiIgTmFtZT0iUGxhaW4gVGFibGUgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MyIgTmFtZT0iUGxhaW4g VGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NCIg TmFtZT0iUGxhaW4gVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NSIgTmFtZT0iUGxhaW4gVGFibGUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0MCIgTmFtZT0iR3JpZCBUYWJsZSBMaWdodCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAx IExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJHcmlkIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3Jp ZCBUYWJsZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIg TmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUg NCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIg TmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h bWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAi IE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5h bWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1l PSJHcmlkIFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBO YW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1l PSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i R3JpZCBUYWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFt ZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0i R3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikdy aWQgVGFibGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9 IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikdy aWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlk IFRhYmxlIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJH cmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlk IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0 IFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDki IE5hbWU9Ikxpc3QgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlz dCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIg TmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUg NSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBD b2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5h bWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUg RGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29s b3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1l PSJMaXN0IFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERh cmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9y ZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0i TGlzdCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJr IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUx IiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1 bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxp c3QgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIg TmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYi IE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0 IFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5h bWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFj Y2VudCA2Ii8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1h bHQ6IkNhbGlzdG8gTVQiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250 LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWdu YXR1cmU6LTUzNjg2OTEyMSAxMTA3MzA1NzI3IDMzNTU0NDMyIDAgNDE1IDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0 Ow0KCW1zby1mb250LWFsdDoiQmllbnZlbnVlIFRUIjsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJ bXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7 DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NTg4ODEgLTEwNzM3MzI0ODUgOSAwIDUxMSAwO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVz Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFu c2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCW1zby1zdHlsZS1ub3Nob3c6 eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsN Cgltc28tYmlkaS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30NCi4u TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVs dC1wcm9wczp5ZXM7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7DQoJbXNvLWhlYWRl ci1tYXJnaW46MzYuMHB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjM2LjBwdDsNCgltc28tcGFwZXIt c291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyAxMF0+PHN0eWxlPi8qIFN0eWxlIERlZmluaXRpb25zICov DQp0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGVhdSBOb3JtYWwi Ow0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6 MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGNtIDUuNHB0IDBjbSA1LjRwdDsN Cgltc28tcGFyYS1tYXJnaW46MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQo8 L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6MzUuNHB0Ij4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 Im1zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5IaSBBdXRob3JzLCBTUFJJTkcgV0csPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5z aS1sYW5ndWFnZTpFTi1HQiI+QXV0aG9ycyBvZiBkcmFmdC08c3BhbiBjbGFzcz0iU3BlbGxFIj5o ZWdkZTwvc3Bhbj4tc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3ItPHNwYW4gY2xhc3M9IlNwZWxs RSI+c3I8L3NwYW4+LTxzcGFuIGNsYXNzPSJTcGVsbEUiPnRlPC9zcGFuPi1wYXRocyBbMV0gaGF2 ZSBhc2tlZCBmb3IgV0cgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhpcyBl bWFpbCBzdGFydHMgYSBwb2xsIGZvciBJUFIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTpFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+SWYg eW91IGFyZSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LTxzcGFuIGNsYXNzPSJT cGVsbEUiPmhlZ2RlPC9zcGFuPi1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci08c3BhbiBjbGFz cz0iU3BlbGxFIj5zcjwvc3Bhbj4tPHNwYW4gY2xhc3M9IlNwZWxsRSI+dGU8L3NwYW4+LXBhdGhz IHBsZWFzZSByZXNwb25kDQogdG8gdGhpcyBlbWFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1hbnNpLWxh bmd1YWdlOkVOLUdCIj5JZiB5b3UgYXJlIGF3YXJlIG9mIElQUiwgcGxlYXNlIGluZGljYXRlIHdo ZXRoZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGFjY29yZGFuY2UgdG8gdGhlIElFVEYgSVBS IHJ1bGVzIChkZXRhaWxlZCBhcmUgZGVzY3JpYmVkIGluIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBh bmQgNTM3OCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+SWYgeW91IGFyZSBhbiAqYXV0aG9y IG9yIGNvbnRyaWJ1dG9yKiBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsLCBvbiB0aGUgU1BS SU5HIG1haWxpbmcgbGlzdCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UncmUgYXdh cmUgb2YgYW55IElQUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5JZiB5 b3UgYXJlIG5vdCBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSBleHBsaWNpdGx5IHJl c3BvbmQgb25seSBpZiB5b3UncmUgYXdhcmUgb2YgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBk aXNjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1s YW5ndWFnZTpFTi1HQiI+QnJ1bm8sIEppbSwgSm9lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFu Z3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0Ii PlsxXSA8L3NwYW4+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDciPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10 ZS1wYXRocy0wNzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1s YW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQpUaGFuayB5b3UuDQo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo8YnI+PC9ibG9ja3F1b3RlPg== ------=ALIBOUNDARY_26720_4d96c940_5f309c03_4a917-- From nobody Tue Aug 11 08:22:02 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472543A1167; Tue, 11 Aug 2020 08:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bell.ca 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 NZHYDi647j81; Tue, 11 Aug 2020 08:21:36 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.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 CCD453A111E; Tue, 11 Aug 2020 08:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1597159296; x=1628695296; h=from:to:cc:date:message-id:mime-version:subject; bh=ydFBXeakmiXBRDft5NqnfKO6I1mGbO+DkAfac8d7JvQ=; b=TsDgrt4Oe2mFDiaz+uzLPGShQQuJhG1YnGjqRepXuoQp25kUt5q/wwqe nzGA1tAt5JveVSlH/cml4VFQDOdd1iFd2qu9R61jiVvTXQ/y4FI1nIp4j QBy3PthThczlxVL1APr3ZRTyBYN11MuBZ56sdbnOlBzV29TTaxuPAWiue zcpBrsosRfeOQnTHS9m0iMzAuOZSSeNOeHWr/X7nZHeEr+GaqnSJgNwsZ YerrgnwLnbhIIZpCUn3ZWWiNyx1Qv5Lr4wl2K7WboZitqPQ/AhafqmhDX 45pScDBzoM45V8iLn7GstbhoAdWextR0c5SjmmU7NmqbARvM6ZBoY/ZaO g==; IronPort-SDR: AEipIfGkSER7fP/N2jM3jcsgKz+6q7MQ5y34GXZeK7qm8fcrMRBi19b0AVFioIXEdR2BP+NPuw yeoIYuBnDqVA== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG1MBX04-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 11 Aug 2020 11:21:34 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 11:21:33 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::18c0:101b:f25e:acdc]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::18c0:101b:f25e:acdc%22]) with mapi id 15.00.1497.006; Tue, 11 Aug 2020 11:21:33 -0400 From: "Voyer, Daniel" To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: [EXT]Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang Thread-Index: AQHWb/MYDydaQE2Ey0ul7rO+utGKbw== Date: Tue, 11 Aug 2020 15:21:33 +0000 Message-ID: <1F3812EF-78E0-465E-B14E-89CEE19D0283@bell.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.6] Content-Type: multipart/alternative; boundary="_000_1F3812EF78E0465EB14E89CEE19D0283bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 15:21:45 -0000 --_000_1F3812EF78E0465EB14E89CEE19D0283bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgY28tYXV0aG9yLCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIElQUi4NCg0K ZGFuDQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBKYW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0KRGF0ZTog VHVlc2RheSwgSnVseSAyOCwgMjAyMCBhdCA2OjQzIEFNDQpUbzogInNwcmluZ0BpZXRmLm9yZyIg PHNwcmluZ0BpZXRmLm9yZz4NCkNjOiAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgPHNwcmluZy1j aGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhUXVJlOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBD YWxsIGZvciBkcmFmdC1yYXphLXNwcmluZy1zcnY2LXlhbmcNCg0KRGVhciBXRzoNCg0KVGhlIDIt d2VlayBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1yYXphLXNwcmluZy1zcnY2LXlhbmcgaGFzIG5v dyBjbG9zZWQuIFRoZXJlIGlzIHN0cm9uZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRv Y3VtZW50IGludG8gdGhlIFdHIGFuZCB0aGVyZWZvcmUgYXV0aG9ycyBwbGVhc2UgcHVibGlzaCBh IG5ldyB2ZXJzaW9uIGFzIGRyYWZ0LWlldGYtc3ByaW5nLXNydjYteWFuZy0wMC4gVGhlIGNoYWly cyBub3RlIHRoYXQgc2V2ZXJhbCBjb21tZW50cyB3ZXJlIHJlY2VpdmVkIGR1cmluZyB0aGUgYWRv cHRpb24gY2FsbCB0byBoZWxwIGltcHJvdmUgdGhlIHN0cnVjdHVyZSBhbmQgcXVhbGl0eSBvZiB0 aGUgZG9jdW1lbnQ7IGF1dGhvcnMgcGxlYXNlIHdvcmsgd2l0aCB0aGUgcGVvcGxlIHRoYXQgcHJv dmlkZWQgdGhlc2UgY29tbWVudHMgdG8gaW5jb3Jwb3JhdGUgdGhlbSBhcyBhcHByb3ByaWF0ZSBp bnRvIHRoZSBkb2N1bWVudC4NCg0KQXV0aG9ycywgcGxlYXNlIGluZGljYXRlIG9uIHRoZSBtYWls aW5nIGxpc3Qgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSB1bmRpc2Nsb3NlZCByZWxldmFu dCBJUFIuDQoNClRoYW5rcyENCg0KSmltLCBKb2VsICYgQnJ1bm8NCg0KDQoNCg0KDQpGcm9tOiBK YW1lcyBHdWljaGFyZA0KU2VudDogTW9uZGF5LCBKdWx5IDEzLCAyMDIwIDU6NTIgUE0NClRvOiBz cHJpbmdAaWV0Zi5vcmcNCkNjOiBzcHJpbmctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBXRyBB ZG9wdGlvbiBDYWxsIGZvciBkcmFmdC1yYXphLXNwcmluZy1zcnY2LXlhbmcNCg0KRGVhciBXRzoN Cg0KVGhpcyBlbWFpbCBiZWdpbnMgYSAyIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmF6YS1zcHJpbmctc3J2Ni15YW5nLyBl bmRpbmcgTW9uZGF5IDI3dGggSnVseSAyMDIwLg0KDQpQbGVhc2Ugc3BlYWsgdXAgaWYgeW91IHN1 cHBvcnQgb3Igb3Bwb3NlIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgaW50byB0aGUgV0cuIFBsZWFz ZSBhbHNvIHByb3ZpZGUgY29tbWVudHMvcmVhc29ucyBmb3IgdGhhdCBzdXBwb3J0IChvciBsYWNr IHRoZXJlb2YpLiBTaWxlbmNlIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgY29uc2VudC4NCg0KVGhh bmtzIQ0KDQpKaW0sIEpvZWwgJiBCcnVubw0KDQoNCg0KDQoNCg== --_000_1F3812EF78E0465EB14E89CEE19D0283bellca_ Content-Type: text/html; charset="utf-8" Content-ID: <707CB8ECA288DB4F827F5448DBC87CCD@exchange.bell.ca> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXMgY28tYXV0aG9yLCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIElQUi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5zcHJpbmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi ZWhhbGYgb2YgSmFtZXMgR3VpY2hhcmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgSnVseSAyOCwgMjAyMCBhdCA2OjQzIEFN PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtzcHJpbmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcm cXVvdDsgJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PltFWFRdUmU6IFtzcHJpbmddIFdHIEFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0LXJhemEtc3ByaW5n LXNydjYteWFuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgMi13ZWVrIGFkb3B0 aW9uIGNhbGwgZm9yIGRyYWZ0LXJhemEtc3ByaW5nLXNydjYteWFuZyBoYXMgbm93IGNsb3NlZC4g VGhlcmUgaXMgc3Ryb25nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgaW50 byB0aGUgV0cgYW5kIHRoZXJlZm9yZSBhdXRob3JzIHBsZWFzZSBwdWJsaXNoIGEgbmV3IHZlcnNp b24gYXMgZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni15YW5nLTAwLiBUaGUgY2hhaXJzDQogbm90ZSB0 aGF0IHNldmVyYWwgY29tbWVudHMgd2VyZSByZWNlaXZlZCBkdXJpbmcgdGhlIGFkb3B0aW9uIGNh bGwgdG8gaGVscCBpbXByb3ZlIHRoZSBzdHJ1Y3R1cmUgYW5kIHF1YWxpdHkgb2YgdGhlIGRvY3Vt ZW50OyBhdXRob3JzIHBsZWFzZSB3b3JrIHdpdGggdGhlIHBlb3BsZSB0aGF0IHByb3ZpZGVkIHRo ZXNlIGNvbW1lbnRzIHRvIGluY29ycG9yYXRlIHRoZW0gYXMgYXBwcm9wcmlhdGUgaW50byB0aGUg ZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0 ZSBvbiB0aGUgbWFpbGluZyBsaXN0IHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgdW5kaXNj bG9zZWQgcmVsZXZhbnQgSVBSLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkppbSwgSm9lbCAmYW1wOyBCcnVubyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48L2I+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IEphbWVzIEd1aWNoYXJkIDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMTMs IDIwMjAgNTo1MiBQTTxicj4NCjxiPlRvOjwvYj4gc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+Q2M6 PC9iPiBzcHJpbmctY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFdHIEFkb3B0 aW9uIENhbGwgZm9yIGRyYWZ0LXJhemEtc3ByaW5nLXNydjYteWFuZzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBlbWFpbCBiZWdpbnMgYSAyIHdlZWsgV0cgYWRvcHRpb24gY2FsbCBmb3IgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmF6YS1zcHJpbmctc3J2Ni15 YW5nLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYXphLXNwcmlu Zy1zcnY2LXlhbmcvPC9hPiBlbmRpbmcgTW9uZGF5IDI3PHN1cD50aDwvc3VwPiBKdWx5IDIwMjAu DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHNwZWFrIHVwIGlmIHlvdSBzdXBwb3J0 IG9yIG9wcG9zZSBhZG9wdGluZyB0aGlzIGRvY3VtZW50IGludG8gdGhlIFdHLiBQbGVhc2UgYWxz byBwcm92aWRlIGNvbW1lbnRzL3JlYXNvbnMgZm9yIHRoYXQgc3VwcG9ydCAob3IgbGFjayB0aGVy ZW9mKS4gU2lsZW5jZSB3aWxsIG5vdCBiZSBjb25zaWRlcmVkIGNvbnNlbnQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmltLCBKb2VsICZh bXA7IEJydW5vPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+ PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1F3812EF78E0465EB14E89CEE19D0283bellca_-- From nobody Tue Aug 11 15:15:26 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67D3A0C77 for ; Tue, 11 Aug 2020 15:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=joelhalpern.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 8370pskcjndG for ; Tue, 11 Aug 2020 15:15:24 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 1A9843A0B41 for ; Tue, 11 Aug 2020 15:15:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BR6bH6Fz2z6G9pQ for ; Tue, 11 Aug 2020 15:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1597184123; bh=h02T+2n9p2YEFisOq6F+SIrNv+pU5NsMc5iYq7Ze6B4=; h=Subject:References:To:From:Date:In-Reply-To:From; b=fgXdDYc4zB12UzBFT5lcaoTNAibSZzs1+Pdkoh9I6A4/2f6H5Z6rXgyLuIhiJ11WG fm+63scG+BOINqqj7tDIr9GBh3eg+9mw83NiQoq2KbGdObo3mOStlU6JbYMWIclENy u2Fp9ScLOTDVHmVHWmaCcWFccfvBssSaF6C62nXY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BR6bH3Glvz6G83f for ; Tue, 11 Aug 2020 15:15:23 -0700 (PDT) References: <2eb45d68-8699-fe5c-c6a7-181fe9ef628e@nokia.com> To: "spring@ietf.org" From: "Joel M. Halpern" X-Forwarded-Message-Id: <2eb45d68-8699-fe5c-c6a7-181fe9ef628e@nokia.com> Message-ID: <343da401-57f8-a550-339e-a24c6583f875@joelhalpern.com> Date: Tue, 11 Aug 2020 18:15:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2eb45d68-8699-fe5c-c6a7-181fe9ef628e@nokia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] Fwd: Re: FW: Re: SPRING SRComp design list X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 22:15:25 -0000 The tools team found a fixed the problem that was preventing us from making the SRComp archives public. They are now public. Thanks to all involved. Yours, Joel -------- Forwarded Message -------- Subject: Re: FW: Re: SPRING SRComp design list Date: Tue, 11 Aug 2020 23:59:41 +0200 From: Martin Vigoureux To: Joel Halpern Direct the archives are now public. please make sure every one is aware. past messages are also public. Le 2020-08-11 à 23:48, Martin Vigoureux a écrit : > seems there is an underlying tools issue somewhere. tools team will look > into that > From nobody Wed Aug 12 00:52:02 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FCA3A0C8B; Wed, 12 Aug 2020 00:52:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <159721872155.8427.16195907105198382874@ietfa.amsl.com> Date: Wed, 12 Aug 2020 00:52:01 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-17.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 07:52:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : SRv6 Network Programming Authors : Clarence Filsfils Pablo Camarillo Garvia John Leddy Daniel Voyer Satoru Matsushima Zhenbin Li Filename : draft-ietf-spring-srv6-network-programming-17.txt Pages : 42 Date : 2020-08-12 Abstract: The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization (Service Level Agreements). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-17 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 12 05:55:58 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D3F3A12A8; Wed, 12 Aug 2020 05:55:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-spring-srv6-network-programming@ietf.org, spring@ietf.org, Bruno Decraene , martin.vigoureux@nokia.com, Joel Halpern , jmh@joelhalpern.com, spring-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159723694970.27067.9766029100632402951@ietfa.amsl.com> Date: Wed, 12 Aug 2020 05:55:49 -0700 Archived-At: Subject: [spring] Last Call: (SRv6 Network Programming) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 12:55:57 -0000 The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document: - 'SRv6 Network Programming' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization (Service Level Agreements). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3464/ From nobody Thu Aug 13 07:03:05 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981C23A0C54; Thu, 13 Aug 2020 07:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=lab.dtag.de 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 VzzuEf3EFmjD; Thu, 13 Aug 2020 07:03:01 -0700 (PDT) Received: from OldBailey.lab.dtag.de (OldBailey.lab.DTAG.DE [194.25.1.220]) (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 942193A0C55; Thu, 13 Aug 2020 07:02:59 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B46B3C0B38; Thu, 13 Aug 2020 16:02:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1597327366; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fU3UBdurEgP8H4CcvwYjqk6huryadGUdNTjVIkFBg24=; b=j6LOSc5Q9wDZVK86yqB08d9KfmjPQf4+r+bMUC5A4dAWfQ2cLpL7cMUzdbXDJdjT4JK/S8 4iJV1125zt7JdOOVFmUiG0+DWzq1JJ3ZSJ0SM+1lqGl0dZ/iccIPGi0DnQ5DVO+cGduOup WWS6aMYsZbIk7fiKAsDe6xAmGr1NJz7lIR39wCjArK7EpHpIeqBKbLDShaZewbgP0+fxUM qGQHysV4rY50yJmyycrayTQWAWMIGLThmt9zU9PzzKBRaDb8QMS2vtc6cO/GZWmoFiyjC+ mYCkcRs3qhmHEJItBAEf2NKMiIIShND/alRjxeIvnfTeCWuCt9HvL2y1hYsAkA== To: Shraddha Hegde , Pushpasis Sarkar Cc: Bruno Decraene , "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Martin Horneffer Message-ID: <79e85a49-9c29-d717-32ec-1bd44b274e17@lab.dtag.de> Date: Thu, 13 Aug 2020 16:02:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------64B83061281CF1E052987787" X-Last-TLS-Session-Version: TLSv1.3 Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 14:03:04 -0000 This is a multi-part message in MIME format. --------------64B83061281CF1E052987787 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Shraddha, Pushpasis, it's a very good point to see this interaction being documented. Thank you! I support it. Best regards, Martin Am 04.08.20 um 19:48 schrieb Shraddha Hegde: > > Hi Pushpasis, > > Thanks for the review and comments. > > Pls check if the below text looks good. > > “ > > draft-ietf-spring-mpls-anycast-segments proposes a mechanism to allow > the use of anycast SIDs in a network > > where all devices do not share a common SRGB.  > draft-ietf-spring-mpls-anycast-segments utilizes the concept of > > a virtual LFIB, which is an application of  the concept of > Context-Specific Label Spaces [RFC5331].  The current draft > > uses the mechanism of context tables, a different application of > Context-Specific Label Spaces, to facilitate node > > protection.  The current draft does not make provisions to support the > virtual LFIB mechanism together with > > node protection context tables.  The use of anycast-SIDs together with > anycast-aware TI-LFA provides effective > > protection against node failure. Therefore, when SRTE paths are > constructed using anycast-SIDs, the anycast-SIDs > > may not require node protection via context tables. “ > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* Pushpasis Sarkar > *Sent:* Tuesday, August 4, 2020 10:47 AM > *To:* Bruno Decraene > *Cc:* spring@ietf.org; > draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org > *Subject:* Re: [spring] WG adoption call for > draft-hegde-spring-node-protection-for-sr-te-paths > > *[External Email. Be cautious of content]* > > Hi WG, > > Support the adoption of this draft. However I think some text should > be added to explain it's interaction with > https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments > . > > > Authors, > > If you prefer, I can provide some text for your perusal. > > Thanks and regards, > > -Pushpasis > > On Thu, Jul 30, 2020 at 5:55 PM > wrote: > > Hi SPRING WG, > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] > have asked for WG adoption. > > Please indicate your support, comments, or objection, for adopting > this draft as a working group item by August 20th 2020. (*) > > Could those who are willing to work on this document, please > notify the list. That gives us an indication of the energy level > in the working group to work on this. > > Thanks, > > Regards, > > Bruno, Jim, Joel > > [1] > https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 > > > (*) 3 weeks to account for the IETF meeting week and the > august/summer period. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. > > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------64B83061281CF1E052987787 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Shraddha, Pushpasis,

it's a very good point to see this interaction being documented. Thank you!
I support it.

Best regards, Martin


Am 04.08.20 um 19:48 schrieb Shraddha Hegde:

Hi Pushpasis,

 

Thanks for the review and comments.

 

Pls check if the below text looks good.

 

“

draft-ietf-spring-mpls-anycast-segments proposes a mechanism to allow the use of anycast SIDs in a network

where all devices do not share a common SRGB.  draft-ietf-spring-mpls-anycast-segments utilizes the concept of

a virtual LFIB, which is an application of  the concept of Context-Specific Label Spaces [RFC5331].  The current draft

uses the mechanism of context tables, a different application of Context-Specific Label Spaces, to facilitate node

protection.  The current draft does not make provisions to support the virtual LFIB mechanism together with

node protection context tables.  The use of anycast-SIDs together with anycast-aware TI-LFA provides effective

protection against node failure.  Therefore, when SRTE paths are constructed using anycast-SIDs, the anycast-SIDs

may not require node protection via context tables. “

 

 

Rgds

Shraddha

 

 

 

Juniper Business Use Only

From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Sent: Tuesday, August 4, 2020 10:47 AM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: spring@ietf.org; draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

 

[External Email. Be cautious of content]

 

Hi WG,

 

Support the adoption of this draft. However I think some text should be added to explain it's interaction with https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments. 

 

Authors,

 

If you prefer, I can provide some text for your perusal.

 

Thanks and regards,

-Pushpasis

 

 

On Thu, Jul 30, 2020 at 5:55 PM <bruno.decraene@orange.com> wrote:

Hi SPRING WG,

 

Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked for WG adoption.

 

Please indicate your support, comments, or objection, for adopting this draft as a working group item by August 20th 2020. (*)

 

Could those who are willing to work on this document, please notify the list. That gives us an indication of the energy level in the working group to work on this.

 

Thanks,

Regards,

Bruno, Jim, Joel

 

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07

(*) 3 weeks to account for the IETF meeting week and the august/summer period.

 

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

--------------64B83061281CF1E052987787-- From nobody Thu Aug 13 11:17:16 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213533A0FFA; Thu, 13 Aug 2020 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3Ct8jRTcxgO; Thu, 13 Aug 2020 11:17:07 -0700 (PDT) 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 C40723A101F; Thu, 13 Aug 2020 11:17:06 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id d22so3223061pfn.5; Thu, 13 Aug 2020 11:17:06 -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=f1Msm/Tgjc8Ws+hZhjaxSCw33HttGiFlqraWqsTIzqE=; b=Rtw2tvMbXLoL0x5Ni+juFahNTbZTATf4+pS6UqOmplp2FTHXFfk4pvSEkBxXKZ+uHs IX51lVGPI9jaW2HhCAK59zlCFG+NqSiWy2uHqzJWrT+jiY326HKEpaLhDxHcQpkRICkH IvYQSY1KxE2v5brwoDvAmg2YHmyU0v8FPMzed4GJrk/KJgHowKHDKONGqfz1ensoeToD nC8Xfeervb8m2ID/fDS7wXSVqpMfiFp1tkJYPm6jnw+QUOKbsK4bCHfbByqUeVVf0r2s KTmQs6xyg+d/ZViVbwgmRxVrUH/iNBouuJ3ScnqYOwq/zoD0+TeMDY2L4/Jq12uIRA2V xDEA== 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=f1Msm/Tgjc8Ws+hZhjaxSCw33HttGiFlqraWqsTIzqE=; b=l4jq07Fkmpii4tyn7enCKWRI24+4iuWoxmKGHAzM4zIuFGK+e4QElMnGRerkyDpYks 3yCnLYGlCmpbg39pBvaGCuP3P8LXPkiV3P4WdpfESgWNVIvB19VbJVZDR+0GbPTjd7/7 HuTraHhO4jCd2Bfu499iQDOdi1hdPh+zgqfyLvgnhOwoaVsrPUmqkTP0Ns2hrSjfDh4b iGMBCm6o0ZQT3WYc+QAaOLPJUZAMDTPK+qNjechrmjwSYMEbdNvFWRgTVHGzoVlJ+DEN lf8vCdnN81gj+JVMzFDORC386x4rEuOpc6+V8cIvj/4a2dHrEuFkZbfPQr90Q8LHNJX+ Ba6w== X-Gm-Message-State: AOAM5308JzMQgReZ9st/smuwCv/yGXXhSm3vdwQnsecXAm7GuWjVNfjG 0hZlkBO1DF+oIKLuBH+Q+wfcB6oC X-Google-Smtp-Source: ABdhPJwNZdYbxx88xtoBHXWe8NJClFGr2gVoCBVhdHT0gfLgpGJWB5kfBDCY/OgXVbiYhfVhN9ywVw== X-Received: by 2002:a65:4044:: with SMTP id h4mr4737780pgp.371.1597342625355; Thu, 13 Aug 2020 11:17:05 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id o10sm5761486pjo.55.2020.08.13.11.17.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2020 11:17:04 -0700 (PDT) Date: Thu, 13 Aug 2020 11:16:45 -0700 From: Jeff Tantsura To: "=?utf-8?Q?spring=40ietf.org?=" , bruno.decraene@orange.com Cc: "=?utf-8?Q?draft-hegde-spring-node-protection-for-sr-te-paths=40ietf.org?=" Message-ID: <62716bd1-ea8f-4b73-b218-6a2c6788c475@Spark> In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> X-Readdle-Message-ID: 62716bd1-ea8f-4b73-b218-6a2c6788c475@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f35839f_6b8b4567_1640" Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 18:17:09 -0000 --5f35839f_6b8b4567_1640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline yes/support Cheers, Jeff On Jul 30, 2020, 5:25 AM -0700, bruno.decraene=40orange.com, wrote: > Hi SPRING WG, > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths =C2=A0=5B= 1=5D have asked for WG adoption. > > Please indicate your support, comments, or objection, for adopting this= draft as a working group item by August 20th 2020. (*) > > Could those who are willing to work on this document, please notify the= list. That gives us an indication of the energy level in the working gro= up to work on this. > > Thanks, > Regards, > Bruno, Jim, Joel > > =5B1=5D https://tools.ietf.org/html/draft-hegde-spring-node-protection-= for-sr-te-paths-07 > (*) 3 weeks to account for the IET=46 meeting week and the august/summe= r period. > > =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=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=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 > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > =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 > spring mailing list > spring=40ietf.org > https://www.ietf.org/mailman/listinfo/spring --5f35839f_6b8b4567_1640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
yes/support

Cheers,
Jeff
On Jul 30, 2020, 5:25 AM -0700, bru= no.decraene=40orange.com, wrote:

Hi SPRING WG,

&=23160;

Authors of draft-hegde-spring-node-protection-for-sr-te-paths &=23160;=5B1=5D have asked for WG adoption.

&=23160;

Please indicate your support, com= ments, or objection, for adopting this draft as a working group item by A= ugust 20th 2020. (*)

&=23160;

Could those who are willing to wo= rk on this document, please notify the list. That gives us an indication = of the energy level in the working group to work on this.

&=23160;

Thanks,

Regards,

Bruno, Jim, Joel

&=23160;

=5B1=5D https://tools= .ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07<= /p>

(*) 3 weeks to account for the IE= T=46 meeting week and the august/summer period.

&=23160;

=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=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=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

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

This message and its attachments may contain confidential or privileged i=
nformation 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 de=
lete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
Thank you.
=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
spring mailing list
spring=40ietf.org
https://www.ietf.org/mailman/listinfo/spring
--5f35839f_6b8b4567_1640-- From nobody Thu Aug 13 13:28:13 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25563A1114; Thu, 13 Aug 2020 13:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fWKo_v4H3vMy; Thu, 13 Aug 2020 13:28:04 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 3DA193A1116; Thu, 13 Aug 2020 13:28:04 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id q13so3577567vsn.9; Thu, 13 Aug 2020 13:28:04 -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=odgBQpd3X6jFibVXP3ChaMuWiZw0bid883CMY/Rkcuc=; b=Y2ePibNdq1lc+PJnsTnKAfs6WROXHqdAF+3b8bzSXlWrybM6e2gyUxqnA3QvyWWLQB JgGCFQEdmeDwgfNc0b8kCQUESkAnBA8/fX2fpttxj4mhWBrOK9dT64EZ/3f4lCtqoTD1 tdmuc5dIcY/CKhbzjT4E5hyalTgrRIuuLM+85/hz6GI+1e0UC73R5+yXpS6v/4w4pYM2 kCHuSphGou4TDCSKOY4ZRvakNerJXhbI/y7AphleRgMso+VJU0vfcaMpRzCC7MNaONiM NZEjm1KhCKI2sWshhtk0V0+nqwq0iY1PGfJUE0OLOYUbii+6pPYaXtQsXeoFVBDZY74c HvLQ== 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=odgBQpd3X6jFibVXP3ChaMuWiZw0bid883CMY/Rkcuc=; b=NTwm305Ao0WZh5mj+zv/prW29jmA2NtluBwmN9xeNTsMNmyRs8+FceT5mp1Y1+xniP kWenfq9ykKWXlRpnIQVxXQOMJfoo0olfHDWQ213DziSWbPnMo4pgCUaLYBAYdiqEa2eB d5vNrew5tLiPtcFZdA4D02zwUi0VnRipHq40zFe28P8vs2lgz4yCp0+5d/LqM0QorDFx bSYxawBIG/YMtgZstr5pZO9AVOlG5poHyzferN3oti/PUWCYE7YK8XzTYkvVuIdDW8S/ lA6pJ6YHweSHpBiwvWpZjvAfGHKK7VWQ5b4A4KmswgnQSJv1YKbwAmOEk1U+U8++qEPr 6Atg== X-Gm-Message-State: AOAM531iD3WpX1jd6/ziaUFTh1H9k0/yU4WK3Lfeh3Wy+OUs3JIInsZ2 WwByEmI87b1EnXLew1tq2G7AKmTBmR62g9wUczs= X-Google-Smtp-Source: ABdhPJw+OUME+31naoURTOpY9iM1z8//xRFasKOilxCvT2LODFVk0ZAUqtLGHeL35aaEnQyzxejJqwrbFcPG/UYWXrU= X-Received: by 2002:a67:fbd1:: with SMTP id o17mr4951854vsr.19.1597350483183; Thu, 13 Aug 2020 13:28:03 -0700 (PDT) MIME-Version: 1.0 References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <62716bd1-ea8f-4b73-b218-6a2c6788c475@Spark> In-Reply-To: <62716bd1-ea8f-4b73-b218-6a2c6788c475@Spark> From: Gyan Mishra Date: Thu, 13 Aug 2020 16:27:52 -0400 Message-ID: To: Jeff Tantsura Cc: bruno.decraene@orange.com, "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000021cb4305acc824f5" Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 20:28:13 -0000 --00000000000021cb4305acc824f5 Content-Type: text/plain; charset="UTF-8" I reviewed the draft and support WG adoption. Thank you Gyan On Thu, Aug 13, 2020 at 2:17 PM Jeff Tantsura wrote: > yes/support > > Cheers, > Jeff > On Jul 30, 2020, 5:25 AM -0700, bruno.decraene@orange.com, wrote: > > Hi SPRING WG, > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have > asked for WG adoption. > > > > Please indicate your support, comments, or objection, for adopting this > draft as a working group item by August 20th 2020. (*) > > > > Could those who are willing to work on this document, please notify the > list. That gives us an indication of the energy level in the working group > to work on this. > > > > Thanks, > > Regards, > > Bruno, Jim, Joel > > > > [1] > https://tools..ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 > > > (*) 3 weeks to account for the IETF meeting week and the august/summer > period. > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000021cb4305acc824f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I reviewed the draft and support WG adoption.
<= /div>

Thank you=C2=A0

Gyan

On Thu, Aug 13, 2020 at= 2:17 PM Jeff Tantsura <jefft= ant.ietf@gmail.com> wrote:
yes/support

Cheers,
Jeff
On Jul 30, 2020, 5:25 AM -0700, bruno.decraene@oran= ge.com, wrote:

Hi SPRING WG,

=C2=A0

Authors of draft-hegde-spring-node-protection-for-sr-te-paths =C2=A0[1] have asked for WG adoption.

=C2=A0

Please indicate your support, c= omments, or objection, for adopting this draft as a working group item by A= ugust 20th 2020. (*)

=C2=A0

Could those who are willing to = work on this document, please notify the list. That gives us an indication = of the energy level in the working group to work on this.

=C2=A0

Thanks,

Regards,

Bruno, Jim, Joel

=C2=A0

[1] https://too= ls..ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07=

<= blockquote type=3D"cite" style=3D"border-left-color:grey;border-left-width:= thin;border-left-style:solid;margin:5px 5px;padding-left:10px">

(*) 3 weeks to account for the = IETF meeting week and the august/summer period.

=C2=A0

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--00000000000021cb4305acc824f5-- From nobody Thu Aug 13 20:59:09 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B105D3A0CA1; Thu, 13 Aug 2020 20:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A03txFMPy8x; Thu, 13 Aug 2020 20:59:06 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 2F4373A0C9E; Thu, 13 Aug 2020 20:59:06 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id g14so9643092iom.0; Thu, 13 Aug 2020 20:59: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:to :cc; bh=OjGPNrYaLkEwEbwxCC9kfPpmAsRBgQNUP8v2s6TPQbE=; b=Qac7q5ZRIZPk0aqfQUuFIhU2fbXAhvGBK+N73ZvgdYwB2FNpRbm6riUBegoltwHxq7 DkHtFpmZKcSqgKLN/DJ9TmwRNdamahkOHDsQyxhhWi8cgBl5AGF+JRQYdd+/bP3Zzspo lEB2lkWPR9FrX80E85YhvMWelUMqMHfTownqPr7RxRnjVAXRIkBGsLwppH/N9ZUTgOU5 4uXHJgqG7WVDTDlaaHrLRHS7UDRNez3xJrxfnl/eWg/H2Vieo323OQyQw/HIysvfH7PW YCluBv7/AGiKBi3slLcakTdBpnkkCXv4vRPuYYdvIfIcabtedJrKh5LZUokBIyxHj0Cz 48BQ== 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=OjGPNrYaLkEwEbwxCC9kfPpmAsRBgQNUP8v2s6TPQbE=; b=ryJsyhYRalDUfclb6tzdURIkz9VZVMvCYoIXALM3NwqUDncaFrXCrdpHMjSCHT7kKb PYaKVPWkHNFeyC1QdNgTzg/FKuQLm960LKEgpB/5ksL+UVC1xST5h+17gzvLnkkXMrYT T7VunhNjulps/xj3MbsksAn9o0th6DooJjlukrJDnB4xzIDfrxfdkpaxyyT0u9ldDFvN Q7TMsLoGSbp2IHzg0faqeN9F94czS3Lr3I47patujUnHo5+K2MvYHMR6dPXrE1ivxZvM VCG5yRxxkTHecLamwpWEd9g3AZAkPbOZHgY8Ede5KbrF377UCi+eyFRO390T9bfOLZdj G2vw== X-Gm-Message-State: AOAM530zfmAv90GzitfnpSf/qEuJKGbxIpjoZKqMu/IUOCGNrHYj9Shh eVlTvlbaFRoNMtVO0GrpfLEJ20Zi/u86kBu2E9g= X-Google-Smtp-Source: ABdhPJzL+vmajVx+CHrcGZXxNb61Ej2L+IU0bvCoNBqmsuH2qo7M3GVPXruoLfj0Erq5heWtJNT0EDmmbkiK6XgI0G4= X-Received: by 2002:a6b:c8ca:: with SMTP id y193mr676938iof.62.1597377545346; Thu, 13 Aug 2020 20:59:05 -0700 (PDT) MIME-Version: 1.0 References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Vishnu Pavan Beeram Date: Thu, 13 Aug 2020 22:58:54 -0500 Message-ID: To: bruno.decraene@orange.com Cc: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Content-Type: multipart/alternative; boundary="00000000000029a65e05acce715b" Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 03:59:08 -0000 --00000000000029a65e05acce715b Content-Type: text/plain; charset="UTF-8" Strongly support adoption -- the document addresses an important missing piece of functionality (also helps that the document is more than sufficiently baked for the WG to take it forward). Regards, -Pavan On Thu, Jul 30, 2020 at 7:25 AM wrote: > Hi SPRING WG, > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have > asked for WG adoption. > > > > Please indicate your support, comments, or objection, for adopting this > draft as a working group item by August 20th 2020. (*) > > > > Could those who are willing to work on this document, please notify the > list. That gives us an indication of the energy level in the working group > to work on this. > > > > Thanks, > > Regards, > > Bruno, Jim, Joel > > > > [1] > https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 > > (*) 3 weeks to account for the IETF meeting week and the august/summer > period. > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000029a65e05acce715b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Strongly support adoption -- the document addresses a= n important missing piece of functionality (also helps that the document is= more than sufficiently baked for the WG to take it forward).
Regards,
-Pavan

 --00000000000029a65e05acce715b-- From nobody Fri Aug 14 01:21:06 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF843A0DF2 for ; Fri, 14 Aug 2020 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xWfgubiW_QVD for ; Fri, 14 Aug 2020 01:21:02 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450: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 726373A0DEE for ; Fri, 14 Aug 2020 01:21:02 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id df16so6197734edb.9 for ; Fri, 14 Aug 2020 01:21:02 -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=MXYcA4P1lHzx50CRnaRt4YGmn4KWGjYNThaExTE7ElE=; b=crlsf7iV+6/7qNucDPcgwbgUKq6vd8UIuGnfpgFgE4+9W6rEMfcyVI08rDcK8xp+ed ZAKcCTm5hXFJ6LZwdoZXpNj82iZU6a9mpqnJeIeZyHmCwSRu458+4bKF4CfpGgWBRdZ/ TPrsvJjTficH/lZfDqLpVwfplEIsiGPExQVP65dtwrnOfMVzfTD9vYxQ5QID0pgcgJLe 1rBL2MaXt1TsZaEAcrXB1pCOCaFPlPp/iAUZbpHxtHz/GOW3Bv4Z/2gcgAnYrP8o68zt rXLPFl7DQj07V+JvxIZi83CbV3Tk81rpqa5zAkJ3uQ0s7YFApXKPsFb7AK5c74ZRlJ3T pJmQ== 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=MXYcA4P1lHzx50CRnaRt4YGmn4KWGjYNThaExTE7ElE=; b=aLG5khJ86w7GC0aBzRJ2ekbZzIZLFcSE/ly+3r89lx9DP1fHmx8bT+yjraUwnqkFZ/ Hj7SCCgnh60Np0LuaD17iNnuxj7M6m1OwBVmJsKVf4IJVHyA+tWQQtgNSNt6w+4JWASX dFHV0en7Ctv85h1VYyPdVNv0d//DgBMpPtmZvuMahOCbLf0+mI7qOVh7aGsMgJpA5n3v Va3uR/KgEaU4IapVHbGyRe8ego08vR28hd9SUAHmTgzPQLOsxSwKCpFYWDNlUWlwLl+D +ZbC4D34sgxg7o4iXKOLuXC4Jlr4ypAPbMoRn2yHBSUT0BVCaksDOc0KSQMQpOKGGqQA g+5w== X-Gm-Message-State: AOAM5304Xk5NL/JJIJ7GwQadLqG6TNPS/ZN/AEvoxxyUY4hgncn7USIB AvZ31izP1216AdMTexOQ2emxhF/nJFLK14UhSgXKPQ== X-Google-Smtp-Source: ABdhPJyZUOJvhWumw3gDbsf7Mq/oZWIMSsAutjp54eShZp6Mim4AnKwtXw+BiyDOT/xJgWu+Xm0Zaoo2yPbOv0mClYk= X-Received: by 2002:aa7:c70b:: with SMTP id i11mr1136797edq.272.1597393260949; Fri, 14 Aug 2020 01:21:00 -0700 (PDT) MIME-Version: 1.0 References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Robert Raszuk Date: Fri, 14 Aug 2020 10:20:50 +0200 Message-ID: To: Bruno Decraene Cc: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e2c58705acd21980" Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 08:21:04 -0000 --000000000000e2c58705acd21980 Content-Type: text/plain; charset="UTF-8" I support the adoption of this draft. It is Informational and provides set of guidance to implementations. Reading it quickly I think I am not seeing a section or exception in handling cases where next sid is a binding sid.Skipping it may break the game. Also section 2.3 is IMO debatable. I know some which would prefer to drop rather then go direct between R3 & R4 as there can be already much more important traffic taking that link. So just always applying node protection based on processing of next SID may not always be a desired behaviour. I think to some level Joel's recent messages discussed similar concerns. Thx a lot, R. On Thu, Jul 30, 2020 at 2:24 PM wrote: > Hi SPRING WG, > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have > asked for WG adoption. > > > > Please indicate your support, comments, or objection, for adopting this > draft as a working group item by August 20th 2020. (*) > > > > Could those who are willing to work on this document, please notify the > list. That gives us an indication of the energy level in the working group > to work on this. > > > > Thanks, > > Regards, > > Bruno, Jim, Joel > > > > [1] > https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 > > (*) 3 weeks to account for the IETF meeting week and the august/summer > period. > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000e2c58705acd21980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the=C2=A0adoption of this draft. It is Informati= onal and provides set of guidance to implementations.=C2=A0

<= div>Reading it quickly I think I am not seeing a section or exception in ha= ndling cases where next=C2=A0sid is a binding sid.Skipping it may break the= game.=C2=A0

Also section 2.3 is IMO debatable. I = know some which would prefer to drop rather then go direct between R3 &= R4 as there can be already much more important traffic taking that link. S= o just always applying node protection based on processing of next=C2=A0SID= may not always be a desired behaviour. I think to some level Joel's re= cent messages discussed similar concerns.=C2=A0

Th= x a lot,
R.
On Thu, Jul 30, 2020 at 7:25= AM <bruno.decraene@orange.= com> wrote:

Hi SPRING WG,

=C2=A0

Authors of draft-hegde-spring-node-protection-for-sr-te-paths =C2=A0[1] have asked for WG adoption.

=C2=A0

Please indicate your support, c= omments, or objection, for adopting this draft as a working group item by A= ugust 20th 2020. (*)

=C2=A0

Could those who are willing to = work on this document, please notify the list. That gives us an indication = of the energy level in the working group to work on this.

=C2=A0

Thanks,

Regards,

Bruno, Jim, Joel<= /span>

=C2=A0

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07

(*) 3 weeks to account for the = IETF meeting week and the august/summer period.

=C2=A0

______________________________________________________________________=
___________________________________________________

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

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

On Thu, Jul 30, 2020 at 2:24 PM <bruno.decraene@orange.com> wrote:

Hi SPRING WG,

=C2=A0

Authors of draft-hegde-spring-node-protection-for-sr-te-paths =C2=A0[1] have asked for WG adoption.

=C2=A0

Please indicate your support, c= omments, or objection, for adopting this draft as a working group item by A= ugust 20th 2020. (*)

=C2=A0

Could those who are willing to = work on this document, please notify the list. That gives us an indication = of the energy level in the working group to work on this.

=C2=A0

Thanks,

Regards,

Bruno, Jim, Joel<= /span>

=C2=A0

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07

(*) 3 weeks to account for the = IETF meeting week and the august/summer period.

=C2=A0

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000e2c58705acd21980-- From nobody Fri Aug 14 04:36:22 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27373A0B9A; Fri, 14 Aug 2020 04:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=V9H1HJaN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EI+gaxGN 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 pdIHGmkrSBoX; Fri, 14 Aug 2020 04:36:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7753A0B8E; Fri, 14 Aug 2020 04:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11750; q=dns/txt; s=iport; t=1597404978; x=1598614578; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=UWbCu0KeLllVQ4/6/ZY8tBD1xqj7YagfJAt7DzdkAXU=; b=V9H1HJaN1a04xs+3GiKFGJmEaLVxaRaB2m9Z4SQKiVH73a+JtAGQIZJw Tz6hOLHehemVDcCMD/OzdFRfbmguI/je5ygmfCDM340Wwv7weGVAc76qI 5AnpvWKbXf5qRtgq0tIOVGAkyKNunhpqoZRIZAnO5yINkrxfkaMLQL0OK 4=; IronPort-PHdr: =?us-ascii?q?9a23=3Ae6CRKByUBa6N14nXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWPt/VqkFrAXIGd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkhSBMP3ZlmUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAQCcdjZf/4wNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTkEAQELAYEiL1EHcFgvLAqHcwONWoJrhx2JcoRtgUKBEQN?= =?us-ascii?q?VCwEBAQwBASUIAgQBAYRMAoJEAiQ3Bg4CAwEBCwEBBQEBAQIBBgRthVwMhXE?= =?us-ascii?q?BAQEBAxIbEwEBOA8CAQgRBAEBKAcyFAkIAgQBEggagwWBfk0DLgEOpy8CgTm?= =?us-ascii?q?IYXSBNIMBAQEFhSEYgg4DBoE4AYJwiikagUE/gVSBT34+ghpCAQECAYEiEio?= =?us-ascii?q?rCYMUgi2ZZItckCFRCoJiiGOMPoUfgn+JW5EegieQX4FZgWyIVoJlkhUCBAI?= =?us-ascii?q?EBQIOAQEFgWkkgVdwFTuCaVAXAg2OH4NxhRSFQnQ3AgYKAQEDCXyNfYE0AYE?= =?us-ascii?q?QAQE?= X-IronPort-AV: E=Sophos;i="5.76,312,1592870400"; d="scan'208,217";a="801428727" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 11:36:17 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EBaH68010342 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 11:36:17 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 06:36:17 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 06:36:16 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 06:36:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MdoNw9uomLpl8NFk3cW5hi3gK4HB7y9WwdUz5Xmjz7RB46MvBSNz8Za1S2lt6MiTwO/fh8PXoouJmhQRKox1fj09BeVCzhULbz4g/4XU0f8atft0F7Iv6qqW32Nuy2a1D3ZjJy5dX+uXb64JWMLDTe6jsTBF7ifREpyPPiTPjIVzyaunYOeD2STzmkJ+uDPCkYF9bHgxG0Rmn3KxkpCCamNa/Fow18GNl6fKlamC7sNq5s8kPHnO6wMUKZHW0Cl0XahdNe1CheFAgiCB+gka5slNfC8seEdV7fhiBeSLzqpyS9i5ndYfWeoz7rPd3kJBBmIIs2VUwzMrz3zhdEpBpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4FGWlK3UPJ6Qslebv6F40IbHjzoBkBlWl3FuVtSjF/I=; b=V9qH9aHIv4Pm1puaT08RhRyOCACtkvLGrl4eRoh1wMB3Zw5uV070G0GViNAMcmlCZ18diRkTTRKCBMZMac7Ncif9xDtyCGJvYodaa8whSJtuONs3/4ICKlBGxd4U9Gz9U2dqQFmJJRInGfzHeSnCbz2t28rRAd/6FfQ0N2xYRliwbhygrR5oQVLqsAqq4C2oITUibuasjYdvzIKlN8/pvXADueJgCdhjlPD7fZYunvfMBDTtcGCV1fMrelAcNjwoqL8ZdPugFXoSyB5Vjfmgprp2b80MDYa0Sb0rxn699mATPVh/ncoV//BGRDJ/NEJoNs6snSx3N6alFN6yaYKCNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4FGWlK3UPJ6Qslebv6F40IbHjzoBkBlWl3FuVtSjF/I=; b=EI+gaxGNWANFLwfal5/bYAKXKIkguvayslVOvft2iNOWGJKwNzN6uNn8OIHQUOgsbu2t2R3JKmbAx6vTIQjXkvK5ZXp5tUsjyreHmzG/wqQEy5kAyDLvna+ZIaTZCs9ojOfexmN6epu2kLFrKjwVMCgBculJ0HPqN9R2xFcwqMc= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4652.namprd11.prod.outlook.com (2603:10b6:303:5a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.18; Fri, 14 Aug 2020 11:36:15 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 11:36:15 +0000 From: "Ketan Talaulikar (ketant)" To: "li_zhenqiang@hotmail.com" , "spring@ietf.org" , draft-ietf-spring-segment-routing-policy Thread-Topic: Comments on SR policy Thread-Index: AQHWawMILoFabYib1kW1oP9vIEh+a6k3bvOg Date: Fri, 14 Aug 2020 11:36:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44e3ef2c-a525-48d7-c2b9-08d8404640d7 x-ms-traffictypediagnostic: MW3PR11MB4652: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FxoZZaPXSYul6WyetCHtb3tz25wn9AeYBttvII+LOTfpveXo9hjuxiaNp33XmrXLd/cNtNDkeHOTbgGzuozL19IEJvOMRujgz1Zmqnlo7nNBkCFZM2KcS0Tv7/CKO+xEH3RK1VZY3cOurMKUlUU2ggkvLNr79aoeLKgMd8mv/E1Et8GS3pm6bjhbydnAen1XEWoJNIh7sQB82uhylxFrrwkmK4JEqLEcpOdVMQiLpMbdPM6dDI7vCAkH+aof2jtD8nfZgie6mZCXKinKPneY1gZWMa8WmwoBldgjYMyEb6jgaAQ0Y5fvyJghwar+w7gVnx1ax3tt2vv0yi1MppnOzjjzV9ZitI5AV9TluKlSt+5ZWrcX7QT2xicI7vQifua9mRJgcBMBb1PBgktWuA2EsA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39860400002)(396003)(346002)(376002)(33656002)(8676002)(5660300002)(186003)(45080400002)(8936002)(478600001)(52536014)(2906002)(26005)(66446008)(7696005)(66476007)(71200400001)(76116006)(83380400001)(66556008)(86362001)(166002)(64756008)(316002)(55016002)(110136005)(53546011)(6506007)(3480700007)(66946007)(966005)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mYCKFVQq2eaJ1+sJwrlBgyq0qahkpeuP7T9kI0ovvERpEL3cXHdb2O9YGfDW6zE6hOv3TAx13lKof8TASypTb2MV/y0qMmIodl/w6ytkBFjKrSJQx/1p4+GJrJwOh7w3Gx2TSLBe5vRnoJWypwzTFMtFLffTK3nIr23KAn7gIz/4K9kmQvMZ4XaL07hACox9JeId71hLL9ZIaHlrwGJhsLA0cUP9+r1LpXt5O3QDt/KFgl4rG6sjwKilt9WYTR7oZcxYXVJWUdY+dzU8nm9FNcNTtbEOYuJO7WKsMzPOz2eZMe+AkZiqHkige85mq6o1IJ2Pc9MvpMV53C1VoKRJu5kgoBlVtdN+AdZhrUC2mWlAJ1/MTHhI4T1musezhb5mdqMx5SzZ/Y5is6TxXpsr/DpvYhZWnC8ULd69U6+9aiiKGYl6Yp3UdS13Ujjuo6E2BLUhr6lceKioP1PbtbBmCI6gdxcyJ71JsRLSqOuhJw00KjBr40ksZGcSIHea8tLhOgyhUKlQ9INn+7ARgvo+fwchOAppo5RRoHqwNg9sL7UBcMvLClK+cE5YoMSnwh+yOacw5WJ6EzwwSWVScMioHYtOlF9EEy+XW6O2mE+AILzjuDeQ5dtuaqBzbVZGCx7QIpI2dxJ8tWCOKbQdQ07gBg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570F5FE3FCE0A626081E8E4C1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44e3ef2c-a525-48d7-c2b9-08d8404640d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 11:36:15.1684 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Z4mGnjMS9fK1C+39MDVn2uaA8szxsqLhWUY3UoCHoyC9KSJHsxHBzXktul8QtRR0+W226K82FzE/JjUlUUZ2qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4652 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] Comments on SR policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 11:36:21 -0000 --_000_MW3PR11MB4570F5FE3FCE0A626081E8E4C1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zhenqiang Li, Thanks for you review and sharing your comments. Please check inline below. From: li_zhenqiang@hotmail.com Sent: 05 August 2020 14:03 To: spring@ietf.org; draft-ietf-spring-segment-routing-policy Subject: Comments on SR policy Dear authors and all, Please consider the following comments. 1. Do you think it is ok to add one more segment type for the segment list = to incorporate the segment for Layer 2 bundle members? Please refer to rfc8= 668. [KT] The Segment Type E covers Layer 2 Bundle Members : https://tools.ietf.= org/html/draft-ietf-spring-segment-routing-policy-08#section-4 This type can also be used to indicate indirection into a layer 2 interface (i.e. without IP address) like a representation of an optical transport path or a layer 2 Ethernet port or circuit at the specified node. 2. For per flow steering to a policy, why do we limit the array index to 0 = to 7? I think this is implementation specific and the number of paths in a= n array depends on the application scenario. I am not sure whether or not 8= paths is enough for all scenarios. [KT] The draft does not limit the Forwarding Classes to 8. The value 8 is m= ore of an example and comes from Traffic Class [RFC5462] and the IP Precede= nce portion of DSCP [RFC2474]. The section starts with "Let us assume" and = there is also the following text in the same section: The array index values (e.g. 0, 1 and 2) and the notion of forwarding-class are implementation specific and only meant to describe the desired behavior. The same can be realized by other mechanisms. 3. For protection in section 9.1, it is better to add some text like "the l= ocal protection may not satisfy the SLA requirements or the path constrains= for the policy" when an SR Policy is built on the basis of TI-LFA protecte= d IGP segments. [KT] Sure. We can add this clarification in the next update. Thanks, Ketan Best Regards, Zhenqiang Li ________________________________ li_zhenqiang@hotmail.com --_000_MW3PR11MB4570F5FE3FCE0A626081E8E4C1400MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Zhenqi= ang Li,

&nbs= p;

Thanks fo= r you review and sharing your comments. Please check inline below.

&nbs= p;

From: li_zhenqiang@hotmail.com <li_zhenqiang@hotmail.com>
Sent: 05 August 2020 14:03
To: spring@ietf.org; draft-ietf-spring-segment-routing-policy <dr= aft-ietf-spring-segment-routing-policy@ietf.org>
Subject: Comments on SR policy

 

Dear authors and all,

 

Please consider the following comments.

1. Do you think it is ok to add one more segmen= t type for the segment list to incorporate the segment for Layer 2 bundle m= embers? Please refer to rfc8668.

[KT] The Segment Type E covers Layer 2 Bundle = Members : https://tools.ietf.org/html/draft-ietf-spring-se= gment-routing-policy-08#section-4

 

       &nbs= p; This type can also be

       &nbs= p; used to indicate indirection into a layer 2 interface (i.e.

       &nbs= p; without IP address) like a representation of an optical

       &nbs= p; transport path or a layer 2 Ethernet port or circuit at the

       &nbs= p; specified node.

 

 

2. For per flow steering to a policy, why do we= limit the array index to 0 to 7?  I think this is implementation spec= ific and the number of paths in an array depends on the application scenario. I am not sure whether or not 8 paths is enough f= or all scenarios.

[KT] The draft does not limit the Forwarding Classes to 8.=
 The value 8 is more of an example and comes from Traffic Class [RFC5462] a=
nd the IP Precedence portion of DSCP [RFC2474]. The section starts with =
220;Let us assume” and there =
is also the following text in the same section:

=
 


   The array index values (e.g. =
0, 1 and 2) and the notion of


   forwarding-class are implemen=
tation specific and only meant to


   describe the desired behavior=
.  The same can be realized by other


   mechanisms.=



 


 

3. For protection in section 9.1, it is better = to add some text like "the local protection may not satisfy the SLA re= quirements or the path constrains for the policy" when an SR Policy is built on the basis of TI-LFA protected IGP segments.

[KT] Sure. We can add this clarification in th= e next update.

 

Thanks,

Ketan

 

Best Regards,

Zhenqiang Li

--_000_MW3PR11MB4570F5FE3FCE0A626081E8E4C1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 05:00:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E903A101C for ; Fri, 14 Aug 2020 05:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.1 X-Spam-Level: X-Spam-Status: No, score=-9.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NQwFw5/H; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=p31Z0Voh 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 cgsfyVOEd4wk for ; Fri, 14 Aug 2020 05:00:23 -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 6AD353A1007 for ; Fri, 14 Aug 2020 05:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36940; q=dns/txt; s=iport; t=1597406423; x=1598616023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rMSC2s22tiUafZt5LzBbbqcrDuMboYdEzR6IheYiatk=; b=NQwFw5/H703jhbl9Nf6rfKUrlDKxz/8lfgYgllb/svMIGV5F2NkOP/A0 HAdO8IQPf76Hrn/MAZeOqKqJA39PaNZAGQAKl723il8jyY71ehv7426Tn SRQDcGL1gtWtI3k6esRziz+BOVCZZmKk9TlNSS8z5jmjJGbV7Z6RxIbci g=; IronPort-PHdr: =?us-ascii?q?9a23=3AQGKGwByBZdFLaJ/XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRaBt/dqgVvJVIHD5uhCzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX8YFDWonS29TMIHF?= =?us-ascii?q?P0Mg8mbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTCQAmfDZf/5xdJa1VCoEJgxwpKAd?= =?us-ascii?q?wWC8sCoQtg0YDjVqBApdlgUKBEQNQAgMLAQEBDAEBGAgNAgQBAYQIRAIXgi4?= =?us-ascii?q?CJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAQMBARAICREMAQEsAQoBCwI?= =?us-ascii?q?CAgEGAhEEAQEBAgIjAwICAhQRCxQBCAgCBAENBQgagwWCSwMuAQ6WUZBoAoE?= =?us-ascii?q?5iGF2gTKDAQEBBYEzAQMCDgMPL4MnGIIOCQWBCSqCcYNghCqBAYEeGoFBPyZ?= =?us-ascii?q?pAQFDgU8uGzU+glwBAQIBARWBEQEHCwEjBRAPBgwCgl0zgi2PRQcSBwMGKoJ?= =?us-ascii?q?rigCZLwqCYohjhXxQhQiGCYJ/Nm2IOJNFhVaMYopChTmLFYQsAgQCBAUCDgE?= =?us-ascii?q?BBYFqI2dwcBU7gmkJRxcCDYhahVEXgQIBAoJJhRSFQnQCAQEzAgYBCQEBAwl?= =?us-ascii?q?8jzEBNFwBAQ?= X-IronPort-AV: E=Sophos;i="5.76,312,1592870400"; d="scan'208";a="813739137" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 12:00:14 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EC0CtW012111 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 12:00:14 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 07:00:09 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 07:00:08 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 07:00:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PIejQKPiZi25cwocK2ngQVX97TUNBAWDy4HkcpWGxBiBZ88Id2ecUdIO+yBVYnj+X49Vcp1gS1GAZAedVz5k+o4rCLq5Y5Nfc39L2U4WAFrEQ6fCJVo8HAR8RFyrLTzpPm6z0nbMB8i9dThSrT4L0aBanj0pamNyTRqxJrtgioHMcaAGsHE82PUH2ZZ77y1Xxd2inQBtIp/yOWCvTCwOMGG9rv6UU+xVyJX681AQCR3d0q5I7N58PyyQHF1jZzclgA2O931970MOSh0jfpbT2yYJ70mNdwpiCDg8HemfjWGewBcpoF/WPS0yzykD9XfYRHesiTtfk6QHtUicZo9uzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rMSC2s22tiUafZt5LzBbbqcrDuMboYdEzR6IheYiatk=; b=PX4ASzkj3/N8PQ+VJutW1yL0CrRyWPN32SdnBTvUMomb7vRJI/QwwnxwivlPH1ZsewwarB2qTgvqRdjvmlb5XdHkJO8fzgelv8dWKb8AAeAB2i95vpjkVAxRrIVdFXBgn2WchVdvEgBO3duXgp6mwQZMU+PfSIKcuvGhjyqb63vh6+6d/1Q7w+PJmpW6WY4nEhdaQ6ImjY+huQTnDwyl9aC3proKvF7QQBGjvVOLk1IPMayVkhRRcsm48mICaSSf4LICqpM3Vc6iELeJCSnjTde3qbRSAsjif3izQFEbNfzlVs59pK1wJEGufOxbjiD/d8x4fukeUDohYWBT07Wvaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rMSC2s22tiUafZt5LzBbbqcrDuMboYdEzR6IheYiatk=; b=p31Z0VohVmhma4bk+goEWHHRQECMeal2dC6Pb3Q6Eu1yXHxLFhpVFDbvU6HJaEsauLgjp9UnFAXY9Zm0UlbOIbwX+7tqMkUBSnKz45zA0wYX3JbG5z9P1Mibib3beDK1SHxHaAQ7BFATnSQ2Ck12nd1hVFDO1tfJpn/nj7XxKO8= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2270.namprd11.prod.outlook.com (2603:10b6:301:54::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 12:00:06 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 12:00:06 +0000 From: "Ketan Talaulikar (ketant)" To: "Joel M. Halpern" , Alexander Vainshtein , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfGJGLEw80LFEa7R79kiStyh6klun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAFLgAgAB1eACAD4BY8A== Date: Fri, 14 Aug 2020 12:00:06 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2221d2af-1d6b-47b2-a05d-08d840499622 x-ms-traffictypediagnostic: MWHPR1101MB2270: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oBXlmOy3WjoehltkYpG1xqWGy6RUYAhFLtZ6xF/FnkfoqCnMS01kg1wjPAsr5kMsG9JxHCZiTMTWw2sdXgfAsATOus+ufyMLlnD4gKnLXWkK+Ts2iJLXftyWvKc3ldxjEO6LDqyKOLtCwzcnxK4Y0aDXo5t37JrgqMnpYdER0lo767ccggUMpwBcM/aVs4bZ/ZsVORn6ytqEhjrTs7P//96+ii6lp+AD+C2MAmZOz+n+p392p3Er8zkp5aTsZZUe/tz+lLQUIw9KUckbg7pBrhP6t+VC8bUK81nm1u+QS5pOXqIUlUCHnkGtDiIe4DAqTvie2RQ/j63H1VdQmzoYpNEn96l9gshEc0okeHGZSYef/zZiLtxIfm6jxOvsjXUb9xoZtNw8iyttHEsd+3T8i/YWnU/CBfpzFfK7NT/RHhBCwbu5K/Mz3c070D21ky/R x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(39860400002)(396003)(136003)(9686003)(55016002)(8676002)(478600001)(86362001)(2906002)(71200400001)(83380400001)(316002)(4326008)(7696005)(6506007)(186003)(5660300002)(53546011)(52536014)(66946007)(76116006)(64756008)(66476007)(30864003)(66446008)(33656002)(26005)(66556008)(966005)(8936002)(110136005)(491001)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ewwn6hvShU8tx+OaRZHXPaAcS5cknb9mZSPQsrddVJifP4rMpxWi2PN4+By9Rw7QIx0loeOY/gvq8GEipG+rbjFR/hI8S9XoBBLnJRXWO3oHegUTCqwG0rBARxgvskcfrNVVv311SF3Xj/WKNXusm3ztEbckXAWkcOfLix9Rt7xlIpzx9PMdrJ1ON/dNIO9c5YZgLb/sCykxP83MtqBoWoca5dVnFf4T+kJ5zfwoQQLBRDlxkXgYiMiSst5kZqruAXRN+xJq9YtqSMqoaWmMuMt1RMDOwEl3n74YY4XCMUiJgWHxdMluoGSL8qPoiXOE3U4FunQIrEKVQLYRBputAQX93eOjX0p/zf0flCNzyuJWhLWnj1YlVCM+xB9eTF3EZ2nYwG1LGP4wUFzce/31o49MaRLUcacIsgha0qkP5ArQYyeYEgA2BQVDyBZ5/c+JPSHxDNQ3U45Wkg6Z3D2xgdgYfkHzxwlxOxjPX3eOS9m2fKwBWJvSJQUiOM1OgvorfG3I2r6hIxvMTiO9jzJ9CVmQHotU2DvZmbtWYzMiGi3U9dCDV9uHoj92Qb4iI4YyBJGN2f+IrrrDcTdlmIoMGlccN3NH6FD66hjjLM1sQu50y9WgMHnbItzSzFPsmYMacuFO7lwBRbW529dlzdxwWA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2221d2af-1d6b-47b2-a05d-08d840499622 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 12:00:06.5649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JG9ylsrx38hxv1WtGDDiPektyGjIGvw5WR8RITfehx8gK9SCo6OjAbAS2Az8U5piFhsKCSOAn6rV8X+LtS4JFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2270 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 12:00:26 -0000 SGkgQWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gc2hhcmUgYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUg b24gdGhpcy4NCg0KRmlyc3QsIHRoYW5rcyB0byBKb2VsIGZvciBicmluZ2luZyB1cCB0aGUgZGlz Y3Vzc2lvbi4gQ2xlYXJseSB3ZSBuZWVkIGEgd2VsbC1kZWZpbmVkIGFwcGxpY2FiaWxpdHkgc3Rh dGVtZW50IGZvciBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5IG9mIHByb3RlY3Rpb24gZm9yIHNl Z21lbnQgdXNlZCBpbiBhbiBTUiBQb2xpY3kuIFNvbWUgb2YgdGhpcyBpcyBjYXB0dXJlZCBpbiBb MV0uDQoNClRoaXMgaXMgYWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkg bmF0dXJlLCB0aGUgUExSIGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICJzdHJpY3Qgb3Ig bm90IiBpcyB0aGUgU0xBIHRoYXQgaXMgYmVpbmcgcHJvdmlkZWQgYnkgdGhlIFNSIFBvbGljeS4g QXdhcmVuZXNzIG9mIHRoYXQgbm90aW9uIGV4aXN0cyBhdCB0aGUgU1IgUG9saWN5IGhlYWRlbmQg YW5kL29yIGNvbXB1dGF0aW9uLW5vZGUuDQoNCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90 ZWN0ZWQgdmFyaWFudHMgb2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlv biB0byBwaWNrIG9yIHRoZSBvdGhlciBiYXNlZCBvbiB0aGUgInN0cmljdG5lc3MiIG9mIHRoZSBT TEEgcmVxdWlyZW1lbnQgZm9yIHBpY2tpbmcgdGhhdCBsaW5rLiBXZSBkbyBub3QgaGF2ZSBzdWNo IGEgbm90aW9uIGZvciBQcmVmaXggU0lEcy4gT25lIGNhbiBzYXkgdGhhdCB3ZSBjb3VsZCBpbnRy b2R1Y2Ugc2lnbmFsbGluZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFBy ZWZpeCBTSUQgY2FuIGJlIGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0 dW5pdHkgZm9yIHRoZSBjb21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3Ig ZGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS4NCg0K SSBoYXZlIGEgcHJvYmxlbSBhbmQgYSBjb25jZXJuIGluIHRoZSBhc3N1bXB0aW9uIHRoYXQgUExS cyBjYW4gYXNzdW1lIHRoYXQgdGhlIGN1cnJlbnRseSBkZWZpbmVkIHZhcmlhbnQgb2YgUHJlZml4 IFNJRHMgaW4gUkZDODQwMiAoYW5kIElHUCBzcGVjcykgYXJlICJieXBhc3MtYWJsZSIuDQoNCkFz IEpvZWwgYW5kIG90aGVycyBoYXZlIGJyb3VnaHQgb3V0LCB0aGUgUHJlZml4IFNJRCBjb3VsZCBi ZSBqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBz dGVlciB0aGUgZmxvdyB0byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0 aW9uIHRvIGl0LiBJbiBvcmRlciB0byBzdXBwb3J0IGEgbWl4IG9mIFNSIFBvbGljaWVzIG9mIGRp ZmZlcmVudCBTTEFzIChzdHJpY3QgYW5kIG5vdC1zdHJpY3QpLCB3ZSBuZWVkIHRvIGVuYWJsZSB0 aGUgY2hvaWNlIG9mIFNJRHMgdGhhdCBpbmRpY2F0ZXMgdG8gdGhlIFBMUiB3aGV0aGVyIHRoZXkg YXJlICJieXBhc3MtYWJsZSIgb3Igbm90Lg0KDQpGb3IgdGhlIGNhc2VzLCB3aGVyZSB0aGUgU1Ig UG9saWN5IGhhcyBhIHNwZWNpZmljIFNMQSwgaXQgaXMgcmVxdWlyZWQgZm9yIG5vZGVzIHRvIGRy b3AgdGhlIHBhY2tldHMgbWVhbnQgZm9yIHRoZSAiYWN0aXZlIHNlZ21lbnQiIHRoYW4gdG8gYnlw YXNzIGl0LiBXaGVuIHRoaXMgbWVjaGFuaXNtIGlzIHVzZWQgYWxvbmcgc2lkZSBTUlRFIHBhdGgg bW9uaXRvcmluZyBtZWNoYW5pc21zLCBpdCBlbmFibGVzIHRoZSBoZWFkZW5kIHRvIGRldGVjdCB0 aGUgZmFpbHVyZSBhbmQgZmFsbGJhY2sgdG8gYW4gYWx0ZXJuYXRlIHBhdGggdXNpbmcgdGhlIHBh dGggcHJvdGVjdGlvbiBhcHByb2FjaC4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyBkZXNjcmli ZWQgYW5kIGluIHVzZSBpbiBkZXBsb3ltZW50cyB0b2RheSBbMV0uDQoNClRoYW5rcywNCktldGFu DQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXBvbGljeS0wOCNzZWN0aW9uLTkNClsyXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOCNzZWN0 aW9uLTkuMw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3ByaW5nIDxzcHJp bmctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDog MDQgQXVndXN0IDIwMjAgMjA6MjUNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVy LlZhaW5zaHRlaW5AcmJibi5jb20+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGE9NDBqdW5pcGVy Lm5ldEBkbWFyYy5pZXRmLm9yZz47IEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29t IDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0 QHJhc3p1ay5uZXQ+DQpDYzogc3ByaW5nQGlldGYub3JnOyBKb2VsIE0uIEhhbHBlcm4gPGptaEBq b2VsaGFscGVybi5jb20+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24g LSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNClRoZXJlIGFyZSwgYXMgZmFyIGFzIEkgY2Fu IHRlbGwsIGEgbnVtYmVyIG9mIHdheXMgdG8gYWRkcmVzcyB0aGlzIGZhbWlseSBvZiByZWxhdGVk IHF1ZXN0aW9ucy4NCldoYXQgc3RydWNrIG1lLCBhbmQgcHJvbXB0ZWQgdGhlIHN0YXJ0aW5nIHF1 ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2VyZSBzcGVsbGVkIG91dC4gIEkgc2VlIGxv dHMgb2YgaW50ZXJlc3RpbmcgaWRlYXMgLyBwcm9wb3NhbHMuDQpTb21lIG9mIHRoZW0gYXJlIGNv bXBhdGlibGUgd2l0aCBvdGhlcnMuICAgU29tZSBhcmUgbm90Lg0KSXQgd291bGQgYmUgZ29vZCBp ZiB3ZSBjb3VsZCByZWFjaCBhZ3JlZW1lbnQgb24gaG93IHdlIHRob3VnaHQgaXQgc2hvdWxkIGJl IGhhbmRsZWQuDQoNClRoYW5rIHlvdSwNCkpvZWwNCg0KT24gOC80LzIwMjAgMzo1NCBBTSwgQWxl eGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+IEhpIGFsbCwNCj4gDQo+IEkgYW0gc3RpbGwgbm90 IHN1cmUgdGhhdCB0aGUgcHJvYmxlbSBvZiBieXBhc3MgZ29pbmcgdGhydSB1bmRlc2lyYWJsZSAN Cj4gbGlua3Mvbm9kZXMgZXhpc3RzIGluIHRoZSBjYXNlIG9mIHRvcG9sb2dpY2FsIFNJRHMuDQo+ IA0KPiBBRkFJSywgRmFjaWxpdHkgUHJvdGVjdGlvbiBpbiBSU1ZQLVRFIEZSUiAoUkZDIDQwOTAN Cj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MDkwPikgaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IGRlcGxveWVkIA0KPiBmb3IgbWFueSB5ZWFycyBiZWZvcmUgU1ItTVBMUyBoYXMgYmVl biBpbnRyb2R1Y2VkLiBXaGF04oCZcyBtb3JlLCANCj4gc2lnbmFsaW5nIG9mIGJ5cGFzcyB0dW5u ZWxzIGhlIFBMUiB1c3VhbGx5IGRpZCBub3QgaW5jbHVkZSBhbnkgb2YgdGhlIA0KPiBjb25zdHJh aW50cyB1c2VkIGZvciBjb21wdXRpbmcgb2YgYW55IHNwZWNpZmljIExTUCB0aGF0IHRoZSBieXBh c3MgTFNQIA0KPiB3b3VsZCBwcm90ZWN0IOKAkyBiZWNhdXNlIGluIHRoZSBGYWNpbGl0eSBQcm90 ZWN0aW9uIG1vZGUgdGhlIHNhbWUgDQo+IGJ5cGFzcyBMU1Agd291bGQgYmUgdXNlZCB0byBwcm90 ZWN0IG11bHRpcGxlIExTUHMgcGFzc2luZyB0aHJ1IHRoZSANCj4gZmFpbGVkIGxpbmsvbm9kZS4N Cj4gDQo+ICBGcm9tIG15IFBPViB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gdGhpcyBiZWhh dmlvciBhbmQgdGhhdCANCj4gaW50cm9kdWNlZCBieSB0aGUg4oCcYnlwYXNzaW5n4oCdIGRyYWZ0 cyBpbiBTUiBpcyB0aGF0LCBpbiB0aGUgY2FzZSBvZiANCj4gUlNWUC1URSwgdGhlIG9wZXJhdG9y IHdvdWxkIGV4cGxpY2l0bHkgaW5kaWNhdGUsIGFzIHBhcnQgb2YgTFNQIA0KPiBzaWduYWxpbmcs IHdoZXRoZXIgaXQgd291bGQgb3Igd291bGQgbm90IHVzZSBGUlI7IExTUHMgdGhhdCB3b3VsZCBu b3QgDQo+IHVzZSBGUlIgd291bGQgdGhlbiBkcm9wIHRyYWZmaWMgcmF0aGVyIHRoYW4gZGVsaXZl cmluZyBpdCB0aGUgd3Jvbmcgd2F5Lg0KPiANCj4gU3VjaCBhbiBvcHRpb24gaW5kZWVkIGRvZXMg bm90IGV4aXN0IGluIFNSLVRFIHRvZGF5LCBidXQgd291bGQgYmUgZWFzeSANCj4gdG8gcHJvdmlk ZSBpZiBzbyBkZXNpcmVkIElNSE8uDQo+IA0KPiBEaWQgSSBtaXNzIHNvbWV0aGluZyBzdWJzdGFu dGlhbD8NCj4gDQo+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0KPiAN Cj4gU2FzaGENCj4gDQo+IE9mZmljZTogKzk3Mi0zOTI2NjMwMg0KPiANCj4gQ2VsbDrCoMKgwqDC oMKgICs5NzItNTQ5MjY2MzAyDQo+IA0KPiBFbWFpbDrCoMKgIEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tDQo+IA0KPiAqRnJvbToqIHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc+ICpPbiBCZWhhbGYgT2YgKlNocmFkZGhhIEhlZ2RlDQo+ICpTZW50OiogVHVlc2RheSwgQXVn dXN0IDQsIDIwMjAgOTo0MSBBTQ0KPiAqVG86KiBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbQ0KPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IFJvYmVydCBSYXN6 dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KPiAqQ2M6KiBzcHJpbmdAaWV0Zi5vcmc7IEpvZWwgTS4g SGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gKlN1YmplY3Q6KiBSZTogW3NwcmluZ10g U3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQo+IA0KPiBBbGws DQo+IA0KPiBUaGlzIGlzIGEgdmVyeSBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIGFuZCB0aGFua3Mg dG8gSm9lbCBmb3Igc3RhcnRpbmcgDQo+IHRoaXMgZGlzY3Vzc2lvbi4gSU1PLCB3aGVuIHRoZXJl IGFyZSBzdHJpY3QgcmVxdWlyZW1lbnRzIG9mIGF2b2lkaW5nIA0KPiBjZXJ0YWluIG5vZGVzL2xp bmtzIGl0IGNhbiBiZSByZWFsaXplZMKgIGVpdGhlciBieSBkZWZpbmluZyBhIGZsZXgtYWxnbyAN Cj4gYXZvaWRpbmcgdGhvc2UNCj4gDQo+IE5vZGVzIGFuZCBsaW5rcyBvciBieSB1c2luZyBhIHN0 YWNrIG9mIHVucHJvdGVjdGVkIGFkai1zaWRzIHRoYXQgYXZvaWQgDQo+IHJlc3RyaWN0ZWQgbm9k ZXMgYW5kIGxpbmtzLiBXaGVuIGEgc3RhY2sgb2YgYWRqLXNpZHMgaXMgdXNlZCB0byANCj4gcmVh bGl6ZSB0aGUgcGF0aCwgdGhlIGhlYWQtZW5kIGJhc2VkIChzQkZEKSBwcm90ZWN0aW9uIG1lY2hh bmlzbXMgY2FuIGJlIGFwcGxpZWQuDQo+IA0KPiBJZiBOb2RlLXNpZHMvcHJlZml4LXNpZC9hbnlj YXN0LXNpZHMgYXJlIHVzZWQgdG8gYnVpbGQgdGhlIHN0YWNrLCB0aGUgDQo+IGZhaWx1cmUgZXZl bnRzIG1heSBjYXVzZSB0cmFmZmljIHRvIGdvIHRocm91Z2ggcmVzdHJpY3RlZCBub2RlcyBhbmQg DQo+IGxpbmtzLiBUaGlzIHdvdWxkIGhhcHBlbiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgYW55IGtp bmQgb2YgcHJvdGVjdGlvbiANCj4gaXMgaW4gdXNlIG9yIG5vdC4NCj4gDQo+IFJnZHMNCj4gDQo+ IFNocmFkZGhhDQo+IA0KPiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+IA0KPiAqRnJvbToq IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcgDQo+IDxtYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpBbmRyZXcgQWxzdG9uDQo+ICpTZW50OiogVHVl c2RheSwgQXVndXN0IDQsIDIwMjAgNTo0MSBBTQ0KPiAqVG86KiBSb2JlcnQgUmFzenVrIDxyb2Jl cnRAcmFzenVrLm5ldCA8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCj4gKkNjOiogc3ByaW5n QGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPjsgSm9lbCBNLiBIYWxwZXJuIA0KPiA8 am1oQGpvZWxoYWxwZXJuLmNvbSA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pg0KPiAqU3Vi amVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxp Y2FiaWxpdHkNCj4gDQo+ICpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRd Kg0KPiANCj4gUm9iZXJ0IHRoaXMgaXMgYWN0dWFsbHkgZmFyIG1vcmUgZGlmZmljdWx0IHdoZW4g 4oCTIGl0IGNhbiBiZSBhbiBlbnRpcmUNCj4gKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0IG5l ZWQgdG8gYmUgYXZvaWRlZC4NCj4gDQo+IEl0IGNvdWxkIHBvdGVudGlhbGx5IGJlIG1hZGUgdG8g d29yayBidXQgSeKAmWQgd29ycnkgdGhhdCB0byBkbyB0aGlzIOKAkyANCj4geW914oCZZCBoYXZl IHRvIHN0YWNrIDEwIOKAkyAyMCDigJMgMzAgbmVnYXRpdmUgbGFiZWxzIOKAkyBhbmQgdGhhdCB3 b3VsZG7igJl0IA0KPiBiZSB2aWFibGUuDQo+IA0KPiBJdOKAmXMgZWFzaWVyIHRvIHVzZSBhbGdv cml0aG1zIGFuZCBhZGphY2VuY3kgc2lkcyBhbmQgb3RoZXIgc3VjaCB0aGluZ3MgDQo+IHRvIGNh bGN1bGF0ZSBwYXRocyDigJMgdGhlIGJpZ2dlc3QgdHJpY2sgaXMgYWJvdXQgdGhlIHN0YWNrIGRl cHRoLsKgIFdoZW4gDQo+IHlvdSBoYXZlIHRoaXMgbmVlZCBmb3Igbm9kZSBhdm9pZGFuY2Ug4oCT IHRoZSBuZWVkIGZvciAxMCsgbGFiZWwgZGVwdGggDQo+IGlzIGNyaXRpY2FsIOKAkyB1bmxlc3Mg eW91IHdhbm5hIGJlIGFwcGx5aW5nIG9uZSBoZWxsIG9mIGEgbG90IG9mIA0KPiBiaW5kaW5nIGxh YmVscyBhbG9uZyB0aGUgd2F5IHdoaWNoIGlzIGEgbmlnaHRtYXJlLg0KPiANCj4gQnV0IHRvIGFu c3dlciB5b3VyIHF1ZXN0aW9uLCBpcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNlIOKAkyBpdOKAmXMg YSB1c2UgDQo+IGNhc2UgdGhhdCBtb3N0IG9mIHRoZSBwZW9wbGUgSSBkaXNjdXNzIHRoaXMgd2l0 aCBjZXJ0YWluIGhhdmUg4oCTIEkgY2FudCANCj4gY29tbWVudCBvbiBhIGdsb2JhbCBzY2FsZSwg b3IgZm9yIGFueW9uZSBlbHNlLCBidXQgZXZlcnkgaW5kaWNhdGlvbiBJIA0KPiBoYXZlIGlzIHRo YXQgeWVzIOKAkyBpdHMgc29tZXRoaW5nIHBlb3BsZSBuZWVkLCBhbmQgd2FudA0KPiANCj4gQW5k cmV3DQo+IA0KPiAqRnJvbToqIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0IDxtYWls dG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqU2VudDoqIFR1ZXNkYXksIDQgQXVndXN0IDIwMjAg MDE6MjcNCj4gKlRvOiogQW5kcmV3IEFsc3RvbiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbSANCj4gPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPj4NCj4gKkNj OiogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tIA0KPiA8bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20+Pjsgc3ByaW5nQGlldGYub3JnIA0KPiA8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4NCj4gKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRl cm1pbmluZyBhcHBsaWNhYmlsaXR5DQo+IA0KPiBJcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNlIGll LsKgICJidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgDQo+IHNlZ21lbnRzIGl0 IGNhbiBuZXZlciB0b3VjaCBvciBmbG93IHRocm91Z2guIg0KPiANCj4gSWYgc28gcGVyaGFwcyBp dHMgdGltZSB0byBkZWZpbmUgbm90aW9uIG9mICpuZWdhdGl2ZS1TSUQqIGllLiBsaXN0IGluIA0K PiB0aGUgcGFja2V0IHJlc291cmNlcyB3aGljaCBnaXZlbsKgcGFja2V0IE1VU1Qgbm90IGV2ZXIg dHJhdmVyc2UuDQo+IA0KPiBQdXQgaW4gdGhlIHBhY2tldCBzZXQgb2Ygbm9kZXMgb3IgbGlua3Mg d2hpY2ggdGhlIHBhY2tldCBzaG91bGQgbmV2ZXIgDQo+IHRyYXZlcnNlLg0KPiANCj4gVGhhdCBn b2VzIGluIGxpbmUgb2YgcmVjZW50IHdhdmUgb2YgbmVnYXRpdmUgcm91dGluZyBpbXBsZW1lbnRh dGlvbnMNCj4gKFJJRlQpIG9yIGRpc2N1c3Npb25zIChMU1IpDQo+IA0KPiBCZXN0LA0KPiBSLg0K PiANCj4gT24gTW9uLCBBdWcgMywgMjAyMCBhdCAxMTo0NiBQTSBBbmRyZXcgQWxzdG9uIA0KPiA8 QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSANCj4gPG1haWx0bzpBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPj4gd3JvdGU6DQo+IA0KPiAgICAgU28g4oCTDQo+IA0KPiAgICAg T25lIG9mIHRoZSB1c2UgY2FzZXMsIGluIGZhY3QsIHNvbWUgdmVyeSBtYWpvciB1c2UgY2FzZXMg aW4gYW55DQo+ICAgICBzcHJpbmcgdGVjaG5vbG9neSBmb3IgdXMgcmV2b2x2ZSBhcm91bmQgdGhl IGZvbGxvd2luZw0KPiANCj4gICAgIGEuVGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWlu IG5vZGVzDQo+IA0KPiAgICAgYi5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gc2Vj dGlvbnMgb2YgdGhlIG5ldHdvcmsNCj4gDQo+ICAgICBBbnl0aGluZyB0aGF0IGNvdWxkIHJlc3Vs dCBpbiB0aGF0IGV4cGxpY2l0IGF2b2lkYW5jZSBiZWluZyB2aW9sYXRlZA0KPiAgICAg4oCTIHdv dWxkIGNyZWF0ZSwgc2hhbGwgd2Ugc2F5IHNpZ25pZmljYW50IHByb2JsZW1zLg0KPiANCj4gICAg IE11Y2ggb2YgdGhlIHVzZSBjYXNlIGlzIG5vdCBhIGNhc2Ugb2Ygd2hpY2ggbm9kZXMgdGhlIHBh Y2tldHMgZmxvdw0KPiAgICAgdGhyb3VnaCDigJMgYnV0IHJhdGhlciDigJMgd2hpY2ggbm9kZXMg LyBuZXR3b3JrIHNlZ21lbnRzIGl0IGNhbiBuZXZlcg0KPiAgICAgdG91Y2ggb3IgZmxvdyB0aHJv dWdoLsKgIEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9neSB0bw0KPiAgICAg YXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuDQo+IA0KPiAgICAgVGhp cyBpcyBhbHNvIG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwg c3RhY2tzIOKAkw0KPiAgICAgdGhpcyBraW5kIG9mIGRldGFpbGVkIHBhdGggcHJvZ3JhbW1pbmcg dGVuZHMgdG8gZGVlcGVuIHRoZSBzdGFjaw0KPiAgICAgYmVjYXVzZSB5b3Ugc29tZXRpbWVzIGhh dmUgdG8gYmUgcHJldHR5IGV4cGxpY2l0Lg0KPiANCj4gICAgIEl0IGlzIGFic29sdXRlbHkgY3Jp dGljYWwgdG8gdXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUg4oCTDQo+ICAgICBh bmQgdGhhdCB3ZSBjYW4gYXZvaWQgc2l0dWF0aW9ucyB3aGljaCBjb3VsZCBjYXVzZSB0cmFmZmlj IHRvDQo+ICAgICBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhwbGljaXRseSBhdm9pZGVkLg0KPiAN Cj4gICAgIEkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgdGhhbiB0aGlzLCBidXQgaXQg aXMgd2hhdCBpdCBpcy4NCj4gDQo+ICAgICBUaGFua3MNCj4gDQo+ICAgICBBbmRyZXcNCj4gDQo+ ICAgICAqRnJvbToqIHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCj4gICAgIDxtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpKb2VsIE0uIEhhbHBl cm4NCj4gICAgICpTZW50OiogTW9uZGF5LCAzIEF1Z3VzdCAyMDIwIDIxOjM2DQo+ICAgICAqVG86 KiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldCA8bWFpbHRvOnJvYmVydEByYXN6dWsu bmV0Pj4NCj4gICAgICpDYzoqIHNwcmluZ0BpZXRmLi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQo+ICAgICAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRl dGVybWluaW5nIA0KPiBhcHBsaWNhYmlsaXR5DQo+IA0KPiAgICAgKFNpbmNlIHRoZSB0aHJlYWQg aGFzIGdvdHRlbiBsb25nIGVub3VnaCwgcmVpdGVyYXRpbmcgdGhhdCB0aGlzIGlzIGFzIGENCj4g ICAgIHBhcnRpY2lwYW50LCBub3QgYSBXRyBjaGFpci4pDQo+IA0KPiAgICAgWWVzLCB3ZSBhcmUg dGFsa2luZyBJUCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29ya3MgdGhh dA0KPiAgICAgY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFsbCBzb3J0cyBvZiByZWFzb25z Lg0KPiAgICAgSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9uZSBt YXkgbm90IHdhbnQgYSByYW5kb20NCj4gICAgIHBhdGggcmF0aGVyIHRoYW4gYSBjaG9zZW4gVEUg cGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXINCj4gICAgIGFib3V0IHdo YXQgY29uc3RyYWludHMgbWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUg dGhleQ0KPiAgICAgaGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0aGF0IGlz IGludGVuZGVkIHRvIHByZXNlcnZlIFFvUy4NCj4gDQo+ICAgICBMZXQncyBiZSBjbGVhci4gSSBh bSBub3QgYXJndWluZyB0aGF0IHRoaXMgaXMgbm90IGEgZ29vZCBpZGVhLiBJdCBpcyBhDQo+ICAg ICBnb29kIGlkZWEuIEFuZCB1c2VmdWwuIEkgYW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdHUgd2hhdCBj b21iaW5hdGlvbiBvZg0KPiAgICAgYWRkaXRpb25hbCBtZWNoYW5pc21zIGFuZCBjbGVhciBkZXNj cmlwdGlvbnMgd2lsbCBsZWFkIHRvIGV2ZXJ5b25lDQo+ICAgICBnZXR0aW5nIHRoZSBiZWhhdmlv ciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5vdCBiZSB0aGUgYmVoYXZpb3IgdGhleQ0KPiAgICAg ZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBiZXN0IHdlIGNhbiBkby4pDQo+IA0KPiAgICAg WW91cnMsDQo+ICAgICBKb2VsDQo+IA0KPiAgICAgT24gOC8zLzIwMjAgMjozMCBQTSwgUm9iZXJ0 IFJhc3p1ayB3cm90ZToNCj4gICAgICA+IEpvZWwsDQo+ICAgICAgPg0KPiAgICAgID4gQXJlIHdl IHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya3PCoGhlcmUgPyBPciBwZXJoYXBzIHNvbWUg aGFyZA0KPiAgICAgID4gc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9y IGRldG5ldHMgPw0KPiAgICAgID4NCj4gICAgICA+IEJlY2F1c2XCoGlmIHdlIGFyZSB0YWxraW5n wqBhYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d28NCj4gICAgIG9ic2VydmF0aW9uczoNCj4g ICAgICA+DQo+ICAgICAgPiBBKSBJZiB5b3UgbmVlZCB0byB0cmF2ZXJzZSB2aWEgYSBzcGVjaWZp YyBub2RlIChpZS4gZmlyZXdhbGwpIHlvdQ0KPiAgICAgYmV0dGVyDQo+ICAgICAgPiBhcHBseSBJ UCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4gSSBkb24ndCB0aGluayBJUA0KPiAgICAgZW5j YXBzdWxhdGlvbsKgY2FuDQo+ICAgICAgPiBiZSBoaWphY2tlZCB0b2RheSBzdWNoIHRoYXQgZGVz dGluYXRpb24gYWRkcmVzcyBvZiB0aGUgcGFja2V0IGlzDQo+ICAgICBpZ25vcmVkLg0KPiAgICAg ID4NCj4gICAgICA+IEIpIEhhdmUgeW91IHNlZW4gYW55IElQIG5ldHdvcmsgd2hlcmUgdXBvbiB0 b3BvbG9neSBjaGFuZ2UgKGxpbmsNCj4gICAgIG9yIG5vZGUNCj4gICAgICA+IGZhaWx1cmUpIHlv dSBzdWRkZW5secKgc3RhcnQgZHJvcHBpbmfCoGZsb3dzIGluIHNwaXRlIG9mIFNQVCBvZmZlcmlu Zw0KPiAgICAgID4gcGVyaGFwcyBmZXcgbXMgbG9uZ2VyIHBhdGggd2l0aCAxMCBtcyBtb3JlIGpp dHRlciA/DQo+ICAgICAgPg0KPiAgICAgID4gT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNsaWRl cyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4NCj4gICAgICA+IHNvbWV0aGluZ8KgbmV3 ID8gV29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3VhcmFudGVlcywNCj4g ICAgICA+IHJlc291cmNlIHJlc2VydmF0aW9uc8KgPyBJIGhvcGUgbm90Lg0KPiAgICAgID4NCj4g ICAgICA+IFRoeCwNCj4gICAgICA+IFIuDQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+ DQo+ICAgICAgPiBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDg6MTAgUE0gSm9lbCBNLiBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tDQo+ICAgICA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20l MjAlMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCj4gICAgICA+DQo+ ICAgICAgPiBXZWxsIGxlc3Mgc2VyaW91cyBmb3IgVEUgU0lEcywgSSBhbSBub3Qgc3VyZSB0aGUg cHJvYmxlbSBpcw0KPiAgICAgcmVzdHJpY3RlZA0KPiAgICAgID4gdG8ganVzdCBzZXJ2aWNlIFNJ RHMuDQo+ICAgICAgPg0KPiAgICAgID4gU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmll ZCB0aGUgcGF0aCB0byBtZWV0IHNvbWUgY29tcGxleCB0ZQ0KPiAgICAgID4gb2JqZWN0aXZlLsKg IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dpbmcgd2hhdCB0aG9zZQ0KPiAgICAg ID4gY29uc3RyYWludHMNCj4gICAgICA+IHdlcmUuwqAgQW5kIGZvciBzb21lIGtpbmRzIG9mIHRy YWZmaWMsIGl0IGlzIGJldHRlciB0byBkcm9wIHRoZSBwYWNrZXQNCj4gICAgICA+IHRoYW4gdG8g ZGVsaXZlciBpdCBvdXRzaWRlIHRoZSBlbnZlbG9wLsKgIEkgc3VzcGVjdCB0aGF0IHRoZSByaWdo dA0KPiAgICAgID4gYW5zd2VyDQo+ICAgICAgPiB0byB0aGlzIGlzICJ0b28gYmFkIi7CoCBJZiBz bywgYXMgd2l0aCB0aGUgZGlzdGluY3Rpb24gcmVnYXJkaW5nDQo+ICAgICBzZXJ2aWNlDQo+ICAg ICAgPiBub2Rlcywgd2Ugc2hvdWxkIHNheSBzbywgc2hvdWxkbid0IHdlPw0KPiAgICAgID4NCj4g ICAgICA+IFlvdXJzLA0KPiAgICAgID4gSm9lbA0KPiAgICAgID4NCj4gICAgICA+IE9uIDgvMy8y MDIwIDI6MzYgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOg0KPiAgICAgID4gPiBNYWNo LCBKb2VsIGFuZCBhbGwsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgdGhpbmsgdGhhdCBpbiBt b3N0IGNhc2VzOg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAxLlRoZXJlIGlzIGNsZWFyIGRpZmZl cmVudGlhdGlvbiBiZXR3ZWVuICJ0b3BvbG9naWNhbCIgYW5kDQo+ICAgICAic2VydmljZSINCj4g ICAgICA+ID4gaW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5nLjoNCj4gICAg ICA+ID4NCj4gICAgICA+ID4gb0lHUCBQcmVmaXggTm9kZSBTSURzIElHUCBBZGotU0lEcyAoaWRl bnRpZmllZCBhcyBzdWNoIGluIHRoZQ0KPiAgICAgID4gPiBjb3JyZXNwb25kaW5nIElHUCBhZHZl cnRpc2VtZW50cykgcmVwcmVzZW50IHRvcG9sb2dpY2FsDQo+ICAgICBpbnN0cnVjdGlvbnMNCj4g ICAgICA+ID4NCj4gICAgICA+ID4gb1NlcnZpY2UgU0lEcyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQ LUJhc2VkIE92ZXJsYXkgU2VydmljZXMNCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJlc3Mtc3J2Ni1z ZXJ2aWNlcy0wNA0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zR0M1YWYy ejNKenBoWkRrUG5jSEFRaTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUy Rl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1p ZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNF9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5 RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG80VC1MMG5s JTI0Pj4NCj4gICAgICA+DQo+ICAgICAgPiA+IGRyYWZ0KSB1bnN1cnByaXNpbmdseSByZXByZXNl bnQg4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnMNCj4gICAgICA+ID4NCj4gICAgICA+ID4gMi5T ZWdtZW50cyB0aGF0IHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5 cGFzc2VkLA0KPiAgICAgID4gPiB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2VudCBzZXJ2aWNl IGluc3RydWN0aW9ucyByZXF1aXJlDQo+ICAgICAgPiBhbHRlcm5hdGl2ZQ0KPiAgICAgID4gPiBw cm90ZWN0aW9uIG1lY2hhbmlzbXMuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IFRoaXMgdmlldyBz ZWVtcyB0byBiZSBhbGlnbmVkIHdpdGggUkZDIDg0MDINCj4gICAgICA+ID4gPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyDQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzM3UHpVS0FEODJjalN2bVZjR3Zwa2hGNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZl bnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0 MDJfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4 cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvMEk0WWJ0bSUyND4+DQo+ICAgICB0aGF0IHNheXMg aW4gU2VjdGlvbiAxOg0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgIMKgwqAgSW4gdGhlIGNvbnRl eHQgb2YgYW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bw0KPiAgICAg ID4gPg0KPiAgICAgID4gPiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIElH UC1BZGphY2VuY3kgc2VnbWVudCBhbmQgdGhlDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgwqDC oCBJR1AtUHJlZml4IHNlZ21lbnQuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgwqDCoCBJbiB0 aGUgY29udGV4dCBvZiBhIEJHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28N Cj4gICAgICA+ID4NCj4gICAgICA+ID4gdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6 IHRoZSBCR1AgcGVlcmluZyBzZWdtZW50IGFuZCB0aGUNCj4gICAgICA+ID4NCj4gICAgICA+ID7C oCDCoMKgIEJHUC1QcmVmaXggc2VnbWVudC4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gSW4gdGhl IGNhc2Ugb2YgU1ItTVBMUyB0aGlzIGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rp b24NCj4gICAgICA+IDMuNCBvZg0KPiAgICAgID4gPiB0aGUgTm9kZSBQcm90ZWN0aW9uIGZvciBT Ui1URSBQYXRoDQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgPGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1m b3Itc3ItdGUtcGF0aHMtMDcjc2VjdGlvbi0zLjQNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vM0NyVWdBUlc4c29tQWJ3NlRpc2pnSjE2SDI/dT1odHRwcyUzQSUyRiUyRnVy bGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUt cGF0aHMtMDclMkFzZWN0aW9uLTMuNF9fJTNCSXclMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlG WU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzl3Ty1Tc24l MjQ+Pg0KPiAgICAgID4NCj4gICAgICA+ID4gZHJhZnQgdGhhdCBzYXlzOg0KPiAgICAgID4gPg0K PiAgICAgID4gPsKgIMKgwqAgVGhlIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVk IGluIHRoZSBwcmV2aW91cw0KPiAgICAgc2VjdGlvbnMNCj4gICAgICA+ID4NCj4gICAgICA+ID7C oCDCoMKgIGRlcGVuZHMgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgbGFiZWwgaW1tZWRpYXRl bHkgYmVsb3cNCj4gICAgICA+IHRoZSB0b3ANCj4gICAgICA+ID4NCj4gICAgICA+ID4gbGFiZWwg aW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElHUCBkb21haW4uwqAgV2hl biB0aGUNCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCDCoMKgIHByb3ZpZGVyIGVkZ2Ugcm91dGVy cyBleGNoYW5nZSBzZXJ2aWNlIGxhYmVscyB2aWEgQkdQIG9yIHNvbWUNCj4gICAgICA+IG90aGVy DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgwqDCoCBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90 dG9tIGxhYmVsIGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1ANCj4gICAgICA+ID4NCj4gICAg ICA+ID7CoCDCoMKgIGRvbWFpbi4NCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCDCoMKgIFRoZSBl Z3Jlc3Mgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdA0K PiAgICAgID4gPg0KPiAgICAgID4gPsKgIMKgwqAgW1JGQzg2NzkgPGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODY3OQ0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zNmRNQWp1WVRRb3ZvOGpId21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZyZmM4Njc5X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVf UjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQ+Pl0N Cj4gICAgIGlzDQo+ICAgICAgPiA+IGFwcGxpY2FibGUgdG8gdGhpcyB1c2UgY2FzZSBhbmQgbm8g YWRkaXRpb25hbCBjaGFuZ2VzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgwqDCoCB3aWxsIGJl IHJlcXVpcmVkIGZvciBTUiBiYXNlZCBuZXR3b3Jrcw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBU aGUgc2NlbmFyaW9zIGluIHdoaWNoIMKgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4g4oCcdG9wb2xv Z2ljYWzigJ0gYW5kDQo+ICAgICAgPiA+IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zIGlzIGJy b2tlbiBhcmUgaW5kZWVkIHByb2JsZW1hdGljLiBFLmcuLA0KPiAgICAgID4gY29uc2lkZXINCj4g ICAgICA+ID4gdGhlIHVzZSBjYXNlIGluIHdoaWNoIGEgTm9kZSBTSUQgaW4gdGhlIEVSTyBvZiBh IFNSLVRFIHBhdGgNCj4gICAgICA+IGlkZW50aWZpZXMgYQ0KPiAgICAgID4gPiBub2RlIHRoYXQg YWN0cyBhcyBhIGZpcmV3YWxsIGZvciBhbGwgcGFja2V0cyBpdCByZWNlaXZlcywgaS5lLiwNCj4g ICAgICA+IHByb3ZpZGVzDQo+ICAgICAgPiA+IHRoZSBmaXJld2FsbCBzZXJ2aWNlIHdpdGhvdXQg YW55IGRlZGljYXRlZCBzZXJ2aWNlIFNJRA0KPiAgICAgID4gaWRlbnRpZnlpbmcgaXQuDQo+ICAg ICAgPiA+IE9uZSBjb3VsZCBzYXkgdGhhdCB0aGUgTm9kZSBTSUQgb2Ygc3VjaCBhIG5vZGUgd291 bGQgY29tYmluZQ0KPiAgICAgID4gdG9wb2xvZ2ljYWwNCj4gICAgICA+ID4gYW5kIHNlcnZpY2Ug aW5zdHJ1Y3Rpb25zIHRodXMgYnJlYWtpbmcgdGhlIGRpZmZlcmVudGlhdGlvbg0KPiAgICAgID4g YmV0d2VlbiB0aGUgdHdvLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJIGFtIG5vdCBzdXJlIGlm IHVzYWdlIG9mIHN1Y2gg4oCcY29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2ZW50ZWQNCj4g ICAgICA+IG9yIGF0DQo+ICAgICAgPiA+IGxlYXN0IGRpc2NvdXJhZ2VkLg0KPiAgICAgID4gPg0K PiAgICAgID4gPiBJZiBub3QsIHByb3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50aWZ5IHN1Y2gg U0lEcyBpbiB0aGUNCj4gICAgICA+IGFkdmVydGlzZW1lbnQNCj4gICAgICA+ID4gbWVjaGFuaXNt cyB3b3VsZCBiZSB1c2VmdWwgSU1ITy4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gTXkgMmMsDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+IFNhc2hhDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IE9mZmlj ZTogKzk3Mi0zOTI2NjMwMg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBDZWxsOsKgwqDCoMKgwqAg Kzk3Mi01NDkyNjYzMDINCj4gICAgICA+ID4NCj4gICAgICA+ID4gRW1haWw6IEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tDQo+ICAgICA8bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tPg0KPiAgICAgID4gPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gICAgICA+ID4gRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZw0KPiAg ICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYj4+DQo+ICAgICA8bWFpbHRvOnNw cmluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1hY2ggQ2hlbg0KPiAgICAgID4g PiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDY6MzAgQU0NCj4gICAgICA+ID4gVG86IEpv ZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPiAgICAgPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tJTBiPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj47DQo+ICAgICBz cHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGll dGYub3JnPg0KPiAgICAgID4gPiBTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rp b24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEhp IEpvZWwsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgcG9p bnQgdGhhdCBtYXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0aGUNCj4gICAgICA+IHBhc3QuIEFuZA0K PiAgICAgID4gPiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAiY2FuIGJlIGJ5cGFzc2Vk IiBpbmRpY2F0aW9uIGluIHRoZQ0KPiAgICAgID4gPiByb3V0aW5nIGFkdmVydGlzZW1lbnQgZm9y IG5vdy4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gSU1ITywgdGhlIGluZm9ybWF0aW9uIGFkdmVy dGlzZWQgYnkgcm91dGluZyBpcyBuZXV0cmFsLCBzdWNoDQo+ICAgICAgPiBpbmZvcm1hdGlvbg0K PiAgICAgID4gPiAoY2FuIG9yIGNhbm5vdCBiZSBieXBhc3NlZCkgaXMgbW9yZSBwYXRoIHNwZWNp ZmljLCB0aHVzDQo+ICAgICBub3JtYWxseSB0aGUNCj4gICAgICA+ID4gY29udHJvbGxlciBzaG91 bGQgYmUgcmVzcG9uc2libGUgZm9yIGRlY2lkaW5nIHdoZXRoZXIvd2hpY2ggU0lEDQo+ICAgICAg PiBjYW4gYmUNCj4gICAgICA+ID4gYnlwYXNzZWQuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEJl c3QgcmVnYXJkcywNCj4gICAgICA+ID4NCj4gICAgICA+ID4gTWFjaA0KPiAgICAgID4gPg0KPiAg ICAgID4gPsKgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gICAgICA+ID4NCj4gICAg ICA+ID7CoCA+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo+ ICAgICAgPiA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUzY21haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyUzZT5dDQo+ICAgICBPbiBCZWhhbGYgT2YgSm9lbCBNLg0KPiAgICAgID4gPg0KPiAg ICAgID4gPsKgID4gSGFscGVybg0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgID4gU2VudDogTW9u ZGF5LCBBdWd1c3QgMywgMjAyMCA3OjUxIEFNDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgPiBU bzogc3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZw0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2Nt YWlsdG86c3ByaW5nQGlldGYub3JnPj4+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgPiBTdWJq ZWN0OiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxp dHkNCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAg PiAoV0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20gYSBzbGlnaHRs eQ0KPiAgICAgID4gY29uZnVzZWQgV0cNCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCA+IHBhcnRp Y2lwYW50LikNCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCA+DQo+ICAgICAgPiA+DQo+ICAgICAg PiA+wqAgPiBJIGhhdmUgYmVlbiByZWFkaW5nIHRoZSB2YXJpb3VzIHJlcGFpciBkcmFmdHMsIGFu ZCB0aGUgdmFyaW91cw0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgID4gbmV0d29ya3MgcHJvZ3Jh bW1pbmcgYW5kIHNlcnZpY2UgcHJvZ3JhbW1pbmcgZHJhZnQsIGFuZCBJIGFtDQo+ICAgICAgPiB0 cnlpbmcgdG8NCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCA+IGZpZ3VyZSBvdXQgb25lIGFzcGVj dCBvZiB0aGUgY29tYmluYXRpb24uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgPg0KPiAgICAg ID4gPg0KPiAgICAgID4gPsKgID4gSG93IGRvZXMgYSBub2RlIHRoYXQgaXMgZG9pbmcgc29tZSBm b3JtIG9mIGJ5cGFzcyAoc3VwcG9zZSwgZm9yDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgPiBz aW1wbGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQg Zm9yDQo+ICAgICAgPiBhIGZhaWxlZA0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgID4gbm9kZSBO Mykga25vdyB0aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ wqAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgID4gSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9y IFRFLCB0aGVuIGl0IGlzICJzYWZlIiBpZiB0aGUgbmV3IHBhdGgNCj4gICAgICA+IG1lZXRzDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgPiB0aGUgVEUgY3JpdGVyaWEuwqAgb3IgbWF5YmUgaXQg aXMgc2FmZSBpZiBpdCBpcyBldmVuIGNsb3NlLCBhcw0KPiAgICAgID4gbG9uZyBhcw0KPiAgICAg ID4gPg0KPiAgICAgID4gPsKgID4gaXQgaXMgbm90IHVzZWQgZm9yIHRvbyBsb25nLg0KPiAgICAg ID4gPg0KPiAgICAgID4gPsKgID4NCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCA+IEJ1dCB3aGF0 IGlmIHRoZSBub2RlIHdlcmUgYSBGaXJld2FsbCwgaW5jbHVkZWQgdG8gbWVldCBsZWdhbA0KPiAg ICAgID4gPiByZXF1aXJlbWVudHM/DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgPiBPciB3YXMg c29tZSBvdGhlciBuZWNlc3NhcnkgcHJvZ3JhbW1hdGljIHRyYW5zZm9ybSAod2luY2Ugd2UgYXJl DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+wqAgPiBkZWxpYmVyYXRlbHkgdmFndWUgYWJvdXQgd2hh dCBub2RlcyBjYW4gZG8gd2hlbiBhc2tlZCBzdWl0YWJseS4pDQo+ICAgICAgPiA+DQo+ICAgICAg PiA+wqAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgID4gSXMgdGhlcmUgc29tZSAiY2FuIGJl IGJ5cGFzc2VkIiBpbmRpY2F0aW9uIGluIHRoZSByb3V0aW5nDQo+ICAgICAgPiA+DQo+ICAgICAg PiA+wqAgPiBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPw0KPiAgICAgID4gPg0KPiAgICAg ID4gPsKgID4NCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCA+IFRoYW5rIHlvdSwNCj4gICAgICA+ ID4NCj4gICAgICA+ID7CoCA+IFlvdXJzLA0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgID4gSm9l bA0KPiAgICAgID4gPg0KPiAgICAgID4gPsKgID4NCj4gICAgICA+ID4NCj4gICAgICA+ID7CoCA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAg PiA+DQo+ICAgICAgPiA+wqAgPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPiA+DQo+ICAg ICAgPiA+wqAgPiBzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAg ICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+IDxtYWlsdG86c3ByaW5nQGlldGYu b3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4gICAgICA+ID4NCj4gICAgICA+ID7C oCA+DQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMg0KPiAgICAgPGh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTd2WDJxV1NVZFdWYzg5Mlh1WHkySDZIMj91 PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlja3Rp bWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0cHMl MkEzQSUyQTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0 UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNkh3UExpbCUyND4NCj4gICAgICA+ ID4NCj4gICAgICA+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3Fo VTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyDQo+ICAgICA8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNBNUI4SDJGbTFyUG5hWjNTdXBqd3I2SDI/dT1odHRwcyUzQSUy RiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVj LmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyNTJf XyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4 cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvem9RaUFIayUyND4+DQo+ICAgICAgPiA+DQo+ICAg ICAgPiA+wqAgPiBGJTJGd3d3LmlldGYub3JnDQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxk ZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5F dDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhP R3Q4QWtUUkR1aURvLXBQQ2p2UiUyND4NCj4gICAgICA+IDxodHRwOi8vMkZ3d3cuaWV0Zi5vcmcN Cj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzlOem5tWUJ0UnVIQVJoR0o1 VzVkR0I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHAlM0El MkYyRnd3dy5pZXRmLm9yZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ix b2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8tcFBDanZSJTI0Pj4lMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcNCj4gICAgICA+ID4NCj4gICAgICA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+ID4NCj4g ICAgICA+ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBzcHJp bmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86c3ByaW5n QGlldGYub3JnJTBiPj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KPiAgICAgID4gPg0KPiAg ICAgID4gPg0KPiAgICAgID4NCj4gICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzNCaHlFdHg0UTduNzRCaGlSbmZNSnRUNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxk ZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYz NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMkYlMkEyRnd3dy5p ZXRmLm9yZyUyQTJGbWFpbG1hbiUyQTJGbGlzdGluZm8lMkEyRnNwcmluZ19fJTNCSlNVbEpTVWwl MjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3 cDZ2cFJIT0d0OEFrVFJEdWlEby1oUjNnQUQlMjQ+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ICAgICAgPiA+IE5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4NCj4gICAgICA+ID4gaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmlj YXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwNCj4gICAgICA+IGFuZC9vcg0KPiAgICAg ID4gPiBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQuIEFueSByZXZpZXcsDQo+ICAgICAgPiA+IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3Ry aWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZw0KPiAgICAgd2l0aG91dA0KPiAgICAgID4g PiBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBu b3QgdGhlDQo+ICAgICAgPiBpbnRlbmRlZA0KPiAgICAgID4gPiByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsDQo+ICAgICAg PiA+IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy4NCj4gICAgICA+ID4NCj4gICAg ICA+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICA+ID4NCj4gICAgICA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+ID4gc3By aW5nIG1haWxpbmcgbGlzdA0KPiAgICAgID4gPiBzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiAgICAgPGh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4 OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5i aiUyND4NCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICAgPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgID4gc3ByaW5nIG1haWxpbmcgbGlz dA0KPiAgICAgID4gc3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3ByaW5nDQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNv bSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUy RnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdt MHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Pg0KPiAgICAgID4NCj4g DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiAgICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgc3ByaW5nQGlldGYub3JnIDxtYWlsdG86 c3ByaW5nQGlldGYub3JnPg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmcNCj4gICAgIA0KPiA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNO ckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElDQo+IDJGJTJGdXJsZGVmZW5zZS5j b20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGkNCj4g bmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFB dFF4Z20weDB3eHFndQ0KPiBvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Pg0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IE5vdGljZTogVGhpcyBlLW1haWwgdG9n ZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gDQo+IGluZm9ybWF0aW9uIG9m IFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vciAN Cj4gcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LiBBbnkgcmV2aWV3LCANCj4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5 IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQgDQo+IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgDQo+IHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0 ZSBhbGwgDQo+IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy4NCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K From nobody Fri Aug 14 05:24:59 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324153A1081; Fri, 14 Aug 2020 05:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QG0E3q7i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RTK2B4KR 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 xCmZu9YDGODm; Fri, 14 Aug 2020 05:24:56 -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 DDB8B3A1080; Fri, 14 Aug 2020 05:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11173; q=dns/txt; s=iport; t=1597407895; x=1598617495; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C83yzHAhPnbv2jEUbitAlG2B1CgVS0Qzp7rd3vMLS/k=; b=QG0E3q7im0HbactbW/7ZqeyH2rvKDsAZll5oHKy+grXYwiGiHfuWYINA mC1bqhrRpHovVTk0V8n31M4uV0XxxeZmPSgMBaSsgXiGoMFH1fXZYS8Cl XPPRng4u0JiNO3+NpqMJtaH+3C+9XK7jVKNPjGKEXjA6+ymtp1trn3IN4 Y=; X-IPAS-Result: =?us-ascii?q?A0CaBQCXgTZf/4QNJK1fHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UqBIy8jLgdwWC8sCodzA41bk3qEbYFCgREDVQsBAQEMAQElCAIEAQGETAKCR?= =?us-ascii?q?QIkOBMCAwEBAQMCAwEBAQEFAQEBAgEGBG2FXAyFcQEBAQEDEgsQEwEBNwEPA?= =?us-ascii?q?gEIEQQBARYZMh0IAQEEAQ0FCBMHgwWBfk0DLgEOpz0CgTmIYXSBNIMBAQEFg?= =?us-ascii?q?TMBAwIRD4NaGIIOAwaBOIJxiikagUE/gRFDgk0+glwBAQOBFRIBEgEjKxKDC?= =?us-ascii?q?4Itj0yKGItckHIKgmKIY5Fdgn+JW5NFkjiKQpR6AgQCBAUCDgEBBYFqI2dwc?= =?us-ascii?q?BU7gjUBATJQFwINjh8MFxSDOoUUhUJ0NwIGCgEBAwl8jzEBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AyaXA+x8Frc7/4P9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN4u9kilDEG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK8K0FTF8u4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.76,312,1592870400"; d="scan'208,217";a="519327242" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 12:24:54 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 07ECOrKw009560 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 12:24:53 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 07:24:53 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 08:24:52 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 07:24:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ATGB9MeMfXw+Bl/n8fowJP+qhPzIM7XYHqNY7dzeiyPlQmn2c8F3vh+yXybu/wL/8VlWS/7mY2h75caqh4QWC+TXEeAfGndc1yD7HGJaPSsSspBQERKb+x8+DShdAYhv2++hj3wXRV5oPRIh6Lbino1h204UwXsWhPUYOzCUSwOWrjn69gW+N8qIJ6fM5t/09t0VSJczEESxtvpvaGcAxqoIs/giksBN2rv5AKhihqysbbvwXrht7xVd0FR+AL03o/dlE6Pyt1ydoqiaBidhfFM17hhM40y8t7I/BmwGBQubM1CgN1sSEPywTYVzmYt5QmsCI4nih6ile1vjKMPkzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CoyvALyBTIVu3aloGZxrlU3qnn1kFTr5uu5F7b+0ZWY=; b=inCXUEu87dbz6BJePeYd/Pxan0efJdnQ/dHx08kOlWsXKpCFqibaadGaNybRT8nl29zjh2OdFTh7dvmvuYp8lzVlW4+akr2Z0B5iUqTr7jIYaJ9GoJ6EK+zzNSlD2ZSh1H/QLCncTS7rsBkx8QVsnguAhYzS7sxPIsw8NE0R8kj4hXz4GZF0byZ94hIK3ernQGB5+ikcAesH7kICEh2aWeQ1CNDYe+5aq3I5JaZAhhB3GixBPphoONuW6tZZDZ19MGQMTxdYU2vromBOXTKk1sIL7ckUk7r7eUpBUoHvdMVq0KznR8sP9XOB3ZsAM6575jXCw9o5sck8+m70D5SQqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CoyvALyBTIVu3aloGZxrlU3qnn1kFTr5uu5F7b+0ZWY=; b=RTK2B4KR3Eml0x1Riq2idho2wqgN8vSlG2WOj41RzCKuPQEaRubtYEffD1ebwpFk2jmZOIC4TEnqhOXvF/c21Mag59oFYYD/aH3VGjMlhr37tJbCckI8huloeg6FAa/rRzdhzlk/dwCoaDKnynDJhwrr0YMaO/v3IXhOUOaGCD8= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4697.namprd11.prod.outlook.com (2603:10b6:303:2c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 12:24:52 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 12:24:51 +0000 From: "Ketan Talaulikar (ketant)" To: "bruno.decraene@orange.com" , "spring@ietf.org" CC: "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Thread-Topic: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths Thread-Index: AdZmaxBja895PvK+QsirQTKFBBYlewLx82dw Date: Fri, 14 Aug 2020 12:24:51 +0000 Message-ID: References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 25c29205-7fc3-4d2d-d6a5-08d8404d0b46 x-ms-traffictypediagnostic: MW3PR11MB4697: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3TjshlrrEMkZmlMENsSh7JMvP8Y88g1CxW9guXzFJpTT9Kjbs9U15m6o7/NjnTJrgw8VErcP1SwH9jUh080EZHO9UH/FFU4CjxTjgqoGwStRGTNdcUMWChOJKLBRRuBcEgCXUbxMtRjHt/DCLxWFGebEbuDfPmiZ6GN/V+hTQWcYDP1AqLdBp72YGTO358Vee/0N45UKEH7XqRL2Q1+oab/1nvOKg7Udx3saXvYPsODnNRFvEBAQfNjzDoAJi65EWbT4d8WAQcr5+5JEpsrEBI7uE/SuSJu9+564oc5PKGW+4893hq9/Gtj/ICFWmdnsOqtWEfN0Iqy9Bm6XXyZYRsg71rl3OtbcrXGnilJb9Rar3TI5i9+XBnkzhq55Br69vDL/Di3ukMr+l5BEKipf7A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(83380400001)(33656002)(64756008)(52536014)(166002)(66946007)(76116006)(66556008)(66476007)(71200400001)(86362001)(110136005)(5660300002)(8676002)(55016002)(26005)(966005)(7696005)(316002)(66446008)(8936002)(478600001)(6506007)(186003)(4326008)(9326002)(53546011)(9686003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Kak/JIO1vXLFiLprQ1SkoH3zE1Kd1amer3+421cdJXWCAQTmOZQzY9BHZHZDFeCc7Xk13LL+oICKXHj6ZVuKUn/Pfcgb36eJij0GItEpFrTw6hOBUVCEcWdVDBUiiw28hMnomOodfp0hwuqW6g8FyX7BCIp+0t8aBQ4iLvANooi+j2iWNzqQCAFIN3YATOfeVZyQBDkG3u/NtB2a272N4mxYoogYbOyMWrMcuXTtbVHRTpDEq6wZyyQC+ZWqOtOIpSsx+YXj1uALJBGAY2oYX77qg7O10x3OykNjnjp1D9HyUHxFbdsKO0dCWFiP+sQnfaNyh/KkSknLxmFrQjqNEuOi4Kn/QwYUEDQpQTxuSO2//S9Uqjt7BwJEeMmc6xEmqvC4Ti42NzYk53Xe3aPiIA7IBBYt/sL/PVi/8IcY2sHPeGp0Kc9ziHzVWm3vnxeivgr5Hmp+VA9tIzioIIyoyCMFOB744jgiqA/USLHSac5oQkkmluluqEBlWozrp6tI9a1QvqDLHrvk3a3n9i76WIOsexfoCwqL5qcu0FlxhcOUIoJnHhaJByTOoelRvXNMd0GH+Eo+DYuRWKujSOu/ATJsdZ1YRCar+Jo9dgo8/vTKSnk/mASVC2tGkLvPngeaDoOOq3cRzxKkHJ+YLaH7JA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB457084F193199C18C0987047C1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25c29205-7fc3-4d2d-d6a5-08d8404d0b46 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 12:24:51.8014 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Rrdnz5l9gZQnihYaYh972r4o8l6dCRPTeSRCFKgIUJT1oull384LbFifv0bBXp9rJgXZvl2vxHHLZYNp0/0AZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4697 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 12:24:58 -0000 --_000_MW3PR11MB457084F193199C18C0987047C1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I believe this topic is relevant and something for the WG to adopt and work= on. I have some concerns though on it's applicability and more specifically it'= s implications on existing deployments/use-cases. I've share the same on th= e thread started by Joel on this specific aspect [1]. Some discussion and c= larity on this would help before adoption. One other bit, for the example in Sec 2.3, perhaps some text is required to= clarify that this applies only for segments signalled via IGPs and if the = 9054 was a BSID or BGP-EPE SID then this approach would not work. May I sug= gest to add a section 2.4 to capture these aspects (it would be some what o= n the lines of Sec 3.4 but not related to the context table solution). The document is well-written and detailed. It does a very good job of descr= ibing the node protection scenarios and options. Thanks, Ketan [1] https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOm= M/ From: spring On Behalf Of bruno.decraene@orange.c= om Sent: 30 July 2020 17:55 To: spring@ietf.org Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org Subject: [spring] WG adoption call for draft-hegde-spring-node-protection-f= or-sr-te-paths Hi SPRING WG, Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have ask= ed for WG adoption. Please indicate your support, comments, or objection, for adopting this dra= ft as a working group item by August 20th 2020. (*) Could those who are willing to work on this document, please notify the lis= t. That gives us an indication of the energy level in the working group to = work on this. Thanks, Regards, Bruno, Jim, Joel [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-t= e-paths-07 (*) 3 weeks to account for the IETF meeting week and the august/summer peri= od. ___________________________________________________________________________= ______________________________________________ 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_MW3PR11MB457084F193199C18C0987047C1400MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I believe this topic is relevant and something for t= he WG to adopt and work on.

 

I have some concerns though on it’s applicabil= ity and more specifically it’s implications on existing deployments/u= se-cases. I’ve share the same on the thread started by Joel on this s= pecific aspect [1]. Some discussion and clarity on this would help before adoption.

 

One other bit, for the example in Sec 2.3, perhaps s= ome text is required to clarify that this applies only for segments signall= ed via IGPs and if the 9054 was a BSID or BGP-EPE SID then this approach wo= uld not work. May I suggest to add a section 2.4 to capture these aspects (it would be some what on the lines= of Sec 3.4 but not related to the context table solution).

 

The document is well-written and detailed. It does a= very good job of describing the node protection scenarios and options.

 

Thanks,

Ketan

 

[1] https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/

 

From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: 30 July 2020 17:55
To: spring@ietf.org
Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org
Subject: [spring] WG adoption call for draft-hegde-spring-node-prote= ction-for-sr-te-paths

 

Hi SPRING WG,=

 

Authors of draft-hegde-spring-n= ode-protection-for-sr-te-paths  [1] have asked for WG adoption.

 

Please indicate your support, c= omments, or objection, for adopting this draft as a working group item by A= ugust 20th 2020. (*)

 

Could those who are willing to = work on this document, please notify the list. That gives us an indication = of the energy level in the working group to work on this.=

 

Thanks,

Regards,

Bruno, Jim, Joel

 

[1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07

(*) 3 weeks to account for the = IETF meeting week and the august/summer period.

 

____________________________________________________=
_____________________________________________________________________<=
/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_MW3PR11MB457084F193199C18C0987047C1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 05:54:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8A3A10A8 for ; Fri, 14 Aug 2020 05:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 q2A01IaPAfjM for ; Fri, 14 Aug 2020 05:54:36 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CD43A1084 for ; Fri, 14 Aug 2020 05:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1597409674; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=g3lnOCkFgkkUOoi+YCQGCfCeMm5iacIeQ1JTJYw/fbk=; b=Svcqn+6ikWtBkDJxRvaD6He3/pMRzf4yMX9d+X0t4mAJ++K4+fGzGjTPHkRxwcofet5uFj tncNJcumw8mBsmsLLJ+MPWcCXZRp+gVm7pkIW6IcW8oxG61mIJwVYCZonmQblkkV0LWpKf U/jvUOo4FZMxAXOD7xWGnXWI0nNlqew= Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-431-GjQGwNK-PEyW43EJjrLVOg-1; Fri, 14 Aug 2020 08:54:32 -0400 X-MC-Unique: GjQGwNK-PEyW43EJjrLVOg-1 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (104.47.1.50) by AZWPVEXEdge02.ecitele.com (10.0.2.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Fri, 14 Aug 2020 15:54:30 +0300 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR03MB4980.eurprd03.prod.outlook.com (2603:10a6:208:106::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 12:54:28 +0000 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1]) by AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1%6]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 12:54:27 +0000 From: Alexander Vainshtein To: "Ketan Talaulikar (ketant)" , "Joel M. Halpern" , Alexander Vainshtein , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JCAAMsLAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAD7UQgAB6ewCAD4ZhAIAAC+KL Date: Fri, 14 Aug 2020 12:54:27 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.183.63.9] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fd1eec42-5c8e-4aaf-e98c-08d840512ddd x-ms-traffictypediagnostic: AM0PR03MB4980: x-microsoft-antispam-prvs: x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:2803; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: g74UeVDlAaIqgjFhOfp5jY+WCJVhH+2dpBnl73bqs7WqPCr+Rz2mGbSDOl5QueV7WQBeAbVr6RaKp/jbfE5vekjKMCBqDAUZWoqU9oGwyAoVXzVwTmA79g85aCIn9ISPUuiXRVLh7pK5pSg256sZdyD7miJUW8rWtQbVNsctWTOop2iBUT3TE5nFbKlrr1z/AcMdggpsSybVI+150Bc7ZHPnJ6fHKVCfbNHD42vEypWn3hRmQ7wkUUYLzEg0hIcm8OqnMmz9S0rxPfe/EAaAPtFmYQRXxU5dZYshSvv16nmsCWy7sTaQPdILX1m9YirNo+mgDaSOuuCw8mBTO2ssau1Ps6XtuHPanONKBNbrh1mYB/G1u8LJG6fLbf7yEZXCaB6RLtb8uDWnhyT07CG9N+JMpZxbvrdpHG5VrDY8ugHTI0/hk3pRkE+SFVXUjaTt4WabDiiESHsFfvZUfyqdHeBl7tTqpcxUyYAxS9qwFzk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4499.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(376002)(366004)(39860400002)(346002)(30864003)(55016002)(53546011)(9686003)(2906002)(4326008)(71200400001)(966005)(8676002)(86362001)(83380400001)(6506007)(5660300002)(26005)(316002)(64756008)(66476007)(66446008)(66556008)(66946007)(478600001)(76116006)(52536014)(110136005)(33656002)(45080400002)(186003)(18265965003)(7696005)(8936002)(166002)(491001)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: zfFAfEyeYX4zKi9Y+hgpAbwKhCRKEokV2DiAadu6MKRqBxBMAwWSdBjApTINPIDST8YThWuMYjHOyEmGyDBn2LJ7Ctq38g383HDkqdrG2qOUhJwVFS91JHew6ya2NaX6Gj28ufLYo8tsmAfLA0eZTj1n/PPhvLY4GSwxOS5kmo6F6WxipGZwAX4OHigsmJPkiqxZTFJv9ZrNvDjiphHwO0SuMr6qm9uf6izaPRGUMqK9LegOYNACCHraBAlhZV8FEfXi6F/Q/1QXC+eHKC2ah0l/33MM0d1vhKnFf+80YU/WQvsPguSmXTchAz12QhG+mb7EP/v+AeLxS0TDoqXIatdfXbcorV6BQdJwKKnpubEl5boFMF3JKVb5Y2zPK+cXo1bY7s4jQCj0KBNWxTt6V0kiE6VQEZZr94IWlxZkljRvdG7slmnBfWpPkbx8Qb0mvKSwf2E3wRz4XXi4g4kYVmHovMOg/by//CUogzQT5HnBGDSJFjNoKzpY7xJPyQwsZs4V/HncBkRcUhJz9URfAgAzCnkMgwgBIlnEkFdEXnBCvTXNbgXsOKn8jWtnVD4V0qvxZjDgyrEb70bC3x9eYFOAn0I4FDPwEvxqZybqlZDl8b17C8SiusQ5wnTVZ8wcQkkgD3QZ6nPQiKUkpn/MEg== MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4499.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fd1eec42-5c8e-4aaf-e98c-08d840512ddd X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 12:54:27.6910 (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-CrossTenant-userprincipalname: 3nmB5fiSrxxs7cUn9lYxNAHpKWN207RWyg2K2IaOOKmV/N9cMJR5KdnfO4YBO1X2Z+Zsb8//HJWdtVSdguUgnQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4980 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA81A106 smtp.mailfrom=alexander.vainshtein@rbbn.com X-Mimecast-Spam-Score: 0.004 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_AM0PR03MB449975114CFA78448BFE54A29D400AM0PR03MB4499eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 12:54:41 -0000 --_000_AM0PR03MB449975114CFA78448BFE54A29D400AM0PR03MB4499eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Regarding the statement "Prefix SID could be just a topological instruction= or may also be used to steer the flow to a node which is applying a servic= e function to it": I think that in SR-MPLS a Node SID that is advertised with PHP aciton can b= e safely considered as "just a topological instruction" by the PLR because = the originating node will not receive it. The same applies to Adj-SDIs. My 2c. Get Outlook for Android ________________________________ From: spring on behalf of Ketan Talaulikar (ketan= t) Sent: Friday, August 14, 2020, 15:00 To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Raszuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi All, I would like to share a different perspective on this. First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1]. This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being provided by t= he SR Policy. Awareness of that notion exists at the SR Policy headend and/= or computation-node. We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of the SLA requ= irement for picking that link. We do not have such a notion for Prefix SIDs= . One can say that we could introduce signalling (e.g. a B flag) to indicat= e whether a Prefix SID can be bypassed or not. This provides the opportunit= y for the computation to use one or the other flavor depending on the natur= e of the SLA for the SR Policy. I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able". As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or not. For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to bypass it. = When this mechanism is used along side SRTE path monitoring mechanisms, it = enables the headend to detect the failure and fallback to an alternate path= using the path protection approach. This is something that is described an= d in use in deployments today [1]. Thanks, Ketan [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9 [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9.3 -----Original Message----- From: spring On Behalf Of Joel M. Halpern Sent: 04 August 2020 20:25 To: Alexander Vainshtein ; Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.co= m ; Robert Raszuk Cc: spring@ietf.org; Joel M. Halpern Subject: Re: [spring] Spring protection - determining applicability There are, as far as I can tell, a number of ways to address this family of= related questions. What struck me, and prompted the starting question, was that none of them w= ere spelled out. I see lots of interesting ideas / proposals. Some of them are compatible with others. Some are not. It would be good if we could reach agreement on how we thought it should be= handled. Thank you, Joel On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > Hi all, > > I am still not sure that the problem of bypass going thru undesirable > links/nodes exists in the case of topological SIDs. > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > ) has been successfully deployed > for many years before SR-MPLS has been introduced. What=E2=80=99s more, > signaling of bypass tunnels he PLR usually did not include any of the > constraints used for computing of any specific LSP that the bypass LSP > would protect =E2=80=93 because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node. > > From my POV the only difference between this behavior and that > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in th= e case of > RSVP-TE, the operator would explicitly indicate, as part of LSP > signaling, whether it would or would not use FRR; LSPs that would not > use FRR would then drop traffic rather than delivering it the wrong way. > > Such an option indeed does not exist in SR-TE today, but would be easy > to provide if so desired IMHO. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:* spring *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM > *To:* EXT-Andrew.Alston@liquidtelecom.com > ; Robert Raszuk > *Cc:* spring@ietf.org; Joel M. Halpern > *Subject:* Re: [spring] Spring protection - determining applicability > > All, > > This is a very interesting discussion and thanks to Joel for starting > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized either by defining a flex-algo > avoiding those > > Nodes and links or by using a stack of unprotected adj-sids that avoid > restricted nodes and links. When a stack of adj-sids is used to > realize the path, the head-end based (sBFD) protection mechanisms can be = applied. > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection > is in use or not. > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* spring > *On Behalf Of *Andrew Alston > *Sent:* Tuesday, August 4, 2020 5:41 AM > *To:* Robert Raszuk > > *Cc:* spring@ietf.org ; Joel M. Halpern > > > *Subject:* Re: [spring] Spring protection - determining applicability > > *[External Email. Be cautious of content]* > > Robert this is actually far more difficult when =E2=80=93 it can be an en= tire > (long) series of nodes that need to be avoided. > > It could potentially be made to work but I=E2=80=99d worry that to do thi= s =E2=80=93 > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labels = =E2=80=93 and that wouldn=E2=80=99t > be viable. > > It=E2=80=99s easier to use algorithms and adjacency sids and other such t= hings > to calculate paths =E2=80=93 the biggest trick is about the stack depth. = When > you have this need for node avoidance =E2=80=93 the need for 10+ label de= pth > is critical =E2=80=93 unless you wanna be applying one hell of a lot of > binding labels along the way which is a nightmare. > > But to answer your question, is this a common use case =E2=80=93 it=E2=80= =99s a use > case that most of the people I discuss this with certain have =E2=80=93 I= cant > comment on a global scale, or for anyone else, but every indication I > have is that yes =E2=80=93 its something people need, and want > > Andrew > > *From:* Robert Raszuk > > *Sent:* Tuesday, 4 August 2020 01:27 > *To:* Andrew Alston > > *Cc:* Joel M. Halpern >; spring@ietf.org > > *Subject:* Re: [spring] Spring protection - determining applicability > > Is this a common use case ie. "but rather =E2=80=93 which nodes / networ= k > segments it can never touch or flow through." > > If so perhaps its time to define notion of *negative-SID* ie. list in > the packet resources which given packet MUST not ever traverse. > > Put in the packet set of nodes or links which the packet should never > traverse. > > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR) > > Best, > R. > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > wrote: > > So =E2=80=93 > > One of the use cases, in fact, some very major use cases in any > spring technology for us revolve around the following > > a.The explicit avoidance of certain nodes > > b.The explicit avoidance of certain sections of the network > > Anything that could result in that explicit avoidance being violated > =E2=80=93 would create, shall we say significant problems. > > Much of the use case is not a case of which nodes the packets flow > through =E2=80=93 but rather =E2=80=93 which nodes / network segments= it can never > touch or flow through. Effectively, to be used as a technology to > avoid certain things for specific reasons. > > This is also one of the reasons for needing such deep label stacks = =E2=80=93 > this kind of detailed path programming tends to deepen the stack > because you sometimes have to be pretty explicit. > > It is absolutely critical to us that this functionality is there =E2= =80=93 > and that we can avoid situations which could cause traffic to > accidently hit things explicitly avoided. > > I wish I could be more specific than this, but it is what it is. > > Thanks > > Andrew > > *From:* spring > *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > > *Cc:* spring@ietf..org > *Subject:* Re: [spring] Spring protection - determining > applicability > > (Since the thread has gotten long enough, reiterating that this is as= a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks tha= t > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clea= r > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve Qo= S. > > Let's be clear. I am not arguing that this is not a good idea. It is = a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two > observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you > better > > apply IP encapsulation to that node. I don't think IP > encapsulation can > > be hijacked today such that destination address of the packet is > ignored. > > > > B) Have you seen any IP network where upon topology change (link > or node > > failure) you suddenly start dropping flows in spite of SPT offerin= g > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > wro= te: > > > > Well less serious for TE SIDs, I am not sure the problem is > restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex t= e > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the pac= ket > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding > service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and > "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological > instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instru= ctions > > > > > > 2.Segments that represent topological instructions can be bypass= ed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, tw= o > > > > > > topological segments are defined: the IGP-Adjacency segment and = the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and th= e > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Sectio= n > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous > sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When = the > > > > > > provider edge routers exchange service labels via BGP or som= e > > other > > > > > > non-IGP mechanism the bottom label is not understood in the = IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 >] > is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between =E2=80=9Ctopolog= ical=E2=80=9D and > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed prob= lematic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs c= ould be prevented > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > > > On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > >; > spring@ietf.org > > > Subject: Re: [spring] Spring protection - determining applicabil= ity > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in th= e > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus > normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicabili= ty > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the variou= s > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, f= or > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new pat= h > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we = are > > > > > > > deliberately vague about what nodes can do when asked suitabl= y.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > >> > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2 > > > > > > > > > > > > > > > F%2Fwww.ietf.org > > > >= %2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= --- > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any revi= ew, > > > disclosure, reliance or distribution by others or forwarding > without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete = all > > > copies, including any attachments. > > > > > > ---------------------------------------------------------------------= --- > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > ---------------------------------------------------------------------- > -- > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ---------------------------------------------------------------------- > -- _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ---------------------------------------------------------------------------= -------------------------------------------- Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipie= nt. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly= prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies,= including any attachments. ---------------------------------------------------------------------------= -------------------------------------------- --_000_AM0PR03MB449975114CFA78448BFE54A29D400AM0PR03MB4499eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
Regarding the statement "Prefix SID could be just a topological instru= ction or may also be used to steer the flow to a node which is applying a s= ervice function to it":


I think that in SR-MPLS a Node SID that is advertised with PHP aciton can b= e safely considered as "just a topological instruction" by the PL= R because the originating node will not receive it.
The same applies to Adj-SDIs.

My 2c.

From: spring <spring-bounces@= ietf.org> on behalf of Ketan Talaulikar (ketant) <ketant=3D40cisco.co= m@dmarc.ietf.org>
Sent: Friday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde;= EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk
Cc: spring@ietf.org
Subject: Re: [spring] Spring protection - determining appl= icability

Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being pro= vided by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= .

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha He= gde <shraddha=3D40juniper.net@dmarc.ietf.org>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <ro= bert@raszuk.net>
Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of= related questions.
What struck me, and prompted the starting question, was that none of them w= ere spelled out.  I see lots of interesting ideas / proposals.
Some of them are compatible with others.   Some are not.
It would be good if we could reach agreement on how we thought it should be= handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirable =
> links/nodes exists in the case of topological SIDs.
>
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
> <https://clicktime.syma= ntec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%= 2Frfc4090>) has been successfully deployed
> for many years before SR-MPLS has been introduced. What=E2=80=99s more= ,
> signaling of bypass tunnels he PLR usually did not include any of the =
> constraints used for computing of any specific LSP that the bypass LSP=
> would protect =E2=80=93 because in the Facility Protection mode the sa= me
> bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>  From my POV the only difference between this behavior and that <= br> > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use FRR; LSPs that would not =
> use FRR would then drop traffic rather than delivering it the wrong wa= y.
>
> Such an option indeed does not exist in SR-TE today, but would be easy=
> to provide if so desired IMHO.
>
> Did I miss something substantial?
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha= Hegde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@rasz= uk.net>
> *Cc:* spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> All,
>
> This is a very interesting discussion and thanks to Joel for starting =
> this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized  either by defining a flex= -algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avoid=
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
> failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org
> <mailto:spring-bounces@i= etf.org>> *On Behalf Of *Andrew Alston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Cc:* spring@ietf.org <mailto:sp= ring@ietf.org>; Joel M. Halpern
> <jmh@joelhalpern.com <mai= lto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> *[External Email. Be cautious of content]*
>
> Robert this is actually far more difficult when =E2=80=93 it can be an= entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93
> you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t
> be viable.
>
> It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things
> to calculate paths =E2=80=93 the biggest trick is about the stack dept= h.  When
> you have this need for node avoidance =E2=80=93 the need for 10+ label= depth
> is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
> case that most of the people I discuss this with certain have =E2=80= =93 I cant
> comment on a global scale, or for anyone else, but every indication I =
> have is that yes =E2=80=93 its something people need, and want
>
> Andrew
>
> *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.A= lston@liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jmh@joelhalpern.com<= /a>>>; spring@ietf.org
> <mailto:spring@ietf.org><= br> > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> Is this a common use case ie.  "but rather =E2=80=93 which n= odes / network
> segments it can never touch or flow through."
>
> If so perhaps its time to define notion of *negative-SID* ie. list in =
> the packet resources which given packet MUST not ever traverse. >
> Put in the packet set of nodes or links which the packet should never =
> traverse.
>
> That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.A= lston@liquidtelecom.com>> wrote:
>
>     So =E2=80=93
>
>     One of the use cases, in fact, some very major= use cases in any
>     spring technology for us revolve around the fo= llowing
>
>     a.The explicit avoidance of certain nodes
>
>     b.The explicit avoidance of certain sections o= f the network
>
>     Anything that could result in that explicit av= oidance being violated
>     =E2=80=93 would create, shall we say significa= nt problems.
>
>     Much of the use case is not a case of which no= des the packets flow
>     through =E2=80=93 but rather =E2=80=93 which n= odes / network segments it can never
>     touch or flow through.  Effectively, to b= e used as a technology to
>     avoid certain things for specific reasons.
>
>     This is also one of the reasons for needing su= ch deep label stacks =E2=80=93
>     this kind of detailed path programming tends t= o deepen the stack
>     because you sometimes have to be pretty explic= it.
>
>     It is absolutely critical to us that this func= tionality is there =E2=80=93
>     and that we can avoid situations which could c= ause traffic to
>     accidently hit things explicitly avoided.
>
>     I wish I could be more specific than this, but= it is what it is.
>
>     Thanks
>
>     Andrew
>
>     *From:* spring <spring-bounces@ietf.org
>     <mailto:spring-bounces@ietf.org>> *On Behalf Of *Joel M. Halpern<= br> >     *Sent:* Monday, 3 August 2020 21:36
>     *To:* Robert Raszuk <robert@raszuk.net <= mailto:robert@raszuk.net>> >     *Cc:* spring@ietf..org <mailto:spring@ietf.org>
>     *Subject:* Re: [spring] Spring protection - de= termining
> applicability
>
>     (Since the thread has gotten long enough, reit= erating that this is as a
>     participant, not a WG chair.)
>
>     Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
>     choose to drop packets. For all sorts of reaso= ns.
>     I think there are likely other reasons why one= may not want a random
>     path rather than a chosen TE path. I think it = is important we be clear
>     about what constraints may be / are violated w= hen we tell people they
>     have this tool (protective rerouting) that is = intended to preserve QoS.
>
>     Let's be clear. I am not arguing that this is = not a good idea. It is a
>     good idea. And useful. I am trying to figure o= tu what combination of
>     additional mechanisms and clear descriptions w= ill lead to everyone
>     getting the behavior they expect (which may no= t be the behavior they
>     desire, but sometimes is the best we can do.)<= br> >
>     Yours,
>     Joel
>
>     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>      > Joel,
>      >
>      > Are we still talking about IP netwo= rks here ? Or perhaps some hard
>      > slicing with real resource reservat= ions or detnets ?
>      >
>      > Because if we are talking = ;about IP networking I have two
>     observations:
>      >
>      > A) If you need to traverse via a sp= ecific node (ie. firewall) you
>     better
>      > apply IP encapsulation to that node= . I don't think IP
>     encapsulation can
>      > be hijacked today such that destina= tion address of the packet is
>     ignored.
>      >
>      > B) Have you seen any IP network whe= re upon topology change (link
>     or node
>      > failure) you suddenly start dr= opping flows in spite of SPT offering
>      > perhaps few ms longer path with 10 = ms more jitter ?
>      >
>      > Or are some SR marketing slides pro= mise to turn IP networks in
>      > something new ? Worse ... do t= hey mention path quality guarantees,
>      > resource reservations ? I hope= not.
>      >
>      > Thx,
>      > R.
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:
>      >
>      > Well less serious for TE SIDs, I am= not sure the problem is
>     restricted
>      > to just service SIDs.
>      >
>      > Suppose that the PCE has specified = the path to meet some complex te
>      > objective.  The bypass node ha= s no way of knowing what those
>      > constraints
>      > were.  And for some kinds of t= raffic, it is better to drop the packet
>      > than to deliver it outside the enve= lop.  I suspect that the right
>      > answer
>      > to this is "too bad".&nbs= p; If so, as with the distinction regarding
>     service
>      > nodes, we should say so, shouldn't = we?
>      >
>      > Yours,
>      > Joel
>      >
>      > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
>      > > Mach, Joel and all,
>      > >
>      > > I think that in most cases: >      > >
>      > > 1.There is clear differentiati= on between "topological" and
>     "service"
>      > > instructions in SID advertisem= ents. E.g.:
>      > >
>      > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
>      > > corresponding IGP advertisemen= ts) represent topological
>     instructions
>      > >
>      > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
>      > >
>      >
>     <https://clicktime.symante= c.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fd= oc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
>     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?= u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2= Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yu= sx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>>=
>      >
>      > > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions
>      > >
>      > > 2.Segments that represent topo= logical instructions can be bypassed,
>      > > while segments that represent = service instructions require
>      > alternative
>      > > protection mechanisms.
>      > >
>      > > This view seems to be aligned = with RFC 8402
>      > > <https://c= licktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ie= tf.org%2Fhtml%2Frfc8402
>     <https://clicktime.sy= mantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>>= ;
>     that says in Section 1:
>      > >
>      > >     In the cont= ext of an IGP-based distributed control plane, two
>      > >
>      > > topological segments are defin= ed: the IGP-Adjacency segment and the
>      > >
>      > >     IGP-Prefix = segment.
>      > >
>      > >     In the cont= ext of a BGP-based distributed control plane, two
>      > >
>      > > topological segments are defin= ed: the BGP peering segment and the
>      > >
>      > >     BGP-Prefix = segment.
>      > >
>      > > In the case of SR-MPLS this di= fferentiation is assumed in Section
>      > 3.4 of
>      > > the Node Protection for SR-TE = Path
>      > >
>      >
>     <https://clicktime.symante= c.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fd= oc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section= -3.4
>     <https://clicktime.sym= antec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%= 2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-= protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yus= x9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>><= br> >      >
>      > > draft that says:
>      > >
>      > >     The node pr= otection mechanism described in the previous
>     sections
>      > >
>      > >     depends on = the assumption that the label immediately below
>      > the top
>      > >
>      > > label in the label stack is un= derstood in the IGP domain.  When the
>      > >
>      > >     provider ed= ge routers exchange service labels via BGP or some
>      > other
>      > >
>      > >     non-IGP mec= hanism the bottom label is not understood in the IGP
>      > >
>      > >     domain.
>      > >
>      > >     The egress = node protection mechanisms described in the draft
>      > >
>      > >     [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H= 2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
>     <https://= clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F%2Furldefe= nse.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3= B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDu= iDo8MGipXc%24>>]
>     is
>      > > applicable to this use case an= d no additional changes
>      > >
>      > >     will be req= uired for SR based networks
>      > >
>      > > The scenarios in which  d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and
>      > > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,
>      > consider
>      > > the use case in which a Node S= ID in the ERO of a SR-TE path
>      > identifies a
>      > > node that acts as a firewall f= or all packets it receives, i.e.,
>      > provides
>      > > the firewall service without a= ny dedicated service SID
>      > identifying it.
>      > > One could say that the Node SI= D of such a node would combine
>      > topological
>      > > and service instructions thus = breaking the differentiation
>      > between the two.
>      > >
>      > > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
>      > or at
>      > > least discouraged.
>      > >
>      > > If not, providing an ability t= o identify such SIDs in the
>      > advertisement
>      > > mechanisms would be useful IMH= O.
>      > >
>      > > My 2c,
>      > >
>      > > Sasha
>      > >
>      > > Office: +972-39266302
>      > >
>      > > Cell:    &= nbsp; +972-549266302
>      > >
>      > > Email: Alexander.Vainshtein@ec= itele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>
>      > <mailto:Alexander.Vainshtein@ecitele.com>
>      > >
>      > > -----Original Message-----
>      > > From: spring <spring-bounce= s@ietf.org
>     <mailto:spring-bounces@ietf.org%0b>>
>     <mailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
>      > > Sent: Monday, August 3, 2020 6= :30 AM
>      > > To: Joel M. Halpern <jmh@jo= elhalpern.com
>     <= mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.com>>;
>     spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>      > > Subject: Re: [spring] Spring p= rotection - determining applicability
>      > >
>      > > Hi Joel,
>      > >
>      > > I think this is a good point t= hat may not be discussed in the
>      > past. And
>      > > I also don't think there is a = "can be bypassed" indication in the
>      > > routing advertisement for now.=
>      > >
>      > > IMHO, the information advertis= ed by routing is neutral, such
>      > information
>      > > (can or cannot be bypassed) is= more path specific, thus
>     normally the
>      > > controller should be responsib= le for deciding whether/which SID
>      > can be
>      > > bypassed.
>      > >
>      > > Best regards,
>      > >
>      > > Mach
>      > >
>      > >  > -----Original Messa= ge-----
>      > >
>      > >  > From: spring [mailto:spring-bounces@ietf.org
>      > <mailto:spring-bounces@ietf.org>
>     <mailto:spring-bounces@ietf.or= g%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>]
>     On Behalf Of Joel M.
>      > >
>      > >  > Halpern
>      > >
>      > >  > Sent: Monday, Augus= t 3, 2020 7:51 AM
>      > >
>      > >  > To: spring@ietf.org= <mailto:spring@ietf.org>
>     <mailto:= spring@ietf.org>
>      > <mailto:spring@= ietf.org <mailto:spring@ietf.org
>     <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org= >>>
>      > >
>      > >  > Subject: [spring] S= pring protection - determining applicability
>      > >
>      > >  >
>      > >
>      > >  > (WG Chair hat Off, = this is merely a note from a slightly
>      > confused WG
>      > >
>      > >  > participant.)
>      > >
>      > >  >
>      > >
>      > >  > I have been reading= the various repair drafts, and the various
>      > >
>      > >  > networks programmin= g and service programming draft, and I am
>      > trying to
>      > >
>      > >  > figure out one aspe= ct of the combination.
>      > >
>      > >  >
>      > >
>      > >  > How does a node tha= t is doing some form of bypass (suppose, for
>      > >
>      > >  > simplicity, it is N= ode N2 deciding to bypass the next SID for
>      > a failed
>      > >
>      > >  > node N3) know that = it is safe to do so?
>      > >
>      > >  >
>      > >
>      > >  > If the path was jus= t for TE, then it is "safe" if the new path
>      > meets
>      > >
>      > >  > the TE criteria.&nb= sp; or maybe it is safe if it is even close, as
>      > long as
>      > >
>      > >  > it is not used for = too long.
>      > >
>      > >  >
>      > >
>      > >  > But what if the nod= e were a Firewall, included to meet legal
>      > > requirements?
>      > >
>      > >  > Or was some other n= ecessary programmatic transform (wince we are
>      > >
>      > >  > deliberately vague = about what nodes can do when asked suitably.)
>      > >
>      > >  >
>      > >
>      > >  > Is there some "= ;can be bypassed" indication in the routing
>      > >
>      > >  > advertisements that= I missed?
>      > >
>      > >  >
>      > >
>      > >  > Thank you,
>      > >
>      > >  > Yours,
>      > >
>      > >  > Joel
>      > >
>      > >  >
>      > >
>      > >  > ___________________= ____________________________
>      > >
>      > >  > spring mailing list=
>      > >
>      > >  > spring@ietf.org <= ;mailto:spring@ietf.org>
>     <mailto:= spring@ietf.org>
>      > <mailto:spring@= ietf.org <mailto:spring@ietf.org
>     <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org= >>>
>      > >
>      > >  >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
>     <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuX= y2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.syman= tec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6= yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%= 24>
>      > >
>      >
>     <https://clicktime.symante= c.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
>     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Sup= jwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.syman= tec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NE= t6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAH= k%24>>
>      > >
>      > >  > F%2Fwww.ietf.org >     <https://clicktime.symantec.com/39NznmY= BtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fw= ww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp= 6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>      > <https://clickt= ime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%2F2Fwww.ietf.org=
>     <https://clicktime.symantec.com/39NznmY= BtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fw= ww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp= 6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
>      > >
>      > > ______________________________= _________________
>      > >
>      > > spring mailing list
>      > >
>      > > spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:= spring@ietf.org> <mailto:spring@ietf.org
>     <mail= to:spring@ietf.org%0b>> <ma= ilto:spring@ietf.org>>
>      > >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps= %3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU= 4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2= Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQ= xgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>      > >
>      > >
>      > >
>      > >
>      >
>     ----------------------------------------------= --------------------------
>      > > Notice: This e-mail together w= ith any attachments may contain
>      > > information of Ribbon Communic= ations Inc. that is confidential
>      > and/or
>      > > proprietary for the sole use o= f the intended recipient. Any review,
>      > > disclosure, reliance or distri= bution by others or forwarding
>     without
>      > > express permission is strictly= prohibited. If you are not the
>      > intended
>      > > recipient, please notify the s= ender immediately and then delete all
>      > > copies, including any attachme= nts.
>      > >
>      >
>     ----------------------------------------------= --------------------------
>      > >
>      > > ______________________________= _________________
>      > > spring mailing list
>      > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://c= licktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Furldefen= se.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o5KlPnbj%24>
>      > >
>      >
>      > ___________________________________= ____________
>      > spring mailing list
>      > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://c= licktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Furldefen= se.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o5KlPnbj%24>
>      >
>
>     ______________________________________________= _
>     spring mailing list
>     spring@ietf.org <mailto:spring@ietf.org>
>     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>    
> <https://clicktime.symantec.com/3NrDnSTReXh671G79B= VGEq16H2?u=3Dhttps%3A%
> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti=
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> ----------------------------------------------------------------------=
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or =
> proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
> recipient, please notify the sender immediately and then delete all > copies, including any attachments.
> ----------------------------------------------------------------------=
> --

_______________________________________________
spring mailing list
spring@ietf.org
https://clicktime.s= ymantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
spring@ietf.org
https://clicktime.s= ymantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Fspring



Notice: Th= is e-mail together with any attachments may contain information of Ribbon C= ommunications Inc. that is confidential and/or proprietary for the sole use= of the intended recipient. Any review, disclosure, reliance or distributi= on by others or forwarding without express permission is strictly prohibite= d. If you are not the intended recipient, please notify the sender immedia= tely and then delete all copies, including any attachments.
 --_000_AM0PR03MB449975114CFA78448BFE54A29D400AM0PR03MB4499eurp_-- From nobody Fri Aug 14 06:23:52 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B053A111C for ; Fri, 14 Aug 2020 06:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BTeLCI+U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uP//OdT4 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 t3T5aTzt03LH for ; Fri, 14 Aug 2020 06:23:45 -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 6B5E93A110D for ; Fri, 14 Aug 2020 06:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=127310; q=dns/txt; s=iport; t=1597411414; x=1598621014; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rMRr4rlfUAO0v+TSTKxMhUe7w/UFmxUs3rHA8p41YhQ=; b=BTeLCI+UADBP9hW/o8JuRKff4oXbubLDiDVlBCkHMUrWj8Kd4QUVatWE PlRoAoG9u5d4Z5xgjLeXcSwEjeJI0ei0e7ED/0FPzf8NP84YIaSGMcj6Q i63ugzzC5tuSAMEUW84geEOOT5xX4+ICLIY6H6sh7LpAbc27p/13JAuOV s=; IronPort-PHdr: =?us-ascii?q?9a23=3A7gLm+BFxewjnsimn/llyqJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QWbR4/R7bRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGAsz0YRvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzCAChjzZf/4YNJK1VCh0BAQEBCQE?= =?us-ascii?q?SAQUFAYIKgSMvKSgHcFgvLAqELYNGA41agQKXZYFCgREDUAIDCwEBAQwBARg?= =?us-ascii?q?BCQcEAgQBAYQIRAIXgi8CJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAQI?= =?us-ascii?q?BAQEQCAEIChMBASwBCgELAgICAQgRBAEBASABBgMCAgIUEQsUCQgCBAENBQg?= =?us-ascii?q?agwAFgX5NAw4gAQ6nSwKBOYhhdoEygwEBAQWBMwEDAg4DDy+DIhiCDgkFgTO?= =?us-ascii?q?CcYNghCqBAYEeGoFBPyZpAQFDgU8uGzU+glwBAQIBARWBEQEHCwEjBQcJCAc?= =?us-ascii?q?BBQEJAgaCWTOCLY9FBxIHAwYqgmuGYYMfiD2QcgqCYohjhXxQhQiGCYJ/Nm2?= =?us-ascii?q?IOJNFhVaLCYFZg2qGWIU5ixWELAIEAgQFAg4BAQWBaiMNWnBwFTuCaQkWMRc?= =?us-ascii?q?CDYhahUUMF4ECAQKCSYQ+VoUJATh0AgEBARUBHAIGAQkBAQMJfI8xATRcAQE?= X-IronPort-AV: E=Sophos;i="5.76,312,1592870400"; d="scan'208,217";a="541995600" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 13:23:30 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EDNUKU000652 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 13:23:30 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 08:23:29 -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.1497.2; Fri, 14 Aug 2020 08:23:29 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 08:23:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NYpVQep6xcYJjeOOkjm/RXag1G8/cbZH2omeCt8WbRA/KjdHW5XgAvdSABcIjL+hVA36dGbiXjNTgZZR5GlwYAn1O6bMyVpBekInYPlzTCtkOGCyLYM2xe7yEg3ZRVazXaWScRO46T/ifXwQ+r/rubAJLhbs/Pf/5uEEWDTMpNaH4oTvZ8d316ROiH5fNR+kLIshjynkIyC8CcTwN3A011ccQ0sarNnEKWoa4ayzDPBx5d1jwpJN+ufJtu3wf15ZPn829c6Kom6wBvhXvWOE/EsOjZ74YCH/fhBTLa7Y2LiQJx7r5qcNksXm907+LTBfdfpWyJ764n7yfubiLR2Ffw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rMRr4rlfUAO0v+TSTKxMhUe7w/UFmxUs3rHA8p41YhQ=; b=fs0K9E9vw/guYG0WxQQ94fGUsMEOAvEMukvZZ7J3eQB28OjT+8Vl4jDyanx2l/r4/Kac1uxx9EwlFLbskd7uSgjcLwuDjRkEHhOLIUlZSenLWo19CLdtrgGv6MMUhHdWRNjP88WfqPZz/V1pVoAiwaocP0JPMvadseMRAC6LeUNXDoVzWC+EwOeARsnlG2V9zoDMZ+eA8oeGidsrkf4T5XdAhu6vD29JT40+7evNE/LbvIGyLZ2gObK5mn3Mzgid0US3X/e+3At9AP/rcnrwVEHXjGgQft15qVZgPRr343caKq7o4OM1IuXwuEagWErEKJjsUk961NTAgSviCHyKeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rMRr4rlfUAO0v+TSTKxMhUe7w/UFmxUs3rHA8p41YhQ=; b=uP//OdT4RG97WOJOT4vNMZPxqSLfb3xc6E4tzGAtYRJw4jjlOC6aXmzRXdhsIdvwMFVcnId7r+jxJBunNSi4o1JypQN1ORko5lt8rSPBRO/lRYhqrkRtswN4ufpWwS2ESCzL24kJaco3kh4gJa250XYEiXqLWRSH7YTvIPHsN/s= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB0077.namprd11.prod.outlook.com (2603:10b6:301:61::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 13:23:27 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 13:23:26 +0000 From: "Ketan Talaulikar (ketant)" To: Alexander Vainshtein , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfGJGLEw80LFEa7R79kiStyh6klun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAFLgAgAB1eACAD4BY8IAAFTmAgAAGD1A= Date: Fri, 14 Aug 2020 13:23:26 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rbbn.com; dkim=none (message not signed) header.d=none;rbbn.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f2dfe7a-a3d8-43b0-2a73-08d840553a70 x-ms-traffictypediagnostic: MWHPR11MB0077: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bYa8R2ETPwL2q7+bJk2aRY+yGrkh1ABmymVp6lpxnAtrg9h3CS4Dm7cdIcRVT23TTt5HYJph4OPSpXE49aFDYYP/CjLTF8qz+5Np4wAMfD/OvTsL6FHg2fZt7N+zpylG6Jz7ToZKl+YLb7XZ9S/Bvm96/lnHMkw4meTpJ1ueniif7jPlhxG94Za/45L5KKpW0UCJfMc9JpB753957vH2I6x1GQSgAveUdxE1SPSsmyExKeIKQruOIRM58PNpTydE0Jy6nFT+aAX0AUo2HY//hkhYzo7l0c333dxKXkRHOuuWES95q7ULODIJ7e7cLb3LEc6y3Ws2BDHlMIPMDg+vet9wH3l6S0CZ6tXlg2zAsPJpFAS5aLtUfMYoQxK1MZRu8l8MqB/fsonVa7p/CEJMqEyjF4JQ/WzOjLxRheBoCpDfxBZEaSvx6+Dc1C6T6r3D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(5660300002)(966005)(478600001)(33656002)(83380400001)(55016002)(9686003)(4326008)(86362001)(6506007)(52536014)(186003)(45080400002)(2906002)(316002)(64756008)(66556008)(30864003)(66446008)(7696005)(166002)(8936002)(53546011)(66946007)(76116006)(66476007)(9326002)(110136005)(8676002)(71200400001)(26005)(491001)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: zZSsiTpe72c9LbQ7nAqseqAozOTKyxQ6jx80iYgmodEnu02XvC9uc0i17JkIo+wYkxkJwU3YxUA/qt/fHpi/jZQpcpcXQKpatN0pjTLvwf8UffBDNJrUT4ydanWht+OuKBNwsuJHpBOCJQhTgbvE4yDtIVDVX+pfMontvO2IaYH7fkyrulQQVO6jfEJ+sZksXkiHax63UH6I4lSlBbZcLF7SL1nFbNp1knxXJRunOm8LtKvGb1aLjwvT7zcCPk/N1iqYMfkxnqXqD4iv5xhI49M7WO/Gd/RWgTF32XJpmaU2YdpPKtTNiIY0UPLC1kVcUueUqiNOWeXTXOqIHmsAh5R/dfaXMoCDKgHfGKKrKK0LuwFwpmZHUts4caE0NWWy3tLryPqy5eSOWgY0p8EIh01FcdOo4sMiyGOhaF3JNaUWdYjf4YBSM50qMfeXZy8h+76lXKO/mMfhIgTzqLjzv90grEmESiop10QAfRnfhoKJCdNfWOiIiZpYGwpwzFtxOdyhae4cPM1be89/sC1UUw6KLm0+PJC35/Hegh/wE2lRDd9fIZZsUW4Y2USePYXufHLm70IuyHy7i2BbRnYJFNltUfCLr5zw/B5GF2Sj9f63ItONArMsrCFMRqvNWzUj5mLl9/yJdCAApGLtxC2bCQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570615B3050B500C456C99EC1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f2dfe7a-a3d8-43b0-2a73-08d840553a70 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 13:23:26.8433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 91lsLyPlk25AC7v3dyqAVzfiF+eu9XE7UKklXQMRkEV5olmzc5XLzJNYHr3aRLSepMDnMm5eiBm0WKBzs5o4eA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0077 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 13:23:50 -0000 --_000_MW3PR11MB4570615B3050B500C456C99EC1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FzaGEsDQoNCklmIHRoZSBzZXJ2aWNlIGRvZXMgbm90IG5lZWQgYW55IGFkZGl0aW9uYWwg Y29udGV4dCAoZS5nLiBhIGZpcmV3YWxsIHRoYXQganVzdCBhcHBsaWVzIGxvY2FsbHkgY29uZmln dXJlZCBkZWZhdWx0IHJ1bGVzIG9uIGl0KSwgdGhlbiBJIGRvbuKAmXQgc2VlIHdoeSBQSFAgY291 bGQgbm90IGJlIGRvbmUgZm9yIGEgUHJlZml4IFNJRCBhc3NvY2lhdGVkIHdpdGggYSBzZXJ2aWNl IG5vZGUuDQoNCkFsc28sIEkgZGlkbuKAmXQgZm9sbG93IHRoZSBwb2ludCB0aGF0IHlvdSB3ZXJl IHRyeWluZyB0byBtYWtlIGFib3V0IEFkai1TSURzLg0KDQpUaGFua3MsDQpLZXRhbg0KDQpGcm9t OiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+DQpT ZW50OiAxNCBBdWd1c3QgMjAyMCAxODoyNA0KVG86IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkg PGtldGFudEBjaXNjby5jb20+OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+ OyBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+OyBT aHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFAanVuaXBlci5uZXQ+OyBFWFQtQW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbSA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IFJvYmVy dCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJp bGl0eQ0KDQpIaSBhbGwsDQpSZWdhcmRpbmcgdGhlIHN0YXRlbWVudCAiUHJlZml4IFNJRCBjb3Vs ZCBiZSBqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0 byBzdGVlciB0aGUgZmxvdyB0byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1 bmN0aW9uIHRvIGl0IjoNCg0KDQpJIHRoaW5rIHRoYXQgaW4gU1ItTVBMUyBhIE5vZGUgU0lEIHRo YXQgaXMgYWR2ZXJ0aXNlZCB3aXRoIFBIUCBhY2l0b24gY2FuIGJlIHNhZmVseSBjb25zaWRlcmVk IGFzICJqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24iIGJ5IHRoZSBQTFIgYmVjYXVzZSB0 aGUgb3JpZ2luYXRpbmcgbm9kZSB3aWxsIG5vdCByZWNlaXZlIGl0Lg0KVGhlIHNhbWUgYXBwbGll cyB0byBBZGotU0RJcy4NCg0KTXkgMmMuDQoNCkdldCBPdXRsb29rIGZvciBBbmRyb2lkPGh0dHBz Oi8vYWthLm1zL2doZWkzNj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFu dD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86a2V0YW50PTQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPj4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNTowMA0KVG86 IEpvZWwgTS4gSGFscGVybjsgQWxleGFuZGVyIFZhaW5zaHRlaW47IFNocmFkZGhhIEhlZ2RlOyBF WFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20+OyBSb2JlcnQgUmFzenVrDQpDYzogc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCg0KSGkgQWxsLA0KDQpJIHdv dWxkIGxpa2UgdG8gc2hhcmUgYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUgb24gdGhpcy4NCg0KRmly c3QsIHRoYW5rcyB0byBKb2VsIGZvciBicmluZ2luZyB1cCB0aGUgZGlzY3Vzc2lvbi4gQ2xlYXJs eSB3ZSBuZWVkIGEgd2VsbC1kZWZpbmVkIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGZvciBkZXRl cm1pbmluZyBhcHBsaWNhYmlsaXR5IG9mIHByb3RlY3Rpb24gZm9yIHNlZ21lbnQgdXNlZCBpbiBh biBTUiBQb2xpY3kuIFNvbWUgb2YgdGhpcyBpcyBjYXB0dXJlZCBpbiBbMV0uDQoNClRoaXMgaXMg YWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkgbmF0dXJlLCB0aGUgUExS IGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICJzdHJpY3Qgb3Igbm90IiBpcyB0aGUgU0xB IHRoYXQgaXMgYmVpbmcgcHJvdmlkZWQgYnkgdGhlIFNSIFBvbGljeS4gQXdhcmVuZXNzIG9mIHRo YXQgbm90aW9uIGV4aXN0cyBhdCB0aGUgU1IgUG9saWN5IGhlYWRlbmQgYW5kL29yIGNvbXB1dGF0 aW9uLW5vZGUuDQoNCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0ZWQgdmFyaWFudHMg b2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0byBwaWNrIG9yIHRo ZSBvdGhlciBiYXNlZCBvbiB0aGUgInN0cmljdG5lc3MiIG9mIHRoZSBTTEEgcmVxdWlyZW1lbnQg Zm9yIHBpY2tpbmcgdGhhdCBsaW5rLiBXZSBkbyBub3QgaGF2ZSBzdWNoIGEgbm90aW9uIGZvciBQ cmVmaXggU0lEcy4gT25lIGNhbiBzYXkgdGhhdCB3ZSBjb3VsZCBpbnRyb2R1Y2Ugc2lnbmFsbGlu ZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFByZWZpeCBTSUQgY2FuIGJl IGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHRoZSBj b21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3IgZGVwZW5kaW5nIG9uIHRo ZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS4NCg0KSSBoYXZlIGEgcHJvYmxl bSBhbmQgYSBjb25jZXJuIGluIHRoZSBhc3N1bXB0aW9uIHRoYXQgUExScyBjYW4gYXNzdW1lIHRo YXQgdGhlIGN1cnJlbnRseSBkZWZpbmVkIHZhcmlhbnQgb2YgUHJlZml4IFNJRHMgaW4gUkZDODQw MiAoYW5kIElHUCBzcGVjcykgYXJlICJieXBhc3MtYWJsZSIuDQoNCkFzIEpvZWwgYW5kIG90aGVy cyBoYXZlIGJyb3VnaHQgb3V0LCB0aGUgUHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0IGEgdG9wb2xv Z2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0aGUgZmxvdyB0 byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGl0LiBJbiBv cmRlciB0byBzdXBwb3J0IGEgbWl4IG9mIFNSIFBvbGljaWVzIG9mIGRpZmZlcmVudCBTTEFzIChz dHJpY3QgYW5kIG5vdC1zdHJpY3QpLCB3ZSBuZWVkIHRvIGVuYWJsZSB0aGUgY2hvaWNlIG9mIFNJ RHMgdGhhdCBpbmRpY2F0ZXMgdG8gdGhlIFBMUiB3aGV0aGVyIHRoZXkgYXJlICJieXBhc3MtYWJs ZSIgb3Igbm90Lg0KDQpGb3IgdGhlIGNhc2VzLCB3aGVyZSB0aGUgU1IgUG9saWN5IGhhcyBhIHNw ZWNpZmljIFNMQSwgaXQgaXMgcmVxdWlyZWQgZm9yIG5vZGVzIHRvIGRyb3AgdGhlIHBhY2tldHMg bWVhbnQgZm9yIHRoZSAiYWN0aXZlIHNlZ21lbnQiIHRoYW4gdG8gYnlwYXNzIGl0LiBXaGVuIHRo aXMgbWVjaGFuaXNtIGlzIHVzZWQgYWxvbmcgc2lkZSBTUlRFIHBhdGggbW9uaXRvcmluZyBtZWNo YW5pc21zLCBpdCBlbmFibGVzIHRoZSBoZWFkZW5kIHRvIGRldGVjdCB0aGUgZmFpbHVyZSBhbmQg ZmFsbGJhY2sgdG8gYW4gYWx0ZXJuYXRlIHBhdGggdXNpbmcgdGhlIHBhdGggcHJvdGVjdGlvbiBh cHByb2FjaC4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyBkZXNjcmliZWQgYW5kIGluIHVzZSBp biBkZXBsb3ltZW50cyB0b2RheSBbMV0uLg0KDQpUaGFua3MsDQpLZXRhbg0KDQpbMV0gaHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1zNkgyP3U9aHR0 cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05DQpbMl0gaHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzM2ZkNNcmdtRWV3QzRhNEFKUnJtbjdINkgyP3U9aHR0cHMlM0ElMkYlMkZ0 b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5LTA4JTIzc2VjdGlvbi05LjMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogMDQgQXVndXN0 IDIwMjAgMjA6MjUNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRl aW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPj47IFNocmFk ZGhhIEhlZ2RlIDxzaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzpz aHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPj47IEVYVC1BbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8 bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNClRoZXJlIGFyZSwgYXMgZmFy IGFzIEkgY2FuIHRlbGwsIGEgbnVtYmVyIG9mIHdheXMgdG8gYWRkcmVzcyB0aGlzIGZhbWlseSBv ZiByZWxhdGVkIHF1ZXN0aW9ucy4NCldoYXQgc3RydWNrIG1lLCBhbmQgcHJvbXB0ZWQgdGhlIHN0 YXJ0aW5nIHF1ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2VyZSBzcGVsbGVkIG91dC4g IEkgc2VlIGxvdHMgb2YgaW50ZXJlc3RpbmcgaWRlYXMgLyBwcm9wb3NhbHMuDQpTb21lIG9mIHRo ZW0gYXJlIGNvbXBhdGlibGUgd2l0aCBvdGhlcnMuICAgU29tZSBhcmUgbm90Lg0KSXQgd291bGQg YmUgZ29vZCBpZiB3ZSBjb3VsZCByZWFjaCBhZ3JlZW1lbnQgb24gaG93IHdlIHRob3VnaHQgaXQg c2hvdWxkIGJlIGhhbmRsZWQuDQoNClRoYW5rIHlvdSwNCkpvZWwNCg0KT24gOC80LzIwMjAgMzo1 NCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+IEhpIGFsbCwNCj4NCj4gSSBhbSBz dGlsbCBub3Qgc3VyZSB0aGF0IHRoZSBwcm9ibGVtIG9mIGJ5cGFzcyBnb2luZyB0aHJ1IHVuZGVz aXJhYmxlDQo+IGxpbmtzL25vZGVzIGV4aXN0cyBpbiB0aGUgY2FzZSBvZiB0b3BvbG9naWNhbCBT SURzLg0KPg0KPiBBRkFJSywgRmFjaWxpdHkgUHJvdGVjdGlvbiBpbiBSU1ZQLVRFIEZSUiAoUkZD IDQwOTANCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTkya25FOVhKdWpyZjhC azdvSnZzNkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM0MDkw PikgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IGRlcGxveWVkDQo+IGZvciBtYW55IHllYXJzIGJlZm9y ZSBTUi1NUExTIGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTigJlzIG1vcmUsDQo+IHNpZ25hbGlu ZyBvZiBieXBhc3MgdHVubmVscyBoZSBQTFIgdXN1YWxseSBkaWQgbm90IGluY2x1ZGUgYW55IG9m IHRoZQ0KPiBjb25zdHJhaW50cyB1c2VkIGZvciBjb21wdXRpbmcgb2YgYW55IHNwZWNpZmljIExT UCB0aGF0IHRoZSBieXBhc3MgTFNQDQo+IHdvdWxkIHByb3RlY3Qg4oCTIGJlY2F1c2UgaW4gdGhl IEZhY2lsaXR5IFByb3RlY3Rpb24gbW9kZSB0aGUgc2FtZQ0KPiBieXBhc3MgTFNQIHdvdWxkIGJl IHVzZWQgdG8gcHJvdGVjdCBtdWx0aXBsZSBMU1BzIHBhc3NpbmcgdGhydSB0aGUNCj4gZmFpbGVk IGxpbmsvbm9kZS4NCj4NCj4gIEZyb20gbXkgUE9WIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2Vl biB0aGlzIGJlaGF2aW9yIGFuZCB0aGF0DQo+IGludHJvZHVjZWQgYnkgdGhlIOKAnGJ5cGFzc2lu Z+KAnSBkcmFmdHMgaW4gU1IgaXMgdGhhdCwgaW4gdGhlIGNhc2Ugb2YNCj4gUlNWUC1URSwgdGhl IG9wZXJhdG9yIHdvdWxkIGV4cGxpY2l0bHkgaW5kaWNhdGUsIGFzIHBhcnQgb2YgTFNQDQo+IHNp Z25hbGluZywgd2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBub3QgdXNlIEZSUjsgTFNQcyB0aGF0 IHdvdWxkIG5vdA0KPiB1c2UgRlJSIHdvdWxkIHRoZW4gZHJvcCB0cmFmZmljIHJhdGhlciB0aGFu IGRlbGl2ZXJpbmcgaXQgdGhlIHdyb25nIHdheS4NCj4NCj4gU3VjaCBhbiBvcHRpb24gaW5kZWVk IGRvZXMgbm90IGV4aXN0IGluIFNSLVRFIHRvZGF5LCBidXQgd291bGQgYmUgZWFzeQ0KPiB0byBw cm92aWRlIGlmIHNvIGRlc2lyZWQgSU1ITy4NCj4NCj4gRGlkIEkgbWlzcyBzb21ldGhpbmcgc3Vi c3RhbnRpYWw/DQo+DQo+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0K Pg0KPiBTYXNoYQ0KPg0KPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4NCj4gQ2VsbDogICAgICAr OTcyLTU0OTI2NjMwMg0KPg0KPiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+DQo+ICpGcm9t Oiogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpTaHJhZGRoYSBIZWdkZQ0KPiAqU2VudDoqIFR1ZXNk YXksIEF1Z3VzdCA0LCAyMDIwIDk6NDEgQU0NCj4gKlRvOiogRVhULUFuZHJldy5BbHN0b25AbGlx dWlkdGVsZWNvbS5jb208bWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29t Pg0KPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86QW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbT4+OyBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqQ2M6KiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPg0KPiBBbGwsDQo+ DQo+IFRoaXMgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIHRoYW5rcyB0byBK b2VsIGZvciBzdGFydGluZw0KPiB0aGlzIGRpc2N1c3Npb24uIElNTywgd2hlbiB0aGVyZSBhcmUg c3RyaWN0IHJlcXVpcmVtZW50cyBvZiBhdm9pZGluZw0KPiBjZXJ0YWluIG5vZGVzL2xpbmtzIGl0 IGNhbiBiZSByZWFsaXplZCAgZWl0aGVyIGJ5IGRlZmluaW5nIGEgZmxleC1hbGdvDQo+IGF2b2lk aW5nIHRob3NlDQo+DQo+IE5vZGVzIGFuZCBsaW5rcyBvciBieSB1c2luZyBhIHN0YWNrIG9mIHVu cHJvdGVjdGVkIGFkai1zaWRzIHRoYXQgYXZvaWQNCj4gcmVzdHJpY3RlZCBub2RlcyBhbmQgbGlu a3MuIFdoZW4gYSBzdGFjayBvZiBhZGotc2lkcyBpcyB1c2VkIHRvDQo+IHJlYWxpemUgdGhlIHBh dGgsIHRoZSBoZWFkLWVuZCBiYXNlZCAoc0JGRCkgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGNhbiBi ZSBhcHBsaWVkLg0KPg0KPiBJZiBOb2RlLXNpZHMvcHJlZml4LXNpZC9hbnljYXN0LXNpZHMgYXJl IHVzZWQgdG8gYnVpbGQgdGhlIHN0YWNrLCB0aGUNCj4gZmFpbHVyZSBldmVudHMgbWF5IGNhdXNl IHRyYWZmaWMgdG8gZ28gdGhyb3VnaCByZXN0cmljdGVkIG5vZGVzIGFuZA0KPiBsaW5rcy4gVGhp cyB3b3VsZCBoYXBwZW4gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFueSBraW5kIG9mIHByb3RlY3Rp b24NCj4gaXMgaW4gdXNlIG9yIG5vdC4NCj4NCj4gUmdkcw0KPg0KPiBTaHJhZGRoYQ0KPg0KPiBK dW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+DQo+ICpGcm9tOiogc3ByaW5nIDxzcHJpbmctYm91 bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUyMCUwYj4+IDxt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpBbmRyZXcgQWxz dG9uDQo+ICpTZW50OiogVHVlc2RheSwgQXVndXN0IDQsIDIwMjAgNTo0MSBBTQ0KPiAqVG86KiBS b2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldCA8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0 Pj4NCj4gKkNjOiogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWls dG86c3ByaW5nQGlldGYub3JnPjsgSm9lbCBNLiBIYWxwZXJuDQo+IDxqbWhAam9lbGhhbHBlcm4u Y29tIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6IFtzcHJp bmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPg0KPiAq W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XSoNCj4NCj4gUm9iZXJ0IHRo aXMgaXMgYWN0dWFsbHkgZmFyIG1vcmUgZGlmZmljdWx0IHdoZW4g4oCTIGl0IGNhbiBiZSBhbiBl bnRpcmUNCj4gKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0IG5lZWQgdG8gYmUgYXZvaWRlZC4N Cj4NCj4gSXQgY291bGQgcG90ZW50aWFsbHkgYmUgbWFkZSB0byB3b3JrIGJ1dCBJ4oCZZCB3b3Jy eSB0aGF0IHRvIGRvIHRoaXMg4oCTDQo+IHlvdeKAmWQgaGF2ZSB0byBzdGFjayAxMCDigJMgMjAg 4oCTIDMwIG5lZ2F0aXZlIGxhYmVscyDigJMgYW5kIHRoYXQgd291bGRu4oCZdA0KPiBiZSB2aWFi bGUuDQo+DQo+IEl04oCZcyBlYXNpZXIgdG8gdXNlIGFsZ29yaXRobXMgYW5kIGFkamFjZW5jeSBz aWRzIGFuZCBvdGhlciBzdWNoIHRoaW5ncw0KPiB0byBjYWxjdWxhdGUgcGF0aHMg4oCTIHRoZSBi aWdnZXN0IHRyaWNrIGlzIGFib3V0IHRoZSBzdGFjayBkZXB0aC4gIFdoZW4NCj4geW91IGhhdmUg dGhpcyBuZWVkIGZvciBub2RlIGF2b2lkYW5jZSDigJMgdGhlIG5lZWQgZm9yIDEwKyBsYWJlbCBk ZXB0aA0KPiBpcyBjcml0aWNhbCDigJMgdW5sZXNzIHlvdSB3YW5uYSBiZSBhcHBseWluZyBvbmUg aGVsbCBvZiBhIGxvdCBvZg0KPiBiaW5kaW5nIGxhYmVscyBhbG9uZyB0aGUgd2F5IHdoaWNoIGlz IGEgbmlnaHRtYXJlLg0KPg0KPiBCdXQgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGlzIHRoaXMg YSBjb21tb24gdXNlIGNhc2Ug4oCTIGl04oCZcyBhIHVzZQ0KPiBjYXNlIHRoYXQgbW9zdCBvZiB0 aGUgcGVvcGxlIEkgZGlzY3VzcyB0aGlzIHdpdGggY2VydGFpbiBoYXZlIOKAkyBJIGNhbnQNCj4g Y29tbWVudCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFueW9uZSBlbHNlLCBidXQgZXZlcnkg aW5kaWNhdGlvbiBJDQo+IGhhdmUgaXMgdGhhdCB5ZXMg4oCTIGl0cyBzb21ldGhpbmcgcGVvcGxl IG5lZWQsIGFuZCB3YW50DQo+DQo+IEFuZHJldw0KPg0KPiAqRnJvbToqIFJvYmVydCBSYXN6dWsg PHJvYmVydEByYXN6dWsubmV0IDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqU2VudDoq IFR1ZXNkYXksIDQgQXVndXN0IDIwMjAgMDE6MjcNCj4gKlRvOiogQW5kcmV3IEFsc3RvbiA8QW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbQ0KPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tJTIwJTBiPj4gPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20u Y29tPj4NCj4gKkNjOiogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20lMjAlMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+Pjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+IDxtYWlsdG86 c3ByaW5nQGlldGYub3JnPg0KPiAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVj dGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4NCj4gSXMgdGhpcyBhIGNvbW1vbiB1 c2UgY2FzZSBpZS4gICJidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsNCj4gc2Vn bWVudHMgaXQgY2FuIG5ldmVyIHRvdWNoIG9yIGZsb3cgdGhyb3VnaC4iDQo+DQo+IElmIHNvIHBl cmhhcHMgaXRzIHRpbWUgdG8gZGVmaW5lIG5vdGlvbiBvZiAqbmVnYXRpdmUtU0lEKiBpZS4gbGlz dCBpbg0KPiB0aGUgcGFja2V0IHJlc291cmNlcyB3aGljaCBnaXZlbiBwYWNrZXQgTVVTVCBub3Qg ZXZlciB0cmF2ZXJzZS4NCj4NCj4gUHV0IGluIHRoZSBwYWNrZXQgc2V0IG9mIG5vZGVzIG9yIGxp bmtzIHdoaWNoIHRoZSBwYWNrZXQgc2hvdWxkIG5ldmVyDQo+IHRyYXZlcnNlLg0KPg0KPiBUaGF0 IGdvZXMgaW4gbGluZSBvZiByZWNlbnQgd2F2ZSBvZiBuZWdhdGl2ZSByb3V0aW5nIGltcGxlbWVu dGF0aW9ucw0KPiAoUklGVCkgb3IgZGlzY3Vzc2lvbnMgKExTUikNCj4NCj4gQmVzdCwNCj4gUi4N Cj4NCj4gT24gTW9uLCBBdWcgMywgMjAyMCBhdCAxMTo0NiBQTSBBbmRyZXcgQWxzdG9uDQo+IDxB bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8bWFpbHRvOkFuZHJldy5BbHN0b25AbGlx dWlkdGVsZWNvbS5jb20lMjAlMGI+PiA8bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb20+PiB3cm90ZToNCj4NCj4gICAgIFNvIOKAkw0KPg0KPiAgICAgT25lIG9mIHRoZSB1c2Ug Y2FzZXMsIGluIGZhY3QsIHNvbWUgdmVyeSBtYWpvciB1c2UgY2FzZXMgaW4gYW55DQo+ICAgICBz cHJpbmcgdGVjaG5vbG9neSBmb3IgdXMgcmV2b2x2ZSBhcm91bmQgdGhlIGZvbGxvd2luZw0KPg0K PiAgICAgYS5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9kZXMNCj4NCj4gICAg IGIuVGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIHNlY3Rpb25zIG9mIHRoZSBuZXR3 b3JrDQo+DQo+ICAgICBBbnl0aGluZyB0aGF0IGNvdWxkIHJlc3VsdCBpbiB0aGF0IGV4cGxpY2l0 IGF2b2lkYW5jZSBiZWluZyB2aW9sYXRlZA0KPiAgICAg4oCTIHdvdWxkIGNyZWF0ZSwgc2hhbGwg d2Ugc2F5IHNpZ25pZmljYW50IHByb2JsZW1zLg0KPg0KPiAgICAgTXVjaCBvZiB0aGUgdXNlIGNh c2UgaXMgbm90IGEgY2FzZSBvZiB3aGljaCBub2RlcyB0aGUgcGFja2V0cyBmbG93DQo+ICAgICB0 aHJvdWdoIOKAkyBidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2VnbWVudHMg aXQgY2FuIG5ldmVyDQo+ICAgICB0b3VjaCBvciBmbG93IHRocm91Z2guICBFZmZlY3RpdmVseSwg dG8gYmUgdXNlZCBhcyBhIHRlY2hub2xvZ3kgdG8NCj4gICAgIGF2b2lkIGNlcnRhaW4gdGhpbmdz IGZvciBzcGVjaWZpYyByZWFzb25zLg0KPg0KPiAgICAgVGhpcyBpcyBhbHNvIG9uZSBvZiB0aGUg cmVhc29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwgc3RhY2tzIOKAkw0KPiAgICAgdGhp cyBraW5kIG9mIGRldGFpbGVkIHBhdGggcHJvZ3JhbW1pbmcgdGVuZHMgdG8gZGVlcGVuIHRoZSBz dGFjaw0KPiAgICAgYmVjYXVzZSB5b3Ugc29tZXRpbWVzIGhhdmUgdG8gYmUgcHJldHR5IGV4cGxp Y2l0Lg0KPg0KPiAgICAgSXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1cyB0aGF0IHRoaXMg ZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDigJMNCj4gICAgIGFuZCB0aGF0IHdlIGNhbiBhdm9pZCBz aXR1YXRpb25zIHdoaWNoIGNvdWxkIGNhdXNlIHRyYWZmaWMgdG8NCj4gICAgIGFjY2lkZW50bHkg aGl0IHRoaW5ncyBleHBsaWNpdGx5IGF2b2lkZWQuDQo+DQo+ICAgICBJIHdpc2ggSSBjb3VsZCBi ZSBtb3JlIHNwZWNpZmljIHRoYW4gdGhpcywgYnV0IGl0IGlzIHdoYXQgaXQgaXMuDQo+DQo+ICAg ICBUaGFua3MNCj4NCj4gICAgIEFuZHJldw0KPg0KPiAgICAgKkZyb206KiBzcHJpbmcgPHNwcmlu Zy1ib3VuY2VzQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiPj4g ICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpKb2Vs IE0uIEhhbHBlcm4NCj4gICAgICpTZW50OiogTW9uZGF5LCAzIEF1Z3VzdCAyMDIwIDIxOjM2DQo+ ICAgICAqVG86KiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldCA8bWFpbHRvOnJvYmVy dEByYXN6dWsubmV0Pj4NCj4gICAgICpDYzoqIHNwcmluZ0BpZXRmLi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgKlN1YmplY3Q6KiBS ZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZw0KPiBhcHBsaWNhYmls aXR5DQo+DQo+ICAgICAoU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCBy ZWl0ZXJhdGluZyB0aGF0IHRoaXMgaXMgYXMgYQ0KPiAgICAgcGFydGljaXBhbnQsIG5vdCBhIFdH IGNoYWlyLikNCj4NCj4gICAgIFllcywgd2UgYXJlIHRhbGtpbmcgSVAgbmV0d29ya3MuIEFuZCB5 ZXMsIEkgaGF2ZSBzZWVuIElQIG5ldHdvcmtzIHRoYXQNCj4gICAgIGNob29zZSB0byBkcm9wIHBh Y2tldHMuIEZvciBhbGwgc29ydHMgb2YgcmVhc29ucy4NCj4gICAgIEkgdGhpbmsgdGhlcmUgYXJl IGxpa2VseSBvdGhlciByZWFzb25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9tDQo+ICAg ICBwYXRoIHJhdGhlciB0aGFuIGEgY2hvc2VuIFRFIHBhdGguIEkgdGhpbmsgaXQgaXMgaW1wb3J0 YW50IHdlIGJlIGNsZWFyDQo+ICAgICBhYm91dCB3aGF0IGNvbnN0cmFpbnRzIG1heSBiZSAvIGFy ZSB2aW9sYXRlZCB3aGVuIHdlIHRlbGwgcGVvcGxlIHRoZXkNCj4gICAgIGhhdmUgdGhpcyB0b29s IChwcm90ZWN0aXZlIHJlcm91dGluZykgdGhhdCBpcyBpbnRlbmRlZCB0byBwcmVzZXJ2ZSBRb1Mu DQo+DQo+ICAgICBMZXQncyBiZSBjbGVhci4gSSBhbSBub3QgYXJndWluZyB0aGF0IHRoaXMgaXMg bm90IGEgZ29vZCBpZGVhLiBJdCBpcyBhDQo+ICAgICBnb29kIGlkZWEuIEFuZCB1c2VmdWwuIEkg YW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdHUgd2hhdCBjb21iaW5hdGlvbiBvZg0KPiAgICAgYWRkaXRp b25hbCBtZWNoYW5pc21zIGFuZCBjbGVhciBkZXNjcmlwdGlvbnMgd2lsbCBsZWFkIHRvIGV2ZXJ5 b25lDQo+ICAgICBnZXR0aW5nIHRoZSBiZWhhdmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5v dCBiZSB0aGUgYmVoYXZpb3IgdGhleQ0KPiAgICAgZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRo ZSBiZXN0IHdlIGNhbiBkby4pDQo+DQo+ICAgICBZb3VycywNCj4gICAgIEpvZWwNCj4NCj4gICAg IE9uIDgvMy8yMDIwIDI6MzAgUE0sIFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+ICAgICAgPiBKb2Vs LA0KPiAgICAgID4NCj4gICAgICA+IEFyZSB3ZSBzdGlsbCB0YWxraW5nIGFib3V0IElQIG5ldHdv cmtzIGhlcmUgPyBPciBwZXJoYXBzIHNvbWUgaGFyZA0KPiAgICAgID4gc2xpY2luZyB3aXRoIHJl YWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5ldHMgPw0KPiAgICAgID4NCj4gICAgICA+ IEJlY2F1c2UgaWYgd2UgYXJlIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya2luZyBJIGhhdmUgdHdv DQo+ICAgICBvYnNlcnZhdGlvbnM6DQo+ICAgICAgPg0KPiAgICAgID4gQSkgSWYgeW91IG5lZWQg dG8gdHJhdmVyc2UgdmlhIGEgc3BlY2lmaWMgbm9kZSAoaWUuIGZpcmV3YWxsKSB5b3UNCj4gICAg IGJldHRlcg0KPiAgICAgID4gYXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuLiBJ IGRvbid0IHRoaW5rIElQDQo+ICAgICBlbmNhcHN1bGF0aW9uIGNhbg0KPiAgICAgID4gYmUgaGlq YWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBp cw0KPiAgICAgaWdub3JlZC4NCj4gICAgICA+DQo+ICAgICAgPiBCKSBIYXZlIHlvdSBzZWVuIGFu eSBJUCBuZXR3b3JrIHdoZXJlIHVwb24gdG9wb2xvZ3kgY2hhbmdlIChsaW5rDQo+ICAgICBvciBu b2RlDQo+ICAgICAgPiBmYWlsdXJlKSB5b3Ugc3VkZGVubHkgc3RhcnQgZHJvcHBpbmcgZmxvd3Mg aW4gc3BpdGUgb2YgU1BUIG9mZmVyaW5nDQo+ICAgICAgPiBwZXJoYXBzIGZldyBtcyBsb25nZXIg cGF0aCB3aXRoIDEwIG1zIG1vcmUgaml0dGVyID8NCj4gICAgICA+DQo+ICAgICAgPiBPciBhcmUg c29tZSBTUiBtYXJrZXRpbmcgc2xpZGVzIHByb21pc2UgdG8gdHVybiBJUCBuZXR3b3JrcyBpbg0K PiAgICAgID4gc29tZXRoaW5nIG5ldyA/IFdvcnNlIC4uLiBkbyB0aGV5IG1lbnRpb24gcGF0aCBx dWFsaXR5IGd1YXJhbnRlZXMsDQo+ICAgICAgPiByZXNvdXJjZSByZXNlcnZhdGlvbnMgPyBJIGhv cGUgbm90Lg0KPiAgICAgID4NCj4gICAgICA+IFRoeCwNCj4gICAgICA+IFIuDQo+ICAgICAgPg0K PiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAg Pg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPiBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDg6 MTAgUE0gSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20lMGI+PiAgICAgPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTIwJTBi Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQo+ICAgICAgPg0KPiAgICAg ID4gV2VsbCBsZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90IHN1cmUgdGhlIHByb2Js ZW0gaXMNCj4gICAgIHJlc3RyaWN0ZWQNCj4gICAgICA+IHRvIGp1c3Qgc2VydmljZSBTSURzLg0K PiAgICAgID4NCj4gICAgICA+IFN1cHBvc2UgdGhhdCB0aGUgUENFIGhhcyBzcGVjaWZpZWQgdGhl IHBhdGggdG8gbWVldCBzb21lIGNvbXBsZXggdGUNCj4gICAgICA+IG9iamVjdGl2ZS4gIFRoZSBi eXBhc3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dpbmcgd2hhdCB0aG9zZQ0KPiAgICAgID4gY29u c3RyYWludHMNCj4gICAgICA+IHdlcmUuICBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywg aXQgaXMgYmV0dGVyIHRvIGRyb3AgdGhlIHBhY2tldA0KPiAgICAgID4gdGhhbiB0byBkZWxpdmVy IGl0IG91dHNpZGUgdGhlIGVudmVsb3AuICBJIHN1c3BlY3QgdGhhdCB0aGUgcmlnaHQNCj4gICAg ICA+IGFuc3dlcg0KPiAgICAgID4gdG8gdGhpcyBpcyAidG9vIGJhZCIuICBJZiBzbywgYXMgd2l0 aCB0aGUgZGlzdGluY3Rpb24gcmVnYXJkaW5nDQo+ICAgICBzZXJ2aWNlDQo+ICAgICAgPiBub2Rl cywgd2Ugc2hvdWxkIHNheSBzbywgc2hvdWxkbid0IHdlPw0KPiAgICAgID4NCj4gICAgICA+IFlv dXJzLA0KPiAgICAgID4gSm9lbA0KPiAgICAgID4NCj4gICAgICA+IE9uIDgvMy8yMDIwIDI6MzYg QU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOg0KPiAgICAgID4gPiBNYWNoLCBKb2VsIGFu ZCBhbGwsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgdGhpbmsgdGhhdCBpbiBtb3N0IGNhc2Vz Og0KPiAgICAgID4gPg0KPiAgICAgID4gPiAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlv biBiZXR3ZWVuICJ0b3BvbG9naWNhbCIgYW5kDQo+ICAgICAic2VydmljZSINCj4gICAgICA+ID4g aW5zdHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5nLjoNCj4gICAgICA+ID4NCj4g ICAgICA+ID4gb0lHUCBQcmVmaXggTm9kZSBTSURzIElHUCBBZGotU0lEcyAoaWRlbnRpZmllZCBh cyBzdWNoIGluIHRoZQ0KPiAgICAgID4gPiBjb3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50 cykgcmVwcmVzZW50IHRvcG9sb2dpY2FsDQo+ICAgICBpbnN0cnVjdGlvbnMNCj4gICAgICA+ID4N Cj4gICAgICA+ID4gb1NlcnZpY2UgU0lEcyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92 ZXJsYXkgU2VydmljZXMNCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICA8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNDQ2N5OW1ZNmNNZmJrN1FmamhpQTNSNkgyP3U9aHR0cHMlM0El MkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWJlc3Mt c3J2Ni1zZXJ2aWNlcy0wNA0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ0NjeTlt WTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQlMGI+PiAgICAg PGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zR0M1YWYyejNKenBoWkRrUG5jSEFRaTZI Mj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRh dHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2 aWNlcy0wNF9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdt MHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG80VC1MMG5sJTI0Pj4NCj4gICAgICA+DQo+ ICAgICAgPiA+IGRyYWZ0KSB1bnN1cnByaXNpbmdseSByZXByZXNlbnQg4oCcc2VydmljZeKAnSBp bnN0cnVjdGlvbnMNCj4gICAgICA+ID4NCj4gICAgICA+ID4gMi5TZWdtZW50cyB0aGF0IHJlcHJl c2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5cGFzc2VkLA0KPiAgICAgID4g PiB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2VudCBzZXJ2aWNlIGluc3RydWN0aW9ucyByZXF1 aXJlDQo+ICAgICAgPiBhbHRlcm5hdGl2ZQ0KPiAgICAgID4gPiBwcm90ZWN0aW9uIG1lY2hhbmlz bXMuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IFRoaXMgdmlldyBzZWVtcyB0byBiZSBhbGlnbmVk IHdpdGggUkZDIDg0MDINCj4gICAgICA+ID4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zNDVOTENCNlR5ZHh1dXFVanRjRFJaeTZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5v cmclMkZodG1sJTJGcmZjODQwMg0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNDVO TENCNlR5ZHh1dXFVanRjRFJaeTZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZo dG1sJTJGcmZjODQwMiUwYj4+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM3 UHpVS0FEODJjalN2bVZjR3Zwa2hGNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUy RnYzJTJGX19odHRwcyUzQSUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDJfXyUzQiUy MSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dw NnZwUkhPR3Q4QWtUUkR1aURvMEk0WWJ0bSUyND4+DQo+ICAgICB0aGF0IHNheXMgaW4gU2VjdGlv biAxOg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQ LWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bw0KPiAgICAgID4gPg0KPiAgICAg ID4gPiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIElHUC1BZGphY2VuY3kg c2VnbWVudCBhbmQgdGhlDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBJR1AtUHJlZml4IHNl Z21lbnQuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBJbiB0aGUgY29udGV4dCBvZiBhIEJH UC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28NCj4gICAgICA+ID4NCj4gICAg ICA+ID4gdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBCR1AgcGVlcmluZyBz ZWdtZW50IGFuZCB0aGUNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIEJHUC1QcmVmaXggc2Vn bWVudC4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gSW4gdGhlIGNhc2Ugb2YgU1ItTVBMUyB0aGlz IGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb24NCj4gICAgICA+IDMuNCBvZg0K PiAgICAgID4gPiB0aGUgTm9kZSBQcm90ZWN0aW9uIGZvciBTUi1URSBQYXRoDQo+ICAgICAgPiA+ DQo+ICAgICAgPg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zSmJTV0d4 NURBZk5Qc1pkaHBFeHh4OTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3It dGUtcGF0aHMtMDclMjNzZWN0aW9uLTMuNA0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zSmJTV0d4NURBZk5Qc1pkaHBFeHh4OTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIu aWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlv bi1mb3Itc3ItdGUtcGF0aHMtMDclMjNzZWN0aW9uLTMuNCUwYj4+ICAgICA8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNDclVnQVJXOHNvbUFidzZUaXNqZ0oxNkgyP3U9aHR0cHMlM0El MkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9y LXNyLXRlLXBhdGhzLTA3JTJBc2VjdGlvbi0zLjRfXyUzQkl3JTIxJTIxTkV0NnlNYU8tZ2slMjFT MFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG85 d08tU3NuJTI0Pj4NCj4gICAgICA+DQo+ICAgICAgPiA+IGRyYWZ0IHRoYXQgc2F5czoNCj4gICAg ICA+ID4NCj4gICAgICA+ID4gICAgIFRoZSBub2RlIHByb3RlY3Rpb24gbWVjaGFuaXNtIGRlc2Ny aWJlZCBpbiB0aGUgcHJldmlvdXMNCj4gICAgIHNlY3Rpb25zDQo+ICAgICAgPiA+DQo+ICAgICAg PiA+ICAgICBkZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVsIGltbWVkaWF0 ZWx5IGJlbG93DQo+ICAgICAgPiB0aGUgdG9wDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IGxhYmVs IGluIHRoZSBsYWJlbCBzdGFjayBpcyB1bmRlcnN0b29kIGluIHRoZSBJR1AgZG9tYWluLiAgV2hl biB0aGUNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBl eGNoYW5nZSBzZXJ2aWNlIGxhYmVscyB2aWEgQkdQIG9yIHNvbWUNCj4gICAgICA+IG90aGVyDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90dG9tIGxh YmVsIGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1ANCj4gICAgICA+ID4NCj4gICAgICA+ID4g ICAgIGRvbWFpbi4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIFRoZSBlZ3Jlc3Mgbm9kZSBw cm90ZWN0aW9uIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdA0KPiAgICAgID4gPg0K PiAgICAgID4gPiAgICAgW1JGQzg2NzkgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z SmZ2dEJBbWFRUE4xakEzcE02VGRDRTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0 Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODY3OQ0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS8zSmZ2dEJBbWFRUE4xakEzcE02VGRDRTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNr ZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODY3OSUwYj4+ICAgICA8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzM2ZE1BanVZVFFvdm84akh3bW0zZUp3NkgyP3U9aHR0cHMlM0El MkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRnJmYzg2NzlfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4 OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOE1HaXBY YyUyND4+XQ0KPiAgICAgaXMNCj4gICAgICA+ID4gYXBwbGljYWJsZSB0byB0aGlzIHVzZSBjYXNl IGFuZCBubyBhZGRpdGlvbmFsIGNoYW5nZXMNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIHdp bGwgYmUgcmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzDQo+ICAgICAgPiA+DQo+ICAgICAg PiA+IFRoZSBzY2VuYXJpb3MgaW4gd2hpY2ggIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRv cG9sb2dpY2Fs4oCdIGFuZA0KPiAgICAgID4gPiDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBp cyBicm9rZW4gYXJlIGluZGVlZCBwcm9ibGVtYXRpYy4gRS5nLiwNCj4gICAgICA+IGNvbnNpZGVy DQo+ICAgICAgPiA+IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUgU0lEIGluIHRoZSBFUk8g b2YgYSBTUi1URSBwYXRoDQo+ICAgICAgPiBpZGVudGlmaWVzIGENCj4gICAgICA+ID4gbm9kZSB0 aGF0IGFjdHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4s DQo+ICAgICAgPiBwcm92aWRlcw0KPiAgICAgID4gPiB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRo b3V0IGFueSBkZWRpY2F0ZWQgc2VydmljZSBTSUQNCj4gICAgICA+IGlkZW50aWZ5aW5nIGl0Lg0K PiAgICAgID4gPiBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2ggYSBub2Rl IHdvdWxkIGNvbWJpbmUNCj4gICAgICA+IHRvcG9sb2dpY2FsDQo+ICAgICAgPiA+IGFuZCBzZXJ2 aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRpb24NCj4gICAg ICA+IGJldHdlZW4gdGhlIHR3by4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gSSBhbSBub3Qgc3Vy ZSBpZiB1c2FnZSBvZiBzdWNoIOKAnGNvbWJpbmVk4oCdIFNJRHMgY291bGQgYmUgcHJldmVudGVk DQo+ICAgICAgPiBvciBhdA0KPiAgICAgID4gPiBsZWFzdCBkaXNjb3VyYWdlZC4NCj4gICAgICA+ ID4NCj4gICAgICA+ID4gSWYgbm90LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0byBpZGVudGlmeSBz dWNoIFNJRHMgaW4gdGhlDQo+ICAgICAgPiBhZHZlcnRpc2VtZW50DQo+ICAgICAgPiA+IG1lY2hh bmlzbXMgd291bGQgYmUgdXNlZnVsIElNSE8uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IE15IDJj LA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBTYXNoYQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiBP ZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gICAgICA+ID4NCj4gICAgICA+ID4gQ2VsbDogICAgICAr OTcyLTU0OTI2NjMwMg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBFbWFpbDogQWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPg0KPiAgICAgPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4g ICAgICA+IDxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICAg PiA+DQo+ICAgICAgPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICAgPiA+IEZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxtYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYj4+ DQo+ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1h Y2ggQ2hlbg0KPiAgICAgID4gPiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDY6MzAgQU0N Cj4gICAgICA+ID4gVG86IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiPj4gICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSUwYj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+Ow0KPiAgICAgc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+ID4gU3ViamVjdDogUmU6IFtzcHJpbmdd IFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiAgICAgID4g Pg0KPiAgICAgID4gPiBIaSBKb2VsLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJIHRoaW5rIHRo aXMgaXMgYSBnb29kIHBvaW50IHRoYXQgbWF5IG5vdCBiZSBkaXNjdXNzZWQgaW4gdGhlDQo+ICAg ICAgPiBwYXN0LiBBbmQNCj4gICAgICA+ID4gSSBhbHNvIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEg ImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBpbiB0aGUNCj4gICAgICA+ID4gcm91dGluZyBh ZHZlcnRpc2VtZW50IGZvciBub3cuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IElNSE8sIHRoZSBp bmZvcm1hdGlvbiBhZHZlcnRpc2VkIGJ5IHJvdXRpbmcgaXMgbmV1dHJhbCwgc3VjaA0KPiAgICAg ID4gaW5mb3JtYXRpb24NCj4gICAgICA+ID4gKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQpIGlz IG1vcmUgcGF0aCBzcGVjaWZpYywgdGh1cw0KPiAgICAgbm9ybWFsbHkgdGhlDQo+ICAgICAgPiA+ IGNvbnRyb2xsZXIgc2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciBkZWNpZGluZyB3aGV0aGVyL3do aWNoIFNJRA0KPiAgICAgID4gY2FuIGJlDQo+ICAgICAgPiA+IGJ5cGFzc2VkLg0KPiAgICAgID4g Pg0KPiAgICAgID4gPiBCZXN0IHJlZ2FyZHMsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IE1hY2gN Cj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g ICAgICA+ID4NCj4gICAgICA+ID4gID4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmcNCj4gICAgICA+IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiJTNlJTIwJTNjbWFpbHRvOnNw cmluZy1ib3VuY2VzQGlldGYub3JnJTNlPl0NCj4gICAgIE9uIEJlaGFsZiBPZiBKb2VsIE0uDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IEhhbHBlcm4NCj4gICAgICA+ID4NCj4gICAgICA+ID4g ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA3OjUxIEFNDQo+ICAgICAgPiA+DQo+ICAg ICAgPiA+ICA+IFRvOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4g ICAgICA+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiAg ICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnPj4+ DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFN1YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90 ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiAgICAgID4gPg0KPiAgICAgID4g PiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiAoV0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBp cyBtZXJlbHkgYSBub3RlIGZyb20gYSBzbGlnaHRseQ0KPiAgICAgID4gY29uZnVzZWQgV0cNCj4g ICAgICA+ID4NCj4gICAgICA+ID4gID4gcGFydGljaXBhbnQuKQ0KPiAgICAgID4gPg0KPiAgICAg ID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBJIGhhdmUgYmVlbiByZWFkaW5nIHRo ZSB2YXJpb3VzIHJlcGFpciBkcmFmdHMsIGFuZCB0aGUgdmFyaW91cw0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgPiBuZXR3b3JrcyBwcm9ncmFtbWluZyBhbmQgc2VydmljZSBwcm9ncmFtbWluZyBk cmFmdCwgYW5kIEkgYW0NCj4gICAgICA+IHRyeWluZyB0bw0KPiAgICAgID4gPg0KPiAgICAgID4g PiAgPiBmaWd1cmUgb3V0IG9uZSBhc3BlY3Qgb2YgdGhlIGNvbWJpbmF0aW9uLg0KPiAgICAgID4g Pg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBIb3cgZG9lcyBhIG5v ZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2YgYnlwYXNzIChzdXBwb3NlLCBmb3INCj4gICAg ICA+ID4NCj4gICAgICA+ID4gID4gc2ltcGxpY2l0eSwgaXQgaXMgTm9kZSBOMiBkZWNpZGluZyB0 byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcg0KPiAgICAgID4gYSBmYWlsZWQNCj4gICAgICA+ID4N Cj4gICAgICA+ID4gID4gbm9kZSBOMykga25vdyB0aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/DQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IElmIHRo ZSBwYXRoIHdhcyBqdXN0IGZvciBURSwgdGhlbiBpdCBpcyAic2FmZSIgaWYgdGhlIG5ldyBwYXRo DQo+ICAgICAgPiBtZWV0cw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiB0aGUgVEUgY3JpdGVy aWEuICBvciBtYXliZSBpdCBpcyBzYWZlIGlmIGl0IGlzIGV2ZW4gY2xvc2UsIGFzDQo+ICAgICAg PiBsb25nIGFzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IGl0IGlzIG5vdCB1c2VkIGZvciB0 b28gbG9uZy4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ ID4gID4gQnV0IHdoYXQgaWYgdGhlIG5vZGUgd2VyZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0byBt ZWV0IGxlZ2FsDQo+ICAgICAgPiA+IHJlcXVpcmVtZW50cz8NCj4gICAgICA+ID4NCj4gICAgICA+ ID4gID4gT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0cmFuc2Zvcm0g KHdpbmNlIHdlIGFyZQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBkZWxpYmVyYXRlbHkgdmFn dWUgYWJvdXQgd2hhdCBub2RlcyBjYW4gZG8gd2hlbiBhc2tlZCBzdWl0YWJseS4pDQo+ICAgICAg PiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IElzIHRoZXJlIHNv bWUgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBpbiB0aGUgcm91dGluZw0KPiAgICAgID4g Pg0KPiAgICAgID4gPiAgPiBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPw0KPiAgICAgID4g Pg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBUaGFuayB5b3UsDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFlvdXJzLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAg PiBKb2VsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAg ICAgPiA+DQo+ICAgICAgPiA+ICA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgICA+ID4NCj4g ICAgICA+ID4gID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWls dG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAg ICAgPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiPj4gICAg IDxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+Pg0K PiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgIGh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91 PWh0dHBzJTNBJTI8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5 dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyPg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zUTd2WDJxV1NVZFdWYzg5Mlh1WHkySDZIMj91PWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJG MzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTJfXyUzQkpTVSUy MSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dw NnZwUkhPR3Q4QWtUUkR1aURvNkh3UExpbCUyND4NCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAg ICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0 NkgyP3U9aHR0cHMlM0ElMjUyDQo8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3Fo VTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyJTBiPj4gICAgIDxodHRwczovL2Ns aWNrdGltZS5zeW1hbnRlYy5jb20vM0E1QjhIMkZtMXJQbmFaM1N1cGp3cjZIMj91PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50 ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTI1 Ml9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgw d3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG96b1FpQUhrJTI0Pj4NCj4gICAgICA+ID4NCj4g ICAgICA+ID4gID4gRiUyRnd3dy5pZXRmLm9yZw0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFO RXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJI T0d0OEFrVFJEdWlEby1wUENqdlIlMjQ+DQo+ICAgICAgPiA8aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzNHV1Q5ZnlqYUZpM0ZjdkhEdm9vZHZTNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3 LmlldGYub3JnDQo8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHV1Q5ZnlqYUZpM0Zj dkhEdm9vZHZTNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3LmlldGYub3JnJTBiPj4gICAgIDxodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1o dHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRm Lm9yZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgw d3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8tcFBDanZSJTI0Pj4lMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzcHJpbmcNCj4gICAgICA+ID4NCj4gICAgICA+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+ID4NCj4gICAgICA+ID4gc3By aW5nIG1haWxpbmcgbGlzdA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcNCjxtYWlsdG86 c3ByaW5nQGlldGYub3JnJTBiPj4gICAgIDxtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiPj4gPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KPiAgICAgID4gPg0KPiAgICAgID4gPg0KPiAgICAgID4N Cj4gICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRl QXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGc3ByaW5nDQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNCaHlFdHg0 UTduNzRCaGlSbmZNSnRUNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJG X19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRl QXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMkYlMkEyRnd3dy5pZXRmLm9yZyUyQTJGbWFpbG1h biUyQTJGbGlzdGluZm8lMkEyRnNwcmluZ19fJTNCSlNVbEpTVWwlMjElMjFORXQ2eU1hTy1nayUy MVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlE by1oUjNnQUQlMjQ+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAg PiA+DQo+ICAgICAgPg0KPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICAgPiA+IE5vdGljZTog VGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4NCj4g ICAgICA+ID4gaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBp cyBjb25maWRlbnRpYWwNCj4gICAgICA+IGFuZC9vcg0KPiAgICAgID4gPiBwcm9wcmlldGFyeSBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsDQo+ ICAgICAgPiA+IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMg b3IgZm9yd2FyZGluZw0KPiAgICAgd2l0aG91dA0KPiAgICAgID4gPiBleHByZXNzIHBlcm1pc3Np b24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+ICAgICAgPiBp bnRlbmRlZA0KPiAgICAgID4gPiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsDQo+ICAgICAgPiA+IGNvcGllcywgaW5jbHVk aW5nIGFueSBhdHRhY2htZW50cy4NCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gICAgICA+ID4NCj4gICAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0K PiAgICAgID4gPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgID4gPiBo dHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/ dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmlu Zw0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3 OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmdfXyUzQiUyMSUy MU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZw UkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyND4NCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICAg PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAg ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz4NCj4gICAgICA+IGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tH eU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNl LmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRR eGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Pg0KPiAgICAgID4N Cj4NCj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ICAgICBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICBodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0KPg0K PiA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXEx NkgyP3U9aHR0cHMlM0ElDQo8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RS ZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMjUlMGI+PiAyRiUyRnVybGRlZmVuc2UuY29t JTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpDQo+IG5m byUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRR eGdtMHgwd3hxZ3UNCj4gb1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyND4NCj4NCj4N Cj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiBOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVy IHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluDQo+IGluZm9ybWF0aW9uIG9mIFJpYmJv biBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vcg0KPiBwcm9w cmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSBy ZXZpZXcsDQo+IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMg b3IgZm9yd2FyZGluZyB3aXRob3V0DQo+IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj4gcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbA0KPiBj b3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmlu ZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgy P3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJp bmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJp bmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4N Cmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZI Mj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3By aW5nDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5vdGljZTogVGhpcyBl LW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gaW5mb3JtYXRp b24gb2YgUmliYm9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwgYW5k L29yIHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dC4gQW55IHJldmlldywgZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90 aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsIGNvcGll cywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo= --_000_MW3PR11MB4570615B3050B500C456C99EC1400MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFNh c2hhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5JZiB0aGUgc2VydmljZSBkb2VzIG5vdCBuZWVkIGFueSBhZGRpdGlvbmFsIGNv bnRleHQgKGUuZy4gYSBmaXJld2FsbCB0aGF0IGp1c3QgYXBwbGllcyBsb2NhbGx5IGNvbmZpZ3Vy ZWQgZGVmYXVsdCBydWxlcyBvbiBpdCksIHRoZW4gSSBkb27igJl0IHNlZSB3aHkgUEhQIGNvdWxk IG5vdCBiZSBkb25lIGZvciBhIFByZWZpeCBTSUQgYXNzb2NpYXRlZA0KIHdpdGggYSBzZXJ2aWNl IG5vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkFsc28sIEkgZGlkbuKAmXQgZm9sbG93IHRoZSBwb2ludCB0aGF0IHlvdSB3 ZXJlIHRyeWluZyB0byBtYWtlIGFib3V0IEFkai1TSURzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5LZXRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7QWxleGFu ZGVyLlZhaW5zaHRlaW5AcmJibi5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXVndXN0 IDIwMjAgMTg6MjQ8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0 O2tldGFudEBjaXNjby5jb20mZ3Q7OyBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFscGVy bi5jb20mZ3Q7OyBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5A cmJibi5jb20mZ3Q7OyBTaHJhZGRoYSBIZWdkZSAmbHQ7c2hyYWRkaGFAanVuaXBlci5uZXQmZ3Q7 OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSAmbHQ7QW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbSZndDs7DQogUm9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJhc3p1ay5u ZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJp bGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+SGkgYWxsLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+UmVnYXJkaW5nIHRoZSBzdGF0 ZW1lbnQgJnF1b3Q7UHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1 Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0aGUgZmxvdyB0byBhIG5vZGUgd2hp Y2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGl0JnF1b3Q7OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMjEyMTIxIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMyMTIxMjEiPkkgdGhpbmsgdGhhdCBpbiBTUi1NUExTIGEgTm9kZSBTSUQgdGhhdCBpcyBhZHZl cnRpc2VkIHdpdGggUEhQIGFjaXRvbiBjYW4gYmUgc2FmZWx5IGNvbnNpZGVyZWQgYXMgJnF1b3Q7 anVzdCBhIHRvcG9sb2dpY2FsIGluc3RydWN0aW9uJnF1b3Q7IGJ5IHRoZSBQTFIgYmVjYXVzZSB0 aGUgb3JpZ2luYXRpbmcgbm9kZSB3aWxsIG5vdCByZWNlaXZlDQogaXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5UaGUgc2FtZSBhcHBsaWVzIHRvIEFkai1TRElzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5NeSAyYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IGlkPSJtcy1vdXRsb29rLW1vYmlsZS1zaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5HZXQgPGEgaHJlZj0iaHR0cHM6Ly9ha2EubXMvZ2hlaTM2Ij5PdXRsb29rIGZvciBB bmRyb2lkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJpZC02YmY0NGQ1MS0w ZTYwLTQ0OGItYmRkZS1kYzQxOTI0OWVmYTIiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIi Pg0KPC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWls dG86a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnIj5rZXRhbnQ9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDo8L3NwYW4+PC9zdHJvbmc+ IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNTowMDxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG86PC9zcGFuPjwv c3Ryb25nPiBKb2VsIE0uIEhhbHBlcm47IEFsZXhhbmRlciBWYWluc2h0ZWluOyBTaHJhZGRoYSBI ZWdkZTsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bSI+RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+OyBSb2JlcnQgUmFzenVr PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5DYzo8L3NwYW4+PC9zdHJvbmc+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciPg0Kc3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDo8L3Nw YW4+PC9zdHJvbmc+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5n IGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgQWxsLDxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0byBzaGFyZSBhIGRpZmZlcmVudCBw ZXJzcGVjdGl2ZSBvbiB0aGlzLjxicj4NCjxicj4NCkZpcnN0LCB0aGFua3MgdG8gSm9lbCBmb3Ig YnJpbmdpbmcgdXAgdGhlIGRpc2N1c3Npb24uIENsZWFybHkgd2UgbmVlZCBhIHdlbGwtZGVmaW5l ZCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBmb3IgZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eSBv ZiBwcm90ZWN0aW9uIGZvciBzZWdtZW50IHVzZWQgaW4gYW4gU1IgUG9saWN5LiBTb21lIG9mIHRo aXMgaXMgY2FwdHVyZWQgaW4gWzFdLjxicj4NCjxicj4NClRoaXMgaXMgYWJvdXQgbG9jYWwgcmVw YWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkgbmF0dXJlLCB0aGUgUExSIGRvZXMgbm90IGhhdmUg YSBub3Rpb24gb2YgaG93ICZxdW90O3N0cmljdCBvciBub3QmcXVvdDsgaXMgdGhlIFNMQSB0aGF0 IGlzIGJlaW5nIHByb3ZpZGVkIGJ5IHRoZSBTUiBQb2xpY3kuIEF3YXJlbmVzcyBvZiB0aGF0IG5v dGlvbiBleGlzdHMgYXQgdGhlIFNSIFBvbGljeSBoZWFkZW5kIGFuZC9vciBjb21wdXRhdGlvbi1u b2RlLjxicj4NCjxicj4NCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0ZWQgdmFyaWFu dHMgb2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0byBwaWNrIG9y IHRoZSBvdGhlciBiYXNlZCBvbiB0aGUgJnF1b3Q7c3RyaWN0bmVzcyZxdW90OyBvZiB0aGUgU0xB IHJlcXVpcmVtZW50IGZvciBwaWNraW5nIHRoYXQgbGluay4gV2UgZG8gbm90IGhhdmUgc3VjaCBh IG5vdGlvbiBmb3IgUHJlZml4IFNJRHMuIE9uZSBjYW4gc2F5IHRoYXQgd2UgY291bGQgaW50cm9k dWNlDQogc2lnbmFsbGluZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFBy ZWZpeCBTSUQgY2FuIGJlIGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0 dW5pdHkgZm9yIHRoZSBjb21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3Ig ZGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS48YnI+ DQo8YnI+DQpJIGhhdmUgYSBwcm9ibGVtIGFuZCBhIGNvbmNlcm4gaW4gdGhlIGFzc3VtcHRpb24g dGhhdCBQTFJzIGNhbiBhc3N1bWUgdGhhdCB0aGUgY3VycmVudGx5IGRlZmluZWQgdmFyaWFudCBv ZiBQcmVmaXggU0lEcyBpbiBSRkM4NDAyIChhbmQgSUdQIHNwZWNzKSBhcmUgJnF1b3Q7YnlwYXNz LWFibGUmcXVvdDsuPGJyPg0KPGJyPg0KQXMgSm9lbCBhbmQgb3RoZXJzIGhhdmUgYnJvdWdodCBv dXQsIHRoZSBQcmVmaXggU0lEIGNvdWxkIGJlIGp1c3QgYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlv biBvciBtYXkgYWxzbyBiZSB1c2VkIHRvIHN0ZWVyIHRoZSBmbG93IHRvIGEgbm9kZSB3aGljaCBp cyBhcHBseWluZyBhIHNlcnZpY2UgZnVuY3Rpb24gdG8gaXQuIEluIG9yZGVyIHRvIHN1cHBvcnQg YSBtaXggb2YgU1IgUG9saWNpZXMgb2YgZGlmZmVyZW50IFNMQXMgKHN0cmljdCBhbmQgbm90LXN0 cmljdCksDQogd2UgbmVlZCB0byBlbmFibGUgdGhlIGNob2ljZSBvZiBTSURzIHRoYXQgaW5kaWNh dGVzIHRvIHRoZSBQTFIgd2hldGhlciB0aGV5IGFyZSAmcXVvdDtieXBhc3MtYWJsZSZxdW90OyBv ciBub3QuPGJyPg0KPGJyPg0KRm9yIHRoZSBjYXNlcywgd2hlcmUgdGhlIFNSIFBvbGljeSBoYXMg YSBzcGVjaWZpYyBTTEEsIGl0IGlzIHJlcXVpcmVkIGZvciBub2RlcyB0byBkcm9wIHRoZSBwYWNr ZXRzIG1lYW50IGZvciB0aGUgJnF1b3Q7YWN0aXZlIHNlZ21lbnQmcXVvdDsgdGhhbiB0byBieXBh c3MgaXQuIFdoZW4gdGhpcyBtZWNoYW5pc20gaXMgdXNlZCBhbG9uZyBzaWRlIFNSVEUgcGF0aCBt b25pdG9yaW5nIG1lY2hhbmlzbXMsIGl0IGVuYWJsZXMgdGhlIGhlYWRlbmQgdG8gZGV0ZWN0IHRo ZQ0KIGZhaWx1cmUgYW5kIGZhbGxiYWNrIHRvIGFuIGFsdGVybmF0ZSBwYXRoIHVzaW5nIHRoZSBw YXRoIHByb3RlY3Rpb24gYXBwcm9hY2guIFRoaXMgaXMgc29tZXRoaW5nIHRoYXQgaXMgZGVzY3Jp YmVkIGFuZCBpbiB1c2UgaW4gZGVwbG95bWVudHMgdG9kYXkgWzFdLi48YnI+DQo8YnI+DQpUaGFu a3MsPGJyPg0KS2V0YW48YnI+DQo8YnI+DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1zNkgyP3U9aHR0cHMlM0ElMkYlMkZ0 b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5LTA4JTIzc2VjdGlvbi05Ij4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z WTNmV3VORllDak1KVWlpQWlXd1VtczZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOCUyM3Nl Y3Rpb24tOTwvYT48YnI+DQpbMl0gPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzM2ZkNNcmdtRWV3QzRhNEFKUnJtbjdINkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRm Lm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4 JTIzc2VjdGlvbi05LjMiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2ZkNNcmdt RWV3QzRhNEFKUnJtbjdINkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwl MkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05 LjM8L2E+PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBz cHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuPGJy Pg0KU2VudDogMDQgQXVndXN0IDIwMjAgMjA6MjU8YnI+DQpUbzogQWxleGFuZGVyIFZhaW5zaHRl aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbSI+QWxl eGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208L2E+Jmd0OzsgU2hyYWRkaGEgSGVnZGUgJmx0Ozxh IGhyZWY9Im1haWx0bzpzaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnIj5zaHJh ZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWls dG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iPkVYVC1BbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25A bGlxdWlkdGVsZWNvbS5jb20iPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0 OzsgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5y b2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT47IEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0 Ozxicj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWlu aW5nIGFwcGxpY2FiaWxpdHk8YnI+DQo8YnI+DQpUaGVyZSBhcmUsIGFzIGZhciBhcyBJIGNhbiB0 ZWxsLCBhIG51bWJlciBvZiB3YXlzIHRvIGFkZHJlc3MgdGhpcyBmYW1pbHkgb2YgcmVsYXRlZCBx dWVzdGlvbnMuPGJyPg0KV2hhdCBzdHJ1Y2sgbWUsIGFuZCBwcm9tcHRlZCB0aGUgc3RhcnRpbmcg cXVlc3Rpb24sIHdhcyB0aGF0IG5vbmUgb2YgdGhlbSB3ZXJlIHNwZWxsZWQgb3V0LiZuYnNwOyBJ IHNlZSBsb3RzIG9mIGludGVyZXN0aW5nIGlkZWFzIC8gcHJvcG9zYWxzLjxicj4NClNvbWUgb2Yg dGhlbSBhcmUgY29tcGF0aWJsZSB3aXRoIG90aGVycy4mbmJzcDsmbmJzcDsgU29tZSBhcmUgbm90 Ljxicj4NCkl0IHdvdWxkIGJlIGdvb2QgaWYgd2UgY291bGQgcmVhY2ggYWdyZWVtZW50IG9uIGhv dyB3ZSB0aG91Z2h0IGl0IHNob3VsZCBiZSBoYW5kbGVkLjxicj4NCjxicj4NClRoYW5rIHlvdSw8 YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gOC80LzIwMjAgMzo1NCBBTSwgQWxleGFuZGVyIFZhaW5z aHRlaW4gd3JvdGU6PGJyPg0KJmd0OyBIaSBhbGwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYW0g c3RpbGwgbm90IHN1cmUgdGhhdCB0aGUgcHJvYmxlbSBvZiBieXBhc3MgZ29pbmcgdGhydSB1bmRl c2lyYWJsZSA8YnI+DQomZ3Q7IGxpbmtzL25vZGVzIGV4aXN0cyBpbiB0aGUgY2FzZSBvZiB0b3Bv bG9naWNhbCBTSURzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBRkFJSywgRmFjaWxpdHkgUHJvdGVj dGlvbiBpbiBSU1ZQLVRFIEZSUiAoUkZDIDQwOTA8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1E5MmtuRTlYSnVqcmY4Qms3b0p2czZIMj91PWh0 dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjNDA5MCI+aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNROTJrbkU5WEp1anJmOEJrN29KdnM2SDI/dT1odHRwcyUzQSUy RiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzQwOTA8L2E+Jmd0OykgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IGRlcGxveWVkDQo8YnI+DQomZ3Q7IGZvciBtYW55IHllYXJzIGJlZm9yZSBTUi1N UExTIGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTigJlzIG1vcmUsIDxicj4NCiZndDsgc2lnbmFs aW5nIG9mIGJ5cGFzcyB0dW5uZWxzIGhlIFBMUiB1c3VhbGx5IGRpZCBub3QgaW5jbHVkZSBhbnkg b2YgdGhlIDxicj4NCiZndDsgY29uc3RyYWludHMgdXNlZCBmb3IgY29tcHV0aW5nIG9mIGFueSBz cGVjaWZpYyBMU1AgdGhhdCB0aGUgYnlwYXNzIExTUCA8YnI+DQomZ3Q7IHdvdWxkIHByb3RlY3Qg 4oCTIGJlY2F1c2UgaW4gdGhlIEZhY2lsaXR5IFByb3RlY3Rpb24gbW9kZSB0aGUgc2FtZSA8YnI+ DQomZ3Q7IGJ5cGFzcyBMU1Agd291bGQgYmUgdXNlZCB0byBwcm90ZWN0IG11bHRpcGxlIExTUHMg cGFzc2luZyB0aHJ1IHRoZSA8YnI+DQomZ3Q7IGZhaWxlZCBsaW5rL25vZGUuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jm5ic3A7IEZyb20gbXkgUE9WIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiB0 aGlzIGJlaGF2aW9yIGFuZCB0aGF0IDxicj4NCiZndDsgaW50cm9kdWNlZCBieSB0aGUg4oCcYnlw YXNzaW5n4oCdIGRyYWZ0cyBpbiBTUiBpcyB0aGF0LCBpbiB0aGUgY2FzZSBvZiA8YnI+DQomZ3Q7 IFJTVlAtVEUsIHRoZSBvcGVyYXRvciB3b3VsZCBleHBsaWNpdGx5IGluZGljYXRlLCBhcyBwYXJ0 IG9mIExTUCA8YnI+DQomZ3Q7IHNpZ25hbGluZywgd2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBu b3QgdXNlIEZSUjsgTFNQcyB0aGF0IHdvdWxkIG5vdCA8YnI+DQomZ3Q7IHVzZSBGUlIgd291bGQg dGhlbiBkcm9wIHRyYWZmaWMgcmF0aGVyIHRoYW4gZGVsaXZlcmluZyBpdCB0aGUgd3Jvbmcgd2F5 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBTdWNoIGFuIG9wdGlvbiBpbmRlZWQgZG9lcyBub3QgZXhp c3QgaW4gU1ItVEUgdG9kYXksIGJ1dCB3b3VsZCBiZSBlYXN5IDxicj4NCiZndDsgdG8gcHJvdmlk ZSBpZiBzbyBkZXNpcmVkIElNSE8uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERpZCBJIG1pc3Mgc29t ZXRoaW5nIHN1YnN0YW50aWFsPzxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLCBhbmQgbG90 cyBvZiB0aGFua3MgaW4gYWR2YW5jZSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2FzaGE8YnI+DQom Z3Q7IDxicj4NCiZndDsgT2ZmaWNlOiArOTcyLTM5MjY2MzAyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IENlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICs5NzItNTQ5MjY2MzAyPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEVtYWlsOiZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7ICpPbiBCZWhhbGYgT2YgKlNocmFkZGhhIEhlZ2RlPGJyPg0KJmd0OyAqU2VudDoqIFR1 ZXNkYXksIEF1Z3VzdCA0LCAyMDIwIDk6NDEgQU08YnI+DQomZ3Q7ICpUbzoqIDxhIGhyZWY9Im1h aWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSI+RVhULUFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb208L2E+PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFu ZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb208L2E+Jmd0OzsgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEBy YXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KJmd0OyAqQ2M6KiA8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyBKb2VsIE0u IEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9l bGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQomZ3Q7ICpTdWJqZWN0OiogUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgPGJy Pg0KJmd0OyBBbGwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgaXMgYSB2ZXJ5IGludGVyZXN0 aW5nIGRpc2N1c3Npb24gYW5kIHRoYW5rcyB0byBKb2VsIGZvciBzdGFydGluZyA8YnI+DQomZ3Q7 IHRoaXMgZGlzY3Vzc2lvbi4gSU1PLCB3aGVuIHRoZXJlIGFyZSBzdHJpY3QgcmVxdWlyZW1lbnRz IG9mIGF2b2lkaW5nIDxicj4NCiZndDsgY2VydGFpbiBub2Rlcy9saW5rcyBpdCBjYW4gYmUgcmVh bGl6ZWQmbmJzcDsgZWl0aGVyIGJ5IGRlZmluaW5nIGEgZmxleC1hbGdvIDxicj4NCiZndDsgYXZv aWRpbmcgdGhvc2U8YnI+DQomZ3Q7IDxicj4NCiZndDsgTm9kZXMgYW5kIGxpbmtzIG9yIGJ5IHVz aW5nIGEgc3RhY2sgb2YgdW5wcm90ZWN0ZWQgYWRqLXNpZHMgdGhhdCBhdm9pZCA8YnI+DQomZ3Q7 IHJlc3RyaWN0ZWQgbm9kZXMgYW5kIGxpbmtzLiBXaGVuIGEgc3RhY2sgb2YgYWRqLXNpZHMgaXMg dXNlZCB0byA8YnI+DQomZ3Q7IHJlYWxpemUgdGhlIHBhdGgsIHRoZSBoZWFkLWVuZCBiYXNlZCAo c0JGRCkgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGNhbiBiZSBhcHBsaWVkLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBJZiBOb2RlLXNpZHMvcHJlZml4LXNpZC9hbnljYXN0LXNpZHMgYXJlIHVzZWQgdG8g YnVpbGQgdGhlIHN0YWNrLCB0aGUgPGJyPg0KJmd0OyBmYWlsdXJlIGV2ZW50cyBtYXkgY2F1c2Ug dHJhZmZpYyB0byBnbyB0aHJvdWdoIHJlc3RyaWN0ZWQgbm9kZXMgYW5kIDxicj4NCiZndDsgbGlu a3MuIFRoaXMgd291bGQgaGFwcGVuIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBhbnkga2luZCBvZiBw cm90ZWN0aW9uIDxicj4NCiZndDsgaXMgaW4gdXNlIG9yIG5vdC48YnI+DQomZ3Q7IDxicj4NCiZn dDsgUmdkczxicj4NCiZndDsgPGJyPg0KJmd0OyBTaHJhZGRoYTxicj4NCiZndDsgPGJyPg0KJmd0 OyBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpGcm9tOiog c3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMjAlMGIi PnNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0OyZndDsgKk9uIEJlaGFsZiBPZiAqQW5kcmV3IEFsc3Rvbjxicj4NCiZndDsgKlNl bnQ6KiBUdWVzZGF5LCBBdWd1c3QgNCwgMjAyMCA1OjQxIEFNPGJyPg0KJmd0OyAqVG86KiBSb2Jl cnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVy dEByYXN6dWsubmV0Ij5tYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyZndDs8YnI+DQom Z3Q7ICpDYzoqIDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdA aWV0Zi5vcmc8L2E+Jmd0OzsgSm9lbCBNLiBIYWxwZXJuDQo8YnI+DQomZ3Q7ICZsdDtqbWhAam9l bGhhbHBlcm4uY29tICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICpTdWJqZWN0Oiog UmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eTxicj4NCiZndDsgPGJyPg0KJmd0OyAqW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBj b250ZW50XSo8YnI+DQomZ3Q7IDxicj4NCiZndDsgUm9iZXJ0IHRoaXMgaXMgYWN0dWFsbHkgZmFy IG1vcmUgZGlmZmljdWx0IHdoZW4g4oCTIGl0IGNhbiBiZSBhbiBlbnRpcmU8YnI+DQomZ3Q7IChs b25nKSBzZXJpZXMgb2Ygbm9kZXMgdGhhdCBuZWVkIHRvIGJlIGF2b2lkZWQuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEl0IGNvdWxkIHBvdGVudGlhbGx5IGJlIG1hZGUgdG8gd29yayBidXQgSeKAmWQg d29ycnkgdGhhdCB0byBkbyB0aGlzIOKAkyA8YnI+DQomZ3Q7IHlvdeKAmWQgaGF2ZSB0byBzdGFj ayAxMCDigJMgMjAg4oCTIDMwIG5lZ2F0aXZlIGxhYmVscyDigJMgYW5kIHRoYXQgd291bGRu4oCZ dCA8YnI+DQomZ3Q7IGJlIHZpYWJsZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXTigJlzIGVhc2ll ciB0byB1c2UgYWxnb3JpdGhtcyBhbmQgYWRqYWNlbmN5IHNpZHMgYW5kIG90aGVyIHN1Y2ggdGhp bmdzIDxicj4NCiZndDsgdG8gY2FsY3VsYXRlIHBhdGhzIOKAkyB0aGUgYmlnZ2VzdCB0cmljayBp cyBhYm91dCB0aGUgc3RhY2sgZGVwdGguJm5ic3A7IFdoZW4gPGJyPg0KJmd0OyB5b3UgaGF2ZSB0 aGlzIG5lZWQgZm9yIG5vZGUgYXZvaWRhbmNlIOKAkyB0aGUgbmVlZCBmb3IgMTArIGxhYmVsIGRl cHRoIDxicj4NCiZndDsgaXMgY3JpdGljYWwg4oCTIHVubGVzcyB5b3Ugd2FubmEgYmUgYXBwbHlp bmcgb25lIGhlbGwgb2YgYSBsb3Qgb2YgPGJyPg0KJmd0OyBiaW5kaW5nIGxhYmVscyBhbG9uZyB0 aGUgd2F5IHdoaWNoIGlzIGEgbmlnaHRtYXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBCdXQgdG8g YW5zd2VyIHlvdXIgcXVlc3Rpb24sIGlzIHRoaXMgYSBjb21tb24gdXNlIGNhc2Ug4oCTIGl04oCZ cyBhIHVzZSA8YnI+DQomZ3Q7IGNhc2UgdGhhdCBtb3N0IG9mIHRoZSBwZW9wbGUgSSBkaXNjdXNz IHRoaXMgd2l0aCBjZXJ0YWluIGhhdmUg4oCTIEkgY2FudCA8YnI+DQomZ3Q7IGNvbW1lbnQgb24g YSBnbG9iYWwgc2NhbGUsIG9yIGZvciBhbnlvbmUgZWxzZSwgYnV0IGV2ZXJ5IGluZGljYXRpb24g SSA8YnI+DQomZ3Q7IGhhdmUgaXMgdGhhdCB5ZXMg4oCTIGl0cyBzb21ldGhpbmcgcGVvcGxlIG5l ZWQsIGFuZCB3YW50PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFuZHJldzxicj4NCiZndDsgPGJyPg0K Jmd0OyAqRnJvbToqIFJvYmVydCBSYXN6dWsgJmx0O3JvYmVydEByYXN6dWsubmV0ICZsdDs8YSBo cmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiPm1haWx0bzpyb2JlcnRAcmFzenVrLm5ldDwv YT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKlNlbnQ6KiBUdWVzZGF5LCA0IEF1Z3VzdCAyMDIwIDAxOjI3 PGJyPg0KJmd0OyAqVG86KiBBbmRyZXcgQWxzdG9uICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSUyMCUwYiI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbQ0KPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tIj5tYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bTwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKkNjOiogSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYiI+am1oQGpvZWxoYWxwZXJuLmNvbQ0K PGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5t YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyI+DQpzcHJpbmdAaWV0Zi5vcmc8L2E+IDxicj4NCiZndDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBk ZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElzIHRoaXMgYSBj b21tb24gdXNlIGNhc2UgaWUuJm5ic3A7ICZxdW90O2J1dCByYXRoZXIg4oCTIHdoaWNoIG5vZGVz IC8gbmV0d29yayA8YnI+DQomZ3Q7IHNlZ21lbnRzIGl0IGNhbiBuZXZlciB0b3VjaCBvciBmbG93 IHRocm91Z2guJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHNvIHBlcmhhcHMgaXRzIHRp bWUgdG8gZGVmaW5lIG5vdGlvbiBvZiAqbmVnYXRpdmUtU0lEKiBpZS4gbGlzdCBpbiA8YnI+DQom Z3Q7IHRoZSBwYWNrZXQgcmVzb3VyY2VzIHdoaWNoIGdpdmVuJm5ic3A7cGFja2V0IE1VU1Qgbm90 IGV2ZXIgdHJhdmVyc2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFB1dCBpbiB0aGUgcGFja2V0IHNl dCBvZiBub2RlcyBvciBsaW5rcyB3aGljaCB0aGUgcGFja2V0IHNob3VsZCBuZXZlciA8YnI+DQom Z3Q7IHRyYXZlcnNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IGdvZXMgaW4gbGluZSBvZiBy ZWNlbnQgd2F2ZSBvZiBuZWdhdGl2ZSByb3V0aW5nIGltcGxlbWVudGF0aW9uczxicj4NCiZndDsg KFJJRlQpIG9yIGRpc2N1c3Npb25zIChMU1IpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QsPGJy Pg0KJmd0OyBSLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDEx OjQ2IFBNIEFuZHJldyBBbHN0b24gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJl dy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGIiPkFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20NCjxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbSI+bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5j b208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFNvIOKAkzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBPbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2ZXJ5IG1ham9yIHVzZSBj YXNlcyBpbiBhbnk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwcmluZyB0ZWNo bm9sb2d5IGZvciB1cyByZXZvbHZlIGFyb3VuZCB0aGUgZm9sbG93aW5nPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEuVGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBv ZiBjZXJ0YWluIG5vZGVzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGIuVGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIHNlY3Rpb25zIG9mIHRoZSBu ZXR3b3JrPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFueXRo aW5nIHRoYXQgY291bGQgcmVzdWx0IGluIHRoYXQgZXhwbGljaXQgYXZvaWRhbmNlIGJlaW5nIHZp b2xhdGVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJMgd291bGQgY3JlYXRl LCBzaGFsbCB3ZSBzYXkgc2lnbmlmaWNhbnQgcHJvYmxlbXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE11Y2ggb2YgdGhlIHVzZSBjYXNlIGlzIG5vdCBhIGNh c2Ugb2Ygd2hpY2ggbm9kZXMgdGhlIHBhY2tldHMgZmxvdzxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhyb3VnaCDigJMgYnV0IHJhdGhlciDigJMgd2hpY2ggbm9kZXMgLyBuZXR3 b3JrIHNlZ21lbnRzIGl0IGNhbiBuZXZlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdG91Y2ggb3IgZmxvdyB0aHJvdWdoLiZuYnNwOyBFZmZlY3RpdmVseSwgdG8gYmUgdXNlZCBh cyBhIHRlY2hub2xvZ3kgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF2b2lk IGNlcnRhaW4gdGhpbmdzIGZvciBzcGVjaWZpYyByZWFzb25zLjxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIGFsc28gb25lIG9mIHRoZSByZWFzb25z IGZvciBuZWVkaW5nIHN1Y2ggZGVlcCBsYWJlbCBzdGFja3Mg4oCTPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgcGF0aCBwcm9ncmFtbWluZyB0 ZW5kcyB0byBkZWVwZW4gdGhlIHN0YWNrPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBiZWNhdXNlIHlvdSBzb21ldGltZXMgaGF2ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIGFic29sdXRlbHkg Y3JpdGljYWwgdG8gdXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUg4oCTPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgdGhhdCB3ZSBjYW4gYXZvaWQgc2l0dWF0 aW9ucyB3aGljaCBjb3VsZCBjYXVzZSB0cmFmZmljIHRvPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhwbGljaXRseSBhdm9pZGVkLjxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIHdpc2ggSSBjb3VsZCBi ZSBtb3JlIHNwZWNpZmljIHRoYW4gdGhpcywgYnV0IGl0IGlzIHdoYXQgaXQgaXMuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rczxicj4NCiZndDsgPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbmRyZXc8YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKkZyb206KiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8 YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyZndDsgKk9uIEJlaGFsZiBPZiAqSm9lbCBNLiBIYWxwZXJuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAqU2VudDoqIE1vbmRheSwgMyBBdWd1c3QgMjAyMCAyMTozNjxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlRvOiogUm9iZXJ0IFJhc3p1ayAmbHQ7 cm9iZXJ0QHJhc3p1ay5uZXQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+ bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYuLm9yZyI+c3By aW5nQGlldGYuLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1p bmluZyA8YnI+DQomZ3Q7IGFwcGxpY2FiaWxpdHk8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgKFNpbmNlIHRoZSB0aHJlYWQgaGFzIGdvdHRlbiBsb25nIGVub3Vn aCwgcmVpdGVyYXRpbmcgdGhhdCB0aGlzIGlzIGFzIGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHBhcnRpY2lwYW50LCBub3QgYSBXRyBjaGFpci4pPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFllcywgd2UgYXJlIHRhbGtpbmcgSVAgbmV0d29y a3MuIEFuZCB5ZXMsIEkgaGF2ZSBzZWVuIElQIG5ldHdvcmtzIHRoYXQ8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNob29zZSB0byBkcm9wIHBhY2tldHMuIEZvciBhbGwgc29ydHMg b2YgcmVhc29ucy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhl cmUgYXJlIGxpa2VseSBvdGhlciByZWFzb25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9t PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXRoIHJhdGhlciB0aGFuIGEgY2hv c2VuIFRFIHBhdGguIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHdlIGJlIGNsZWFyPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhYm91dCB3aGF0IGNvbnN0cmFpbnRzIG1heSBiZSAv IGFyZSB2aW9sYXRlZCB3aGVuIHdlIHRlbGwgcGVvcGxlIHRoZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGhhdmUgdGhpcyB0b29sIChwcm90ZWN0aXZlIHJlcm91dGluZykgdGhh dCBpcyBpbnRlbmRlZCB0byBwcmVzZXJ2ZSBRb1MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IExldCdzIGJlIGNsZWFyLiBJIGFtIG5vdCBhcmd1aW5nIHRoYXQg dGhpcyBpcyBub3QgYSBnb29kIGlkZWEuIEl0IGlzIGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGdvb2QgaWRlYS4gQW5kIHVzZWZ1bC4gSSBhbSB0cnlpbmcgdG8gZmlndXJlIG90 dSB3aGF0IGNvbWJpbmF0aW9uIG9mPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh ZGRpdGlvbmFsIG1lY2hhbmlzbXMgYW5kIGNsZWFyIGRlc2NyaXB0aW9ucyB3aWxsIGxlYWQgdG8g ZXZlcnlvbmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdldHRpbmcgdGhlIGJl aGF2aW9yIHRoZXkgZXhwZWN0ICh3aGljaCBtYXkgbm90IGJlIHRoZSBiZWhhdmlvciB0aGV5PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNpcmUsIGJ1dCBzb21ldGltZXMgaXMg dGhlIGJlc3Qgd2UgY2FuIGRvLik8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgWW91cnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKb2VsPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIDgvMy8yMDIwIDI6 MzAgUE0sIFJvYmVydCBSYXN6dWsgd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IEpvZWwsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEFy ZSB3ZSBzdGlsbCB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtzJm5ic3A7aGVyZSA/IE9yIHBlcmhh cHMgc29tZSBoYXJkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IHNsaWNpbmcgd2l0aCByZWFsIHJlc291cmNlIHJlc2VydmF0aW9ucyBvciBkZXRuZXRzID88YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQmVjYXVzZSZuYnNwO2lmIHdlIGFyZSB0YWxr aW5nJm5ic3A7YWJvdXQgSVAgbmV0d29ya2luZyBJIGhhdmUgdHdvPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBvYnNlcnZhdGlvbnM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IEEpIElmIHlvdSBuZWVkIHRvIHRyYXZlcnNlIHZpYSBhIHNwZWNpZmljIG5vZGUgKGll LiBmaXJld2FsbCkgeW91PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZXR0ZXI8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYXBwbHkgSVAgZW5j YXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuLiBJIGRvbid0IHRoaW5rIElQPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBlbmNhcHN1bGF0aW9uJm5ic3A7Y2FuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGJlIGhpamFja2VkIHRvZGF5IHN1Y2ggdGhh dCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXM8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGlnbm9yZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IEIpIEhhdmUgeW91IHNlZW4gYW55IElQIG5ldHdvcmsgd2hlcmUgdXBvbiB0b3BvbG9neSBjaGFu Z2UgKGxpbms8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIG5vZGU8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgZmFpbHVyZSkgeW91IHN1ZGRl bmx5Jm5ic3A7c3RhcnQgZHJvcHBpbmcmbmJzcDtmbG93cyBpbiBzcGl0ZSBvZiBTUFQgb2ZmZXJp bmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcGVyaGFwcyBm ZXcgbXMgbG9uZ2VyIHBhdGggd2l0aCAxMCBtcyBtb3JlIGppdHRlciA/PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IE9yIGFyZSBzb21lIFNSIG1hcmtldGluZyBzbGlkZXMgcHJvbWlz ZSB0byB0dXJuIElQIG5ldHdvcmtzIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IHNvbWV0aGluZyZuYnNwO25ldyA/IFdvcnNlIC4uLiBkbyB0aGV5IG1lbnRp b24gcGF0aCBxdWFsaXR5IGd1YXJhbnRlZXMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IHJlc291cmNlIHJlc2VydmF0aW9ucyZuYnNwOz8gSSBob3BlIG5vdC48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgVGh4LDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBSLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDg6MTAgUE0gSm9l bCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYiI+ am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYiI+bWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20lMjAlMGI8L2E+Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgV2VsbCBsZXNzIHNlcmlv dXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90IHN1cmUgdGhlIHByb2JsZW0gaXM8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3RyaWN0ZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG8ganVzdCBzZXJ2aWNlIFNJRHMuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IFN1cHBvc2UgdGhhdCB0aGUgUENFIGhhcyBzcGVjaWZpZWQgdGhl IHBhdGggdG8gbWVldCBzb21lIGNvbXBsZXggdGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgb2JqZWN0aXZlLiZuYnNwOyBUaGUgYnlwYXNzIG5vZGUgaGFzIG5v IHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2U8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgY29uc3RyYWludHM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgd2VyZS4mbmJzcDsgQW5kIGZvciBzb21lIGtpbmRzIG9mIHRyYWZmaWMs IGl0IGlzIGJldHRlciB0byBkcm9wIHRoZSBwYWNrZXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhhbiB0byBkZWxpdmVyIGl0IG91dHNpZGUgdGhlIGVudmVs b3AuJm5ic3A7IEkgc3VzcGVjdCB0aGF0IHRoZSByaWdodDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhbnN3ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgdG8gdGhpcyBpcyAmcXVvdDt0b28gYmFkJnF1b3Q7LiZuYnNwOyBJ ZiBzbywgYXMgd2l0aCB0aGUgZGlzdGluY3Rpb24gcmVnYXJkaW5nPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IG5vZGVzLCB3ZSBzaG91bGQgc2F5IHNvLCBzaG91bGRuJ3Qgd2U/PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFlvdXJzLDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBKb2VsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IE9uIDgvMy8yMDIwIDI6MzYgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOjxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IE1hY2gsIEpvZWwg YW5kIGFsbCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEkgdGhp bmsgdGhhdCBpbiBtb3N0IGNhc2VzOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsgMS5UaGVyZSBpcyBjbGVhciBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiAmcXVvdDt0 b3BvbG9naWNhbCZxdW90OyBhbmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O3NlcnZpY2UmcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyBpbnN0cnVjdGlvbnMgaW4gU0lEIGFkdmVydGlzZW1lbnRzLiBFLmcuOjxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgb0lHUCBQcmVmaXggTm9kZSBT SURzIElHUCBBZGotU0lEcyAoaWRlbnRpZmllZCBhcyBzdWNoIGluIHRoZTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGNvcnJlc3BvbmRpbmcgSUdQIGFk dmVydGlzZW1lbnRzKSByZXByZXNlbnQgdG9wb2xvZ2ljYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGluc3RydWN0aW9uczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgb1NlcnZpY2UgU0lEcyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92 ZXJsYXkgU2VydmljZXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zQ0NjeTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNy djYtc2VydmljZXMtMDQlMGIiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ0NjeTlt WTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQ8YnI+DQo8L2E+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNHQzVhZjJ6M0p6cGhaRGtQbmNIQVFpNkgyP3U9aHR0cHMlM0ElMkYl MkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0X18lM0IlMjEl MjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2 cFJIT0d0OEFrVFJEdWlEbzRULUwwbmwlMjQiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zR0M1YWYyejNKenBoWkRrUG5jSEFRaTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5j b20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwl MkZkcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNF9fJTNCJTIxJTIxTkV0NnlNYU8tZ2sl MjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVp RG80VC1MMG5sJTI0PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsgZHJhZnQpIHVuc3VycHJpc2luZ2x5IHJlcHJlc2VudCDigJxzZXJ2aWNl4oCdIGluc3Ry dWN0aW9uczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgMi5TZWdt ZW50cyB0aGF0IHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5cGFz c2VkLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHdo aWxlIHNlZ21lbnRzIHRoYXQgcmVwcmVzZW50IHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHJlcXVpcmU8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYWx0ZXJuYXRpdmU8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBwcm90ZWN0 aW9uIG1lY2hhbmlzbXMuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyBUaGlzIHZpZXcgc2VlbXMgdG8gYmUgYWxpZ25lZCB3aXRoIFJGQyA4NDAyPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNDVOTENCNlR5ZHh1dXFVanRjRFJaeTZIMj91PWh0 dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjODQwMiUwYiI+aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM0NU5MQ0I2VHlkeHV1cVVqdGNEUlp5NkgyP3U9aHR0cHMl M0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyPGJyPg0KPC9hPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zN1B6VUtBRDgyY2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVm ZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4 NDAyX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3 eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJNFlidG0lMjQiPmh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zN1B6VUtBRDgyY2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNBJTJGJTJG dXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwl MkZyZmM4NDAyX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4 Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJNFlidG0lMjQ8L2E+Jmd0OyZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgc2F5cyBpbiBTZWN0aW9uIDE6 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsm bmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wg cGxhbmUsIHR3bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgdG9w b2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNlZ21lbnQg YW5kIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IElHUC1QcmVmaXggc2VnbWVudC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBJbiB0aGUgY29udGV4dCBvZiBh IEJHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZp bmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBhbmQgdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgQkdQLVByZWZpeCBzZWdt ZW50Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSW4gdGhlIGNh c2Ugb2YgU1ItTVBMUyB0aGlzIGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb248 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgMy40IG9mPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgdGhlIE5vZGUgUHJv dGVjdGlvbiBmb3IgU1ItVEUgUGF0aDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFmTlBzWmRocEV4eHg5NkgyP3U9aHR0 cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdk ZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rpb24tMy40 JTBiIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0piU1dHeDVEQWZOUHNaZGhwRXh4 eDk2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUy RmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3JTIz c2VjdGlvbi0zLjQ8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNDclVnQVJXOHNvbUFidzZUaXNq Z0oxNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUy RmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1u b2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3JTJBc2VjdGlvbi0zLjRfXyUzQkl3JTIx JTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2 dnBSSE9HdDhBa1RSRHVpRG85d08tU3NuJTI0Ij5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vM0NyVWdBUlc4c29tQWJ3NlRpc2pnSjE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2Uu Y29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1s JTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDcl MkFzZWN0aW9uLTMuNF9fJTNCSXclMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFv aVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzl3Ty1Tc24lMjQ8L2E+Jmd0 OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBkcmFmdCB0aGF0IHNh eXM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgVGhlIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoZSBw cmV2aW91czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VjdGlvbnM8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBk ZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVsIGltbWVkaWF0ZWx5IGJlbG93 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRoZSB0b3A8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGxhYmVsIGluIHRoZSBsYWJl bCBzdGFjayBpcyB1bmRlcnN0b29kIGluIHRoZSBJR1AgZG9tYWluLiZuYnNwOyBXaGVuIHRoZTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5i c3A7IHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBleGNoYW5nZSBzZXJ2aWNlIGxhYmVscyB2aWEgQkdQ IG9yIHNvbWU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgb3Ro ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyZuYnNwOyBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90dG9tIGxhYmVsIGlzIG5vdCB1bmRlcnN0 b29kIGluIHRoZSBJR1A8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyZuYnNwOyBkb21haW4uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgVGhlIGVncmVzcyBub2RlIHByb3RlY3Rp b24gbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgW1JGQzg2NzkgJmx0Ozxh IGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zSmZ2dEJBbWFRUE4xakEzcE02 VGRDRTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1s JTJGcmZjODY3OSUwYiI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQ TjFqQTNwTTZUZENFNkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZyZmM4Njc5PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmRNQWp1WVRRb3Zv OGpId21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0 cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5X18lM0Il MjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3 cDZ2cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS8zNmRNQWp1WVRRb3ZvOGpId21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5z ZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0 bWwlMkZyZmM4Njc5X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFB dFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQ8L2E+Jmd0OyZn dDtdPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpczxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGFwcGxpY2FibGUgdG8gdGhpcyB1c2Ug Y2FzZSBhbmQgbm8gYWRkaXRpb25hbCBjaGFuZ2VzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgd2lsbCBiZSByZXF1aXJlZCBmb3Ig U1IgYmFzZWQgbmV0d29ya3M8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7IFRoZSBzY2VuYXJpb3MgaW4gd2hpY2ggJm5ic3A7ZGlmZmVyZW50aWF0aW9uIGJldHdlZW4g 4oCcdG9wb2xvZ2ljYWzigJ0gYW5kPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsg4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnMgaXMgYnJva2VuIGFyZSBp bmRlZWQgcHJvYmxlbWF0aWMuIEUuZy4sPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IGNvbnNpZGVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsgdGhlIHVzZSBjYXNlIGluIHdoaWNoIGEgTm9kZSBTSUQgaW4gdGhlIEVS TyBvZiBhIFNSLVRFIHBhdGg8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgaWRlbnRpZmllcyBhPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgbm9kZSB0aGF0IGFjdHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMg aXQgcmVjZWl2ZXMsIGkuZS4sPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IHByb3ZpZGVzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsgdGhlIGZpcmV3YWxsIHNlcnZpY2Ugd2l0aG91dCBhbnkgZGVkaWNhdGVkIHNlcnZp Y2UgU0lEPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGlkZW50 aWZ5aW5nIGl0Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7IE9uZSBjb3VsZCBzYXkgdGhhdCB0aGUgTm9kZSBTSUQgb2Ygc3VjaCBhIG5vZGUgd291bGQg Y29tYmluZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0b3Bv bG9naWNhbDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 IGFuZCBzZXJ2aWNlIGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRp b248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYmV0d2VlbiB0 aGUgdHdvLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSBhbSBu b3Qgc3VyZSBpZiB1c2FnZSBvZiBzdWNoIOKAnGNvbWJpbmVk4oCdIFNJRHMgY291bGQgYmUgcHJl dmVudGVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IG9yIGF0 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgbGVhc3Qg ZGlzY291cmFnZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBJ ZiBub3QsIHByb3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50aWZ5IHN1Y2ggU0lEcyBpbiB0aGU8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYWR2ZXJ0aXNlbWVu dDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IG1lY2hh bmlzbXMgd291bGQgYmUgdXNlZnVsIElNSE8uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyBNeSAyYyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IFNhc2hhPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBP ZmZpY2U6ICs5NzItMzkyNjYzMDI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IENlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICs5NzItNTQ5MjY2MzAy PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBFbWFpbDogPGEgaHJl Zj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iPm1h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iPm1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEZyb206IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzxi cj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIiPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y ZyUwYjwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7IE9uIEJlaGFsZiBPZiBNYWNoIENoZW48YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBTZW50OiBNb25kYXksIEF1 Z3VzdCAzLCAyMDIwIDY6MzAgQU08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSUwYiI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSUwYiI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMGI8L2E+Jmd0OyZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5tYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbTwvYT4mZ3Q7Jmd0Ozs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsgU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5p bmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgSGkgSm9lbCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEkg dGhpbmsgdGhpcyBpcyBhIGdvb2QgcG9pbnQgdGhhdCBtYXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0 aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcGFzdC4gQW5k PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSBhbHNv IGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgJnF1b3Q7Y2FuIGJlIGJ5cGFzc2VkJnF1b3Q7IGluZGlj YXRpb24gaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsgcm91dGluZyBhZHZlcnRpc2VtZW50IGZvciBub3cuPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBJTUhPLCB0aGUgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBi eSByb3V0aW5nIGlzIG5ldXRyYWwsIHN1Y2g8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgaW5mb3JtYXRpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyAoY2FuIG9yIGNhbm5vdCBiZSBieXBhc3NlZCkgaXMgbW9yZSBw YXRoIHNwZWNpZmljLCB0aHVzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub3Jt YWxseSB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyBjb250cm9sbGVyIHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93 aGljaCBTSUQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgY2Fu IGJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgYnlw YXNzZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBCZXN0IHJl Z2FyZHMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBNYWNoPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmZ3Q7IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiJTNlJTIwJTNjbWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTNlIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmclMGIlM2UlMjAlM2NtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclM2U8L2E+Jmd0 O108YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIEJlaGFsZiBPZiBKb2VsIE0u PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IEhh bHBlcm48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA3OjUxIEFNPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiIj5tYWlsdG86c3ByaW5nQGlldGYub3Jn ICZsdDttYWlsdG86c3ByaW5nQGlldGYub3JnPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmlu Z0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgU3ViamVjdDogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rp b24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IChXRyBDaGFpciBoYXQgT2ZmLCB0aGlzIGlzIG1lcmVs eSBhIG5vdGUgZnJvbSBhIHNsaWdodGx5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IGNvbmZ1c2VkIFdHPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IHBhcnRpY2lwYW50Lik8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSSBoYXZlIGJlZW4gcmVhZGluZyB0aGUgdmFy aW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgbmV0d29ya3MgcHJvZ3JhbW1pbmcgYW5k IHNlcnZpY2UgcHJvZ3JhbW1pbmcgZHJhZnQsIGFuZCBJIGFtPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRyeWluZyB0bzxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBmaWd1cmUgb3V0IG9uZSBhc3BlY3Qgb2Yg dGhlIGNvbWJpbmF0aW9uLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJmd0OyBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2YgYnlw YXNzIChzdXBwb3NlLCBmb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgc2ltcGxpY2l0eSwgaXQgaXMgTm9kZSBOMiBkZWNpZGluZyB0byBieXBh c3MgdGhlIG5leHQgU0lEIGZvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBhIGZhaWxlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0OyBub2RlIE4zKSBrbm93IHRoYXQgaXQgaXMgc2FmZSB0byBkbyBzbz88YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSWYgdGhlIHBh dGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0IGlzICZxdW90O3NhZmUmcXVvdDsgaWYgdGhlIG5l dyBwYXRoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IG1lZXRz PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IHRo ZSBURSBjcml0ZXJpYS4mbmJzcDsgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBpdCBpcyBldmVuIGNs b3NlLCBhczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBsb25n IGFzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7 IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgQnV0IHdoYXQgaWYgdGhlIG5vZGUgd2VyZSBhIEZpcmV3 YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPzxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBPciB3YXMgc29tZSBvdGhlciBuZWNlc3Nh cnkgcHJvZ3JhbW1hdGljIHRyYW5zZm9ybSAod2luY2Ugd2UgYXJlPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IGRlbGliZXJhdGVseSB2YWd1ZSBh Ym91dCB3aGF0IG5vZGVzIGNhbiBkbyB3aGVuIGFza2VkIHN1aXRhYmx5Lik8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSXMgdGhlcmUgc29tZSAmcXVv dDtjYW4gYmUgYnlwYXNzZWQmcXVvdDsgaW5kaWNhdGlvbiBpbiB0aGUgcm91dGluZzxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBhZHZlcnRpc2Vt ZW50cyB0aGF0IEkgbWlzc2VkPzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0OyBUaGFuayB5b3UsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IFlvdXJzLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBKb2VsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRv OnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFp bHRvOnNwcmluZ0BpZXRmLm9yZyUwYiI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyAmbHQ7bWFpbHRv OnNwcmluZ0BpZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8 L2E+Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MiI+DQpo dHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/ dT1odHRwcyUzQSUyPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Ozxh IGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTd2WDJxV1NVZFdWYzg5Mlh1 WHkySDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0El MkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1 JTNEaHR0cHMlMkEzQSUyQTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4 RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNkh3UExpbCUyNCI+ aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRN3ZYMnFXU1VkV1ZjODkyWHVYeTJINkgy P3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNr dGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRw cyUyQTNBJTJBMl9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lR QXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG82SHdQTGlsJTI0PC9hPiZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MiUwYiI+aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMl M0ElMjUyPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9 Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQTVCOEgyRm0xclBuYVozU3VwandyNkgy P3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNr dGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRw cyUyQTNBJTJBMjUyX18lM0JKU1UlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFv aVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEb3pvUWlBSGslMjQiPmh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQTVCOEgyRm0xclBuYVozU3VwandyNkgyP3U9aHR0 cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5z eW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNB JTJBMjUyX18lM0JKU1UlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4 Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEb3pvUWlBSGslMjQ8L2E+Jmd0OyZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgRiUy Rnd3dy5pZXRmLm9yZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhy ZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRH QjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJG d3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFB dFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQiPmh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0dHBz JTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYub3Jn X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFn dW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQ8L2E+Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNHV1Q5ZnlqYUZpM0ZjdkhEdm9vZHZTNkgyP3U9aHR0cCUzQSUy RiUyRjJGd3d3LmlldGYub3JnJTBiIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dX VDlmeWphRmkzRmN2SER2b29kdlM2SDI/dT1odHRwJTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmc8YnI+ DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdf XyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1 b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLXBQQ2p2UiUyNCI+aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxk ZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5F dDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhP R3Q4QWtUUkR1aURvLXBQQ2p2UiUyNDwvYT4mZ3Q7Jmd0OyUyRm1haWxtYW4lMkZsaXN0aW5mbyUy RnNwcmluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyUwYiI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiIj5t YWlsdG86c3ByaW5nQGlldGYub3JnJTBiPC9hPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5 dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzcHJpbmciPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRL aVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNCaHlFdHg0UTdu NzRCaGlSbmZNSnRUNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19o dHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQ NDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMkYlMkEyRnd3dy5pZXRmLm9yZyUyQTJGbWFpbG1hbiUy QTJGbGlzdGluZm8lMkEyRnNwcmluZ19fJTNCSlNVbEpTVWwlMjElMjFORXQ2eU1hTy1nayUyMVMw WXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1o UjNnQUQlMjQiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQmh5RXR4NFE3bjc0Qmhp Um5mTUp0VDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIl M0Z1JTNEaHR0cHMlMkEzQSUyQTJGJTJBMkZ3d3cuaWV0Zi5vcmclMkEyRm1haWxtYW4lMkEyRmxp c3RpbmZvJTJBMkZzcHJpbmdfXyUzQkpTVWxKU1VsJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5 RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8taFIzZ0FE JTI0PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsgTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRh Y2htZW50cyBtYXkgY29udGFpbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRo YXQgaXMgY29uZmlkZW50aWFsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IGFuZC9vcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lw aWVudC4gQW55IHJldmlldyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJz IG9yIGZvcndhcmRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGhvdXQ8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBleHByZXNz IHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGludGVuZGVkPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGNvcGllcywg aW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFM cTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c3ByaW5nIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lW UEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGc3ByaW5nPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Ozxh IGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJW R0VxMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0El MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5F dDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhP R3Q4QWtUUkR1aURvNUtsUG5iaiUyNCI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNO ckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUy RnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgw d3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0PC9hPiZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBzcHJp bmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5v cmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+bWFpbHRvOnNw cmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tH eU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGc3ByaW5nIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z UTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJE blNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2 MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJp bmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4 cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyNCI+aHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1 cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThF X1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0PC9h PiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmdAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmci Pg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxx NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz cHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7ICZs dDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFH NzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyNSUwYiI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElPGJyPg0KPC9hPiZndDsg MkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1h aWxtYW4lMkZsaXN0aTxicj4NCiZndDsgbmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1n ayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndTxicj4NCiZndDsgb1pIZ3dwNnZw UkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyNCZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBOb3Rp Y2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWlu IDxicj4NCiZndDsgaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRpb25zIEluYy4gdGhh dCBpcyBjb25maWRlbnRpYWwgYW5kL29yIDxicj4NCiZndDsgcHJvcHJpZXRhcnkgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCA8YnI+DQomZ3Q7 IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2Fy ZGluZyB3aXRob3V0IDxicj4NCiZndDsgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCA8YnI+DQomZ3Q7IHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBh bGwgPGJyPg0KJmd0OyBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuPGJyPg0KJmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAtLTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5K Q0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZs aXN0aW5mbyUyRnNwcmluZyI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5 TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFM cTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c3ByaW5nIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBC eWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRnNwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPk5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRpb25z IEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwgYW5kL29yIHByb3ByaWV0YXJ5IGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkDQogcmVjaXBpZW50LiBBbnkgcmV2aWV3LCBkaXNjbG9zdXJl LCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91 dCBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwgY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGhyIHNp emU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW3PR11MB4570615B3050B500C456C99EC1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 06:33:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D443A0BFA for ; Fri, 14 Aug 2020 06:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YdOghNxr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qYPxtnC1 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 uKuR79frJuCZ for ; Fri, 14 Aug 2020 06:33:24 -0700 (PDT) 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 40D4C3A0BF9 for ; Fri, 14 Aug 2020 06:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7830; q=dns/txt; s=iport; t=1597412004; x=1598621604; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CO1VXjDMDAyIsusnWsBavKUpTRuk2xD6wgHmfAmg4RM=; b=YdOghNxryP3ljicqbCZWnr6h2jZrcE9RnBLz9bMywlLXCSZmmUohu68F m65akt6dACnQ289uUIXtQ6pKJ15TkSoETcu5xHg0jLlXBv8wuB3XkSkoz KuVxmBsLY17s3xgpx2/bUr2UGbiQoXOONrOzu7E2hAPir7+vZBAbMhwks 0=; IronPort-PHdr: =?us-ascii?q?9a23=3Ab3x6Ph338hq1orQusmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGtadvkVnIRYjBrfRJl7mev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtXBcD/f1DI5Hu/8W1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiCQDOkTZf/5NdJa1fHgEBCxIMQIJ?= =?us-ascii?q?tL1EHcA5KLywKh3MDjVuTeoRtglMDVQsBAQEMAQEjCgIEAQGETAKCRwIkOBM?= =?us-ascii?q?CAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEBAxIbEwEBNwEPAgEIEQQBAS8yHQg?= =?us-ascii?q?BAQQBDQUIGoMFgX5NAy4BDqdNAoE5iGF0gTSDAQEBBYE3AoNzGIIOAwaBOIJ?= =?us-ascii?q?xhhuEDhqBQT+BEUOCTT6CXAEBA4Feg0iCLZlknE4KgmKIY5Fdgn+JW5NFhWm?= =?us-ascii?q?MT4pClHoCBAIEBQIOAQEFgWojgVdwFYMkUBcCDY4fT4MihRSFCQE4dDcCBgo?= =?us-ascii?q?BAQMJfI8xAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,312,1592870400"; d="scan'208,217";a="793211662" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 13:33:21 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EDXL4A014857 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 13:33:21 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 08:33:21 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 09:33:20 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 08:33:20 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KxkEXD0ZeQ6tlyTYaGoRpNl5Js3mghXO9TV7JVHi4Fou3Ac2kLux4hzVsRpxZ14QNwO4pbkVRHgkFK6LDxugNt2f/7QgNwLlGRptKNwy1kWuGi1DkmwvVEJnBTim2BxRJyt2VW2+qtLCGXBovTqI9xnKItnRrjHVVOzT+H19PZ+ysMUsWch4B8+lCvDNrgBKLa+B6GaY+WBMYeQOm0DPIzfA0VoQ+YViMgU3/iY6PtTLz5PCNyuM8TNd7ZC7R2Dr7cGm1tHRS6j4D3cN5rkKHJZdOTErMiiLa4brk3XMGDUTcV17D47/oMa2V/E2wpF5izpofMZJ7ZX6BxnzxQWdog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kvCNE7akS4iuxKhSxNfHL05UprruZWGCezR5ADHQA8E=; b=HZHKdzqqmZLJ+ErsA+4yL2E22VykCtJKbxaR61QuS0UYWhh9PXIWhrlgQQBloo0DKQEg5EdTZ16Gi4W34ekYpofbw15C/ikSdgfZI5N2A/YkZ/s8ng1a6CQltAM9xoBwhNP0IMBlCXiUdGqqlbGhk41VYMRWKEtHlB2r3GTzTLsVob2wHn9q2VLtd/6IqPeDGJW3rlPnSBXlMt1dBZJyTuyShbNVNoJc3/LFCvrnh/azwTjP0/BV8mSmR8s4a6RIn5RfX0oUVKuW31687111tqesQhOCWeHb5j+ZcasvLYKYYEY/kKe6Pq3yQowjVO6/rhAvLDuEVJbijYy5cMQ08w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kvCNE7akS4iuxKhSxNfHL05UprruZWGCezR5ADHQA8E=; b=qYPxtnC1ycR17NBJF6Inx7Wi+YKK4C+Bmwq+9kJqOQ+t/rqCQpAB54WNcvPvtAICUQjfbCucZhp2/0AIfGWo27V5plMUqFJVV7k6UxWEtJqW6WXKGyMCaD3l7KQgUx32IBGrJMVSAIpSPxovlE6wMNnv6I2X4VpTplbafkuNBTA= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4649.namprd11.prod.outlook.com (2603:10b6:303:5b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 13:33:16 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 13:33:16 +0000 From: "Ketan Talaulikar (ketant)" To: Rajesh M , "Peter Psenak (ppsenak)" , Shraddha Hegde , "Clarence Filsfils (cfilsfil)" , "Gulko, Arkadiy (Refinitiv)" CC: SPRING WG Thread-Topic: https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-08 (OSPFv2 flex algo) Thread-Index: AdZsb7FCx7n0n1puTvue8MZUiX5E5wFznPsQ Date: Fri, 14 Aug 2020 13:33:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-07T04:02:14Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5bb61b8a-4a8c-4987-a07c-88fa32413e16; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5f03f20-c31d-43f0-cd19-08d840569a17 x-ms-traffictypediagnostic: MW3PR11MB4649: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a0K8qvgXcl7UmbrVuEoopprFhGvKt9tAM0d7FW4ORcq8yUa8CZnIZdRSILDS71qJ/jAkApu5yPZtg31Qa76U/0C3OtzK5CTp40S61dpbJlVT5NdDmmWzs4bb0cGD8FmxulHUZ7105i4U/10fwIN3FXvbDf8FnskCoGEoImMRs0WiN5Kx96tSSDoR+v/2QzraQ8Lu2faCEvglAGnXjQXhwjXMA/yRGiFeYd5gf6y6KNl27UCgnrqzFoPEIKEwN8v83fi4jLhj5oZU0uSDuTeqPdj0RI6QLNOeLEx7ZORqK7f47rrEnS2paFwGm6rr0cS5NarS+YhVHUlusiqvhhsIxxo4yBih4BwvMDBzk7Atur8fRa6bz8ocg+4xI1sscXFal2rKLbgTWXgAHnYsF8ghCA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(396003)(136003)(366004)(66446008)(6506007)(7696005)(4326008)(76116006)(53546011)(9326002)(33656002)(8936002)(186003)(26005)(52536014)(66946007)(5660300002)(66556008)(66476007)(9686003)(71200400001)(2906002)(110136005)(316002)(86362001)(55016002)(966005)(478600001)(8676002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: kAF/8/HcRjKoJZCUzcZbpYEM+gak+F0D0pcwIrM3osMjJJskrJppYl02cwS2uETWC0Bh0J3Nq4hBFL8Qr6lIguNIP5Tc3uIqFlfNX6G+l2/UjuOU/VlvXIq4EqvirwszBU3of++zx6mNldctHffB+At5xLJRmB4AicSAlibSmsPBO9tPGVSHqgwaHn5l4Yvq864ThhzWKMIEakoD0tG8daQkav4UiVZozUY7Du8jxJvGIamZ6MHHEvBv+LMs5kCG53w4hnUfpZPS446RfuKh4RAL3xv8VdcywWwFdItVa7RF95hlj25Fggr+DSP8UQx2iNEkUVpWNZBoUzs9pz4QMJ6UBxyXvpGpiJX8CQtkNByTL6PyqiwJidKFq+obng7BX39oRtMHrI0VbhWHUV2iMNBE8zRp6ah4QhTDdlNoW0ZaqQ+jHJNc+prcha2K11TdqYSpvaul8p/9BjDw1EL/yY4lAO2KFWwo7srnVXVOuHEo2wRG+LB5PqK1OwkfhFvv8HTOGYgvMAQTEoPiEDEKhFwz7XbQnRR8EGxMyKkgr8vnnJWFTNm9EugR+m7Le82qgKQhr8pfM7EeeX8I9pCpgjgVqtY8IVq9bNUBGFXGmpPYFa8OZw4YOjhkU3IYhwVV+eq+VkMovpAAs8ftO0qlbQ== Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570B68DEC57442209E908C7C1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5f03f20-c31d-43f0-cd19-08d840569a17 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 13:33:16.7814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Et+MAiC84v9g/csQfkTLMM1PQHKbq6kzgvGh7t/kRJ3YNoXlz5ky1R9nkHrxBbj3+5s4ClvGdqOr8ySuW5Br/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4649 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-08 (OSPFv2 flex algo) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 13:33:26 -0000 --_000_MW3PR11MB4570B68DEC57442209E908C7C1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rajesh, The prefix reachability is always signalled via the OSPFv2 Type 3/5/7 LSAs = - this is required for Algo 0 and 1 but also for Flex Algo for basic reacha= bility. These LSAs carry/include the IGP metric in them. The OSPFv2 Extende= d Prefix TLV is used to carry the Prefix SIDs - both algo 0 and Flex Algos.= The FAPM in the OSPFv2 Extended Prefix TLV enables the prefix metric speci= fic to the FA to be also signalled with using FAD with M flag. I am not sure if I understood your question correctly and if not please ela= borate. Thanks, Ketan From: Rajesh M Sent: 07 August 2020 09:34 To: Peter Psenak (ppsenak) ; Shraddha Hegde ; Clarence Filsfils (cfilsfil) ; Ketan Talaul= ikar (ketant) ; Gulko, Arkadiy (Refinitiv) Cc: SPRING WG Subject: https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-08 (OSPFv2 fl= ex algo) Note : Discussion is not about FAPM. For flex algorithm (example take it as 128) OSPF Prefix (For summary/extern= al prefixes), how to get the prefix cost ? there is no prefix cost field i= n OSPFv2 Extended Prefix TLV. Currently only way I can see is prefix needs to be advertised in flex algo = zero(as summary or external prefixes in legacy ospf) as well as in flex alg= o 128 (OSPFv2 Extended Prefix TLV) Thanks Rajesh Juniper Business Use Only --_000_MW3PR11MB4570B68DEC57442209E908C7C1400MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rajesh= ,

&nbs= p;

The prefi= x reachability is always signalled via the OSPFv2 Type 3/5/7 LSAs – t= his is required for Algo 0 and 1 but also for Flex Algo for basic reachabil= ity. These LSAs carry/include the IGP metric in them. The OSPFv2 Extended Prefix TLV is used to carry the Prefix SIDs &= #8211; both algo 0 and Flex Algos. The FAPM in the OSPFv2 Extended Prefix T= LV enables the prefix metric specific to the FA to be also signalled with u= sing FAD with M flag.

&nbs= p;

I am not = sure if I understood your question correctly and if not please elaborate.

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: Rajesh M <mrajesh@juniper.net>
Sent: 07 August 2020 09:34
To: Peter Psenak (ppsenak) <ppsenak@cisco.com>; Shraddha Hegde= <shraddha@juniper.net>; Clarence Filsfils (cfilsfil) <cfilsfil@ci= sco.com>; Ketan Talaulikar (ketant) <ketant@cisco.com>; Gulko, Ark= adiy (Refinitiv) <arkadiy.gulko@refinitiv.com>
Cc: SPRING WG <spring@ietf.org>
Subject: https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-08 (OS= PFv2 flex algo)

 

 

Note : Discussion is not abo= ut FAPM.

 =

For flex algorithm (example take it as 128)= OSPF Prefix (For summary/external prefixes)= ,  how to get the prefix cost ? there is no prefix cost field in OSPFv2 Extended Prefix TLV.

Currently only way I can see is prefix need= s to be advertised in flex algo zero(as summary or external prefixes in leg= acy ospf) as well as in flex algo 128 (OSPFv2 Extended Prefix TLV)

 

Thanks

Rajesh

 

 

 

Juniper Business= Use Only

--_000_MW3PR11MB4570B68DEC57442209E908C7C1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 06:44:57 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E273A1121; Fri, 14 Aug 2020 06:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSY9kViaNdmX; Fri, 14 Aug 2020 06:44:54 -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 E82063A111C; Fri, 14 Aug 2020 06:44:53 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 03F3DF2CCFBBBC04163F; Fri, 14 Aug 2020 14:44:48 +0100 (IST) Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 14 Aug 2020 14:44:47 +0100 Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 14 Aug 2020 14:44:47 +0100 Received: from DGGEMM509-MBX.china.huawei.com ([169.254.9.186]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0487.000; Fri, 14 Aug 2020 21:44:41 +0800 From: Huzhibo To: IETF Secretariat , "spring-chairs@ietf.org" , "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Thread-Topic: [spring] The SPRING WG has placed draft-hegde-spring-node-protection-for-sr-te-paths in state "Call For Adoption By WG Issued" Thread-Index: AQHWZmzX/My34LUJFUGU+VKA29sviqk3s7Vg Date: Fri, 14 Aug 2020 13:44:41 +0000 Message-ID: <06CF729DA0D6854E8C1E5121AC3330DFAF749133@dggemm509-mbx.china.huawei.com> References: <159611203375.23062.15788303421011485933@ietfa.amsl.com> In-Reply-To: <159611203375.23062.15788303421011485933@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.165.70] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] =?gb2312?b?tPC4tDogIFRoZSBTUFJJTkcgV0cgaGFzIHBsYWNlZCBk?= =?gb2312?b?cmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1w?= =?gb2312?b?YXRocyBpbiBzdGF0ZSAiQ2FsbCBGb3IgQWRvcHRpb24gQnkgV0cgSXNzdWVk?= =?gb2312?b?Ig==?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 13:44:56 -0000 SGkgIGFsbKO6DQogICAgSSB0aGluayB0aGlzIGRyYWZ0IGlzIGEgdXNlZnVsIHRvcGljo6xIb3dl dmVyLCBJIHRoaW5rIHRoZXJlIGlzIHN0aWxsIHNwYWNlIGZvciBpbXByb3ZlbWVudCBpbiB0aGlz IHNvbHV0aW9uLiBBY2NvcmRpbmcgdG8gdGhlIHNvbHV0aW9uIGluIHRoZSBkcmFmdCwgdGhlIHNp emUgb2YgdGhlIGNvbnRleHQgdGFibGUgb2YgZWFjaCBub2RlIGlzIHRoZSBudW1iZXIgb2YgbmVp Z2hib3JzICogKHRoZSBudW1iZXIgb2YgbmV0d29yayBub2RlcyArIHRoZSBudW1iZXIgb2YgbmVp Z2hib3JzIG9mIG5laWdoYm9ycykuIFRoaXMgd2lsbCBjYXVzZSBzY2FsYWJpbGl0eSBwcm9ibGVt cy4gSWYgdGhlIFNSR0IgZGlmZmVyZW5jZSB2YWx1ZSBpcyB1c2VkIHRvIGNhbGN1bGF0ZSB0aGUg bWFwcGluZyB2YWx1ZSBmcm9tIHRoZSByZW1vdGUgbGFiZWwgdG8gdGhlIGxvY2FsIGxhYmVsIGRp cmVjdGx5IHdoZW4gZm9yd2FyZGluZywgaXQgaXMgYSByZWNvbW1lbmRlZCBtZXRob2QuDQoNClRo YW5rcw0KDQpaaGlibw0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBzcHJpbmcgW21h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBJRVRGIFNlY3JldGFyaWF0DQq3osvN yrG85DogMjAyMMTqN9TCMzDI1SAyMDoyNw0KytW8/sjLOiBzcHJpbmctY2hhaXJzQGlldGYub3Jn OyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9y LXNyLXRlLXBhdGhzQGlldGYub3JnDQrW98ziOiBbc3ByaW5nXSBUaGUgU1BSSU5HIFdHIGhhcyBw bGFjZWQgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMg aW4gc3RhdGUgIkNhbGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCINCg0KDQpUaGUgU1BSSU5H IFdHIGhhcyBwbGFjZWQgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3It dGUtcGF0aHMNCmluIHN0YXRlIENhbGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCAoZW50ZXJl ZCBieSBCcnVubyBEZWNyYWVuZSkNCg0KVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdA0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJv dGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMvDQoNCkNvbW1lbnQ6DQpDYWxsIGZvciBhZG9wdGlvbjoN Cmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL0I2Y3g3MktBZVgx Z3FEaFYwU29jVDVRbGhtdy8NCg0KSVBSIHBvbGw6DQpodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NwcmluZy9uT1BXaFQtNUlhS1ZhclRHcklHdFJDcjh6YVEvDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGlu ZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nDQo= From nobody Fri Aug 14 07:54:21 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC603A11B8 for ; Fri, 14 Aug 2020 07:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 AFfmC8ikWifD for ; Fri, 14 Aug 2020 07:54:09 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F303A11AA for ; Fri, 14 Aug 2020 07:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1597416848; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=asivyzfmC1+b4BLBRXReMCvKBTiyYd5SQ39vZn4B3ec=; b=RqGr07KP5PIfs3Wi2JY+jLmWfUNC7Tq7O6UoAcGEc2e7qgLEDxsoVPfBCxnXOqtLhEJr7Y QnPrg5m8t3KYNK3orMewqkoZQAuh8knTbMzUEPmO0X9YUn0ocFlZHxce+yotgqk9eNNC5L mwxKK4/j58Y7/Eb9eiGGiWXGxqYgt9Q= Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-310-PbGarKk3NyGkeqMmdR5OZg-1; Fri, 14 Aug 2020 10:54:06 -0400 X-MC-Unique: PbGarKk3NyGkeqMmdR5OZg-1 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (104.47.17.104) by AZWPVEXEdge02.ecitele.com (10.0.2.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Fri, 14 Aug 2020 17:54:04 +0300 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR03MB4195.eurprd03.prod.outlook.com (2603:10a6:208:c0::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18; Fri, 14 Aug 2020 14:54:02 +0000 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1]) by AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1%6]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 14:54:01 +0000 From: Alexander Vainshtein To: "Ketan Talaulikar (ketant)" , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JCAAMsLAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAD7UQgAB6ewCAD4ZhAIAAC+KLgAALZwCAABX95g== Date: Fri, 14 Aug 2020 14:54:01 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.183.63.9] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 72d6c37e-5999-4914-b7a7-08d84061e1f1 x-ms-traffictypediagnostic: AM0PR03MB4195: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rjha12LzsUNb1q/pSNNxF4m5P7WGIx/lEaozNPKIGg/8HP8olbisqwwu6GlnyARH/WYqc7io79MjxZvtJjTSGami8dSW5a/+zAr+hn1qf84ndhsqk0q88PZK4BXNeAc4gzhj19DKYcwPXbLxSJ475t9ykuY2Q8rYoyMNvpH1bi3gRdRiR+pxdVBJmioLQTJ/68unLtGKkIpbaKmx1jL7ClR9UZRYFWaiad2XRLm8Yif6jTrVxGhfbOLJ2axwHRrJn18itoQrAqkzQ/KqcHVA6kc0YiDR1vkprWSvZqRl0RMJVEHuyftMG/45Hv7WpPrbB6cMqU6CZHLFR153ERetMUY4I936kTg4NP72AX8MOIieKn/c+Eu5A4LYD06EyO4uIHzQVvaw3/y0wwmuASa/CUTOUflIS45XDc350jcN1npK3pxoCMLGpMC10CRIXyIL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4499.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(366004)(346002)(396003)(376002)(39860400002)(86362001)(8676002)(4326008)(966005)(83380400001)(110136005)(316002)(478600001)(6506007)(53546011)(26005)(186003)(33656002)(7696005)(2906002)(45080400002)(5660300002)(66446008)(64756008)(66476007)(66556008)(30864003)(66946007)(52536014)(55016002)(76116006)(9686003)(8936002)(166002)(71200400001)(491001)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: gbupjpp1Ueursn2a9CbvuY0nQPA3OwZ1o67NGa8SKziuhMT62TPqo4Ok6S7iygD0nHCp89DbFw2fe2iQkHbRc2JdQOskMjP0h2gCfL2WZMSAO1pf8bceCOuSqDRLN/U8aPr4+eAHjpbsglrDSV5HUo+QUUqsy91UDmZbA/ShN8C4YSRJXbMI69CJtzNsakkxil6aHvKNI7Lwz/lf/p6pb4w2xUeQdJdINoVa5IGPxGJdk+NtCnoRzEd4/biML6blk4LUUxOjkzKMm3PbQEwD8o9XdkVFazF1VD3U4UCGgGeRCA/cH31bQVRoFKSfvmZ6gropBJJEhVqbN0stA97jLh+XnRRASGDuwOK64NMVggWUmSCc2WRVj81jbyN3RnTTGdB52G5YEgjudJzms+VUon9DsthEHmN+XPOAWQ0WeXtdCpD87k6/fDziQvSxUuyhdQM+MObcpawVFcwtP5pNVmNOLxTlY3IPnViR5GShe91Ki7wIXnyXaesOVPkN6/zoxr1GeF2Vy86W1TIYDfkcl2fhIynMQj9sqgwBVNc8BCF6cT9W4EsYmCLtf41h0E38w229j47jEfziD4DIBLJ5i9GgbFninREN6fUYheHG3uy11Z7UxoVwRQfiUiA/FeH3HEoskeNrMAI5jJLpf2NhQA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4499.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 72d6c37e-5999-4914-b7a7-08d84061e1f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 14:54:01.9131 (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-CrossTenant-userprincipalname: L5gV4ydDMz2Qfakv7xz3Ve1zd8A+8jaiA09Xkf2lhi/hA36vDQJLtxbaC8Xe1H0uvc/q3UVamUkwkL+ZHDnjfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4195 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA81A106 smtp.mailfrom=alexander.vainshtein@rbbn.com X-Mimecast-Spam-Score: 0.004 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_AM0PR03MB4499C8691A7D5690D052EEB59D400AM0PR03MB4499eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 14:54:14 -0000 --_000_AM0PR03MB4499C8691A7D5690D052EEB59D400AM0PR03MB4499eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Ketan, and all, I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are a= dvertised with PHP can ONLY represent topological instructions in SR-MPLS = - because the advertising node will not receive them and therefore can hard= ly be expected to associate any service function with them. This is complementary to what you have said. Hope this clarifies my position. What, if anything, did I miss? Regards, Sasha Get Outlook for Android ________________________________ From: Ketan Talaulikar (ketant) Sent: Friday, August 14, 2020, 16:23 To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Raszuk Cc: spring@ietf.org Subject: RE: [spring] Spring protection - determining applicability ________________________________ NOTICE: This email was received from an EXTERNAL sender ________________________________ Hi Sasha, If the service does not need any additional context (e.g. a firewall that j= ust applies locally configured default rules on it), then I don=92t see why= PHP could not be done for a Prefix SID associated with a service node. Also, I didn=92t follow the point that you were trying to make about Adj-SI= Ds. Thanks, Ketan From: Alexander Vainshtein Sent: 14 August 2020 18:24 To: Ketan Talaulikar (ketant) ; Joel M. Halpern ; Alexander Vainshtein ; Shraddh= a Hegde ; EXT-Andrew.Alston@liquidtelecom.com ; Robert Raszuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi all, Regarding the statement "Prefix SID could be just a topological instruction= or may also be used to steer the flow to a node which is applying a servic= e function to it": I think that in SR-MPLS a Node SID that is advertised with PHP aciton can b= e safely considered as "just a topological instruction" by the PLR because = the originating node will not receive it. The same applies to Adj-SDIs. My 2c. Get Outlook for Android ________________________________ From: spring > on b= ehalf of Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 15:00 To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi All, I would like to share a different perspective on this. First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1]. This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being provided by t= he SR Policy. Awareness of that notion exists at the SR Policy headend and/= or computation-node. We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of the SLA requ= irement for picking that link. We do not have such a notion for Prefix SIDs= . One can say that we could introduce signalling (e.g. a B flag) to indicat= e whether a Prefix SID can be bypassed or not. This provides the opportunit= y for the computation to use one or the other flavor depending on the natur= e of the SLA for the SR Policy. I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able". As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or not. For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to bypass it. = When this mechanism is used along side SRTE path monitoring mechanisms, it = enables the headend to detect the failure and fallback to an alternate path= using the path protection approach. This is something that is described an= d in use in deployments today [1].. Thanks, Ketan [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9 [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9.3 -----Original Message----- From: spring > On B= ehalf Of Joel M. Halpern Sent: 04 August 2020 20:25 To: Alexander Vainshtein >; Shraddha Hegde >; EXT-Andrew.Alston@liqui= dtelecom.com >; Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability There are, as far as I can tell, a number of ways to address this family of= related questions. What struck me, and prompted the starting question, was that none of them w= ere spelled out. I see lots of interesting ideas / proposals. Some of them are compatible with others. Some are not. It would be good if we could reach agreement on how we thought it should be= handled. Thank you, Joel On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > Hi all, > > I am still not sure that the problem of bypass going thru undesirable > links/nodes exists in the case of topological SIDs. > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > ) has been successfully deployed > for many years before SR-MPLS has been introduced. What=92s more, > signaling of bypass tunnels he PLR usually did not include any of the > constraints used for computing of any specific LSP that the bypass LSP > would protect =96 because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node. > > From my POV the only difference between this behavior and that > introduced by the =93bypassing=94 drafts in SR is that, in the case of > RSVP-TE, the operator would explicitly indicate, as part of LSP > signaling, whether it would or would not use FRR; LSPs that would not > use FRR would then drop traffic rather than delivering it the wrong way. > > Such an option indeed does not exist in SR-TE today, but would be easy > to provide if so desired IMHO. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:* spring > = *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM > *To:* EXT-Andrew.Alston@liquidtelecom.com > >= ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > All, > > This is a very interesting discussion and thanks to Joel for starting > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized either by defining a flex-algo > avoiding those > > Nodes and links or by using a stack of unprotected adj-sids that avoid > restricted nodes and links. When a stack of adj-sids is used to > realize the path, the head-end based (sBFD) protection mechanisms can be = applied. > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection > is in use or not. > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* spring > > *= On Behalf Of *Andrew Alston > *Sent:* Tuesday, August 4, 2020 5:41 AM > *To:* Robert Raszuk > > *Cc:* spring@ietf.org ; J= oel M. Halpern > > > *Subject:* Re: [spring] Spring protection - determining applicability > > *[External Email. Be cautious of content]* > > Robert this is actually far more difficult when =96 it can be an entire > (long) series of nodes that need to be avoided. > > It could potentially be made to work but I=92d worry that to do this =96 > you=92d have to stack 10 =96 20 =96 30 negative labels =96 and that would= n=92t > be viable. > > It=92s easier to use algorithms and adjacency sids and other such things > to calculate paths =96 the biggest trick is about the stack depth. When > you have this need for node avoidance =96 the need for 10+ label depth > is critical =96 unless you wanna be applying one hell of a lot of > binding labels along the way which is a nightmare. > > But to answer your question, is this a common use case =96 it=92s a use > case that most of the people I discuss this with certain have =96 I cant > comment on a global scale, or for anyone else, but every indication I > have is that yes =96 its something people need, and want > > Andrew > > *From:* Robert Raszuk > > *Sent:* Tuesday, 4 August 2020 01:27 > *To:* Andrew Alston > > > *Cc:* Joel M. Halpern > >; spring@i= etf.org > > *Subject:* Re: [spring] Spring protection - determining applicability > > Is this a common use case ie. "but rather =96 which nodes / network > segments it can never touch or flow through." > > If so perhaps its time to define notion of *negative-SID* ie. list in > the packet resources which given packet MUST not ever traverse. > > Put in the packet set of nodes or links which the packet should never > traverse. > > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR) > > Best, > R. > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > wrote: > > So =96 > > One of the use cases, in fact, some very major use cases in any > spring technology for us revolve around the following > > a.The explicit avoidance of certain nodes > > b.The explicit avoidance of certain sections of the network > > Anything that could result in that explicit avoidance being violated > =96 would create, shall we say significant problems. > > Much of the use case is not a case of which nodes the packets flow > through =96 but rather =96 which nodes / network segments it can neve= r > touch or flow through. Effectively, to be used as a technology to > avoid certain things for specific reasons. > > This is also one of the reasons for needing such deep label stacks = =96 > this kind of detailed path programming tends to deepen the stack > because you sometimes have to be pretty explicit. > > It is absolutely critical to us that this functionality is there =96 > and that we can avoid situations which could cause traffic to > accidently hit things explicitly avoided. > > I wish I could be more specific than this, but it is what it is. > > Thanks > > Andrew > > *From:* spring > > = *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > > *Cc:* spring@ietf..org > *Subject:* Re: [spring] Spring protection - determining > applicability > > (Since the thread has gotten long enough, reiterating that this is as= a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks tha= t > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clea= r > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve Qo= S. > > Let's be clear. I am not arguing that this is not a good idea. It is = a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two > observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you > better > > apply IP encapsulation to that node.. I don't think IP > encapsulation can > > be hijacked today such that destination address of the packet is > ignored. > > > > B) Have you seen any IP network where upon topology change (link > or node > > failure) you suddenly start dropping flows in spite of SPT offerin= g > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > > wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is > restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex t= e > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the pac= ket > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding > service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and > "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological > instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > >= > > > > > > draft) unsurprisingly represent =93service=94 instructions > > > > > > 2.Segments that represent topological instructions can be bypass= ed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, tw= o > > > > > > topological segments are defined: the IGP-Adjacency segment and = the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and th= e > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Sectio= n > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > > > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous > sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When = the > > > > > > provider edge routers exchange service labels via BGP or som= e > > other > > > > > > non-IGP mechanism the bottom label is not understood in the = IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 > >] > is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between =93topological= =94 and > > > =93service=94 instructions is broken are indeed problematic. E.g= ., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such =93combined=94 SIDs could be prev= ented > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > > > > On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > > >; > spring@ietf.org > > > Subject: Re: [spring] Spring protection - determining applicabil= ity > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in th= e > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus > normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicabili= ty > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the variou= s > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, f= or > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new pat= h > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we = are > > > > > > > deliberately vague about what nodes can do when asked suitabl= y.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > > >> > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2 > > > > > > > > > > > > > > > > F%2Fwww.ietf.org > > > > >%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= --- > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any revi= ew, > > > disclosure, reliance or distribution by others or forwarding > without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete = all > > > copies, including any attachments. > > > > > > ---------------------------------------------------------------------= --- > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org = > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <= mailto:spring@ietf.org> > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > ---------------------------------------------------------------------- > -- > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ---------------------------------------------------------------------- > -- _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ________________________________ Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for th= e sole use of the intended recipient. Any review, disclosure, reliance or d= istribution by others or forwarding without express permission is strictly = prohibited. If you are not the intended recipient, please notify the sender= immediately and then delete all copies, including any attachments. ________________________________ --_000_AM0PR03MB4499C8691A7D5690D052EEB59D400AM0PR03MB4499eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Ketan, and all,
I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are a= dvertised with PHP can  ONLY represent topological instructions in SR-= MPLS - because the advertising node will not receive them and therefore can= hardly be expected to associate any service function with them.

This is complementary to what you have said.

Hope this clarifies my position.
What, if anything, did I miss?

Regards,
Sasha

From: Ketan Talaulikar (ketant) = <ketant@cisco.com>
Sent: Friday, August 14, 2020, 16:23
To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde;= EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk
Cc: spring@ietf.org
Subject: RE: [spring] Spring protection - determining appl= icability

NOTICE: This email was received from an EXTERNAL sender

Hi Sasha,

 

If the service does not need any ad= ditional context (e.g. a firewall that just applies locally configured defa= ult rules on it), then I don=92t see why PHP could not be done for a Prefix= SID associated with a service node.

 

Also, I didn=92t follow the point t= hat you were trying to make about Adj-SIDs.

 

Thanks,

Ketan

 

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halp= ern <jmh@joelhalpern.com>; Alexander Vainshtein <Alexander.Vainsht= ein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.A= lston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

 

Hi all,

Regarding the statement "Prefix SID could be just a t= opological instruction or may also be used to steer the flow to a node whic= h is applying a service function to it":

 

 

I think that in SR-MPLS a Node SID that is advertised with= PHP aciton can be safely considered as "just a topological instructio= n" by the PLR because the originating node will not receive it.

The same applies to Adj-SDIs.

 

My 2c.

 

From: spring <spring-bounces@ietf.org> o= n behalf of Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.= ietf.org>
Sent: Friday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk
Cc: spring@ietf.org
Subject:= Re: [spring] Spring protection - determining applicability=



Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being pro= vided by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddh= a Hegde <shraddha=3D40juniper.net@dmarc.ietf.org>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtel= ecom.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@iet= f.org; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of= related questions.
What struck me, and prompted the starting question, was that none of them w= ere spelled out.  I see lots of interesting ideas / proposals.
Some of them are compatible with others.   Some are not.
It would be good if we could reach agreement on how we thought it should be= handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirable =
> links/nodes exists in the case of topological SIDs.
>
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A= %2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
> for many years before SR-MPLS has been introduced. What=92s more,
> signaling of bypass tunnels he PLR usually did not include any of the =
> constraints used for computing of any specific LSP that the bypass LSP=
> would protect =96 because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>  From my POV the only difference between this behavior and that <= br> > introduced by the =93bypassing=94 drafts in SR is that, in the case of=
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use FRR; LSPs that would not =
> use FRR would then drop traffic rather than delivering it the wrong wa= y.
>
> Such an option indeed does not exist in SR-TE today, but would be easy=
> to provide if so desired IMHO.
>
> Did I miss something substantial?
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha H= egde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net= >
> *Cc:* spr= ing@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> All,
>
> This is a very interesting discussion and thanks to Joel for starting =
> this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized  either by defining a flex= -algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avoid=
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
> failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org
> <mailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Als= ton
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
> *Cc:* spr= ing@ietf.org <mailto:spring@ietf.org>; Joel M. Halpern
> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> *[External Email. Be cautious of content]*
>
> Robert this is actually far more difficult when =96 it can be an entir= e
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=92d worry that to do this = =96
> you=92d have to stack 10 =96 20 =96 30 negative labels =96 and that wo= uldn=92t
> be viable.
>
> It=92s easier to use algorithms and adjacency sids and other such thin= gs
> to calculate paths =96 the biggest trick is about the stack depth.&nbs= p; When
> you have this need for node avoidance =96 the need for 10+ label depth=
> is critical =96 unless you wanna be applying one hell of a lot of
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =96 it=92s a us= e
> case that most of the people I discuss this with certain have =96 I ca= nt
> comment on a global scale, or for anyone else, but every indication I =
> have is that yes =96 its something people need, and want
>
> Andrew
>
> *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>&g= t;
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jmh@joelhalpern.com>>; spring@ietf.or= g
> <mailt= o:spring@ietf.org>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> Is this a common use case ie.  "but rather =96 which nodes /= network
> segments it can never touch or flow through."
>
> If so perhaps its time to define notion of *negative-SID* ie. list in =
> the packet resources which given packet MUST not ever traverse. >
> Put in the packet set of nodes or links which the packet should never =
> traverse.
>
> That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com>> wrote:<= br> >
>     So =96
>
>     One of the use cases, in fact, some very major= use cases in any
>     spring technology for us revolve around the fo= llowing
>
>     a.The explicit avoidance of certain nodes
>
>     b.The explicit avoidance of certain sections o= f the network
>
>     Anything that could result in that explicit av= oidance being violated
>     =96 would create, shall we say significant pro= blems.
>
>     Much of the use case is not a case of which no= des the packets flow
>     through =96 but rather =96 which nodes / netwo= rk segments it can never
>     touch or flow through.  Effectively, to b= e used as a technology to
>     avoid certain things for specific reasons.
>
>     This is also one of the reasons for needing su= ch deep label stacks =96
>     this kind of detailed path programming tends t= o deepen the stack
>     because you sometimes have to be pretty explic= it.
>
>     It is absolutely critical to us that this func= tionality is there =96
>     and that we can avoid situations which could c= ause traffic to
>     accidently hit things explicitly avoided.
>
>     I wish I could be more specific than this, but= it is what it is.
>
>     Thanks
>
>     Andrew
>
>     *From:* spring <spring-bounces@ietf.org
>     <mailto:spring-bounces@ietf.org>> *= On Behalf Of *Joel M. Halpern
>     *Sent:* Monday, 3 August 2020 21:36
>     *To:* Robert Raszuk <robert@raszuk.net <= mailto:rober= t@raszuk.net>>
>     *Cc:* spring@ietf..org <mailto:spring@ietf.org>
>     *Subject:* Re: [spring] Spring protection - de= termining
> applicability
>
>     (Since the thread has gotten long enough, reit= erating that this is as a
>     participant, not a WG chair.)
>
>     Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
>     choose to drop packets. For all sorts of reaso= ns.
>     I think there are likely other reasons why one= may not want a random
>     path rather than a chosen TE path. I think it = is important we be clear
>     about what constraints may be / are violated w= hen we tell people they
>     have this tool (protective rerouting) that is = intended to preserve QoS.
>
>     Let's be clear. I am not arguing that this is = not a good idea. It is a
>     good idea. And useful. I am trying to figure o= tu what combination of
>     additional mechanisms and clear descriptions w= ill lead to everyone
>     getting the behavior they expect (which may no= t be the behavior they
>     desire, but sometimes is the best we can do.)<= br> >
>     Yours,
>     Joel
>
>     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>      > Joel,
>      >
>      > Are we still talking about IP netwo= rks here ? Or perhaps some hard
>      > slicing with real resource reservat= ions or detnets ?
>      >
>      > Because if we are talking = ;about IP networking I have two
>     observations:
>      >
>      > A) If you need to traverse via a sp= ecific node (ie. firewall) you
>     better
>      > apply IP encapsulation to that node= .. I don't think IP
>     encapsulation can
>      > be hijacked today such that destina= tion address of the packet is
>     ignored.
>      >
>      > B) Have you seen any IP network whe= re upon topology change (link
>     or node
>      > failure) you suddenly start dr= opping flows in spite of SPT offering
>      > perhaps few ms longer path with 10 = ms more jitter ?
>      >
>      > Or are some SR marketing slides pro= mise to turn IP networks in
>      > something new ? Worse ... do t= hey mention path quality guarantees,
>      > resource reservations ? I hope= not.
>      >
>      > Thx,
>      > R.
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com%20%0b>&g= t; <mai= lto:jmh@joelhalpern.com>> wrote:
>      >
>      > Well less serious for TE SIDs, I am= not sure the problem is
>     restricted
>      > to just service SIDs.
>      >
>      > Suppose that the PCE has specified = the path to meet some complex te
>      > objective.  The bypass node ha= s no way of knowing what those
>      > constraints
>      > were.  And for some kinds of t= raffic, it is better to drop the packet
>      > than to deliver it outside the enve= lop.  I suspect that the right
>      > answer
>      > to this is "too bad".&nbs= p; If so, as with the distinction regarding
>     service
>      > nodes, we should say so, shouldn't = we?
>      >
>      > Yours,
>      > Joel
>      >
>      > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
>      > > Mach, Joel and all,
>      > >
>      > > I think that in most cases: >      > >
>      > > 1.There is clear differentiati= on between "topological" and
>     "service"
>      > > instructions in SID advertisem= ents. E.g.:
>      > >
>      > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
>      > > corresponding IGP advertisemen= ts) represent topological
>     instructions
>      > >
>      > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
>      > >
>      >
>     <https:= //clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
>     <https://clicktime.symantec.c= om/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__htt= ps%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-0= 4__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8A= kTRDuiDo4T-L0nl%24>>
>      >
>      > > draft) unsurprisingly represen= t =93service=94 instructions
>      > >
>      > > 2.Segments that represent topo= logical instructions can be bypassed,
>      > > while segments that represent = service instructions require
>      > alternative
>      > > protection mechanisms.
>      > >
>      > > This view seems to be aligned = with RFC 8402
>      > > <https://clicktime.symantec.= com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frf= c8402
>     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhtt= ps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc84= 02__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8= AkTRDuiDo0I4Ybtm%24>>
>     that says in Section 1:
>      > >
>      > >     In the cont= ext of an IGP-based distributed control plane, two
>      > >
>      > > topological segments are defin= ed: the IGP-Adjacency segment and the
>      > >
>      > >     IGP-Prefix = segment.
>      > >
>      > >     In the cont= ext of a BGP-based distributed control plane, two
>      > >
>      > > topological segments are defin= ed: the BGP peering segment and the
>      > >
>      > >     BGP-Prefix = segment.
>      > >
>      > > In the case of SR-MPLS this di= fferentiation is assumed in Section
>      > 3.4 of
>      > > the Node Protection for SR-TE = Path
>      > >
>      >
>     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZ= dhpExxx96H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-heg= de-spring-node-protection-for-sr-te-paths-07%23section-3.4
>     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fh= tml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__= %3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8Ak= TRDuiDo9wO-Ssn%24>>
>      >
>      > > draft that says:
>      > >
>      > >     The node pr= otection mechanism described in the previous
>     sections
>      > >
>      > >     depends on = the assumption that the label immediately below
>      > the top
>      > >
>      > > label in the label stack is un= derstood in the IGP domain.  When the
>      > >
>      > >     provider ed= ge routers exchange service labels via BGP or some
>      > other
>      > >
>      > >     non-IGP mec= hanism the bottom label is not understood in the IGP
>      > >
>      > >     domain.
>      > >
>      > >     The egress = node protection mechanisms described in the draft
>      > >
>      > >     [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3D= https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
>     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJ= w6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.= org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxg= m0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
>     is
>      > > applicable to this use case an= d no additional changes
>      > >
>      > >     will be req= uired for SR based networks
>      > >
>      > > The scenarios in which  d= ifferentiation between =93topological=94 and
>      > > =93service=94 instructions is = broken are indeed problematic. E.g.,
>      > consider
>      > > the use case in which a Node S= ID in the ERO of a SR-TE path
>      > identifies a
>      > > node that acts as a firewall f= or all packets it receives, i.e.,
>      > provides
>      > > the firewall service without a= ny dedicated service SID
>      > identifying it.
>      > > One could say that the Node SI= D of such a node would combine
>      > topological
>      > > and service instructions thus = breaking the differentiation
>      > between the two.
>      > >
>      > > I am not sure if usage of such= =93combined=94 SIDs could be prevented
>      > or at
>      > > least discouraged.
>      > >
>      > > If not, providing an ability t= o identify such SIDs in the
>      > advertisement
>      > > mechanisms would be useful IMH= O.
>      > >
>      > > My 2c,
>      > >
>      > > Sasha
>      > >
>      > > Office: +972-39266302
>      > >
>      > > Cell:    &= nbsp; +972-549266302
>      > >
>      > > Email: Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com= >
>      > <mailto:Alexander.Vainshtein@= ecitele.com>
>      > >
>      > > -----Original Message-----
>      > > From: spring <spring-bounces@i= etf.org
>     <mailto:spring-bounces@ietf.org%0b>= >
>     <mailto:spring-bounces@ietf.org>> On Be= half Of Mach Chen
>      > > Sent: Monday, August 3, 2020 6= :30 AM
>      > > To: Joel M. Halpern <jmh@joelhalpe= rn.com
>     <mailto:jmh@joelhalpern.com%0b>> <= ;mailto:jm= h@joelhalpern.com>>;
>     spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org&= gt;
>      > > Subject: Re: [spring] Spring p= rotection - determining applicability
>      > >
>      > > Hi Joel,
>      > >
>      > > I think this is a good point t= hat may not be discussed in the
>      > past. And
>      > > I also don't think there is a = "can be bypassed" indication in the
>      > > routing advertisement for now.=
>      > >
>      > > IMHO, the information advertis= ed by routing is neutral, such
>      > information
>      > > (can or cannot be bypassed) is= more path specific, thus
>     normally the
>      > > controller should be responsib= le for deciding whether/which SID
>      > can be
>      > > bypassed.
>      > >
>      > > Best regards,
>      > >
>      > > Mach
>      > >
>      > >  > -----Original Messa= ge-----
>      > >
>      > >  > From: spring [mailt= o:spring-bounces@ietf.org
>      > <mailto:spring-bounces@ietf.org>= ;
>     <mai= lto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>]
>     On Behalf Of Joel M.
>      > >
>      > >  > Halpern
>      > >
>      > >  > Sent: Monday, Augus= t 3, 2020 7:51 AM
>      > >
>      > >  > To: spring@ietf.org <mailto:spring@ietf.= org>
>     <mailto:spring@ietf.org>
>      > <mailto:spring@= ietf.org <mailto:spring@ietf.org
>     <mailto:spring@ietf.org%2= 0%3cmailto:spring@ietf.org>>>
>      > >
>      > >  > Subject: [spring] S= pring protection - determining applicability
>      > >
>      > >  >
>      > >
>      > >  > (WG Chair hat Off, = this is merely a note from a slightly
>      > confused WG
>      > >
>      > >  > participant.)
>      > >
>      > >  >
>      > >
>      > >  > I have been reading= the various repair drafts, and the various
>      > >
>      > >  > networks programmin= g and service programming draft, and I am
>      > trying to
>      > >
>      > >  > figure out one aspe= ct of the combination.
>      > >
>      > >  >
>      > >
>      > >  > How does a node tha= t is doing some form of bypass (suppose, for
>      > >
>      > >  > simplicity, it is N= ode N2 deciding to bypass the next SID for
>      > a failed
>      > >
>      > >  > node N3) know that = it is safe to do so?
>      > >
>      > >  >
>      > >
>      > >  > If the path was jus= t for TE, then it is "safe" if the new path
>      > meets
>      > >
>      > >  > the TE criteria.&nb= sp; or maybe it is safe if it is even close, as
>      > long as
>      > >
>      > >  > it is not used for = too long.
>      > >
>      > >  >
>      > >
>      > >  > But what if the nod= e were a Firewall, included to meet legal
>      > > requirements?
>      > >
>      > >  > Or was some other n= ecessary programmatic transform (wince we are
>      > >
>      > >  > deliberately vague = about what nodes can do when asked suitably.)
>      > >
>      > >  >
>      > >
>      > >  > Is there some "= ;can be bypassed" indication in the routing
>      > >
>      > >  > advertisements that= I missed?
>      > >
>      > >  >
>      > >
>      > >  > Thank you,
>      > >
>      > >  > Yours,
>      > >
>      > >  > Joel
>      > >
>      > >  >
>      > >
>      > >  > ___________________= ____________________________
>      > >
>      > >  > spring mailing list=
>      > >
>      > >  > spring@ietf.org <mailto:spring@ietf.or= g>
>     <mailto:spring@ietf.org>
>      > <mailto:spring@= ietf.org <mailto:spring@ietf.org
>     <mailto:spring@ietf.org%2= 0%3cmailto:spring@ietf.org>>>
>      > >
>      > >  >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
>     <https://clicktime.symante= c.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__= https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%= 2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp= 6vpRHOGt8AkTRDuiDo6HwPLil%24>
>      > >
>      >
>     <h= ttps://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252 >     <https://clicktime.sy= mantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%= 2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dht= tps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu= oZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24>>
>      > >
>      > >  > F%2Fwww.ietf.org >     <https://clic= ktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.= com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E= _R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvo= odvS6H2?u=3Dhttp%3A%2F%2F2Fwww.ietf.org
>     <https://= clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefe= nse.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FY= NE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fma= ilman%2Flistinfo%2Fspring
>      > >
>      > > ______________________________= _________________
>      > >
>      > > spring mailing list
>      > >
>      > > spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:spring@ietf.org> <mailto:spring@ietf.org
>     <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.or= g>>
>      > >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3BhyEtx4Q7= n74BhiRnfMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclick= time.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fww= w.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-g= k%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24= >
>      > >
>      > >
>      > >
>      > >
>      >
>     ----------------------------------------------= --------------------------
>      > > Notice: This e-mail together w= ith any attachments may contain
>      > > information of Ribbon Communic= ations Inc. that is confidential
>      > and/or
>      > > proprietary for the sole use o= f the intended recipient. Any review,
>      > > disclosure, reliance or distri= bution by others or forwarding
>     without
>      > > express permission is strictly= prohibited. If you are not the
>      > intended
>      > > recipient, please notify the s= ender immediately and then delete all
>      > > copies, including any attachme= nts.
>      > >
>      >
>     ----------------------------------------------= --------------------------
>      > >
>      > > ______________________________= _________________
>      > > spring mailing list
>      > > spring@ietf.org <mailto:spring@ietf.org> <= ;mailto:spring= @ietf.org>
>      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?= u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman= %2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>      > >
>      >
>      > ___________________________________= ____________
>      > spring mailing list
>      > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf= .org>
>      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?= u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman= %2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>      >
>
>     ______________________________________________= _
>     spring mailing list
>     spring@ietf.org <mailto:spring@ietf.org>
>     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>    
> <https://clicktime.symantec= .com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Fl= isti
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> ----------------------------------------------------------------------=
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or =
> proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
> recipient, please notify the sender immediately and then delete all > copies, including any attachments.
> ----------------------------------------------------------------------=
> --

_______________________________________________
spring mailing list
spring@ietf.or= g
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
spring@ietf.or= g
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

 

 

Notice: This e-mail together with any attachments may= contain information of Ribbon Communications Inc. that is confidential and= /or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or f= orwarding without express permission is strictly prohibited. If you are not= the intended recipient, please notify the sender immediately and then dele= te all copies, including any attachments.


--_000_AM0PR03MB4499C8691A7D5690D052EEB59D400AM0PR03MB4499eurp_-- From nobody Fri Aug 14 08:10:01 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0752E3A1018 for ; Fri, 14 Aug 2020 08:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.069 X-Spam-Level: * X-Spam-Status: No, score=1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.497, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTTP_ESCAPED_HOST=0.1, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.949, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 s466XTvxV6iJ for ; Fri, 14 Aug 2020 08:09:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 9D1C93A0FC8 for ; Fri, 14 Aug 2020 08:09:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4BSn0y3CF9z1p4bL for ; Fri, 14 Aug 2020 08:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1597417794; bh=vytqaVvjeZ1/WyKG6J9Nl3XJpkrfOPkdn8OqUH7NAZA=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=M5gMNSBf5MNOEtxgma8fWJQljZn+tNwWeQCdbAKw9RRti/f1lOpQcr+zQ3fkS4FNq 1ywqsCkIfyOD6laE7z8B7XnDFz6Xu3BFXur4VvmOixrbPfCIA8zcZPNSTRkTfCRp8s P1ZkWVX68r6IW7F5pFT9cZOb8TfgHf0YcE4rDEtE= X-Quarantine-ID: <1DsQ_LyVqGkN> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4BSn0x6djgz1nvCV for ; Fri, 14 Aug 2020 08:09:53 -0700 (PDT) Cc: "spring@ietf.org" References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <067dfd10-cbd6-fb1c-4361-4bb69f4375ae@joelhalpern.com> Date: Fri, 14 Aug 2020 11:09:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 15:10:00 -0000 From what I have seen in this discussion, we have a number of different views, all reasonable, mostly non-document. It would seem helpful to write down our assumptions about meaning and get WG agreement?? Yours, Joel On 8/14/2020 10:54 AM, Alexander Vainshtein wrote: > Ketan, and all, > I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that > are advertised with PHP can  ONLY represent topological instructions in > SR-MPLS - because the advertising node will not receive them and > therefore can hardly be expected to associate any service function with > them. > > This is complementary to what you have said. > > Hope this clarifies my position. > What, if anything, did I miss? > > Regards, > Sasha > > Get Outlook for Android > > ------------------------------------------------------------------------ > *From:* Ketan Talaulikar (ketant) > *Sent:* Friday, August 14, 2020, 16:23 > *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* RE: [spring] Spring protection - determining applicability > > ------------------------------------------------------------------------ > NOTICE: This email was received from an EXTERNAL sender > ------------------------------------------------------------------------ > > Hi Sasha, > > If the service does not need any additional context (e.g. a firewall > that just applies locally configured default rules on it), then I don’t > see why PHP could not be done for a Prefix SID associated with a service > node. > > Also, I didn’t follow the point that you were trying to make about Adj-SIDs. > > Thanks, > > Ketan > > *From:*Alexander Vainshtein > *Sent:* 14 August 2020 18:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern > ; Alexander Vainshtein > ; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > Hi all, > > Regarding the statement "Prefix SID could be just a topological > instruction or may also be used to steer the flow to a node which is > applying a service function to it": > > I think that in SR-MPLS a Node SID that is advertised with PHP aciton > can be safely considered as "just a topological instruction" by the PLR > because the originating node will not receive it. > > The same applies to Adj-SDIs. > > My 2c. > > Get Outlook for Android > > > ------------------------------------------------------------------------ > > *From:* spring > on behalf of Ketan Talaulikar (ketant) > > > *Sent:* Friday, August 14, 2020, 15:00 > *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com > ; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi All, > > I would like to share a different perspective on this. > > First, thanks to Joel for bringing up the discussion. Clearly we need a > well-defined applicability statement for determining applicability of > protection for segment used in an SR Policy. Some of this is captured in > [1]. > > This is about local repair at a PLR. By it's very nature, the PLR does > not have a notion of how "strict or not" is the SLA that is being > provided by the SR Policy. Awareness of that notion exists at the SR > Policy headend and/or computation-node. > > We have protected and un-protected variants of adjacency SIDs to enable > the computation to pick or the other based on the "strictness" of the > SLA requirement for picking that link. We do not have such a notion for > Prefix SIDs. One can say that we could introduce signalling (e.g. a B > flag) to indicate whether a Prefix SID can be bypassed or not. This > provides the opportunity for the computation to use one or the other > flavor depending on the nature of the SLA for the SR Policy. > > I have a problem and a concern in the assumption that PLRs can assume > that the currently defined variant of Prefix SIDs in RFC8402 (and IGP > specs) are "bypass-able". > > As Joel and others have brought out, the Prefix SID could be just a > topological instruction or may also be used to steer the flow to a node > which is applying a service function to it. In order to support a mix of > SR Policies of different SLAs (strict and not-strict), we need to enable > the choice of SIDs that indicates to the PLR whether they are > "bypass-able" or not. > > For the cases, where the SR Policy has a specific SLA, it is required > for nodes to drop the packets meant for the "active segment" than to > bypass it. When this mechanism is used along side SRTE path monitoring > mechanisms, it enables the headend to detect the failure and fallback to > an alternate path using the path protection approach. This is something > that is described and in use in deployments today [1].. > > Thanks, > Ketan > > [1] > https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9 > [2] > https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9.3 > > -----Original Message----- > From: spring > > On Behalf Of Joel M. Halpern > Sent: 04 August 2020 20:25 > To: Alexander Vainshtein >; Shraddha Hegde > >; > EXT-Andrew.Alston@liquidtelecom.com > > >; Robert Raszuk > > > Cc: spring@ietf.org ; Joel M. Halpern > > > Subject: Re: [spring] Spring protection - determining applicability > > There are, as far as I can tell, a number of ways to address this family > of related questions. > What struck me, and prompted the starting question, was that none of > them were spelled out.  I see lots of interesting ideas / proposals. > Some of them are compatible with others.   Some are not. > It would be good if we could reach agreement on how we thought it should > be handled. > > Thank you, > Joel > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > Hi all, > > > > I am still not sure that the problem of bypass going thru undesirable > > links/nodes exists in the case of topological SIDs. > > > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > > > ) > has been successfully deployed > > for many years before SR-MPLS has been introduced. What’s more, > > signaling of bypass tunnels he PLR usually did not include any of the > > constraints used for computing of any specific LSP that the bypass LSP > > would protect – because in the Facility Protection mode the same > > bypass LSP would be used to protect multiple LSPs passing thru the > > failed link/node. > > > >  From my POV the only difference between this behavior and that > > introduced by the “bypassing” drafts in SR is that, in the case of > > RSVP-TE, the operator would explicitly indicate, as part of LSP > > signaling, whether it would or would not use FRR; LSPs that would not > > use FRR would then drop traffic rather than delivering it the wrong way. > > > > Such an option indeed does not exist in SR-TE today, but would be easy > > to provide if so desired IMHO. > > > > Did I miss something substantial? > > > > Regards, and lots of thanks in advance, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell:      +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > *From:* spring > *On Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > *To:* EXT-Andrew.Alston@liquidtelecom.com > > > >; Robert Raszuk > > > > *Cc:* spring@ietf.org ; Joel M. Halpern > > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > All, > > > > This is a very interesting discussion and thanks to Joel for starting > > this discussion. IMO, when there are strict requirements of avoiding > > certain nodes/links it can be realized  either by defining a flex-algo > > avoiding those > > > > Nodes and links or by using a stack of unprotected adj-sids that avoid > > restricted nodes and links. When a stack of adj-sids is used to > > realize the path, the head-end based (sBFD) protection mechanisms can > be applied. > > > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > > failure events may cause traffic to go through restricted nodes and > > links. This would happen regardless of whether any kind of protection > > is in use or not. > > > > Rgds > > > > Shraddha > > > > Juniper Business Use Only > > > > *From:* spring > > > *On Behalf Of *Andrew Alston > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > *To:* Robert Raszuk > > > *Cc:* spring@ietf.org > ; Joel M. Halpern > > > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > *[External Email. Be cautious of content]* > > > > Robert this is actually far more difficult when – it can be an entire > > (long) series of nodes that need to be avoided. > > > > It could potentially be made to work but I’d worry that to do this – > > you’d have to stack 10 – 20 – 30 negative labels – and that wouldn’t > > be viable. > > > > It’s easier to use algorithms and adjacency sids and other such things > > to calculate paths – the biggest trick is about the stack depth.  When > > you have this need for node avoidance – the need for 10+ label depth > > is critical – unless you wanna be applying one hell of a lot of > > binding labels along the way which is a nightmare. > > > > But to answer your question, is this a common use case – it’s a use > > case that most of the people I discuss this with certain have – I cant > > comment on a global scale, or for anyone else, but every indication I > > have is that yes – its something people need, and want > > > > Andrew > > > > *From:* Robert Raszuk > > > *Sent:* Tuesday, 4 August 2020 01:27 > > *To:* Andrew Alston > > > > > *Cc:* Joel M. Halpern > >; > spring@ietf.org > > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Is this a common use case ie.  "but rather – which nodes / network > > segments it can never touch or flow through." > > > > If so perhaps its time to define notion of *negative-SID* ie. list in > > the packet resources which given packet MUST not ever traverse. > > > > Put in the packet set of nodes or links which the packet should never > > traverse. > > > > That goes in line of recent wave of negative routing implementations > > (RIFT) or discussions (LSR) > > > > Best, > > R. > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > > > wrote: > > > >     So – > > > >     One of the use cases, in fact, some very major use cases in any > >     spring technology for us revolve around the following > > > >     a.The explicit avoidance of certain nodes > > > >     b.The explicit avoidance of certain sections of the network > > > >     Anything that could result in that explicit avoidance being violated > >     – would create, shall we say significant problems. > > > >     Much of the use case is not a case of which nodes the packets flow > >     through – but rather – which nodes / network segments it can never > >     touch or flow through.  Effectively, to be used as a technology to > >     avoid certain things for specific reasons. > > > >     This is also one of the reasons for needing such deep label stacks – > >     this kind of detailed path programming tends to deepen the stack > >     because you sometimes have to be pretty explicit. > > > >     It is absolutely critical to us that this functionality is there – > >     and that we can avoid situations which could cause traffic to > >     accidently hit things explicitly avoided. > > > >     I wish I could be more specific than this, but it is what it is. > > > >     Thanks > > > >     Andrew > > > >     *From:* spring > > > *On Behalf Of *Joel M. Halpern > >     *Sent:* Monday, 3 August 2020 21:36 > >     *To:* Robert Raszuk > > >     *Cc:* spring@ietf..org > > >     *Subject:* Re: [spring] Spring protection - determining > > applicability > > > >     (Since the thread has gotten long enough, reiterating that this > is as a > >     participant, not a WG chair.) > > > >     Yes, we are talking IP networks. And yes, I have seen IP networks > that > >     choose to drop packets. For all sorts of reasons. > >     I think there are likely other reasons why one may not want a random > >     path rather than a chosen TE path. I think it is important we be > clear > >     about what constraints may be / are violated when we tell people they > >     have this tool (protective rerouting) that is intended to > preserve QoS. > > > >     Let's be clear. I am not arguing that this is not a good idea. It > is a > >     good idea. And useful. I am trying to figure otu what combination of > >     additional mechanisms and clear descriptions will lead to everyone > >     getting the behavior they expect (which may not be the behavior they > >     desire, but sometimes is the best we can do.) > > > >     Yours, > >     Joel > > > >     On 8/3/2020 2:30 PM, Robert Raszuk wrote: > >      > Joel, > >      > > >      > Are we still talking about IP networks here ? Or perhaps some hard > >      > slicing with real resource reservations or detnets ? > >      > > >      > Because if we are talking about IP networking I have two > >     observations: > >      > > >      > A) If you need to traverse via a specific node (ie. firewall) you > >     better > >      > apply IP encapsulation to that node.. I don't think IP > >     encapsulation can > >      > be hijacked today such that destination address of the packet is > >     ignored. > >      > > >      > B) Have you seen any IP network where upon topology change (link > >     or node > >      > failure) you suddenly start dropping flows in spite of SPT > offering > >      > perhaps few ms longer path with 10 ms more jitter ? > >      > > >      > Or are some SR marketing slides promise to turn IP networks in > >      > something new ? Worse ... do they mention path quality guarantees, > >      > resource reservations ? I hope not. > >      > > >      > Thx, > >      > R. > >      > > >      > > >      > > >      > > >      > > >      > > >      > > >      > > >      > > >      > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > >     > > > wrote: > >      > > >      > Well less serious for TE SIDs, I am not sure the problem is > >     restricted > >      > to just service SIDs. > >      > > >      > Suppose that the PCE has specified the path to meet some > complex te > >      > objective.  The bypass node has no way of knowing what those > >      > constraints > >      > were.  And for some kinds of traffic, it is better to drop the > packet > >      > than to deliver it outside the envelop.  I suspect that the right > >      > answer > >      > to this is "too bad".  If so, as with the distinction regarding > >     service > >      > nodes, we should say so, shouldn't we? > >      > > >      > Yours, > >      > Joel > >      > > >      > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > >      > > Mach, Joel and all, > >      > > > >      > > I think that in most cases: > >      > > > >      > > 1.There is clear differentiation between "topological" and > >     "service" > >      > > instructions in SID advertisements. E.g.: > >      > > > >      > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > >      > > corresponding IGP advertisements) represent topological > >     instructions > >      > > > >      > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > >      > > > >      > > > > > > > > >      > > >      > > draft) unsurprisingly represent “service” instructions > >      > > > >      > > 2.Segments that represent topological instructions can be > bypassed, > >      > > while segments that represent service instructions require > >      > alternative > >      > > protection mechanisms. > >      > > > >      > > This view seems to be aligned with RFC 8402 > >      > > > > > > > >     that says in Section 1: > >      > > > >      > >     In the context of an IGP-based distributed control > plane, two > >      > > > >      > > topological segments are defined: the IGP-Adjacency segment > and the > >      > > > >      > >     IGP-Prefix segment. > >      > > > >      > >     In the context of a BGP-based distributed control plane, two > >      > > > >      > > topological segments are defined: the BGP peering segment > and the > >      > > > >      > >     BGP-Prefix segment. > >      > > > >      > > In the case of SR-MPLS this differentiation is assumed in > Section > >      > 3.4 of > >      > > the Node Protection for SR-TE Path > >      > > > >      > > > > > > > > >      > > >      > > draft that says: > >      > > > >      > >     The node protection mechanism described in the previous > >     sections > >      > > > >      > >     depends on the assumption that the label immediately below > >      > the top > >      > > > >      > > label in the label stack is understood in the IGP domain. > When the > >      > > > >      > >     provider edge routers exchange service labels via BGP or > some > >      > other > >      > > > >      > >     non-IGP mechanism the bottom label is not understood in > the IGP > >      > > > >      > >     domain. > >      > > > >      > >     The egress node protection mechanisms described in the draft > >      > > > >      > >     [RFC8679 > > > >] > >     is > >      > > applicable to this use case and no additional changes > >      > > > >      > >     will be required for SR based networks > >      > > > >      > > The scenarios in which  differentiation between > “topological” and > >      > > “service” instructions is broken are indeed problematic. E.g., > >      > consider > >      > > the use case in which a Node SID in the ERO of a SR-TE path > >      > identifies a > >      > > node that acts as a firewall for all packets it receives, i.e., > >      > provides > >      > > the firewall service without any dedicated service SID > >      > identifying it. > >      > > One could say that the Node SID of such a node would combine > >      > topological > >      > > and service instructions thus breaking the differentiation > >      > between the two. > >      > > > >      > > I am not sure if usage of such “combined” SIDs could be > prevented > >      > or at > >      > > least discouraged. > >      > > > >      > > If not, providing an ability to identify such SIDs in the > >      > advertisement > >      > > mechanisms would be useful IMHO. > >      > > > >      > > My 2c, > >      > > > >      > > Sasha > >      > > > >      > > Office: +972-39266302 > >      > > > >      > > Cell:      +972-549266302 > >      > > > >      > > Email: Alexander.Vainshtein@ecitele.com > > >     > >      > > >      > > > >      > > -----Original Message----- > >      > > From: spring > > > > >     > On Behalf Of Mach Chen > >      > > Sent: Monday, August 3, 2020 6:30 AM > >      > > To: Joel M. Halpern >     > > >; > > spring@ietf.org > > >      > > Subject: Re: [spring] Spring protection - determining > applicability > >      > > > >      > > Hi Joel, > >      > > > >      > > I think this is a good point that may not be discussed in the > >      > past. And > >      > > I also don't think there is a "can be bypassed" indication > in the > >      > > routing advertisement for now. > >      > > > >      > > IMHO, the information advertised by routing is neutral, such > >      > information > >      > > (can or cannot be bypassed) is more path specific, thus > >     normally the > >      > > controller should be responsible for deciding whether/which SID > >      > can be > >      > > bypassed. > >      > > > >      > > Best regards, > >      > > > >      > > Mach > >      > > > >      > >  > -----Original Message----- > >      > > > >      > >  > From: spring [mailto:spring-bounces@ietf.org > >      > > > > ] > >     On Behalf Of Joel M. > >      > > > >      > >  > Halpern > >      > > > >      > >  > Sent: Monday, August 3, 2020 7:51 AM > >      > > > >      > >  > To: spring@ietf.org > > >     > >      > > > >> > >      > > > >      > >  > Subject: [spring] Spring protection - determining > applicability > >      > > > >      > >  > > >      > > > >      > >  > (WG Chair hat Off, this is merely a note from a slightly > >      > confused WG > >      > > > >      > >  > participant.) > >      > > > >      > >  > > >      > > > >      > >  > I have been reading the various repair drafts, and the > various > >      > > > >      > >  > networks programming and service programming draft, and I am > >      > trying to > >      > > > >      > >  > figure out one aspect of the combination. > >      > > > >      > >  > > >      > > > >      > >  > How does a node that is doing some form of bypass > (suppose, for > >      > > > >      > >  > simplicity, it is Node N2 deciding to bypass the next SID for > >      > a failed > >      > > > >      > >  > node N3) know that it is safe to do so? > >      > > > >      > >  > > >      > > > >      > >  > If the path was just for TE, then it is "safe" if the new > path > >      > meets > >      > > > >      > >  > the TE criteria.  or maybe it is safe if it is even close, as > >      > long as > >      > > > >      > >  > it is not used for too long. > >      > > > >      > >  > > >      > > > >      > >  > But what if the node were a Firewall, included to meet legal > >      > > requirements? > >      > > > >      > >  > Or was some other necessary programmatic transform (wince > we are > >      > > > >      > >  > deliberately vague about what nodes can do when asked > suitably.) > >      > > > >      > >  > > >      > > > >      > >  > Is there some "can be bypassed" indication in the routing > >      > > > >      > >  > advertisements that I missed? > >      > > > >      > >  > > >      > > > >      > >  > Thank you, > >      > > > >      > >  > Yours, > >      > > > >      > >  > Joel > >      > > > >      > >  > > >      > > > >      > >  > _______________________________________________ > >      > > > >      > >  > spring mailing list > >      > > > >      > >  > spring@ietf.org > > >     > >      > > > >> > >      > > > >      > >  > > >      > > > >      > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 > > > > > >      > > > >      > > > > > > > > >      > > > >      > >  > F%2Fwww.ietf.org > > > > >      > > > > >%2Fmailman%2Flistinfo%2Fspring > >      > > > >      > > _______________________________________________ > >      > > > >      > > spring mailing list > >      > > > >      > > spring@ietf.org > > >     >     > > > > >      > > > >      > > > >      > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > >      > > > >      > > > >      > > > >      > > > >      > > > > ------------------------------------------------------------------------ > >      > > Notice: This e-mail together with any attachments may contain > >      > > information of Ribbon Communications Inc. that is confidential > >      > and/or > >      > > proprietary for the sole use of the intended recipient. Any > review, > >      > > disclosure, reliance or distribution by others or forwarding > >     without > >      > > express permission is strictly prohibited. If you are not the > >      > intended > >      > > recipient, please notify the sender immediately and then > delete all > >      > > copies, including any attachments. > >      > > > >      > > > > ------------------------------------------------------------------------ > >      > > > >      > > _______________________________________________ > >      > > spring mailing list > >      > > spring@ietf.org > > >      > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > >      > > > >      > > >      > _______________________________________________ > >      > spring mailing list > >      > spring@ietf.org > > >      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > >      > > > > >     _______________________________________________ > >     spring mailing list > > spring@ietf.org > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti > > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > ---------------------------------------------------------------------- > > -- > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > ---------------------------------------------------------------------- > > -- > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > ------------------------------------------------------------------------ > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > > ------------------------------------------------------------------------ > From nobody Fri Aug 14 08:32:23 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD803A0EBA for ; Fri, 14 Aug 2020 08:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=E6hjSqy9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RNuakF1s 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 ZRtNS8ITOfs0 for ; Fri, 14 Aug 2020 08:32:15 -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 95D663A0E45 for ; Fri, 14 Aug 2020 08:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=104047; q=dns/txt; s=iport; t=1597419135; x=1598628735; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x8IpjVOb4kqNPuMI5SACqiwYuSdq/CuZQNUYXyolXpI=; b=E6hjSqy9QzA6m12ETF3Y/vYRf7IAmgc2Uvcipyr22M82UzKRNyYOKwVk 1rxfIhyOpxjn/VdxMKECzXV/DsiIAmaP4PXufT75mp0+oL4tmeNSEhEjE HvPNadS28CGZ16XjmBdgWGpxCwBwcXZTpV7mAIXSk0pRUUYdS/BWFqtT5 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AlhtobxLjmGjVVWECztmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK8/llXDW8PQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoK0JfHoD1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApCABmrTZf/4gNJK1VCh0BAQEBCQE?= =?us-ascii?q?SAQUFAUCBSoEjLykoB3BYLywKhgqBaQONVIECl2WBQoERA1ACAwsBAQEMAQE?= =?us-ascii?q?YAQkHBAIEAQGECEQCgkcCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAwE?= =?us-ascii?q?BARAIARITAQEsAQoBBAcCAgIBCBEEAQEBIAEGBxYRCxQJCAIEAQ0FCBqDAAW?= =?us-ascii?q?Bfk0DDiABDqdoAoE5iGF0gTSDAQEBBYEzAQMCDgMPL4MnGIIOCQWBM4JxiA2?= =?us-ascii?q?BAYEeGoFBPyZpAQFDgU8uGzU+glwBAQIBARWBEQEHCwEjBQcRBwEFAQkCBoM?= =?us-ascii?q?Mgi2PRQcSBwMGKolMgx+IPZByCoJiiGOFfFCFCIYJgn82bYg4k0WFVosJgVm?= =?us-ascii?q?DaoZYhTmLFYQsAgQCBAUCDgEBBYFqIw1acHAVO4JpCRYxFwINiFqFIiMMF4E?= =?us-ascii?q?CAQIMgj2EPlaFCQE4dAIBAQEVARwCBgoBAQMJfI1gBYEwATRcAQE?= X-IronPort-AV: E=Sophos;i="5.76,312,1592870400"; d="scan'208,217";a="526705486" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 15:32:12 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EFWCXx000575 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 15:32:12 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 10:32:11 -0500 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.1497.2; Fri, 14 Aug 2020 11:32:10 -0400 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.1497.2 via Frontend Transport; Fri, 14 Aug 2020 10:32:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XHEvYwjEpFU8bHEh629XcQxSC4CsPvEauAdSE5vMHDiMUocUNHA6oOxyJ5ol0PVTzqtGPTq/HFDHbxYbCiHOG3Vyzf/mgmfzncQghQEUpZurKp2O76Y6DCjA8bdXSWpBZyXH2i1eBrLdeDrCETH2vao9xJb8r5d0YSjCPkitp1AOIpFaUOFDbh78HiWbX3kr6fy8hfRdNytm+bhZWk07zPVF0elwlua8nFScZoHR1rvH5LhUXJp4K/UlCINWiyZIvmjq34F2QBZSXJYksMM7qGfeO02Z7jwGyo6l35VgBZ21Oh3DFaSpgmLuXrzXv8yxODUp192Yv7LxAmHFLWkngg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RHYVo4qjqWDzUwSLPRIu3J3QVtpZ29Ov6HgzQfvLn6w=; b=HmhIl/axS4xq+mKH87zR1VzIVyFM/uIBg2pXj5d19Sp62A7L93qMEIdNMDLYgfB9CkcUB4KthpDYJ9wkpI0indczuwTcfPoGX1benuYsCvDzm47ffFmT3wkculldZIZgoMKfjIrpY2lZcwuyfe8QTwlrd8KZdWs6GkUJdpv0tt0azfXFGtmr/6dgkKTo4niowwlzx6jeZxxlfYKqv9QTs9N8XzJPYNh9c9RLsH0sTcTUpvFe68jDboDiNuXshHWXNrdhW24+f7W+TtnWIfMTBrYlk9kfDrCKye2TIYcKoh3MIBMtkA7jDQWlPBKgK7K00k+GXUQ2QixqH0i5+FHEZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RHYVo4qjqWDzUwSLPRIu3J3QVtpZ29Ov6HgzQfvLn6w=; b=RNuakF1s8ZyOfHQkYLernW5DWoFVasn13luWd2SdGsLbaSzX402sABK2HX2DsPF3keIwKSCI8MZcU+UxOPetHC+MWAvpqP+IlobFdJTTY+wA8NdV/SzqHXWkPU7b/Vu8ZrQIJzVA365xkUuvZ8MUTrAWaBP0H4GqBQfwcicUqPQ= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2368.namprd11.prod.outlook.com (2603:10b6:300:7a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 15:32:08 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 15:32:07 +0000 From: "Ketan Talaulikar (ketant)" To: Alexander Vainshtein , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , Robert Raszuk CC: "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfGJGLEw80LFEa7R79kiStyh6klun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAFLgAgAB1eACAD4BY8IAAFTmAgAAGD1CAABtZgIAACTzg Date: Fri, 14 Aug 2020 15:32:07 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> , , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rbbn.com; dkim=none (message not signed) header.d=none;rbbn.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe37f6ae-a5c4-4b3d-cd4c-08d840673480 x-ms-traffictypediagnostic: MWHPR1101MB2368: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(86362001)(9686003)(9326002)(53546011)(316002)(6506007)(5660300002)(8936002)(26005)(7696005)(30864003)(52536014)(83380400001)(110136005)(55016002)(186003)(166002)(966005)(66946007)(66556008)(64756008)(66476007)(478600001)(66446008)(45080400002)(33656002)(4326008)(8676002)(71200400001)(2906002)(76116006)(491001)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570C29F44A9234A5B0729D0C1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe37f6ae-a5c4-4b3d-cd4c-08d840673480 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 15:32:07.7634 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7TJsYOBnTfAOMDq73mwIkIAcVhyZch5HI5VASBrnBTlRnipLB1OMMymGKqFVK2xzT+MBJGbqVxFr4S/AQ3sbEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2368 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 15:32:21 -0000 --_000_MW3PR11MB4570C29F44A9234A5B0729D0C1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, The service node advertises its own Prefix SID. The service function that t= his service node implements does not require any context (i.e. all packets = arriving at the node are subjected to that service). Therefore the service = node does not need to receive a packet with it's own Prefix SID. Thus, we cannot assume that when PHP is used, then the SID is only associat= ed with a topological instruction. Hope that clarifies? Thanks, Ketan From: Alexander Vainshtein Sent: 14 August 2020 20:24 To: Ketan Talaulikar (ketant) ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston@liqu= idtelecom.com ; Robert Raszuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Ketan, and all, I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are a= dvertised with PHP can ONLY represent topological instructions in SR-MPLS = - because the advertising node will not receive them and therefore can hard= ly be expected to associate any service function with them. This is complementary to what you have said. Hope this clarifies my position. What, if anything, did I miss? Regards, Sasha Get Outlook for Android ________________________________ From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 16:23 To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: RE: [spring] Spring protection - determining applicability ________________________________ NOTICE: This email was received from an EXTERNAL sender ________________________________ Hi Sasha, If the service does not need any additional context (e.g. a firewall that j= ust applies locally configured default rules on it), then I don't see why P= HP could not be done for a Prefix SID associated with a service node. Also, I didn't follow the point that you were trying to make about Adj-SIDs= . Thanks, Ketan From: Alexander Vainshtein > Sent: 14 August 2020 18:24 To: Ketan Talaulikar (ketant) >; = Joel M. Halpern >; Alexande= r Vainshtein >; Shraddha Hegde >= ; EXT-Andrew.Alston@liquidtelecom.com >; Robert Raszuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi all, Regarding the statement "Prefix SID could be just a topological instruction= or may also be used to steer the flow to a node which is applying a servic= e function to it": I think that in SR-MPLS a Node SID that is advertised with PHP aciton can b= e safely considered as "just a topological instruction" by the PLR because = the originating node will not receive it. The same applies to Adj-SDIs. My 2c. Get Outlook for Android ________________________________ From: spring > on b= ehalf of Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 15:00 To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi All, I would like to share a different perspective on this. First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1]. This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being provided by t= he SR Policy. Awareness of that notion exists at the SR Policy headend and/= or computation-node. We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of the SLA requ= irement for picking that link. We do not have such a notion for Prefix SIDs= . One can say that we could introduce signalling (e.g. a B flag) to indicat= e whether a Prefix SID can be bypassed or not. This provides the opportunit= y for the computation to use one or the other flavor depending on the natur= e of the SLA for the SR Policy. I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able". As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or not. For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to bypass it. = When this mechanism is used along side SRTE path monitoring mechanisms, it = enables the headend to detect the failure and fallback to an alternate path= using the path protection approach. This is something that is described an= d in use in deployments today [1].. Thanks, Ketan [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9 [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9.3 -----Original Message----- From: spring > On B= ehalf Of Joel M. Halpern Sent: 04 August 2020 20:25 To: Alexander Vainshtein >; Shraddha Hegde >; EXT-Andrew.Alston@liqui= dtelecom.com >; Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability There are, as far as I can tell, a number of ways to address this family of= related questions. What struck me, and prompted the starting question, was that none of them w= ere spelled out. I see lots of interesting ideas / proposals. Some of them are compatible with others. Some are not. It would be good if we could reach agreement on how we thought it should be= handled. Thank you, Joel On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > Hi all, > > I am still not sure that the problem of bypass going thru undesirable > links/nodes exists in the case of topological SIDs. > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > ) has been successfully deployed > for many years before SR-MPLS has been introduced. What's more, > signaling of bypass tunnels he PLR usually did not include any of the > constraints used for computing of any specific LSP that the bypass LSP > would protect - because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node. > > From my POV the only difference between this behavior and that > introduced by the "bypassing" drafts in SR is that, in the case of > RSVP-TE, the operator would explicitly indicate, as part of LSP > signaling, whether it would or would not use FRR; LSPs that would not > use FRR would then drop traffic rather than delivering it the wrong way. > > Such an option indeed does not exist in SR-TE today, but would be easy > to provide if so desired IMHO. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:* spring > = *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM > *To:* EXT-Andrew.Alston@liquidtelecom.com > >= ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > All, > > This is a very interesting discussion and thanks to Joel for starting > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized either by defining a flex-algo > avoiding those > > Nodes and links or by using a stack of unprotected adj-sids that avoid > restricted nodes and links. When a stack of adj-sids is used to > realize the path, the head-end based (sBFD) protection mechanisms can be = applied. > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection > is in use or not. > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* spring > > *= On Behalf Of *Andrew Alston > *Sent:* Tuesday, August 4, 2020 5:41 AM > *To:* Robert Raszuk > > *Cc:* spring@ietf.org ; J= oel M. Halpern > > > *Subject:* Re: [spring] Spring protection - determining applicability > > *[External Email. Be cautious of content]* > > Robert this is actually far more difficult when - it can be an entire > (long) series of nodes that need to be avoided. > > It could potentially be made to work but I'd worry that to do this - > you'd have to stack 10 - 20 - 30 negative labels - and that wouldn't > be viable. > > It's easier to use algorithms and adjacency sids and other such things > to calculate paths - the biggest trick is about the stack depth. When > you have this need for node avoidance - the need for 10+ label depth > is critical - unless you wanna be applying one hell of a lot of > binding labels along the way which is a nightmare. > > But to answer your question, is this a common use case - it's a use > case that most of the people I discuss this with certain have - I cant > comment on a global scale, or for anyone else, but every indication I > have is that yes - its something people need, and want > > Andrew > > *From:* Robert Raszuk > > *Sent:* Tuesday, 4 August 2020 01:27 > *To:* Andrew Alston > > > *Cc:* Joel M. Halpern > >; spring@i= etf.org > > *Subject:* Re: [spring] Spring protection - determining applicability > > Is this a common use case ie. "but rather - which nodes / network > segments it can never touch or flow through." > > If so perhaps its time to define notion of *negative-SID* ie. list in > the packet resources which given packet MUST not ever traverse. > > Put in the packet set of nodes or links which the packet should never > traverse. > > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR) > > Best, > R. > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > wrote: > > So - > > One of the use cases, in fact, some very major use cases in any > spring technology for us revolve around the following > > a.The explicit avoidance of certain nodes > > b.The explicit avoidance of certain sections of the network > > Anything that could result in that explicit avoidance being violated > - would create, shall we say significant problems. > > Much of the use case is not a case of which nodes the packets flow > through - but rather - which nodes / network segments it can never > touch or flow through. Effectively, to be used as a technology to > avoid certain things for specific reasons. > > This is also one of the reasons for needing such deep label stacks - > this kind of detailed path programming tends to deepen the stack > because you sometimes have to be pretty explicit. > > It is absolutely critical to us that this functionality is there - > and that we can avoid situations which could cause traffic to > accidently hit things explicitly avoided. > > I wish I could be more specific than this, but it is what it is. > > Thanks > > Andrew > > *From:* spring > > = *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > > *Cc:* spring@ietf..org > *Subject:* Re: [spring] Spring protection - determining > applicability > > (Since the thread has gotten long enough, reiterating that this is as= a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks tha= t > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clea= r > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve Qo= S. > > Let's be clear. I am not arguing that this is not a good idea. It is = a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two > observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you > better > > apply IP encapsulation to that node.. I don't think IP > encapsulation can > > be hijacked today such that destination address of the packet is > ignored. > > > > B) Have you seen any IP network where upon topology change (link > or node > > failure) you suddenly start dropping flows in spite of SPT offerin= g > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > > wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is > restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex t= e > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the pac= ket > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding > service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and > "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological > instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > >= > > > > > > draft) unsurprisingly represent "service" instructions > > > > > > 2.Segments that represent topological instructions can be bypass= ed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, tw= o > > > > > > topological segments are defined: the IGP-Adjacency segment and = the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and th= e > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Sectio= n > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > > > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous > sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When = the > > > > > > provider edge routers exchange service labels via BGP or som= e > > other > > > > > > non-IGP mechanism the bottom label is not understood in the = IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 > >] > is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between "topological" an= d > > > "service" instructions is broken are indeed problematic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such "combined" SIDs could be prevente= d > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > > > > On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > > >; > spring@ietf.org > > > Subject: Re: [spring] Spring protection - determining applicabil= ity > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in th= e > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus > normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicabili= ty > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the variou= s > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, f= or > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new pat= h > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we = are > > > > > > > deliberately vague about what nodes can do when asked suitabl= y.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > > >> > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2 > > > > > > > > > > > > > > > > F%2Fwww.ietf.org > > > > >%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= --- > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any revi= ew, > > > disclosure, reliance or distribution by others or forwarding > without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete = all > > > copies, including any attachments. > > > > > > ---------------------------------------------------------------------= --- > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org = > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <= mailto:spring@ietf.org> > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > ---------------------------------------------------------------------- > -- > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ---------------------------------------------------------------------- > -- _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ________________________________ Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for th= e sole use of the intended recipient. Any review, disclosure, reliance or d= istribution by others or forwarding without express permission is strictly = prohibited. If you are not the intended recipient, please notify the sender= immediately and then delete all copies, including any attachments. ________________________________ --_000_MW3PR11MB4570C29F44A9234A5B0729D0C1400MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,=

&nbs= p;

The servi= ce node advertises its own Prefix SID. The service function that this servi= ce node implements does not require any context (i.e. all packets arriving = at the node are subjected to that service). Therefore the service node does not need to receive a packet with it’= ;s own Prefix SID.

&nbs= p;

Thus, we = cannot assume that when PHP is used, then the SID is only associated with a= topological instruction.

&nbs= p;

Hope that= clarifies?

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halp= ern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>= ;; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com&= gt;; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= o:p>

 

Ketan, and all,

I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that = are advertised with PHP can  ONLY represent topological instructions i= n SR-MPLS - because the advertising node will not receive them and therefore can hardly be expected to associate any ser= vice function with them.

 

This is complementary to what you have said.

 

Hope this clarifies my position.

What, if anything, did I miss?

 

Regards,

Sasha

 

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Friday, August 14, 2020, 16:23
To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alston@li= quidtelecom.com; Robert Raszuk
Cc: spring@ietf.org
Subject:= RE: [spring] Spring protection - determining applicability=



NOTICE: This email was received from an EXTERNAL sen= der

 

Hi Sasha,

 

If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don’t see why PHP could not be done for a Prefix SID associat= ed with a service node.

 

Also, I didn’t follow the point that you were = trying to make about Adj-SIDs.

 

Thanks,

Ketan

 

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com= >; Shraddha Hegde <shraddha@junipe= r.net>; EXT-Andrew.Alston@li= quidtelecom.com <= Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

 

Hi all,

Regarding the statement "Prefix SID could be just a topological i= nstruction or may also be used to steer the flow to a node which is applyin= g a service function to it":

 

 

I think that in SR-MPLS a Node SID that is advertised with PHP aciton = can be safely considered as "just a topological instruction" by t= he PLR because the originating node will not receive it.

The same applies to Adj-SDIs.

 

My 2c.

 

From: spring <spring-bounces@ietf.org> on behalf of Ketan Talaulik= ar (ketant) <keta= nt=3D40cisco.com@dmarc.ietf.org>
Sent: Friday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@li= quidtelecom.com; Robert Raszuk
Cc: spring@ietf.org
Subject:= Re: [spring] Spring protection - determining applicability=

 

Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being pro= vided by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

-----Original Message-----
From: spring <spring-bounces@= ietf.org> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha=3D40juniper.net@dmarc= .ietf.org>; EXT-Andrew.Alston@li= quidtelecom.com <= Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org; Joel M. Halpern= <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of= related questions.
What struck me, and prompted the starting question, was that none of them w= ere spelled out.  I see lots of interesting ideas / proposals.
Some of them are compatible with others.   Some are not.
It would be good if we could reach agreement on how we thought it should be= handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirable =
> links/nodes exists in the case of topological SIDs.
>
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
> <https://clicktime.syma= ntec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%= 2Frfc4090>) has been successfully deployed
> for many years before SR-MPLS has been introduced. What’s more, =
> signaling of bypass tunnels he PLR usually did not include any of the =
> constraints used for computing of any specific LSP that the bypass LSP=
> would protect – because in the Facility Protection mode the same=
> bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>  From my POV the only difference between this behavior and that <= br> > introduced by the “bypassing” drafts in SR is that, in the= case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use FRR; LSPs that would not =
> use FRR would then drop traffic rather than delivering it the wrong wa= y.
>
> Such an option indeed does not exist in SR-TE today, but would be easy=
> to provide if so desired IMHO.
>
> Did I miss something substantial?
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
> *From:* spring <spring-b= ounces@ietf.org> *On Behalf Of *Shraddha Hegde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andre= w.Alston@liquidtelecom.com
> <Andrew.Alston@l= iquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
> *Cc:* spring@ietf.org; Joel M. = Halpern <jmh@joelhalpern.com&= gt;
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> All,
>
> This is a very interesting discussion and thanks to Joel for starting =
> this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized  either by defining a flex= -algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avoid=
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
> failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* spring <sp= ring-bounces@ietf.org
> <mailto:spring-bounc= es@ietf.org>> *On Behalf Of *Andrew Alston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Cc:* spring@ietf.org <mailto:spring@ietf.org>; Joel M. Halpe= rn
> <jmh@joelhalpern.com <mai= lto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> *[External Email. Be cautious of content]*
>
> Robert this is actually far more difficult when – it can be an e= ntire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I’d worry that to do th= is –
> you’d have to stack 10 – 20 – 30 negative labels = 211; and that wouldn’t
> be viable.
>
> It’s easier to use algorithms and adjacency sids and other such = things
> to calculate paths – the biggest trick is about the stack depth.=   When
> you have this need for node avoidance – the need for 10+ label d= epth
> is critical – unless you wanna be applying one hell of a lot of =
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case – it̵= 7;s a use
> case that most of the people I discuss this with certain have – = I cant
> comment on a global scale, or for anyone else, but every indication I =
> have is that yes – its something people need, and want
>
> Andrew
>
> *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
> <mailto:Andr= ew.Alston@liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jmh@joelhalpern.= com>>; spring@ietf.org
> <mailto:spring@ietf.org><= br> > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> Is this a common use case ie.  "but rather – which nod= es / network
> segments it can never touch or flow through."
>
> If so perhaps its time to define notion of *negative-SID* ie. list in =
> the packet resources which given packet MUST not ever traverse. >
> Put in the packet set of nodes or links which the packet should never =
> traverse.
>
> That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Al= ston@liquidtelecom.com
> <mailto:Andr= ew.Alston@liquidtelecom.com>> wrote:
>
>     So –
>
>     One of the use cases, in fact, some very major= use cases in any
>     spring technology for us revolve around the fo= llowing
>
>     a.The explicit avoidance of certain nodes
>
>     b.The explicit avoidance of certain sections o= f the network
>
>     Anything that could result in that explicit av= oidance being violated
>     – would create, shall we say significant= problems.
>
>     Much of the use case is not a case of which no= des the packets flow
>     through – but rather – which nodes= / network segments it can never
>     touch or flow through.  Effectively, to b= e used as a technology to
>     avoid certain things for specific reasons.
>
>     This is also one of the reasons for needing su= ch deep label stacks –
>     this kind of detailed path programming tends t= o deepen the stack
>     because you sometimes have to be pretty explic= it.
>
>     It is absolutely critical to us that this func= tionality is there –
>     and that we can avoid situations which could c= ause traffic to
>     accidently hit things explicitly avoided.
>
>     I wish I could be more specific than this, but= it is what it is.
>
>     Thanks
>
>     Andrew
>
>     *From:* spring <spring-bounces@ietf.org
>     <mailto:spring-bounces@ietf.org>> *On Behalf Of *Joel M. Halp= ern
>     *Sent:* Monday, 3 August 2020 21:36
>     *To:* Robert Raszuk <robert@raszuk.net <= mailto:robert@raszuk.net>> >     *Cc:* spri= ng@ietf..org <mailto:spring@ietf.= org>
>     *Subject:* Re: [spring] Spring protection - de= termining
> applicability
>
>     (Since the thread has gotten long enough, reit= erating that this is as a
>     participant, not a WG chair.)
>
>     Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
>     choose to drop packets. For all sorts of reaso= ns.
>     I think there are likely other reasons why one= may not want a random
>     path rather than a chosen TE path. I think it = is important we be clear
>     about what constraints may be / are violated w= hen we tell people they
>     have this tool (protective rerouting) that is = intended to preserve QoS.
>
>     Let's be clear. I am not arguing that this is = not a good idea. It is a
>     good idea. And useful. I am trying to figure o= tu what combination of
>     additional mechanisms and clear descriptions w= ill lead to everyone
>     getting the behavior they expect (which may no= t be the behavior they
>     desire, but sometimes is the best we can do.)<= br> >
>     Yours,
>     Joel
>
>     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>      > Joel,
>      >
>      > Are we still talking about IP netwo= rks here ? Or perhaps some hard
>      > slicing with real resource reservat= ions or detnets ?
>      >
>      > Because if we are talking = ;about IP networking I have two
>     observations:
>      >
>      > A) If you need to traverse via a sp= ecific node (ie. firewall) you
>     better
>      > apply IP encapsulation to that node= .. I don't think IP
>     encapsulation can
>      > be hijacked today such that destina= tion address of the packet is
>     ignored.
>      >
>      > B) Have you seen any IP network whe= re upon topology change (link
>     or node
>      > failure) you suddenly start dr= opping flows in spite of SPT offering
>      > perhaps few ms longer path with 10 = ms more jitter ?
>      >
>      > Or are some SR marketing slides pro= mise to turn IP networks in
>      > something new ? Worse ... do t= hey mention path quality guarantees,
>      > resource reservations ? I hope= not.
>      >
>      > Thx,
>      > R.
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.c= om
>     <mailto:jmh@joelhalpern.com%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:
>      >
>      > Well less serious for TE SIDs, I am= not sure the problem is
>     restricted
>      > to just service SIDs.
>      >
>      > Suppose that the PCE has specified = the path to meet some complex te
>      > objective.  The bypass node ha= s no way of knowing what those
>      > constraints
>      > were.  And for some kinds of t= raffic, it is better to drop the packet
>      > than to deliver it outside the enve= lop.  I suspect that the right
>      > answer
>      > to this is "too bad".&nbs= p; If so, as with the distinction regarding
>     service
>      > nodes, we should say so, shouldn't = we?
>      >
>      > Yours,
>      > Joel
>      >
>      > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
>      > > Mach, Joel and all,
>      > >
>      > > I think that in most cases: >      > >
>      > > 1.There is clear differentiati= on between "topological" and
>     "service"
>      > > instructions in SID advertisem= ents. E.g.:
>      > >
>      > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
>      > > corresponding IGP advertisemen= ts) represent topological
>     instructions
>      > >
>      > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
>      > >
>      >
>     <https://clicktime.symantec.com/3= CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fht= ml%2Fdraft-ietf-bess-srv6-services-04
>     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi= 6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.o= rg%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21= S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>= >
>      >
>      > > draft) unsurprisingly represen= t “service” instructions
>      > >
>      > > 2.Segments that represent topo= logical instructions can be bypassed,
>      > > while segments that represent = service instructions require
>      > alternative
>      > > protection mechanisms.
>      > >
>      > > This view seems to be aligned = with RFC 8402
>      > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZ= y6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
>     <https://clicktim= e.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F%2Furldefense.com%= 2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>= ;>
>     that says in Section 1:
>      > >
>      > >     In the cont= ext of an IGP-based distributed control plane, two
>      > >
>      > > topological segments are defin= ed: the IGP-Adjacency segment and the
>      > >
>      > >     IGP-Prefix = segment.
>      > >
>      > >     In the cont= ext of a BGP-based distributed control plane, two
>      > >
>      > > topological segments are defin= ed: the BGP peering segment and the
>      > >
>      > >     BGP-Prefix = segment.
>      > >
>      > > In the case of SR-MPLS this di= fferentiation is assumed in Section
>      > 3.4 of
>      > > the Node Protection for SR-TE = Path
>      > >
>      >
>     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2= F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-= for-sr-te-paths-07%23section-3.4
>     <https://clicktime= .symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%2Furldefense.com%2= Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-n= ode-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S= 0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>&= gt;
>      >
>      > > draft that says:
>      > >
>      > >     The node pr= otection mechanism described in the previous
>     sections
>      > >
>      > >     depends on = the assumption that the label immediately below
>      > the top
>      > >
>      > > label in the label stack is un= derstood in the IGP domain.  When the
>      > >
>      > >     provider ed= ge routers exchange service labels via BGP or some
>      > other
>      > >
>      > >     non-IGP mec= hanism the bottom label is not understood in the IGP
>      > >
>      > >     domain.
>      > >
>      > >     The egress = node protection mechanisms described in the draft
>      > >
>      > >     [RFC8679 &l= t;https://click= time.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%2F%2Fdatatracker.= ietf.org%2Fdoc%2Fhtml%2Frfc8679
>     <http= s://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F%2Furl= defense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679= __%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8Ak= TRDuiDo8MGipXc%24>>]
>     is
>      > > applicable to this use case an= d no additional changes
>      > >
>      > >     will be req= uired for SR based networks
>      > >
>      > > The scenarios in which  d= ifferentiation between “topological” and
>      > > “service” instruct= ions is broken are indeed problematic. E.g.,
>      > consider
>      > > the use case in which a Node S= ID in the ERO of a SR-TE path
>      > identifies a
>      > > node that acts as a firewall f= or all packets it receives, i.e.,
>      > provides
>      > > the firewall service without a= ny dedicated service SID
>      > identifying it.
>      > > One could say that the Node SI= D of such a node would combine
>      > topological
>      > > and service instructions thus = breaking the differentiation
>      > between the two.
>      > >
>      > > I am not sure if usage of such= “combined” SIDs could be prevented
>      > or at
>      > > least discouraged.
>      > >
>      > > If not, providing an ability t= o identify such SIDs in the
>      > advertisement
>      > > mechanisms would be useful IMH= O.
>      > >
>      > > My 2c,
>      > >
>      > > Sasha
>      > >
>      > > Office: +972-39266302
>      > >
>      > > Cell:    &= nbsp; +972-549266302
>      > >
>      > > Email: Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>
>      > <mailto:Alexander.Vainshtein@ecitele.com>
>      > >
>      > > -----Original Message-----
>      > > From: spring <spring-bounces@ietf.org
>     <mailto:spring-bounces@ietf.org%0b>>
>     <mailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
>      > > Sent: Monday, August 3, 2020 6= :30 AM
>      > > To: Joel M. Halpern <jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.com>>;
>     spring@ietf= .org <mailto:spring@ietf.org&= gt; <mailto:spring@ietf.org> >      > > Subject: Re: [spring] Spring p= rotection - determining applicability
>      > >
>      > > Hi Joel,
>      > >
>      > > I think this is a good point t= hat may not be discussed in the
>      > past. And
>      > > I also don't think there is a = "can be bypassed" indication in the
>      > > routing advertisement for now.=
>      > >
>      > > IMHO, the information advertis= ed by routing is neutral, such
>      > information
>      > > (can or cannot be bypassed) is= more path specific, thus
>     normally the
>      > > controller should be responsib= le for deciding whether/which SID
>      > can be
>      > > bypassed.
>      > >
>      > > Best regards,
>      > >
>      > > Mach
>      > >
>      > >  > -----Original Messa= ge-----
>      > >
>      > >  > From: spring [mailt= o:spring-bounces@ietf.org
>      > <mailto:spring-bounces@ietf.org>
>     <mailto:spring-bounces@ietf.or= g%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>]
>     On Behalf Of Joel M.
>      > >
>      > >  > Halpern
>      > >
>      > >  > Sent: Monday, Augus= t 3, 2020 7:51 AM
>      > >
>      > >  > To: spring@ietf.org <mailto:spring@ietf.org>
>     <mailto:= spring@ietf.org>
>      > <mailto:spring@ietf.org <mailto:spring= @ietf.org
>     <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org= >>>
>      > >
>      > >  > Subject: [spring] S= pring protection - determining applicability
>      > >
>      > >  >
>      > >
>      > >  > (WG Chair hat Off, = this is merely a note from a slightly
>      > confused WG
>      > >
>      > >  > participant.)
>      > >
>      > >  >
>      > >
>      > >  > I have been reading= the various repair drafts, and the various
>      > >
>      > >  > networks programmin= g and service programming draft, and I am
>      > trying to
>      > >
>      > >  > figure out one aspe= ct of the combination.
>      > >
>      > >  >
>      > >
>      > >  > How does a node tha= t is doing some form of bypass (suppose, for
>      > >
>      > >  > simplicity, it is N= ode N2 deciding to bypass the next SID for
>      > a failed
>      > >
>      > >  > node N3) know that = it is safe to do so?
>      > >
>      > >  >
>      > >
>      > >  > If the path was jus= t for TE, then it is "safe" if the new path
>      > meets
>      > >
>      > >  > the TE criteria.&nb= sp; or maybe it is safe if it is even close, as
>      > long as
>      > >
>      > >  > it is not used for = too long.
>      > >
>      > >  >
>      > >
>      > >  > But what if the nod= e were a Firewall, included to meet legal
>      > > requirements?
>      > >
>      > >  > Or was some other n= ecessary programmatic transform (wince we are
>      > >
>      > >  > deliberately vague = about what nodes can do when asked suitably.)
>      > >
>      > >  >
>      > >
>      > >  > Is there some "= ;can be bypassed" indication in the routing
>      > >
>      > >  > advertisements that= I missed?
>      > >
>      > >  >
>      > >
>      > >  > Thank you,
>      > >
>      > >  > Yours,
>      > >
>      > >  > Joel
>      > >
>      > >  >
>      > >
>      > >  > ___________________= ____________________________
>      > >
>      > >  > spring mailing list=
>      > >
>      > >  > spring@ietf.org <= mailto:spring@ietf.org>
>     <mailto:= spring@ietf.org>
>      > <mailto:spring@ietf.org <mailto:spring= @ietf.org
>     <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org= >>>
>      > >
>      > >  >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
>     <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuX= y2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.syman= tec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6= yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%= 24>
>      > >
>      >
>     <https://clicktime.symantec.= com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
>     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ= 3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.s= ymantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%= 21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozo= QiAHk%24>>
>      > >
>      > >  > F%2Fwww.ietf.org >     <https://clicktime.symantec.com/39NznmY= BtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fw= ww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp= 6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>      > <h= ttps://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%2F2= Fwww.ietf.org
>     <https://clicktime.symantec.com/39N= znmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2= F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZ= Hgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring<= br> >      > >
>      > > ______________________________= _________________
>      > >
>      > > spring mailing list
>      > >
>      > > spring@ietf.org <mailto:spri= ng@ietf.org>
>     <mailto:= spring@ietf.org> <mailto:sp= ring@ietf.org
>     <= mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>>
>      > >
>      > >
>      >
>     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps= %3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU= 4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2= Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQ= xgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>      > >
>      > >
>      > >
>      > >
>      >
>     ----------------------------------------------= --------------------------
>      > > Notice: This e-mail together w= ith any attachments may contain
>      > > information of Ribbon Communic= ations Inc. that is confidential
>      > and/or
>      > > proprietary for the sole use o= f the intended recipient. Any review,
>      > > disclosure, reliance or distri= bution by others or forwarding
>     without
>      > > express permission is strictly= prohibited. If you are not the
>      > intended
>      > > recipient, please notify the s= ender immediately and then delete all
>      > > copies, including any attachme= nts.
>      > >
>      >
>     ----------------------------------------------= --------------------------
>      > >
>      > > ______________________________= _________________
>      > > spring mailing list
>      > > spring@ietf.org <mailto:spri= ng@ietf.org> <mailto:spring@ie= tf.org>
>      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://c= licktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Furldefen= se.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o5KlPnbj%24>
>      > >
>      >
>      > ___________________________________= ____________
>      > spring mailing list
>      > = spring@ietf.org <mailto:spring@ie= tf.org> <mailto:spring@ietf.or= g>
>      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>     <https://c= licktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Furldefen= se.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o5KlPnbj%24>
>      >
>
>     ______________________________________________= _
>     spring mailing list
>     spring@ietf= .org <mailto:spring@ietf.org&= gt;
>     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>    
> <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGE= q16H2?u=3Dhttps%3A%
> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Fl= isti
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> ----------------------------------------------------------------------=
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or =
> proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
> recipient, please notify the sender immediately and then delete all > copies, including any attachments.
> ----------------------------------------------------------------------=
> --

_______________________________________________
spring mailing list
spring@ietf.org
https://clicktime.s= ymantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
spring@ietf.org
https://clicktime.s= ymantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Fspring

 

 

Notice: This e-mail together with any attachments may = contain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or f= orwarding without express permission is strictly prohibited. If you are not= the intended recipient, please notify the sender immediately and then dele= te all copies, including any attachments.

 

--_000_MW3PR11MB4570C29F44A9234A5B0729D0C1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 08:42:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7533A0FE9 for ; Fri, 14 Aug 2020 08:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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=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 xTJI5R8R0Cic for ; Fri, 14 Aug 2020 08:42:48 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB45A3A100E for ; Fri, 14 Aug 2020 08:42:47 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id jp10so10413425ejb.0 for ; Fri, 14 Aug 2020 08:42:47 -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=VsVB2/M9iZ+JPo1lxDG10lrKMvqhryDuZdVStX9niLs=; b=bVCCrGb3UAITctQ25YKCpb+ikRMkCjLnrWNIP6KW508yXs/2c67Jc0tAm0Ib3auZ2l y1EqOKhfeHENUhMbAy+B7572CiZDuqGrspkhYKflXjIVmwSiYymeY9gz2hzc/e9wCVGD ys0zJAHGVlTKR21v9/BGDrI22F5qSyXvsghrLm9aI0tcF4y/aZTSF6oBhbkjd8bFCcE6 lcyJDQjpF+qpSoEsO+RFZRQlW9taUhJy5piI2wRkS0EKG+cZsNgtlR4NQDE9n4nXDTqn MsobObj10Mos2Rr6UlQb2i8zHUHbx4FbMcp0ezhqxDPtu/V23xwSUNt2gJxX3PpE8YhX +Crg== 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=VsVB2/M9iZ+JPo1lxDG10lrKMvqhryDuZdVStX9niLs=; b=fay5/2qluhXdeERKhXdvNkkwY+AMtFdGVpGvuqAgNxzb4UOfpWtTQrB0dlVL9LdtN0 00TBeuCAmosFNYsP9C1f2DU74mB+REl3eXrmlnIo6kH/7VVik4maX4JQyTAnGBIoDLhF Gu8fKYy77g9MEKJSVqWrqB7Gb2pPd3WnmuSgw4ZByDqTGmN06KFf2QvDgGmt7py20huP IAT13uzU4Le+GOQMSSnRfj5W5ZN9RWGZ69przVYaY4N5Q6rTAr1V7IOsnNwrf8zJnbky 0LlI1ovKchwzDfCuZElWFt5MIyx5Qml1RWWsvtdjWzhezM4UgcOiNIFhAqcc32Co7LOs XSLw== X-Gm-Message-State: AOAM533oXoe720YcVMkX5e4s4ColUz54IscYmwJks2Evp8NT0cIt7bbI S6kDcK9vNvsyvpHRXihsw/JuK9XvexegO8v7YEc4xA== X-Google-Smtp-Source: ABdhPJwqrRvLS4X+FxgXSNhZcMBql0muuGnu2tl00soejTuPkW4MhBFS12Uh+kTJNhs0MCq37fnN4Yb2LGzyzhwE5WA= X-Received: by 2002:a17:907:94ca:: with SMTP id dn10mr2970998ejc.110.1597419766184; Fri, 14 Aug 2020 08:42:46 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Fri, 14 Aug 2020 17:42:36 +0200 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: Alexander Vainshtein , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b894f205acd84576" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 15:42:54 -0000 --000000000000b894f205acd84576 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ketan, While I completely agree with your note the consequences of it are pretty sevre. Unless we signal which prefix SID is protection eligible and which is not how would other nodes know if they can protect it or not ? It seems that today's safe thing is not to apply any node protection on SR flows at the PLRs then. And link protection MUST assure that packets will arrive at the neighbor node via some other link regardless of further path towards destination. Is it correct ? Thx R On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) wrote: > Hi Sasha, > > > > The service node advertises its own Prefix SID. The service function that > this service node implements does not require any context (i.e. all packe= ts > arriving at the node are subjected to that service). Therefore the servic= e > node does not need to receive a packet with it=E2=80=99s own Prefix SID. > > > > Thus, we cannot assume that when PHP is used, then the SID is only > associated with a topological instruction. > > > > Hope that clarifies? > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 20:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Ketan, and all, > > I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are > advertised with PHP can ONLY represent topological instructions in SR-MP= LS > - because the advertising node will not receive them and therefore can > hardly be expected to associate any service function with them. > > > > This is complementary to what you have said. > > > > Hope this clarifies my position. > > What, if anything, did I miss? > > > > Regards, > > Sasha > > > > Get Outlook for Android > > > ------------------------------ > > *From:* Ketan Talaulikar (ketant) > *Sent:* Friday, August 14, 2020, 16:23 > *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* RE: [spring] Spring protection - determining applicability > > > > ------------------------------ > > NOTICE: This email was received from an EXTERNAL sender > ------------------------------ > > > > Hi Sasha, > > > > If the service does not need any additional context (e.g. a firewall that > just applies locally configured default rules on it), then I don=E2=80=99= t see why > PHP could not be done for a Prefix SID associated with a service node. > > > > Also, I didn=E2=80=99t follow the point that you were trying to make abou= t > Adj-SIDs. > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 18:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Alexander Vainshtein ; > Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.co= m > ; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi all, > > Regarding the statement "Prefix SID could be just a topological > instruction or may also be used to steer the flow to a node which is > applying a service function to it": > > > > > > I think that in SR-MPLS a Node SID that is advertised with PHP aciton can > be safely considered as "just a topological instruction" by the PLR becau= se > the originating node will not receive it. > > The same applies to Adj-SDIs. > > > > My 2c. > > > > Get Outlook for Android > > > > ------------------------------ > > *From:* spring on behalf of Ketan Talaulikar > (ketant) > *Sent:* Friday, August 14, 2020, 15:00 > *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi All, > > I would like to share a different perspective on this. > > First, thanks to Joel for bringing up the discussion. Clearly we need a > well-defined applicability statement for determining applicability of > protection for segment used in an SR Policy. Some of this is captured in > [1]. > > This is about local repair at a PLR. By it's very nature, the PLR does no= t > have a notion of how "strict or not" is the SLA that is being provided by > the SR Policy. Awareness of that notion exists at the SR Policy headend > and/or computation-node. > > We have protected and un-protected variants of adjacency SIDs to enable > the computation to pick or the other based on the "strictness" of the SLA > requirement for picking that link. We do not have such a notion for Prefi= x > SIDs. One can say that we could introduce signalling (e.g. a B flag) to > indicate whether a Prefix SID can be bypassed or not. This provides the > opportunity for the computation to use one or the other flavor depending = on > the nature of the SLA for the SR Policy. > > I have a problem and a concern in the assumption that PLRs can assume tha= t > the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) a= re > "bypass-able". > > As Joel and others have brought out, the Prefix SID could be just a > topological instruction or may also be used to steer the flow to a node > which is applying a service function to it. In order to support a mix of = SR > Policies of different SLAs (strict and not-strict), we need to enable the > choice of SIDs that indicates to the PLR whether they are "bypass-able" o= r > not. > > For the cases, where the SR Policy has a specific SLA, it is required for > nodes to drop the packets meant for the "active segment" than to bypass i= t. > When this mechanism is used along side SRTE path monitoring mechanisms, i= t > enables the headend to detect the failure and fallback to an alternate pa= th > using the path protection approach. This is something that is described a= nd > in use in deployments today [1].. > > Thanks, > Ketan > > [1] > https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9 > [2] > https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9.3 > > -----Original Message----- > From: spring On Behalf Of Joel M. Halpern > Sent: 04 August 2020 20:25 > To: Alexander Vainshtein ; Shraddha Hegde = < > shraddha=3D40juniper.net@dmarc.ietf.org>; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability > > There are, as far as I can tell, a number of ways to address this family > of related questions. > What struck me, and prompted the starting question, was that none of them > were spelled out. I see lots of interesting ideas / proposals. > Some of them are compatible with others. Some are not. > It would be good if we could reach agreement on how we thought it should > be handled. > > Thank you, > Joel > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > Hi all, > > > > I am still not sure that the problem of bypass going thru undesirable > > links/nodes exists in the case of topological SIDs. > > > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > > < > https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%= 2Ftools.ietf.org%2Fhtml%2Frfc4090>) > has been successfully deployed > > for many years before SR-MPLS has been introduced. What=E2=80=99s more, > > signaling of bypass tunnels he PLR usually did not include any of the > > constraints used for computing of any specific LSP that the bypass LSP > > would protect =E2=80=93 because in the Facility Protection mode the sam= e > > bypass LSP would be used to protect multiple LSPs passing thru the > > failed link/node. > > > > From my POV the only difference between this behavior and that > > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in = the case of > > RSVP-TE, the operator would explicitly indicate, as part of LSP > > signaling, whether it would or would not use FRR; LSPs that would not > > use FRR would then drop traffic rather than delivering it the wrong way= . > > > > Such an option indeed does not exist in SR-TE today, but would be easy > > to provide if so desired IMHO. > > > > Did I miss something substantial? > > > > Regards, and lots of thanks in advance, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* spring *On Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > *To:* EXT-Andrew.Alston@liquidtelecom.com > > ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > All, > > > > This is a very interesting discussion and thanks to Joel for starting > > this discussion. IMO, when there are strict requirements of avoiding > > certain nodes/links it can be realized either by defining a flex-algo > > avoiding those > > > > Nodes and links or by using a stack of unprotected adj-sids that avoid > > restricted nodes and links. When a stack of adj-sids is used to > > realize the path, the head-end based (sBFD) protection mechanisms can b= e > applied. > > > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > > failure events may cause traffic to go through restricted nodes and > > links. This would happen regardless of whether any kind of protection > > is in use or not. > > > > Rgds > > > > Shraddha > > > > Juniper Business Use Only > > > > *From:* spring > >> *On Behalf Of *Andrew Alston > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf.org >; Joel > M. Halpern > > >= > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > *[External Email. Be cautious of content]* > > > > Robert this is actually far more difficult when =E2=80=93 it can be an = entire > > (long) series of nodes that need to be avoided. > > > > It could potentially be made to work but I=E2=80=99d worry that to do t= his =E2=80=93 > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative label= s =E2=80=93 and that wouldn=E2=80=99t > > be viable. > > > > It=E2=80=99s easier to use algorithms and adjacency sids and other such= things > > to calculate paths =E2=80=93 the biggest trick is about the stack depth= . When > > you have this need for node avoidance =E2=80=93 the need for 10+ label = depth > > is critical =E2=80=93 unless you wanna be applying one hell of a lot of > > binding labels along the way which is a nightmare. > > > > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use > > case that most of the people I discuss this with certain have =E2=80=93= I cant > > comment on a global scale, or for anyone else, but every indication I > > have is that yes =E2=80=93 its something people need, and want > > > > Andrew > > > > *From:* Robert Raszuk >> > > *Sent:* Tuesday, 4 August 2020 01:27 > > *To:* Andrew Alston > < > mailto:Andrew.Alston@liquidtelecom.com >= > > > *Cc:* Joel M. Halpern > >>; spring@ietf.org > > > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Is this a common use case ie. "but rather =E2=80=93 which nodes / netw= ork > > segments it can never touch or flow through." > > > > If so perhaps its time to define notion of *negative-SID* ie. list in > > the packet resources which given packet MUST not ever traverse. > > > > Put in the packet set of nodes or links which the packet should never > > traverse. > > > > That goes in line of recent wave of negative routing implementations > > (RIFT) or discussions (LSR) > > > > Best, > > R. > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > < > mailto:Andrew.Alston@liquidtelecom.com >= > > wrote: > > > > So =E2=80=93 > > > > One of the use cases, in fact, some very major use cases in any > > spring technology for us revolve around the following > > > > a.The explicit avoidance of certain nodes > > > > b.The explicit avoidance of certain sections of the network > > > > Anything that could result in that explicit avoidance being violate= d > > =E2=80=93 would create, shall we say significant problems. > > > > Much of the use case is not a case of which nodes the packets flow > > through =E2=80=93 but rather =E2=80=93 which nodes / network segmen= ts it can never > > touch or flow through. Effectively, to be used as a technology to > > avoid certain things for specific reasons. > > > > This is also one of the reasons for needing such deep label stacks = =E2=80=93 > > this kind of detailed path programming tends to deepen the stack > > because you sometimes have to be pretty explicit. > > > > It is absolutely critical to us that this functionality is there = =E2=80=93 > > and that we can avoid situations which could cause traffic to > > accidently hit things explicitly avoided. > > > > I wish I could be more specific than this, but it is what it is. > > > > Thanks > > > > Andrew > > > > *From:* spring > >> *On Behalf Of *Joel M. Halpern > > *Sent:* Monday, 3 August 2020 21:36 > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf..org > > > *Subject:* Re: [spring] Spring protection - determining > > applicability > > > > (Since the thread has gotten long enough, reiterating that this is > as a > > participant, not a WG chair.) > > > > Yes, we are talking IP networks. And yes, I have seen IP networks > that > > choose to drop packets. For all sorts of reasons. > > I think there are likely other reasons why one may not want a rando= m > > path rather than a chosen TE path. I think it is important we be > clear > > about what constraints may be / are violated when we tell people th= ey > > have this tool (protective rerouting) that is intended to preserve > QoS. > > > > Let's be clear. I am not arguing that this is not a good idea. It i= s > a > > good idea. And useful. I am trying to figure otu what combination o= f > > additional mechanisms and clear descriptions will lead to everyone > > getting the behavior they expect (which may not be the behavior the= y > > desire, but sometimes is the best we can do.) > > > > Yours, > > Joel > > > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > > Joel, > > > > > > Are we still talking about IP networks here ? Or perhaps some ha= rd > > > slicing with real resource reservations or detnets ? > > > > > > Because if we are talking about IP networking I have two > > observations: > > > > > > A) If you need to traverse via a specific node (ie. firewall) yo= u > > better > > > apply IP encapsulation to that node.. I don't think IP > > encapsulation can > > > be hijacked today such that destination address of the packet is > > ignored. > > > > > > B) Have you seen any IP network where upon topology change (link > > or node > > > failure) you suddenly start dropping flows in spite of SPT > offering > > > perhaps few ms longer path with 10 ms more jitter ? > > > > > > Or are some SR marketing slides promise to turn IP networks in > > > something new ? Worse ... do they mention path quality guarantee= s, > > > resource reservations ? I hope not. > > > > > > Thx, > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern < > jmh@joelhalpern.com > > >> >> wrote: > > > > > > Well less serious for TE SIDs, I am not sure the problem is > > restricted > > > to just service SIDs. > > > > > > Suppose that the PCE has specified the path to meet some complex > te > > > objective. The bypass node has no way of knowing what those > > > constraints > > > were. And for some kinds of traffic, it is better to drop the > packet > > > than to deliver it outside the envelop. I suspect that the righ= t > > > answer > > > to this is "too bad". If so, as with the distinction regarding > > service > > > nodes, we should say so, shouldn't we? > > > > > > Yours, > > > Joel > > > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > > Mach, Joel and all, > > > > > > > > I think that in most cases: > > > > > > > > 1.There is clear differentiation between "topological" and > > "service" > > > > instructions in SID advertisements. E.g.: > > > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > > corresponding IGP advertisements) represent topological > > instructions > > > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > < > https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04 > > > > < > https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQ= AtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24 > >> > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D inst= ructions > > > > > > > > 2.Segments that represent topological instructions can be > bypassed, > > > > while segments that represent service instructions require > > > alternative > > > > protection mechanisms. > > > > > > > > This view seems to be aligned with RFC 8402 > > > > < > https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Frfc8402 > > > > < > https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24 > >> > > that says in Section 1: > > > > > > > > In the context of an IGP-based distributed control plane, > two > > > > > > > > topological segments are defined: the IGP-Adjacency segment an= d > the > > > > > > > > IGP-Prefix segment. > > > > > > > > In the context of a BGP-based distributed control plane, t= wo > > > > > > > > topological segments are defined: the BGP peering segment and > the > > > > > > > > BGP-Prefix segment. > > > > > > > > In the case of SR-MPLS this differentiation is assumed in > Section > > > 3.4 of > > > > the Node Protection for SR-TE Path > > > > > > > > > < > https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-f= or-sr-te-paths-07%23section-3.4 > > > > < > https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 9wO-Ssn%24 > >> > > > > > > > draft that says: > > > > > > > > The node protection mechanism described in the previous > > sections > > > > > > > > depends on the assumption that the label immediately below > > > the top > > > > > > > > label in the label stack is understood in the IGP domain. Whe= n > the > > > > > > > > provider edge routers exchange service labels via BGP or > some > > > other > > > > > > > > non-IGP mechanism the bottom label is not understood in th= e > IGP > > > > > > > > domain. > > > > > > > > The egress node protection mechanisms described in the dra= ft > > > > > > > > [RFC8679 < > https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679 > > > > < > https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fr= fc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRH= OGt8AkTRDuiDo8MGipXc%24 > >>] > > is > > > > applicable to this use case and no additional changes > > > > > > > > will be required for SR based networks > > > > > > > > The scenarios in which differentiation between =E2=80=9Ctopol= ogical=E2=80=9D > and > > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed pr= oblematic. E.g., > > > consider > > > > the use case in which a Node SID in the ERO of a SR-TE path > > > identifies a > > > > node that acts as a firewall for all packets it receives, i.e.= , > > > provides > > > > the firewall service without any dedicated service SID > > > identifying it. > > > > One could say that the Node SID of such a node would combine > > > topological > > > > and service instructions thus breaking the differentiation > > > between the two. > > > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs= could be > prevented > > > or at > > > > least discouraged. > > > > > > > > If not, providing an ability to identify such SIDs in the > > > advertisement > > > > mechanisms would be useful IMHO. > > > > > > > > My 2c, > > > > > > > > Sasha > > > > > > > > Office: +972-39266302 > > > > > > > > Cell: +972-549266302 > > > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > > > > > > > -----Original Message----- > > > > From: spring > >> > > >> On > Behalf Of Mach Chen > > > > Sent: Monday, August 3, 2020 6:30 AM > > > > To: Joel M. Halpern > >> >>; > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > Subject: Re: [spring] Spring protection - determining > applicability > > > > > > > > Hi Joel, > > > > > > > > I think this is a good point that may not be discussed in the > > > past. And > > > > I also don't think there is a "can be bypassed" indication in > the > > > > routing advertisement for now. > > > > > > > > IMHO, the information advertised by routing is neutral, such > > > information > > > > (can or cannot be bypassed) is more path specific, thus > > normally the > > > > controller should be responsible for deciding whether/which SI= D > > > can be > > > > bypassed. > > > > > > > > Best regards, > > > > > > > > Mach > > > > > > > > > -----Original Message----- > > > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > > > > < > mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%= 3e > >] > > On Behalf Of Joel M. > > > > > > > > > Halpern > > > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > > > To: spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > Subject: [spring] Spring protection - determining > applicability > > > > > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > > confused WG > > > > > > > > > participant.) > > > > > > > > > > > > > > > > > > I have been reading the various repair drafts, and the > various > > > > > > > > > networks programming and service programming draft, and I a= m > > > trying to > > > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, > for > > > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID f= or > > > a failed > > > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new > path > > > meets > > > > > > > > > the TE criteria. or maybe it is safe if it is even close, = as > > > long as > > > > > > > > > it is not used for too long. > > > > > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet lega= l > > > > requirements? > > > > > > > > > Or was some other necessary programmatic transform (wince w= e > are > > > > > > > > > deliberately vague about what nodes can do when asked > suitably.) > > > > > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > Yours, > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > spring mailing list > > > > > > > > > spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2 > > > < > https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8= E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24 > > > > > > > > > > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2 > > > > < > https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW= 9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE= 8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24 > >> > > > > > > > > > F%2Fwww.ietf.org > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > > > > > < > https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%= 2F2Fwww.ietf.org > > > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > >>%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > > > > > > > spring mailing list > > > > > > > > spring@ietf.org > > > > > = >> > >> > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flisti= nfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0= wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24 > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Notice: This e-mail together with any attachments may contain > > > > information of Ribbon Communications Inc. that is confidential > > > and/or > > > > proprietary for the sole use of the intended recipient. Any > review, > > > > disclosure, reliance or distribution by others or forwarding > > without > > > > express permission is strictly prohibited. If you are not the > > > intended > > > > recipient, please notify the sender immediately and then delet= e > all > > > > copies, including any attachments. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti > > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > ---------------------------------------------------------------------- > > -- > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > ---------------------------------------------------------------------- > > -- > > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > ------------------------------ > > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. that is confidential and/or proprietary for > the sole use of the intended recipient. Any review, disclosure, reliance = or > distribution by others or forwarding without express permission is strict= ly > prohibited. If you are not the intended recipient, please notify the send= er > immediately and then delete all copies, including any attachments. > ------------------------------ > > > --000000000000b894f205acd84576 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ketan,

While I completely agree with= your note the consequences of it are pretty sevre.=C2=A0

Unless we signal which prefix SID is protection eligible and which = is not how would other nodes know if they can protect it or not ?=C2=A0

It seems that today's safe thing is not to apply = any node protection on SR flows at the PLRs then.=C2=A0

And link protection MUST assure that packets will arrive at the neigh= bor node via some other link regardless of further path towards destination= .=C2=A0

Is it correct ?=C2=A0

=
Thx
R

On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar = (ketant) <ketant@cisco.com> w= rote:

Hi Sasha,

=C2=A0

The service node advertises its own Prefix SID= . The service function that this service node implements does not require a= ny context (i.e. all packets arriving at the node are subjected to that ser= vice). Therefore the service node does not need to receive a packet with it=E2=80= =99s own Prefix SID.

=C2=A0

Thus, we cannot assume that when PHP is used, = then the SID is only associated with a topological instruction.

=C2=A0

Hope that clarifies?

=C2=A0

Thanks,

Ketan

=C2=A0

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com &= lt;And= rew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= u>

=C2=A0

Ketan, and all,

I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs= that are advertised with PHP can=C2=A0 ONLY represent topological instruct= ions in SR-MPLS - because the advertising node will not receive them and therefore can hardly be expected to associate any ser= vice function with them.

=C2=A0

This is complementary to what you have said.

=C2=A0

Hope this clarifies my position.

What, if anything, did I miss?

=C2=A0

Regards,

Sasha

=C2=A0

Get Outlook for Android

=C2=A0

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Friday, August 14, 2020, 16:23
To: = Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
Cc: = spring@ietf.org
Subject: RE: [spring] Spring protection - determining applicability



NOTICE: This email was received from an EXTERNAL sen= der

=C2=A0

Hi Sasha,

=C2=A0

If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don=E2=80=99t see why PHP could not be done for a Prefix SID associ= ated with a service node.

=C2=A0

Also, I didn=E2=80=99t follow the point that you wer= e trying to make about Adj-SIDs.

=C2=A0

Thanks,

Ketan

=C2=A0

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

Hi all,

Regarding the statement "Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it":

=C2=A0

=C2=A0

I think that in SR-MPLS a Node SID that is advertised with PHP a= citon can be safely considered as "just a topological instruction"= ; by the PLR because the originating node will not receive it.

The same applies to Adj-SDIs.

=C2=A0

My 2c.

=C2=A0

Get Outlook for Android

=C2=A0

From: spring <spring-bounces@ietf.org> on behalf of Ketan Ta= laulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>
Sent: Friday, August 14, 2020, 15:00
To: = Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
Cc: = spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability

=C2=A0

Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does = not have a notion of how "strict or not" is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Polic= y headend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of= related questions.
What struck me, and prompted the starting question, was that none of them w= ere spelled out.=C2=A0 I see lots of interesting ideas / proposals.
Some of them are compatible with others.=C2=A0=C2=A0 Some are not.
It would be good if we could reach agreement on how we thought it should be= handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirable =
> links/nodes exists in the case of topological SIDs.
>
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
> <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
> for many years before SR-MPLS has been introduced. What=E2=80=99s more= ,
> signaling of bypass tunnels he PLR usually did not include any of the =
> constraints used for computing of any specific LSP that the bypass LSP=
> would protect =E2=80=93 because in the Facility Protection mode the sa= me
> bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>=C2=A0 From my POV the only difference between this behavior and that <= br> > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use FRR; LSPs that would not =
> use FRR would then drop traffic rather than delivering it the wrong wa= y.
>
> Such an option indeed does not exist in SR-TE today, but would be easy=
> to provide if so desired IMHO.
>
> Did I miss something substantial?
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
>
> Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
> *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> All,
>
> This is a very interesting discussion and thanks to Joel for starting =
> this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized=C2=A0 either by defining a flex= -algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avoid=
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
> failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org
> <m= ailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern
> <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> *[External Email. Be cautious of content]*
>
> Robert this is actually far more difficult when =E2=80=93 it can be an= entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93
> you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t
> be viable.
>
> It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things
> to calculate paths =E2=80=93 the biggest trick is about the stack dept= h.=C2=A0 When
> you have this need for node avoidance =E2=80=93 the need for 10+ label= depth
> is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
> case that most of the people I discuss this with certain have =E2=80= =93 I cant
> comment on a global scale, or for anyone else, but every indication I =
> have is that yes =E2=80=93 its something people need, and want
>
> Andrew
>
> *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org
> <mailto:spring= @ietf.org>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> Is this a common use case ie.=C2=A0 "but rather =E2=80=93 which n= odes / network
> segments it can never touch or flow through."
>
> If so perhaps its time to define notion of *negative-SID* ie. list in =
> the packet resources which given=C2=A0packet MUST not ever traverse. >
> Put in the packet set of nodes or links which the packet should never =
> traverse.
>
> That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
>
>=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93
>
>=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very major= use cases in any
>=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve around the fo= llowing
>
>=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain nodes
>
>=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain sections o= f the network
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that explicit av= oidance being violated
>=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say significa= nt problems.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case of which no= des the packets flow
>=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 which n= odes / network segments it can never
>=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effectively, to b= e used as a technology to
>=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific reasons.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for needing su= ch deep label stacks =E2=80=93
>=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming tends t= o deepen the stack
>=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pretty explic= it.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this func= tionality is there =E2=80=93
>=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations which could c= ause traffic to
>=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly avoided.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than this, but= it is what it is.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Thanks
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Andrew
>
>=C2=A0=C2=A0=C2=A0=C2=A0 *From:* spring <spring-bounces@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> *On Behal= f Of *Joel M. Halpern
>=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36
>=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
>=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring@ietf..org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: [spring] Spring protection - de= termining
> applicability
>
>=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long enough, reit= erating that this is as a
>=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.)
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
>=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. For all sorts of reaso= ns.
>=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons why one= may not want a random
>=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. I think it = is important we be clear
>=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are violated w= hen we tell people they
>=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerouting) that is = intended to preserve QoS.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing that this= is not a good idea. It is a
>=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying to figure o= tu what combination of
>=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descriptions w= ill lead to everyone
>=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (which may no= t be the behavior they
>=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can do.)<= br> >
>=C2=A0=C2=A0=C2=A0=C2=A0 Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0 Joel
>
>=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about IP netwo= rks=C2=A0here ? Or perhaps some hard
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reservat= ions or detnets ?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talking=C2= =A0about IP networking I have two
>=C2=A0=C2=A0=C2=A0=C2=A0 observations:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via a sp= ecific node (ie. firewall) you
>=C2=A0=C2=A0=C2=A0=C2=A0 better
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to that node= .. I don't think IP
>=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that destina= tion address of the packet is
>=C2=A0=C2=A0=C2=A0=C2=A0 ignored.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP network whe= re upon topology change (link
>=C2=A0=C2=A0=C2=A0=C2=A0 or node
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0start dr= opping=C2=A0flows in spite of SPT offering
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path with 10 = ms more jitter ?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing slides pro= mise to turn IP networks in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new ? Worse ... do t= hey mention path quality guarantees,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0? I hope= not.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R.
>=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%20%0b>> <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">mailto:jmh@joelhalp= ern.com>> wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SIDs, I am= not sure the problem is
>=C2=A0=C2=A0=C2=A0=C2=A0 restricted
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has specified = the path to meet some complex te
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass node ha= s no way of knowing what those
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some kinds of t= raffic, it is better to drop the packet
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside the enve= lop.=C2=A0 I suspect that the right
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is "too bad".=C2= =A0 If so, as with the distinction regarding
>=C2=A0=C2=A0=C2=A0=C2=A0 service
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn= 9;t we?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most cases: >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differentiati= on between "topological" and
>=C2=A0=C2=A0=C2=A0=C2=A0 "service"
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID advertisem= ents. E.g.:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP advertisemen= ts) represent topological
>=C2=A0=C2=A0=C2=A0=C2=A0 instructions
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
>=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 <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3GC5a= f2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F= datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 4T-L0nl%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent topo= logical instructions can be bypassed,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that represent = service instructions require
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be aligned = with RFC 8402
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0 that says in Section 1:
>=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 In the cont= ext of an IGP-based distributed control plane, two
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the IGP-Adjacency segment and the
>=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 IGP-Prefix = segment.
>=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 In the cont= ext of a BGP-based distributed control plane, two
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the BGP peering segment and the
>=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 BGP-Prefix = segment.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this di= fferentiation is assumed in Section
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for SR-TE = Path
>=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 <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdr= aft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21= %21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9= wO-Ssn%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft that says:
>=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 The node pr= otection mechanism described in the previous
>=C2=A0=C2=A0=C2=A0=C2=A0 sections
>=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 depends on = the assumption that the label immediately below
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack is un= derstood in the IGP domain.=C2=A0 When the
>=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 provider ed= ge routers exchange service labels via BGP or some
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other
>=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 non-IGP mec= hanism the bottom label is not understood in the IGP
>=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 domain.
>=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 The egress = node protection mechanisms described in the draft
>=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 [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u= =3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2F= doc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
>=C2=A0=C2=A0=C2=A0=C2=A0 is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use case an= d no additional changes
>=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 will be req= uired for SR based networks
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2=A0d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a Node S= ID in the ERO of a SR-TE path
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firewall f= or all packets it receives, i.e.,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service without a= ny dedicated service SID
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the Node SI= D of such a node would combine
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus = breaking the differentiation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ability t= o identify such SIDs in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMH= O.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein@ecitele= .com
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:Alexander.Vainshtein@ecitele.com>=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:Alexander.Vainshtein@ecitele.= com>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > -----Original Message-----
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > From: spring <spring-bounces@ietf.org<= br> >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org%0b>>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2020 6= :30 AM
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern <jmh@joelhalpern.com >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.co= m>>;
>=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: [spring] Spring p= rotection - determining applicability
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good point t= hat may not be discussed in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there i= s a "can be bypassed" indication in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now.=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information advertis= ed by routing is neutral, such
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypassed) is= more path specific, thus
>=C2=A0=C2=A0=C2=A0=C2=A0 normally the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be responsib= le for deciding whether/which SID
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Messa= ge-----
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > From: spring [mailt= o:spring-bounc= es@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring-bounces@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>] >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, Augus= t 3, 2020 7:51 AM
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Subject: [spring] S= pring protection - determining applicability
>=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 > (WG Chair hat Off, = this is merely a note from a slightly
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.)
>=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 > I have been reading= the various repair drafts, and the various
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programmin= g and service programming draft, and I am
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspe= ct of the combination.
>=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 > How does a node tha= t is doing some form of bypass (suppose, for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is N= ode N2 deciding to bypass the next SID for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know that = it is safe to do so?
>=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 > If the path was jus= t for TE, then it is "safe" if the new path
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2= =A0 or maybe it is safe if it is even close, as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used for = too long.
>=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 > But what if the nod= e were a Firewall, included to meet legal
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other n= ecessary programmatic transform (wince we are
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague = about what nodes can do when asked suitably.)
>=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 > Is there some "= ;can be bypassed" indication in the routing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements that= I missed?
>=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 > Thank you,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel
>=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=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing list=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
>=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=A0 https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3Q= 7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A= %2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2= __%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt= 8AkTRDuiDo6HwPLil%24>
>=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 <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.c= om/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http= s%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A= %2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6v= pRHOGt8AkTRDuiDozoQiAHk%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > F%2Fwww.ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.sy= mantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktim= e.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%= 2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1o= iQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2F= listinfo%2Fspring
>=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 > > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org> <mailto:spring@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>> >=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 https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRn= fMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sym= antec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.o= rg%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yu= sx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>=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=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0 ----------------------------------------------= --------------------------
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Notice: This e-mail together w= ith any attachments may contain
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Communic= ations Inc. that is confidential
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole use o= f the intended recipient. Any review,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distri= bution by others or forwarding
>=C2=A0=C2=A0=C2=A0=C2=A0 without
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly= prohibited. If you are not the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify the s= ender immediately and then delete all
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attachme= nts.
>=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=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>=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 > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>=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 spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0
> <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> ----------------------------------------------------------------------=
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or =
> proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
> recipient, please notify the sender immediately and then delete all > copies, including any attachments.
> ----------------------------------------------------------------------=
> --

_______________________________________________
spring mailing list
spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring

=C2=A0

=C2=A0

Notice: This e-mail together with any attachments may contain inform= ation of Ribbon Communications Inc. that is confidential and/or proprietary= for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or f= orwarding without express permission is strictly prohibited. If you are not= the intended recipient, please notify the sender immediately and then dele= te all copies, including any attachments.

=C2=A0

--000000000000b894f205acd84576-- From nobody Fri Aug 14 09:17:14 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE53A0EAA for ; Fri, 14 Aug 2020 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=deUlBoGB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dWP0NSlb 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 SjakU7Miobvp for ; Fri, 14 Aug 2020 09:17:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D4B3A0D94 for ; Fri, 14 Aug 2020 09:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=154352; q=dns/txt; s=iport; t=1597421828; x=1598631428; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hYLnLKLIliwhbFW4ky/MrsoeoYm6UqNB/bCYv+JSE94=; b=deUlBoGB0k7PU//0Z5+Oq5atMFAZGmO2BB7Fk43k/UUklvs9uLn7hx1C SFkHzR9d7Hfle6jwvxp6PWgK2K7P6558D/pe2Dh+tG3BxXM/kxBH+pPzP nsfkVz47f+l49uaTpXMjzoP6dejJogn3bzrmPodhs+CY6AR4N3/u9ASxz s=; IronPort-PHdr: =?us-ascii?q?9a23=3A4gy1xBQjlrJ8O2GIBnjigoiAYtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ8ftfmffV9abtRT9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Iq2ag8D1UHB?= =?us-ascii?q?jjZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBQBLuDZf/5BdJa1VChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggqBIy8pKAdwWC8sCoQtg0YDjVOBApdlgUKBEQNQAgMLAQE?= =?us-ascii?q?BDAEBGAEJBwQCBAEBhAhEAheCMAIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXE?= =?us-ascii?q?BAQEEAQEQCAEIChMBASwBCgELAgICAQgRBAEBASABBgMCAgIUEQsUCQgCBA4?= =?us-ascii?q?FCBqDAAWBfk0DLgEOp3oCgTmIYXaBMoMBAQEFgTMBAwIOAw8vgyoYgg4JBYE?= =?us-ascii?q?zgnGDYIQtgQGBHhqBQT8maQEBQ4FPLhs1PoJcAQECAQEVgREBBwsBIwUHCQg?= =?us-ascii?q?HAQUBCQIGglkzgi2PRQcSBwMGKoIvPIZhgx+IPZByCoJiiGOFfFCFCIYJgn8?= =?us-ascii?q?2bYg4kR6CJ4VWiwmFQ4ZYhTmLFYQsAgQCBAUCDgEBBYFAKiMNWnBwFTuCaQk?= =?us-ascii?q?WMRcCDYhahUUMF4ECAQKCSYQ+VoVCdAIBAQEVARwCBgEJAQEDCXyNYAWBMAE?= =?us-ascii?q?0XAEB?= X-IronPort-AV: E=Sophos;i="5.76,312,1592870400"; d="scan'208,217";a="801520974" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 16:17:03 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EGH2eV001089 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 16:17:03 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 11:17:02 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 11:17:01 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 12:17:01 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nfVhyZXRTjjKFBBESUy8224aLS4E64KQ3vfaQcHUl2O7WSve+dmGd+0ybw0AuY5hk1HUPfXFYdX/U2yJwSxT4sSVwqvW6X2m5CUslSsl9HaIcIZ+upacJ8V39rQ2h/0iKMg9MJVsIozBmFbkav88vHLYNsuNivkyD3kvo2Jl286EKwgN5w0WxsiywOPyP2ROENvh1Q0jIOQSquhVwyLwQUDpQIaodZLqGgcE3mozOBQAMiJW+ajkE7Wm5c8ohJBGH6lQgeN1B63X47puiai7uh5oDmj+IZ88MNUcM3Z9VLZoVEo6lLPSMLere30B+D6uYzUapLg9CAqBWMxjULMC2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hYLnLKLIliwhbFW4ky/MrsoeoYm6UqNB/bCYv+JSE94=; b=N/kLUuZ1ejOjvYwjVXfDF6e6E11gkQAcYvq/fdrjeYHaaiIJ3rQ2T/2fsrbpdX5f2xdmtd/lcrMtGCa8xp8+fypeq8pmQCsWXSJM/qLhyp/tt51iTPzjcJWqbi+MA5hOneUOQmU7cz0LGmr+JGRmis/HxCeLH4IL9T05duUwDi8IBhKFykmdq9w34IwUcInVIJ9q4XdJT2RxhuEIh6ChQ1VPVYLd1IJbmFCvYb6fnCtzTtaoLHhA253SIb96J5MeiCd+nwJ42KXJvK1XJNlzmunMEwmhNWw9xd+HLyBacWkR4zFlrK8GRd478YRIJh9uEmESTCwBLXEbfuExYpUpFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hYLnLKLIliwhbFW4ky/MrsoeoYm6UqNB/bCYv+JSE94=; b=dWP0NSlbTPKBt4QW8glQqFdS9zv6kNZ9C9i9Ruw1teHonqnHPdkhM4j+AumaxSn8mX3ZFHz74l8HHhaMjE6ouj7uLmziFzTQJ7U7Oq8819Htua/YieWDjSpqyy39yd6ZvFTT6RXfjZqFZGK6rl0s+NzcFAlqxU1EBUqCD0TsDkU= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4761.namprd11.prod.outlook.com (2603:10b6:303:53::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Fri, 14 Aug 2020 16:16:59 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 16:16:59 +0000 From: "Ketan Talaulikar (ketant)" To: Robert Raszuk CC: Alexander Vainshtein , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfGJGLEw80LFEa7R79kiStyh6klun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAFLgAgAB1eACAD4BY8IAAFTmAgAAGD1CAABtZgIAACTzggAAEVwCAAAYyoA== Date: Fri, 14 Aug 2020 16:16:59 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15023bb7-3e46-4bef-d7a3-08d8406d78db x-ms-traffictypediagnostic: MW3PR11MB4761: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sv8Cypwju8uDHR13q0MiV2T/SQadtsWwpqV9wI85YAt9afMD9SEXp5+24KIELc5eXflccIj0a9PlH+Fa6i9RazUWhNrC0eviIduLkskiTmKwIrH+AlMK4/9iM8/4DX1IdW3Pd3q1GUOMWpLbitkxzijPXhZEl6FRBe+FQ+Gi+NFOy+KRXZ0Cftjbt+ksfzga0AIrN2DgHpK/xZgOF+9JI0IdimoBUP7UOy0vbiaTZmi1ltkvfu15FcYdmJanBSvDMufD8mBhkIzumgaOFkTB2uHSfqZp0qjpk+5CnnhH7GmDf95n7y9GMFVrIqJ91gHLsbvCwOrYiWkgxJ4hht5lyO6UjvPMdVxCmp8j+znwNY4xU4yGxotvurZ/mVHU1YTGt2P1mrz6MEwj2tJeqCRlVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(396003)(366004)(346002)(376002)(186003)(4326008)(5660300002)(9326002)(2906002)(26005)(71200400001)(166002)(54906003)(30864003)(66476007)(52536014)(45080400002)(33656002)(53546011)(6506007)(76116006)(478600001)(8936002)(64756008)(66446008)(55016002)(966005)(8676002)(9686003)(7696005)(83380400001)(66556008)(66946007)(6916009)(86362001)(316002)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IwIC0zRZElpsOeeGNjz+14B4Ez/N+c6SMNntPJWdIIY3mm9MOcHM1KuCkpW8g2yAeboBdYKTj5ZByVsMz1CY/LmGMg1UlJO1hEKzkkZrMTQ5nnx/PCH5fvzx/qGgP1M4iVnYDDnp1wgxKcyh1T5FRL11Es4tp25BxkHyC+F/p2NLWmuRq9Q+fq+BP/rvnr2YbWXYUTZebx9Kl3Jahm1S2lLHBIjXoV/hR6P+qL0cgBHexxp11Ivh4WA+y0SXoY/2UwNRA3I25gJRp2n4zbF4eBpcLQilyWqaGRnomPsahpo3y75KNeX3kmYnSxo/Y4YxqxybAUVuwD+2NehgNNuecCqWXgfSnAN0aroB78RHMaCC5NBgHiPn75VkRbxl0S7nGyQeRDHqbb0gcN43xwimWJJuKvOdhUkuusSRUCAgUsoqN31duRLWBiHXejoRd2Hpe2mPxGU9al7o4idJW7EnWUruzx9zlk3MxGPGj/6kUaSAIdVzhVMx+LGYV+sFexS8lg3+4W8a7IXcz2+sMrsz0lQoRB62A9tCAbUUzNGOy3aLYo1Cqq0/iYSdGi6eVDc+KmsyuQjkLLHeQAWl2NvZvy3yWkIdz+ptEZlVt8LAsmFWZROyFXXpSI2ii0Oqzpwx10y/pWnTk6RQT6VbsFQF6Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB457066589CAE97721BB97D84C1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15023bb7-3e46-4bef-d7a3-08d8406d78db X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 16:16:59.4170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IHl+ecPk5M27TzbP4c8T6EcMMxgiDp/wxnW7Ly9RGLE83NHDlkjWasS2u1YoekG9UP8hKPCSZvR06R8cta0b1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4761 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 16:17:12 -0000 --_000_MW3PR11MB457066589CAE97721BB97D84C1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBSb2JlcnQg UmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NClNlbnQ6IDE0IEF1Z3VzdCAyMDIwIDIxOjEzDQpU bzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbT4NCkNjOiBBbGV4 YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+OyBKb2VsIE0u IEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFA anVuaXBlci5uZXQ+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSA8QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0K DQpIaSBLZXRhbiwNCg0KV2hpbGUgSSBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91ciBub3RlIHRo ZSBjb25zZXF1ZW5jZXMgb2YgaXQgYXJlIHByZXR0eSBzZXZyZS4NCltLVF0gSSB1bmRlcnN0YW5k LiBXZSBuZWVkIHRvIGJlIG1pbmRmdWwgb2YgaW1wbGljYXRpb25zIG9mIHByb3RlY3Rpb24gc2No ZW1lcyBmb3IgdGhlIFNMQXMvaW50ZW50IG9mIFNSIFBvbGljaWVzLg0KDQpVbmxlc3Mgd2Ugc2ln bmFsIHdoaWNoIHByZWZpeCBTSUQgaXMgcHJvdGVjdGlvbiBlbGlnaWJsZSBhbmQgd2hpY2ggaXMg bm90IGhvdyB3b3VsZCBvdGhlciBub2RlcyBrbm93IGlmIHRoZXkgY2FuIHByb3RlY3QgaXQgb3Ig bm90ID8NCltLVF0gQ29ycmVjdC4gVG8gYmUgbW9yZSBhY2N1cmF0ZSwgd2UgbmVlZCB0byBjb25z aWRlciB0aGlzIG1vcmUgaW4gdGhlIGNvbnRleHQgb2YgU0xBIG9yIOKAnGludGVudOKAnSBvZiBT UiBQb2xpY2llcyBhbmQgd2hpY2ggc2VnbWVudHMgbWF5IGJlIOKAnGJ5cGFzcy1hYmxl4oCdIGZv ciBsb2NhbCBwcm90ZWN0aW9uIGZvciBzb21lIG9mIHRob3NlIFNSIFBvbGljaWVzLiBXZSBhbHNv IGhhdmUgcGF0aC1wcm90ZWN0aW9uIG1lY2hhbmlzbXMuDQoNCkl0IHNlZW1zIHRoYXQgdG9kYXkn cyBzYWZlIHRoaW5nIGlzIG5vdCB0byBhcHBseSBhbnkgbm9kZSBwcm90ZWN0aW9uIG9uIFNSIGZs b3dzIGF0IHRoZSBQTFJzIHRoZW4uDQoNCkFuZCBsaW5rIHByb3RlY3Rpb24gTVVTVCBhc3N1cmUg dGhhdCBwYWNrZXRzIHdpbGwgYXJyaXZlIGF0IHRoZSBuZWlnaGJvciBub2RlIHZpYSBzb21lIG90 aGVyIGxpbmsgcmVnYXJkbGVzcyBvZiBmdXJ0aGVyIHBhdGggdG93YXJkcyBkZXN0aW5hdGlvbi4N CltLVF0gWWVzLiBXZSBoYXZlIGEgbWVjaGFuaXNtIHRvIGluZGljYXRlIHdoaWNoIGFkai1TSURz IGhhdmUgcHJvdGVjdGlvbiAodGhhdCBtZWNoYW5pc20gb25seSBwcm92aWRlcyBsaW5rIHByb3Rl Y3Rpb24gdG8gZ2V0IHRvIHRoZSBuZWlnaGJvciBub2RlKSBzbyB0aGUgU1IgUG9saWN5IGNvbXB1 dGF0aW9uIGlzIGFibGUgdG8gaW5kaWNhdGUgd2hldGhlciB0aGF0IHNwZWNpZmljIGxpbmsgaXMg 4oCcYnlwYXNzLWFibGXigJ0gb3Igbm90IGJ5IGl0cyBjaG9pY2Ugb2YgcHJvdGVjdGVkIG9yIHVu cHJvdGVjdGVkIGFkai1TSURzIHJlc3BlY3RpdmVseS4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KSXMg aXQgY29ycmVjdCA/DQoNClRoeA0KUg0KDQpPbiBGcmksIEF1ZyAxNCwgMjAyMCBhdCA1OjMyIFBN IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb208bWFpbHRvOmtldGFu dEBjaXNjby5jb20+PiB3cm90ZToNCkhpIFNhc2hhLA0KDQpUaGUgc2VydmljZSBub2RlIGFkdmVy dGlzZXMgaXRzIG93biBQcmVmaXggU0lELiBUaGUgc2VydmljZSBmdW5jdGlvbiB0aGF0IHRoaXMg c2VydmljZSBub2RlIGltcGxlbWVudHMgZG9lcyBub3QgcmVxdWlyZSBhbnkgY29udGV4dCAoaS5l LiBhbGwgcGFja2V0cyBhcnJpdmluZyBhdCB0aGUgbm9kZSBhcmUgc3ViamVjdGVkIHRvIHRoYXQg c2VydmljZSkuIFRoZXJlZm9yZSB0aGUgc2VydmljZSBub2RlIGRvZXMgbm90IG5lZWQgdG8gcmVj ZWl2ZSBhIHBhY2tldCB3aXRoIGl04oCZcyBvd24gUHJlZml4IFNJRC4NCg0KVGh1cywgd2UgY2Fu bm90IGFzc3VtZSB0aGF0IHdoZW4gUEhQIGlzIHVzZWQsIHRoZW4gdGhlIFNJRCBpcyBvbmx5IGFz c29jaWF0ZWQgd2l0aCBhIHRvcG9sb2dpY2FsIGluc3RydWN0aW9uLg0KDQpIb3BlIHRoYXQgY2xh cmlmaWVzPw0KDQpUaGFua3MsDQpLZXRhbg0KDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8 QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWlu QHJiYm4uY29tPj4NClNlbnQ6IDE0IEF1Z3VzdCAyMDIwIDIwOjI0DQpUbzogS2V0YW4gVGFsYXVs aWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+ OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+PjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PG1haWx0bzpz aHJhZGRoYUBqdW5pcGVyLm5ldD4+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+IDxBbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20u Y29tPj47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFz enVrLm5ldD4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBs aWNhYmlsaXR5DQoNCktldGFuLCBhbmQgYWxsLA0KSSBoYXZlIHN0YXRlZCB0aGF0LCBJTUhPIGFu ZCBGV0lXLCBib3RoIEFkai1TSURzIGFuZCBQcmVmaXggU0lEcyB0aGF0IGFyZSBhZHZlcnRpc2Vk IHdpdGggUEhQIGNhbiAgT05MWSByZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb25zIGlu IFNSLU1QTFMgLSBiZWNhdXNlIHRoZSBhZHZlcnRpc2luZyBub2RlIHdpbGwgbm90IHJlY2VpdmUg dGhlbSBhbmQgdGhlcmVmb3JlIGNhbiBoYXJkbHkgYmUgZXhwZWN0ZWQgdG8gYXNzb2NpYXRlIGFu eSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGggdGhlbS4NCg0KVGhpcyBpcyBjb21wbGVtZW50YXJ5IHRv IHdoYXQgeW91IGhhdmUgc2FpZC4NCg0KSG9wZSB0aGlzIGNsYXJpZmllcyBteSBwb3NpdGlvbi4N CldoYXQsIGlmIGFueXRoaW5nLCBkaWQgSSBtaXNzPw0KDQpSZWdhcmRzLA0KU2FzaGENCg0KR2V0 IE91dGxvb2sgZm9yIEFuZHJvaWQ8aHR0cHM6Ly9ha2EubXMvZ2hlaTM2Pg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8 a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+DQpTZW50OiBGcmlkYXks IEF1Z3VzdCAxNCwgMjAyMCwgMTY6MjMNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgSm9lbCBN LiBIYWxwZXJuOyBTaHJhZGRoYSBIZWdkZTsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb208bWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPjsgUm9iZXJ0 IFJhc3p1aw0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3Vi amVjdDogUkU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGlj YWJpbGl0eQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTk9USUNFOiBUaGlz IGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNlbmRlcg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KSGkgU2FzaGEsDQoNCklmIHRoZSBzZXJ2aWNlIGRvZXMg bm90IG5lZWQgYW55IGFkZGl0aW9uYWwgY29udGV4dCAoZS5nLiBhIGZpcmV3YWxsIHRoYXQganVz dCBhcHBsaWVzIGxvY2FsbHkgY29uZmlndXJlZCBkZWZhdWx0IHJ1bGVzIG9uIGl0KSwgdGhlbiBJ IGRvbuKAmXQgc2VlIHdoeSBQSFAgY291bGQgbm90IGJlIGRvbmUgZm9yIGEgUHJlZml4IFNJRCBh c3NvY2lhdGVkIHdpdGggYSBzZXJ2aWNlIG5vZGUuDQoNCkFsc28sIEkgZGlkbuKAmXQgZm9sbG93 IHRoZSBwb2ludCB0aGF0IHlvdSB3ZXJlIHRyeWluZyB0byBtYWtlIGFib3V0IEFkai1TSURzLg0K DQpUaGFua3MsDQpLZXRhbg0KDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVy LlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29t Pj4NClNlbnQ6IDE0IEF1Z3VzdCAyMDIwIDE4OjI0DQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0 YW50KSA8a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+OyBKb2VsIE0u IEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ PjsgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPG1h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8c2hy YWRkaGFAanVuaXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj47IEVYVC1BbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1 aWR0ZWxlY29tLmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFu ZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJh c3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJv dGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KSGkgYWxsLA0KUmVnYXJkaW5n IHRoZSBzdGF0ZW1lbnQgIlByZWZpeCBTSUQgY291bGQgYmUganVzdCBhIHRvcG9sb2dpY2FsIGlu c3RydWN0aW9uIG9yIG1heSBhbHNvIGJlIHVzZWQgdG8gc3RlZXIgdGhlIGZsb3cgdG8gYSBub2Rl IHdoaWNoIGlzIGFwcGx5aW5nIGEgc2VydmljZSBmdW5jdGlvbiB0byBpdCI6DQoNCg0KSSB0aGlu ayB0aGF0IGluIFNSLU1QTFMgYSBOb2RlIFNJRCB0aGF0IGlzIGFkdmVydGlzZWQgd2l0aCBQSFAg YWNpdG9uIGNhbiBiZSBzYWZlbHkgY29uc2lkZXJlZCBhcyAianVzdCBhIHRvcG9sb2dpY2FsIGlu c3RydWN0aW9uIiBieSB0aGUgUExSIGJlY2F1c2UgdGhlIG9yaWdpbmF0aW5nIG5vZGUgd2lsbCBu b3QgcmVjZWl2ZSBpdC4NClRoZSBzYW1lIGFwcGxpZXMgdG8gQWRqLVNESXMuDQoNCk15IDJjLg0K DQpHZXQgT3V0bG9vayBmb3IgQW5kcm9pZDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v Mzc1YzVZWUJlRWJhRVp3VWNIcENZMW02SDI/dT1odHRwcyUzQSUyRiUyRmFrYS5tcyUyRmdoZWkz Nj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHNwcmluZyA8c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gb24g YmVoYWxmIG9mIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudD00MGNpc2NvLmNvbUBk bWFyYy5pZXRmLm9yZzxtYWlsdG86a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4N ClNlbnQ6IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNTowMA0KVG86IEpvZWwgTS4gSGFscGVy bjsgQWxleGFuZGVyIFZhaW5zaHRlaW47IFNocmFkZGhhIEhlZ2RlOyBFWFQtQW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb20+OyBSb2JlcnQgUmFzenVrDQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRl cm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCkhpIEFsbCwNCg0KSSB3b3VsZCBsaWtlIHRvIHNoYXJl IGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIG9uIHRoaXMuDQoNCkZpcnN0LCB0aGFua3MgdG8gSm9l bCBmb3IgYnJpbmdpbmcgdXAgdGhlIGRpc2N1c3Npb24uIENsZWFybHkgd2UgbmVlZCBhIHdlbGwt ZGVmaW5lZCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBmb3IgZGV0ZXJtaW5pbmcgYXBwbGljYWJp bGl0eSBvZiBwcm90ZWN0aW9uIGZvciBzZWdtZW50IHVzZWQgaW4gYW4gU1IgUG9saWN5LiBTb21l IG9mIHRoaXMgaXMgY2FwdHVyZWQgaW4gWzFdLg0KDQpUaGlzIGlzIGFib3V0IGxvY2FsIHJlcGFp ciBhdCBhIFBMUi4gQnkgaXQncyB2ZXJ5IG5hdHVyZSwgdGhlIFBMUiBkb2VzIG5vdCBoYXZlIGEg bm90aW9uIG9mIGhvdyAic3RyaWN0IG9yIG5vdCIgaXMgdGhlIFNMQSB0aGF0IGlzIGJlaW5nIHBy b3ZpZGVkIGJ5IHRoZSBTUiBQb2xpY3kuIEF3YXJlbmVzcyBvZiB0aGF0IG5vdGlvbiBleGlzdHMg YXQgdGhlIFNSIFBvbGljeSBoZWFkZW5kIGFuZC9vciBjb21wdXRhdGlvbi1ub2RlLg0KDQpXZSBo YXZlIHByb3RlY3RlZCBhbmQgdW4tcHJvdGVjdGVkIHZhcmlhbnRzIG9mIGFkamFjZW5jeSBTSURz IHRvIGVuYWJsZSB0aGUgY29tcHV0YXRpb24gdG8gcGljayBvciB0aGUgb3RoZXIgYmFzZWQgb24g dGhlICJzdHJpY3RuZXNzIiBvZiB0aGUgU0xBIHJlcXVpcmVtZW50IGZvciBwaWNraW5nIHRoYXQg bGluay4gV2UgZG8gbm90IGhhdmUgc3VjaCBhIG5vdGlvbiBmb3IgUHJlZml4IFNJRHMuIE9uZSBj YW4gc2F5IHRoYXQgd2UgY291bGQgaW50cm9kdWNlIHNpZ25hbGxpbmcgKGUuZy4gYSBCIGZsYWcp IHRvIGluZGljYXRlIHdoZXRoZXIgYSBQcmVmaXggU0lEIGNhbiBiZSBieXBhc3NlZCBvciBub3Qu IFRoaXMgcHJvdmlkZXMgdGhlIG9wcG9ydHVuaXR5IGZvciB0aGUgY29tcHV0YXRpb24gdG8gdXNl IG9uZSBvciB0aGUgb3RoZXIgZmxhdm9yIGRlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9mIHRoZSBT TEEgZm9yIHRoZSBTUiBQb2xpY3kuDQoNCkkgaGF2ZSBhIHByb2JsZW0gYW5kIGEgY29uY2VybiBp biB0aGUgYXNzdW1wdGlvbiB0aGF0IFBMUnMgY2FuIGFzc3VtZSB0aGF0IHRoZSBjdXJyZW50bHkg ZGVmaW5lZCB2YXJpYW50IG9mIFByZWZpeCBTSURzIGluIFJGQzg0MDIgKGFuZCBJR1Agc3BlY3Mp IGFyZSAiYnlwYXNzLWFibGUiLg0KDQpBcyBKb2VsIGFuZCBvdGhlcnMgaGF2ZSBicm91Z2h0IG91 dCwgdGhlIFByZWZpeCBTSUQgY291bGQgYmUganVzdCBhIHRvcG9sb2dpY2FsIGluc3RydWN0aW9u IG9yIG1heSBhbHNvIGJlIHVzZWQgdG8gc3RlZXIgdGhlIGZsb3cgdG8gYSBub2RlIHdoaWNoIGlz IGFwcGx5aW5nIGEgc2VydmljZSBmdW5jdGlvbiB0byBpdC4gSW4gb3JkZXIgdG8gc3VwcG9ydCBh IG1peCBvZiBTUiBQb2xpY2llcyBvZiBkaWZmZXJlbnQgU0xBcyAoc3RyaWN0IGFuZCBub3Qtc3Ry aWN0KSwgd2UgbmVlZCB0byBlbmFibGUgdGhlIGNob2ljZSBvZiBTSURzIHRoYXQgaW5kaWNhdGVz IHRvIHRoZSBQTFIgd2hldGhlciB0aGV5IGFyZSAiYnlwYXNzLWFibGUiIG9yIG5vdC4NCg0KRm9y IHRoZSBjYXNlcywgd2hlcmUgdGhlIFNSIFBvbGljeSBoYXMgYSBzcGVjaWZpYyBTTEEsIGl0IGlz IHJlcXVpcmVkIGZvciBub2RlcyB0byBkcm9wIHRoZSBwYWNrZXRzIG1lYW50IGZvciB0aGUgImFj dGl2ZSBzZWdtZW50IiB0aGFuIHRvIGJ5cGFzcyBpdC4gV2hlbiB0aGlzIG1lY2hhbmlzbSBpcyB1 c2VkIGFsb25nIHNpZGUgU1JURSBwYXRoIG1vbml0b3JpbmcgbWVjaGFuaXNtcywgaXQgZW5hYmxl cyB0aGUgaGVhZGVuZCB0byBkZXRlY3QgdGhlIGZhaWx1cmUgYW5kIGZhbGxiYWNrIHRvIGFuIGFs dGVybmF0ZSBwYXRoIHVzaW5nIHRoZSBwYXRoIHByb3RlY3Rpb24gYXBwcm9hY2guIFRoaXMgaXMg c29tZXRoaW5nIHRoYXQgaXMgZGVzY3JpYmVkIGFuZCBpbiB1c2UgaW4gZGVwbG95bWVudHMgdG9k YXkgWzFdLi4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KWzFdIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zWTNmV3VORllDak1KVWlpQWlXd1VtczZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMu aWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGlj eS0wOCUyM3NlY3Rpb24tOQ0KWzJdIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmZD TXJnbUVld0M0YTRBSlJybW43SDZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZo dG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOCUyM3NlY3Rp b24tOS4zDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzcHJpbmcgPHNwcmlu Zy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJl aGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IDA0IEF1Z3VzdCAyMDIwIDIwOjI1DQpUbzog QWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPG1haWx0 bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRk aGE9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86c2hyYWRkaGE9NDBqdW5pcGVy Lm5ldEBkbWFyYy5pZXRmLm9yZz4+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+IDxBbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20u Y29tPj47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFz enVrLm5ldD4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBK b2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+Pg0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJt aW5pbmcgYXBwbGljYWJpbGl0eQ0KDQpUaGVyZSBhcmUsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLCBh IG51bWJlciBvZiB3YXlzIHRvIGFkZHJlc3MgdGhpcyBmYW1pbHkgb2YgcmVsYXRlZCBxdWVzdGlv bnMuDQpXaGF0IHN0cnVjayBtZSwgYW5kIHByb21wdGVkIHRoZSBzdGFydGluZyBxdWVzdGlvbiwg d2FzIHRoYXQgbm9uZSBvZiB0aGVtIHdlcmUgc3BlbGxlZCBvdXQuICBJIHNlZSBsb3RzIG9mIGlu dGVyZXN0aW5nIGlkZWFzIC8gcHJvcG9zYWxzLg0KU29tZSBvZiB0aGVtIGFyZSBjb21wYXRpYmxl IHdpdGggb3RoZXJzLiAgIFNvbWUgYXJlIG5vdC4NCkl0IHdvdWxkIGJlIGdvb2QgaWYgd2UgY291 bGQgcmVhY2ggYWdyZWVtZW50IG9uIGhvdyB3ZSB0aG91Z2h0IGl0IHNob3VsZCBiZSBoYW5kbGVk Lg0KDQpUaGFuayB5b3UsDQpKb2VsDQoNCk9uIDgvNC8yMDIwIDM6NTQgQU0sIEFsZXhhbmRlciBW YWluc2h0ZWluIHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IEkgYW0gc3RpbGwgbm90IHN1cmUgdGhh dCB0aGUgcHJvYmxlbSBvZiBieXBhc3MgZ29pbmcgdGhydSB1bmRlc2lyYWJsZQ0KPiBsaW5rcy9u b2RlcyBleGlzdHMgaW4gdGhlIGNhc2Ugb2YgdG9wb2xvZ2ljYWwgU0lEcy4NCj4NCj4gQUZBSUss IEZhY2lsaXR5IFByb3RlY3Rpb24gaW4gUlNWUC1URSBGUlIgKFJGQyA0MDkwDQo+IDxodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1E5MmtuRTlYSnVqcmY4Qms3b0p2czZIMj91PWh0dHBz JTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjNDA5MD4pIGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBkZXBsb3llZA0KPiBmb3IgbWFueSB5ZWFycyBiZWZvcmUgU1ItTVBMUyBoYXMgYmVl biBpbnRyb2R1Y2VkLiBXaGF04oCZcyBtb3JlLA0KPiBzaWduYWxpbmcgb2YgYnlwYXNzIHR1bm5l bHMgaGUgUExSIHVzdWFsbHkgZGlkIG5vdCBpbmNsdWRlIGFueSBvZiB0aGUNCj4gY29uc3RyYWlu dHMgdXNlZCBmb3IgY29tcHV0aW5nIG9mIGFueSBzcGVjaWZpYyBMU1AgdGhhdCB0aGUgYnlwYXNz IExTUA0KPiB3b3VsZCBwcm90ZWN0IOKAkyBiZWNhdXNlIGluIHRoZSBGYWNpbGl0eSBQcm90ZWN0 aW9uIG1vZGUgdGhlIHNhbWUNCj4gYnlwYXNzIExTUCB3b3VsZCBiZSB1c2VkIHRvIHByb3RlY3Qg bXVsdGlwbGUgTFNQcyBwYXNzaW5nIHRocnUgdGhlDQo+IGZhaWxlZCBsaW5rL25vZGUuDQo+DQo+ ICBGcm9tIG15IFBPViB0aGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gdGhpcyBiZWhhdmlvciBh bmQgdGhhdA0KPiBpbnRyb2R1Y2VkIGJ5IHRoZSDigJxieXBhc3NpbmfigJ0gZHJhZnRzIGluIFNS IGlzIHRoYXQsIGluIHRoZSBjYXNlIG9mDQo+IFJTVlAtVEUsIHRoZSBvcGVyYXRvciB3b3VsZCBl eHBsaWNpdGx5IGluZGljYXRlLCBhcyBwYXJ0IG9mIExTUA0KPiBzaWduYWxpbmcsIHdoZXRoZXIg aXQgd291bGQgb3Igd291bGQgbm90IHVzZSBGUlI7IExTUHMgdGhhdCB3b3VsZCBub3QNCj4gdXNl IEZSUiB3b3VsZCB0aGVuIGRyb3AgdHJhZmZpYyByYXRoZXIgdGhhbiBkZWxpdmVyaW5nIGl0IHRo ZSB3cm9uZyB3YXkuDQo+DQo+IFN1Y2ggYW4gb3B0aW9uIGluZGVlZCBkb2VzIG5vdCBleGlzdCBp biBTUi1URSB0b2RheSwgYnV0IHdvdWxkIGJlIGVhc3kNCj4gdG8gcHJvdmlkZSBpZiBzbyBkZXNp cmVkIElNSE8uDQo+DQo+IERpZCBJIG1pc3Mgc29tZXRoaW5nIHN1YnN0YW50aWFsPw0KPg0KPiBS ZWdhcmRzLCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2YW5jZSwNCj4NCj4gU2FzaGENCj4NCj4g T2ZmaWNlOiArOTcyLTM5MjY2MzAyDQo+DQo+IENlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDINCj4N Cj4gRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPg0KPiAqRnJvbToqIHNwcmluZyA8c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gKk9uIEJl aGFsZiBPZiAqU2hyYWRkaGEgSGVnZGUNCj4gKlNlbnQ6KiBUdWVzZGF5LCBBdWd1c3QgNCwgMjAy MCA5OjQxIEFNDQo+ICpUbzoqIEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1h aWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4NCj4gPEFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5j b20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6 dWsubmV0Pj4NCj4gKkNjOiogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+Pg0KPiAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAt IGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4NCj4gQWxsLA0KPg0KPiBUaGlzIGlzIGEgdmVy eSBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIGFuZCB0aGFua3MgdG8gSm9lbCBmb3Igc3RhcnRpbmcN Cj4gdGhpcyBkaXNjdXNzaW9uLiBJTU8sIHdoZW4gdGhlcmUgYXJlIHN0cmljdCByZXF1aXJlbWVu dHMgb2YgYXZvaWRpbmcNCj4gY2VydGFpbiBub2Rlcy9saW5rcyBpdCBjYW4gYmUgcmVhbGl6ZWQg IGVpdGhlciBieSBkZWZpbmluZyBhIGZsZXgtYWxnbw0KPiBhdm9pZGluZyB0aG9zZQ0KPg0KPiBO b2RlcyBhbmQgbGlua3Mgb3IgYnkgdXNpbmcgYSBzdGFjayBvZiB1bnByb3RlY3RlZCBhZGotc2lk cyB0aGF0IGF2b2lkDQo+IHJlc3RyaWN0ZWQgbm9kZXMgYW5kIGxpbmtzLiBXaGVuIGEgc3RhY2sg b2YgYWRqLXNpZHMgaXMgdXNlZCB0bw0KPiByZWFsaXplIHRoZSBwYXRoLCB0aGUgaGVhZC1lbmQg YmFzZWQgKHNCRkQpIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBjYW4gYmUgYXBwbGllZC4NCj4NCj4g SWYgTm9kZS1zaWRzL3ByZWZpeC1zaWQvYW55Y2FzdC1zaWRzIGFyZSB1c2VkIHRvIGJ1aWxkIHRo ZSBzdGFjaywgdGhlDQo+IGZhaWx1cmUgZXZlbnRzIG1heSBjYXVzZSB0cmFmZmljIHRvIGdvIHRo cm91Z2ggcmVzdHJpY3RlZCBub2RlcyBhbmQNCj4gbGlua3MuIFRoaXMgd291bGQgaGFwcGVuIHJl Z2FyZGxlc3Mgb2Ygd2hldGhlciBhbnkga2luZCBvZiBwcm90ZWN0aW9uDQo+IGlzIGluIHVzZSBv ciBub3QuDQo+DQo+IFJnZHMNCj4NCj4gU2hyYWRkaGENCj4NCj4gSnVuaXBlciBCdXNpbmVzcyBV c2UgT25seQ0KPg0KPiAqRnJvbToqIHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMjAlMGI+PiA8bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPj4gKk9uIEJlaGFsZiBPZiAqQW5kcmV3IEFsc3Rvbg0KPiAqU2VudDoqIFR1 ZXNkYXksIEF1Z3VzdCA0LCAyMDIwIDU6NDEgQU0NCj4gKlRvOiogUm9iZXJ0IFJhc3p1ayA8cm9i ZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PiA8bWFpbHRvOnJvYmVydEBy YXN6dWsubmV0Pj4NCj4gKkNjOiogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPjsgSm9lbCBNLiBIYWxwZXJuDQo+IDxqbWhAam9l bGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPiA8bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+Pg0KPiAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlv biAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4NCj4gKltFeHRlcm5hbCBFbWFpbC4gQmUg Y2F1dGlvdXMgb2YgY29udGVudF0qDQo+DQo+IFJvYmVydCB0aGlzIGlzIGFjdHVhbGx5IGZhciBt b3JlIGRpZmZpY3VsdCB3aGVuIOKAkyBpdCBjYW4gYmUgYW4gZW50aXJlDQo+IChsb25nKSBzZXJp ZXMgb2Ygbm9kZXMgdGhhdCBuZWVkIHRvIGJlIGF2b2lkZWQuDQo+DQo+IEl0IGNvdWxkIHBvdGVu dGlhbGx5IGJlIG1hZGUgdG8gd29yayBidXQgSeKAmWQgd29ycnkgdGhhdCB0byBkbyB0aGlzIOKA kw0KPiB5b3XigJlkIGhhdmUgdG8gc3RhY2sgMTAg4oCTIDIwIOKAkyAzMCBuZWdhdGl2ZSBsYWJl bHMg4oCTIGFuZCB0aGF0IHdvdWxkbuKAmXQNCj4gYmUgdmlhYmxlLg0KPg0KPiBJdOKAmXMgZWFz aWVyIHRvIHVzZSBhbGdvcml0aG1zIGFuZCBhZGphY2VuY3kgc2lkcyBhbmQgb3RoZXIgc3VjaCB0 aGluZ3MNCj4gdG8gY2FsY3VsYXRlIHBhdGhzIOKAkyB0aGUgYmlnZ2VzdCB0cmljayBpcyBhYm91 dCB0aGUgc3RhY2sgZGVwdGguICBXaGVuDQo+IHlvdSBoYXZlIHRoaXMgbmVlZCBmb3Igbm9kZSBh dm9pZGFuY2Ug4oCTIHRoZSBuZWVkIGZvciAxMCsgbGFiZWwgZGVwdGgNCj4gaXMgY3JpdGljYWwg 4oCTIHVubGVzcyB5b3Ugd2FubmEgYmUgYXBwbHlpbmcgb25lIGhlbGwgb2YgYSBsb3Qgb2YNCj4g YmluZGluZyBsYWJlbHMgYWxvbmcgdGhlIHdheSB3aGljaCBpcyBhIG5pZ2h0bWFyZS4NCj4NCj4g QnV0IHRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uLCBpcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNlIOKA kyBpdOKAmXMgYSB1c2UNCj4gY2FzZSB0aGF0IG1vc3Qgb2YgdGhlIHBlb3BsZSBJIGRpc2N1c3Mg dGhpcyB3aXRoIGNlcnRhaW4gaGF2ZSDigJMgSSBjYW50DQo+IGNvbW1lbnQgb24gYSBnbG9iYWwg c2NhbGUsIG9yIGZvciBhbnlvbmUgZWxzZSwgYnV0IGV2ZXJ5IGluZGljYXRpb24gSQ0KPiBoYXZl IGlzIHRoYXQgeWVzIOKAkyBpdHMgc29tZXRoaW5nIHBlb3BsZSBuZWVkLCBhbmQgd2FudA0KPg0K PiBBbmRyZXcNCj4NCj4gKkZyb206KiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+IDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAq U2VudDoqIFR1ZXNkYXksIDQgQXVndXN0IDIwMjAgMDE6MjcNCj4gKlRvOiogQW5kcmV3IEFsc3Rv biA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbQ0KPG1haWx0bzpBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tJTIwJTBiPj4gPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPj4NCj4gKkNjOiogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29t DQo8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMjAlMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+Pjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+IDxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcg cHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4NCj4gSXMgdGhpcyBhIGNv bW1vbiB1c2UgY2FzZSBpZS4gICJidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsN Cj4gc2VnbWVudHMgaXQgY2FuIG5ldmVyIHRvdWNoIG9yIGZsb3cgdGhyb3VnaC4iDQo+DQo+IElm IHNvIHBlcmhhcHMgaXRzIHRpbWUgdG8gZGVmaW5lIG5vdGlvbiBvZiAqbmVnYXRpdmUtU0lEKiBp ZS4gbGlzdCBpbg0KPiB0aGUgcGFja2V0IHJlc291cmNlcyB3aGljaCBnaXZlbiBwYWNrZXQgTVVT VCBub3QgZXZlciB0cmF2ZXJzZS4NCj4NCj4gUHV0IGluIHRoZSBwYWNrZXQgc2V0IG9mIG5vZGVz IG9yIGxpbmtzIHdoaWNoIHRoZSBwYWNrZXQgc2hvdWxkIG5ldmVyDQo+IHRyYXZlcnNlLg0KPg0K PiBUaGF0IGdvZXMgaW4gbGluZSBvZiByZWNlbnQgd2F2ZSBvZiBuZWdhdGl2ZSByb3V0aW5nIGlt cGxlbWVudGF0aW9ucw0KPiAoUklGVCkgb3IgZGlzY3Vzc2lvbnMgKExTUikNCj4NCj4gQmVzdCwN Cj4gUi4NCj4NCj4gT24gTW9uLCBBdWcgMywgMjAyMCBhdCAxMTo0NiBQTSBBbmRyZXcgQWxzdG9u DQo+IDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8bWFpbHRvOkFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGI+PiA8bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb20+PiB3cm90ZToNCj4NCj4gICAgIFNvIOKAkw0KPg0KPiAgICAgT25lIG9mIHRo ZSB1c2UgY2FzZXMsIGluIGZhY3QsIHNvbWUgdmVyeSBtYWpvciB1c2UgY2FzZXMgaW4gYW55DQo+ ICAgICBzcHJpbmcgdGVjaG5vbG9neSBmb3IgdXMgcmV2b2x2ZSBhcm91bmQgdGhlIGZvbGxvd2lu Zw0KPg0KPiAgICAgYS5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9kZXMNCj4N Cj4gICAgIGIuVGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIHNlY3Rpb25zIG9mIHRo ZSBuZXR3b3JrDQo+DQo+ICAgICBBbnl0aGluZyB0aGF0IGNvdWxkIHJlc3VsdCBpbiB0aGF0IGV4 cGxpY2l0IGF2b2lkYW5jZSBiZWluZyB2aW9sYXRlZA0KPiAgICAg4oCTIHdvdWxkIGNyZWF0ZSwg c2hhbGwgd2Ugc2F5IHNpZ25pZmljYW50IHByb2JsZW1zLg0KPg0KPiAgICAgTXVjaCBvZiB0aGUg dXNlIGNhc2UgaXMgbm90IGEgY2FzZSBvZiB3aGljaCBub2RlcyB0aGUgcGFja2V0cyBmbG93DQo+ ICAgICB0aHJvdWdoIOKAkyBidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2Vn bWVudHMgaXQgY2FuIG5ldmVyDQo+ICAgICB0b3VjaCBvciBmbG93IHRocm91Z2guICBFZmZlY3Rp dmVseSwgdG8gYmUgdXNlZCBhcyBhIHRlY2hub2xvZ3kgdG8NCj4gICAgIGF2b2lkIGNlcnRhaW4g dGhpbmdzIGZvciBzcGVjaWZpYyByZWFzb25zLg0KPg0KPiAgICAgVGhpcyBpcyBhbHNvIG9uZSBv ZiB0aGUgcmVhc29ucyBmb3IgbmVlZGluZyBzdWNoIGRlZXAgbGFiZWwgc3RhY2tzIOKAkw0KPiAg ICAgdGhpcyBraW5kIG9mIGRldGFpbGVkIHBhdGggcHJvZ3JhbW1pbmcgdGVuZHMgdG8gZGVlcGVu IHRoZSBzdGFjaw0KPiAgICAgYmVjYXVzZSB5b3Ugc29tZXRpbWVzIGhhdmUgdG8gYmUgcHJldHR5 IGV4cGxpY2l0Lg0KPg0KPiAgICAgSXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1cyB0aGF0 IHRoaXMgZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDigJMNCj4gICAgIGFuZCB0aGF0IHdlIGNhbiBh dm9pZCBzaXR1YXRpb25zIHdoaWNoIGNvdWxkIGNhdXNlIHRyYWZmaWMgdG8NCj4gICAgIGFjY2lk ZW50bHkgaGl0IHRoaW5ncyBleHBsaWNpdGx5IGF2b2lkZWQuDQo+DQo+ICAgICBJIHdpc2ggSSBj b3VsZCBiZSBtb3JlIHNwZWNpZmljIHRoYW4gdGhpcywgYnV0IGl0IGlzIHdoYXQgaXQgaXMuDQo+ DQo+ICAgICBUaGFua3MNCj4NCj4gICAgIEFuZHJldw0KPg0KPiAgICAgKkZyb206KiBzcHJpbmcg PHNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn JTBiPj4gICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9m ICpKb2VsIE0uIEhhbHBlcm4NCj4gICAgICpTZW50OiogTW9uZGF5LCAzIEF1Z3VzdCAyMDIwIDIx OjM2DQo+ICAgICAqVG86KiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86 cm9iZXJ0QHJhc3p1ay5uZXQ+IDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAgICAgKkNj Oiogc3ByaW5nQGlldGYuLm9yZzxtYWlsdG86c3ByaW5nQGlldGYuLm9yZz4gPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQo+ICAgICAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVj dGlvbiAtIGRldGVybWluaW5nDQo+IGFwcGxpY2FiaWxpdHkNCj4NCj4gICAgIChTaW5jZSB0aGUg dGhyZWFkIGhhcyBnb3R0ZW4gbG9uZyBlbm91Z2gsIHJlaXRlcmF0aW5nIHRoYXQgdGhpcyBpcyBh cyBhDQo+ICAgICBwYXJ0aWNpcGFudCwgbm90IGEgV0cgY2hhaXIuKQ0KPg0KPiAgICAgWWVzLCB3 ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29y a3MgdGhhdA0KPiAgICAgY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFsbCBzb3J0cyBvZiBy ZWFzb25zLg0KPiAgICAgSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5 IG9uZSBtYXkgbm90IHdhbnQgYSByYW5kb20NCj4gICAgIHBhdGggcmF0aGVyIHRoYW4gYSBjaG9z ZW4gVEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXINCj4gICAgIGFi b3V0IHdoYXQgY29uc3RyYWludHMgbWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBw ZW9wbGUgdGhleQ0KPiAgICAgaGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0 aGF0IGlzIGludGVuZGVkIHRvIHByZXNlcnZlIFFvUy4NCj4NCj4gICAgIExldCdzIGJlIGNsZWFy LiBJIGFtIG5vdCBhcmd1aW5nIHRoYXQgdGhpcyBpcyBub3QgYSBnb29kIGlkZWEuIEl0IGlzIGEN Cj4gICAgIGdvb2QgaWRlYS4gQW5kIHVzZWZ1bC4gSSBhbSB0cnlpbmcgdG8gZmlndXJlIG90dSB3 aGF0IGNvbWJpbmF0aW9uIG9mDQo+ICAgICBhZGRpdGlvbmFsIG1lY2hhbmlzbXMgYW5kIGNsZWFy IGRlc2NyaXB0aW9ucyB3aWxsIGxlYWQgdG8gZXZlcnlvbmUNCj4gICAgIGdldHRpbmcgdGhlIGJl aGF2aW9yIHRoZXkgZXhwZWN0ICh3aGljaCBtYXkgbm90IGJlIHRoZSBiZWhhdmlvciB0aGV5DQo+ ICAgICBkZXNpcmUsIGJ1dCBzb21ldGltZXMgaXMgdGhlIGJlc3Qgd2UgY2FuIGRvLikNCj4NCj4g ICAgIFlvdXJzLA0KPiAgICAgSm9lbA0KPg0KPiAgICAgT24gOC8zLzIwMjAgMjozMCBQTSwgUm9i ZXJ0IFJhc3p1ayB3cm90ZToNCj4gICAgICA+IEpvZWwsDQo+ICAgICAgPg0KPiAgICAgID4gQXJl IHdlIHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya3MgaGVyZSA/IE9yIHBlcmhhcHMgc29t ZSBoYXJkDQo+ICAgICAgPiBzbGljaW5nIHdpdGggcmVhbCByZXNvdXJjZSByZXNlcnZhdGlvbnMg b3IgZGV0bmV0cyA/DQo+ICAgICAgPg0KPiAgICAgID4gQmVjYXVzZSBpZiB3ZSBhcmUgdGFsa2lu ZyBhYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d28NCj4gICAgIG9ic2VydmF0aW9uczoNCj4g ICAgICA+DQo+ICAgICAgPiBBKSBJZiB5b3UgbmVlZCB0byB0cmF2ZXJzZSB2aWEgYSBzcGVjaWZp YyBub2RlIChpZS4gZmlyZXdhbGwpIHlvdQ0KPiAgICAgYmV0dGVyDQo+ICAgICAgPiBhcHBseSBJ UCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4uIEkgZG9uJ3QgdGhpbmsgSVANCj4gICAgIGVu Y2Fwc3VsYXRpb24gY2FuDQo+ICAgICAgPiBiZSBoaWphY2tlZCB0b2RheSBzdWNoIHRoYXQgZGVz dGluYXRpb24gYWRkcmVzcyBvZiB0aGUgcGFja2V0IGlzDQo+ICAgICBpZ25vcmVkLg0KPiAgICAg ID4NCj4gICAgICA+IEIpIEhhdmUgeW91IHNlZW4gYW55IElQIG5ldHdvcmsgd2hlcmUgdXBvbiB0 b3BvbG9neSBjaGFuZ2UgKGxpbmsNCj4gICAgIG9yIG5vZGUNCj4gICAgICA+IGZhaWx1cmUpIHlv dSBzdWRkZW5seSBzdGFydCBkcm9wcGluZyBmbG93cyBpbiBzcGl0ZSBvZiBTUFQgb2ZmZXJpbmcN Cj4gICAgICA+IHBlcmhhcHMgZmV3IG1zIGxvbmdlciBwYXRoIHdpdGggMTAgbXMgbW9yZSBqaXR0 ZXIgPw0KPiAgICAgID4NCj4gICAgICA+IE9yIGFyZSBzb21lIFNSIG1hcmtldGluZyBzbGlkZXMg cHJvbWlzZSB0byB0dXJuIElQIG5ldHdvcmtzIGluDQo+ICAgICAgPiBzb21ldGhpbmcgbmV3ID8g V29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3VhcmFudGVlcywNCj4gICAg ICA+IHJlc291cmNlIHJlc2VydmF0aW9ucyA/IEkgaG9wZSBub3QuDQo+ICAgICAgPg0KPiAgICAg ID4gVGh4LA0KPiAgICAgID4gUi4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAg ICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4g ICAgICA+IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgODoxMCBQTSBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20NCjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYj4+ICAgICA8 bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMjAlMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+PiB3cm90ZToNCj4gICAgICA+DQo+ICAgICAgPiBXZWxsIGxlc3Mgc2VyaW91cyBmb3Ig VEUgU0lEcywgSSBhbSBub3Qgc3VyZSB0aGUgcHJvYmxlbSBpcw0KPiAgICAgcmVzdHJpY3RlZA0K PiAgICAgID4gdG8ganVzdCBzZXJ2aWNlIFNJRHMuDQo+ICAgICAgPg0KPiAgICAgID4gU3VwcG9z ZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0aGUgcGF0aCB0byBtZWV0IHNvbWUgY29tcGxl eCB0ZQ0KPiAgICAgID4gb2JqZWN0aXZlLiAgVGhlIGJ5cGFzcyBub2RlIGhhcyBubyB3YXkgb2Yg a25vd2luZyB3aGF0IHRob3NlDQo+ICAgICAgPiBjb25zdHJhaW50cw0KPiAgICAgID4gd2VyZS4g IEFuZCBmb3Igc29tZSBraW5kcyBvZiB0cmFmZmljLCBpdCBpcyBiZXR0ZXIgdG8gZHJvcCB0aGUg cGFja2V0DQo+ICAgICAgPiB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lkZSB0aGUgZW52ZWxvcC4g IEkgc3VzcGVjdCB0aGF0IHRoZSByaWdodA0KPiAgICAgID4gYW5zd2VyDQo+ICAgICAgPiB0byB0 aGlzIGlzICJ0b28gYmFkIi4gIElmIHNvLCBhcyB3aXRoIHRoZSBkaXN0aW5jdGlvbiByZWdhcmRp bmcNCj4gICAgIHNlcnZpY2UNCj4gICAgICA+IG5vZGVzLCB3ZSBzaG91bGQgc2F5IHNvLCBzaG91 bGRuJ3Qgd2U/DQo+ICAgICAgPg0KPiAgICAgID4gWW91cnMsDQo+ICAgICAgPiBKb2VsDQo+ICAg ICAgPg0KPiAgICAgID4gT24gOC8zLzIwMjAgMjozNiBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4g d3JvdGU6DQo+ICAgICAgPiA+IE1hY2gsIEpvZWwgYW5kIGFsbCwNCj4gICAgICA+ID4NCj4gICAg ICA+ID4gSSB0aGluayB0aGF0IGluIG1vc3QgY2FzZXM6DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ IDEuVGhlcmUgaXMgY2xlYXIgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gInRvcG9sb2dpY2FsIiBh bmQNCj4gICAgICJzZXJ2aWNlIg0KPiAgICAgID4gPiBpbnN0cnVjdGlvbnMgaW4gU0lEIGFkdmVy dGlzZW1lbnRzLiBFLmcuOg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBvSUdQIFByZWZpeCBOb2Rl IFNJRHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4gdGhlDQo+ICAgICAgPiA+ IGNvcnJlc3BvbmRpbmcgSUdQIGFkdmVydGlzZW1lbnRzKSByZXByZXNlbnQgdG9wb2xvZ2ljYWwN Cj4gICAgIGluc3RydWN0aW9ucw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBvU2VydmljZSBTSURz IGZvciBTUnY2IChzZWUgU1J2NiBCR1AtQmFzZWQgT3ZlcmxheSBTZXJ2aWNlcw0KPiAgICAgID4g Pg0KPiAgICAgID4NCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0NDY3k5 bVk2Y01mYms3UWZqaGlBM1I2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0DQo8aHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNDQ2N5OW1ZNmNNZmJrN1FmamhpQTNSNkgyP3U9aHR0 cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRm LWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNCUwYj4+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzNHQzVhZjJ6M0p6cGhaRGtQbmNIQVFpNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZl bnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJG aHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0X18lM0IlMjElMjFORXQ2eU1h Ty1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFr VFJEdWlEbzRULUwwbmwlMjQ+Pg0KPiAgICAgID4NCj4gICAgICA+ID4gZHJhZnQpIHVuc3VycHJp c2luZ2x5IHJlcHJlc2VudCDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucw0KPiAgICAgID4gPg0K PiAgICAgID4gPiAyLlNlZ21lbnRzIHRoYXQgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0 aW9ucyBjYW4gYmUgYnlwYXNzZWQsDQo+ICAgICAgPiA+IHdoaWxlIHNlZ21lbnRzIHRoYXQgcmVw cmVzZW50IHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHJlcXVpcmUNCj4gICAgICA+IGFsdGVybmF0aXZl DQo+ICAgICAgPiA+IHByb3RlY3Rpb24gbWVjaGFuaXNtcy4NCj4gICAgICA+ID4NCj4gICAgICA+ ID4gVGhpcyB2aWV3IHNlZW1zIHRvIGJlIGFsaWduZWQgd2l0aCBSRkMgODQwMg0KPiAgICAgID4g PiA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM0NU5MQ0I2VHlkeHV1cVVqdGNEUlp5 NkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyDQo8aHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM0NU5MQ0I2VHlkeHV1cVVqdGNEUlp5NkgyP3U9 aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyJTBiPj4gICAgIDxo dHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzdQelVLQUQ4MmNqU3ZtVmNHdnBraEY2SDI/ dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGdG9vbHMu aWV0Zi5vcmclMkZodG1sJTJGcmZjODQwMl9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5 RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8wSTRZYnRt JTI0Pj4NCj4gICAgIHRoYXQgc2F5cyBpbiBTZWN0aW9uIDE6DQo+ICAgICAgPiA+DQo+ICAgICAg PiA+ICAgICBJbiB0aGUgY29udGV4dCBvZiBhbiBJR1AtYmFzZWQgZGlzdHJpYnV0ZWQgY29udHJv bCBwbGFuZSwgdHdvDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IHRvcG9sb2dpY2FsIHNlZ21lbnRz IGFyZSBkZWZpbmVkOiB0aGUgSUdQLUFkamFjZW5jeSBzZWdtZW50IGFuZCB0aGUNCj4gICAgICA+ ID4NCj4gICAgICA+ID4gICAgIElHUC1QcmVmaXggc2VnbWVudC4NCj4gICAgICA+ID4NCj4gICAg ICA+ID4gICAgIEluIHRoZSBjb250ZXh0IG9mIGEgQkdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRy b2wgcGxhbmUsIHR3bw0KPiAgICAgID4gPg0KPiAgICAgID4gPiB0b3BvbG9naWNhbCBzZWdtZW50 cyBhcmUgZGVmaW5lZDogdGhlIEJHUCBwZWVyaW5nIHNlZ21lbnQgYW5kIHRoZQ0KPiAgICAgID4g Pg0KPiAgICAgID4gPiAgICAgQkdQLVByZWZpeCBzZWdtZW50Lg0KPiAgICAgID4gPg0KPiAgICAg ID4gPiBJbiB0aGUgY2FzZSBvZiBTUi1NUExTIHRoaXMgZGlmZmVyZW50aWF0aW9uIGlzIGFzc3Vt ZWQgaW4gU2VjdGlvbg0KPiAgICAgID4gMy40IG9mDQo+ICAgICAgPiA+IHRoZSBOb2RlIFByb3Rl Y3Rpb24gZm9yIFNSLVRFIFBhdGgNCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICA8aHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFmTlBzWmRocEV4eHg5NkgyP3U9aHR0 cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdk ZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rpb24tMy40 DQo8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFmTlBzWmRocEV4eHg5 NkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZk cmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyM3Nl Y3Rpb24tMy40JTBiPj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0NyVWdB Ulc4c29tQWJ3NlRpc2pnSjE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMl MkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQt aGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDclMkFzZWN0aW9u LTMuNF9fJTNCSXclMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzl3Ty1Tc24lMjQ+Pg0KPiAgICAgID4NCj4g ICAgICA+ID4gZHJhZnQgdGhhdCBzYXlzOg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgVGhl IG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cw0KPiAg ICAgc2VjdGlvbnMNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIGRlcGVuZHMgb24gdGhlIGFz c3VtcHRpb24gdGhhdCB0aGUgbGFiZWwgaW1tZWRpYXRlbHkgYmVsb3cNCj4gICAgICA+IHRoZSB0 b3ANCj4gICAgICA+ID4NCj4gICAgICA+ID4gbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVu ZGVyc3Rvb2QgaW4gdGhlIElHUCBkb21haW4uICBXaGVuIHRoZQ0KPiAgICAgID4gPg0KPiAgICAg ID4gPiAgICAgcHJvdmlkZXIgZWRnZSByb3V0ZXJzIGV4Y2hhbmdlIHNlcnZpY2UgbGFiZWxzIHZp YSBCR1Agb3Igc29tZQ0KPiAgICAgID4gb3RoZXINCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAg IG5vbi1JR1AgbWVjaGFuaXNtIHRoZSBib3R0b20gbGFiZWwgaXMgbm90IHVuZGVyc3Rvb2QgaW4g dGhlIElHUA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgZG9tYWluLg0KPiAgICAgID4gPg0K PiAgICAgID4gPiAgICAgVGhlIGVncmVzcyBub2RlIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBkZXNj cmliZWQgaW4gdGhlIGRyYWZ0DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBbUkZDODY3OSA8 aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFqQTNwTTZUZENFNkgy P3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4 Njc5DQo8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFqQTNwTTZU ZENFNkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwl MkZyZmM4Njc5JTBiPj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzZkTUFq dVlUUW92bzhqSHdtbTNlSnc2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMl MkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODY3 OV9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hx Z3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG84TUdpcFhjJTI0Pj5dDQo+ICAgICBpcw0KPiAgICAg ID4gPiBhcHBsaWNhYmxlIHRvIHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdl cw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgd2lsbCBiZSByZXF1aXJlZCBmb3IgU1IgYmFz ZWQgbmV0d29ya3MNCj4gICAgICA+ID4NCj4gICAgICA+ID4gVGhlIHNjZW5hcmlvcyBpbiB3aGlj aCAgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4g4oCcdG9wb2xvZ2ljYWzigJ0gYW5kDQo+ICAgICAg PiA+IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zIGlzIGJyb2tlbiBhcmUgaW5kZWVkIHByb2Js ZW1hdGljLiBFLmcuLA0KPiAgICAgID4gY29uc2lkZXINCj4gICAgICA+ID4gdGhlIHVzZSBjYXNl IGluIHdoaWNoIGEgTm9kZSBTSUQgaW4gdGhlIEVSTyBvZiBhIFNSLVRFIHBhdGgNCj4gICAgICA+ IGlkZW50aWZpZXMgYQ0KPiAgICAgID4gPiBub2RlIHRoYXQgYWN0cyBhcyBhIGZpcmV3YWxsIGZv ciBhbGwgcGFja2V0cyBpdCByZWNlaXZlcywgaS5lLiwNCj4gICAgICA+IHByb3ZpZGVzDQo+ICAg ICAgPiA+IHRoZSBmaXJld2FsbCBzZXJ2aWNlIHdpdGhvdXQgYW55IGRlZGljYXRlZCBzZXJ2aWNl IFNJRA0KPiAgICAgID4gaWRlbnRpZnlpbmcgaXQuDQo+ICAgICAgPiA+IE9uZSBjb3VsZCBzYXkg dGhhdCB0aGUgTm9kZSBTSUQgb2Ygc3VjaCBhIG5vZGUgd291bGQgY29tYmluZQ0KPiAgICAgID4g dG9wb2xvZ2ljYWwNCj4gICAgICA+ID4gYW5kIHNlcnZpY2UgaW5zdHJ1Y3Rpb25zIHRodXMgYnJl YWtpbmcgdGhlIGRpZmZlcmVudGlhdGlvbg0KPiAgICAgID4gYmV0d2VlbiB0aGUgdHdvLg0KPiAg ICAgID4gPg0KPiAgICAgID4gPiBJIGFtIG5vdCBzdXJlIGlmIHVzYWdlIG9mIHN1Y2gg4oCcY29t YmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2ZW50ZWQNCj4gICAgICA+IG9yIGF0DQo+ICAgICAg PiA+IGxlYXN0IGRpc2NvdXJhZ2VkLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJZiBub3QsIHBy b3ZpZGluZyBhbiBhYmlsaXR5IHRvIGlkZW50aWZ5IHN1Y2ggU0lEcyBpbiB0aGUNCj4gICAgICA+ IGFkdmVydGlzZW1lbnQNCj4gICAgICA+ID4gbWVjaGFuaXNtcyB3b3VsZCBiZSB1c2VmdWwgSU1I Ty4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gTXkgMmMsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ IFNhc2hhDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IE9mZmljZTogKzk3Mi0zOTI2NjMwMg0KPiAg ICAgID4gPg0KPiAgICAgID4gPiBDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyDQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+IEVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICA8bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPiAgICAgID4gPG1haWx0bzpBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gICAgICA+ID4gRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNl c0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYj4+ICAgICA8bWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiPj4NCj4gICAgIDxtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFjaCBDaGVuDQo+ICAgICAgPiA+IFNlbnQ6 IE1vbmRheSwgQXVndXN0IDMsIDIwMjAgNjozMCBBTQ0KPiAgICAgID4gPiBUbzogSm9lbCBNLiBI YWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20l MGI+PiAgICAgPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiPj4gPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPj47DQo+ICAgICBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K PiAgICAgID4gPiBTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRl cm1pbmluZyBhcHBsaWNhYmlsaXR5DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEhpIEpvZWwsDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgcG9pbnQgdGhhdCBt YXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0aGUNCj4gICAgICA+IHBhc3QuIEFuZA0KPiAgICAgID4g PiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAiY2FuIGJlIGJ5cGFzc2VkIiBpbmRpY2F0 aW9uIGluIHRoZQ0KPiAgICAgID4gPiByb3V0aW5nIGFkdmVydGlzZW1lbnQgZm9yIG5vdy4NCj4g ICAgICA+ID4NCj4gICAgICA+ID4gSU1ITywgdGhlIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgYnkg cm91dGluZyBpcyBuZXV0cmFsLCBzdWNoDQo+ICAgICAgPiBpbmZvcm1hdGlvbg0KPiAgICAgID4g PiAoY2FuIG9yIGNhbm5vdCBiZSBieXBhc3NlZCkgaXMgbW9yZSBwYXRoIHNwZWNpZmljLCB0aHVz DQo+ICAgICBub3JtYWxseSB0aGUNCj4gICAgICA+ID4gY29udHJvbGxlciBzaG91bGQgYmUgcmVz cG9uc2libGUgZm9yIGRlY2lkaW5nIHdoZXRoZXIvd2hpY2ggU0lEDQo+ICAgICAgPiBjYW4gYmUN Cj4gICAgICA+ID4gYnlwYXNzZWQuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEJlc3QgcmVnYXJk cywNCj4gICAgICA+ID4NCj4gICAgICA+ID4gTWFjaA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAg PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBG cm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc+DQo+ICAgICAgPiA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUzY21h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUzZT5dDQo+ICAgICBPbiBCZWhhbGYgT2YgSm9l bCBNLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBIYWxwZXJuDQo+ICAgICAgPiA+DQo+ICAg ICAgPiA+ICA+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMsIDIwMjAgNzo1MSBBTQ0KPiAgICAgID4g Pg0KPiAgICAgID4gPiAgPiBUbzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQo+ICAgICAgPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZw0KPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3Jn JTBiPj4gICAgIDxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4+Pg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBTdWJqZWN0OiBbc3ByaW5nXSBTcHJp bmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4gICAgICA+ID4NCj4g ICAgICA+ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gKFdHIENoYWlyIGhhdCBPZmYs IHRoaXMgaXMgbWVyZWx5IGEgbm90ZSBmcm9tIGEgc2xpZ2h0bHkNCj4gICAgICA+IGNvbmZ1c2Vk IFdHDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IHBhcnRpY2lwYW50LikNCj4gICAgICA+ID4N Cj4gICAgICA+ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gSSBoYXZlIGJlZW4gcmVh ZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXMNCj4gICAgICA+ ID4NCj4gICAgICA+ID4gID4gbmV0d29ya3MgcHJvZ3JhbW1pbmcgYW5kIHNlcnZpY2UgcHJvZ3Jh bW1pbmcgZHJhZnQsIGFuZCBJIGFtDQo+ICAgICAgPiB0cnlpbmcgdG8NCj4gICAgICA+ID4NCj4g ICAgICA+ID4gID4gZmlndXJlIG91dCBvbmUgYXNwZWN0IG9mIHRoZSBjb21iaW5hdGlvbi4NCj4g ICAgICA+ID4NCj4gICAgICA+ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gSG93IGRv ZXMgYSBub2RlIHRoYXQgaXMgZG9pbmcgc29tZSBmb3JtIG9mIGJ5cGFzcyAoc3VwcG9zZSwgZm9y DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IHNpbXBsaWNpdHksIGl0IGlzIE5vZGUgTjIgZGVj aWRpbmcgdG8gYnlwYXNzIHRoZSBuZXh0IFNJRCBmb3INCj4gICAgICA+IGEgZmFpbGVkDQo+ICAg ICAgPiA+DQo+ICAgICAgPiA+ICA+IG5vZGUgTjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRv IHNvPw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAg PiBJZiB0aGUgcGF0aCB3YXMganVzdCBmb3IgVEUsIHRoZW4gaXQgaXMgInNhZmUiIGlmIHRoZSBu ZXcgcGF0aA0KPiAgICAgID4gbWVldHMNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gdGhlIFRF IGNyaXRlcmlhLiAgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBpdCBpcyBldmVuIGNsb3NlLCBhcw0K PiAgICAgID4gbG9uZyBhcw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBpdCBpcyBub3QgdXNl ZCBmb3IgdG9vIGxvbmcuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+ICA+IEJ1dCB3aGF0IGlmIHRoZSBub2RlIHdlcmUgYSBGaXJld2FsbCwgaW5jbHVk ZWQgdG8gbWVldCBsZWdhbA0KPiAgICAgID4gPiByZXF1aXJlbWVudHM/DQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+ICA+IE9yIHdhcyBzb21lIG90aGVyIG5lY2Vzc2FyeSBwcm9ncmFtbWF0aWMgdHJh bnNmb3JtICh3aW5jZSB3ZSBhcmUNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gZGVsaWJlcmF0 ZWx5IHZhZ3VlIGFib3V0IHdoYXQgbm9kZXMgY2FuIGRvIHdoZW4gYXNrZWQgc3VpdGFibHkuKQ0K PiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBJcyB0 aGVyZSBzb21lICJjYW4gYmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmcNCj4g ICAgICA+ID4NCj4gICAgICA+ID4gID4gYWR2ZXJ0aXNlbWVudHMgdGhhdCBJIG1pc3NlZD8NCj4g ICAgICA+ID4NCj4gICAgICA+ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gVGhhbmsg eW91LA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBZb3VycywNCj4gICAgICA+ID4NCj4gICAg ICA+ID4gID4gSm9lbA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAg PiA+DQo+ICAgICAgPiA+ICA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3Jn PiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIDxtYWlsdG86c3ByaW5nQGlldGYub3Jn Pg0KPiAgICAgID4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmcNCjxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUw Yj4+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5v cmc+Pj4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+DQo+ ICAgICBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2 UDQ2SDI/dT1odHRwcyUzQSUyPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0 S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1Mj4NCj4gICAgIDxodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vM1E3dlgycVdTVWRXVmM4OTJYdVh5Mkg2SDI/dT1odHRwcyUzQSUy RiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVj LmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyX18l M0JKU1UlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFn dW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzZId1BMaWwlMjQ+DQo+ICAgICAgPiA+DQo+ICAgICAg Pg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVH QzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1Mg0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MiUwYj4+ICAgICA8aHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNBNUI4SDJGbTFyUG5hWjNTdXBqd3I2SDI/dT1o dHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1l LnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJB M0ElMkEyNTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0 UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvem9RaUFIayUyND4+DQo+ICAgICAg PiA+DQo+ICAgICAgPiA+ICA+IEYlMkZ3d3cuaWV0Zi5vcmc8aHR0cDovLzJGd3d3LmlldGYub3Jn Pg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhH SjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUz QSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVf UjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQ+DQo+ ICAgICAgPiA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHV1Q5ZnlqYUZpM0ZjdkhE dm9vZHZTNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3LmlldGYub3JnDQo8aHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNHV1Q5ZnlqYUZpM0ZjdkhEdm9vZHZTNkgyP3U9aHR0cCUzQSUyRiUy RjJGd3d3LmlldGYub3JnJTBiPj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v MzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29t JTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9yZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2sl MjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVp RG8tcFBDanZSJTI0Pj4lMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcNCj4gICAgICA+ID4N Cj4gICAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gICAgICA+ID4NCj4gICAgICA+ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgID4g Pg0KPiAgICAgID4gPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmcNCjxtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiPj4gICAgIDxt YWlsdG86c3ByaW5nQGlldGYub3JnJTBiPj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KPiAg ICAgID4gPg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+ICAgICA8aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzNCaHlFdHg0UTduNzRCaGlSbmZNSnRUNkgyP3U9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1h bnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJB MkYlMkEyRnd3dy5pZXRmLm9yZyUyQTJGbWFpbG1hbiUyQTJGbGlzdGluZm8lMkEyRnNwcmluZ19f JTNCSlNVbEpTVWwlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1oUjNnQUQlMjQ+DQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ICAgICAgPiA+IE5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBh bnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4NCj4gICAgICA+ID4gaW5mb3JtYXRpb24gb2YgUmli Ym9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwNCj4gICAgICA+IGFu ZC9vcg0KPiAgICAgID4gPiBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRl bmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsDQo+ICAgICAgPiA+IGRpc2Nsb3N1cmUsIHJlbGlh bmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZw0KPiAgICAgd2l0aG91 dA0KPiAgICAgID4gPiBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgeW91IGFyZSBub3QgdGhlDQo+ICAgICAgPiBpbnRlbmRlZA0KPiAgICAgID4gPiByZWNpcGll bnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUg YWxsDQo+ICAgICAgPiA+IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy4NCj4gICAg ICA+ID4NCj4gICAgICA+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICA+ID4NCj4gICAg ICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g ICAgICA+ID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgID4gPiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86 c3ByaW5nQGlldGYub3JnPg0KPiAgICAgID4gPiBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJG dXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4 RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyND4N Cj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAg ICAgID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3By aW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+IGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+ICAg ICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXEx NkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlN YU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhB a1RSRHVpRG81S2xQbmJqJTI0Pg0KPiAgICAgID4NCj4NCj4gICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICBzcHJpbmcgbWFpbGluZyBsaXN0 DQo+ICAgICBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQo+ICAgICBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1Ex eHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1h aWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0KPg0KPiA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElDQo8aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMl M0ElMjUlMGI+PiAyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3Lmll dGYub3JnPGh0dHA6Ly8yRnd3dy5pZXRmLm9yZz4lMkZtYWlsbWFuJTJGbGlzdGkNCj4gbmZvJTJG c3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndQ0KPiBvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Pg0KPg0KPg0KPg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+IE5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0 aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4NCj4gaW5mb3JtYXRpb24gb2YgUmliYm9uIENv bW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwgYW5kL29yDQo+IHByb3ByaWV0 YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmll dywNCj4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBm b3J3YXJkaW5nIHdpdGhvdXQNCj4gZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPiByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsDQo+IGNvcGll cywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1h aWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1o dHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBt YWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTm90aWNlOiBUaGlzIGUtbWFp bCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiBv ZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbCBhbmQvb3Ig cHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBB bnkgcmV2aWV3LCBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJz IG9yIGZvcndhcmRpbmcgd2l0aG91dCBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwgY29waWVzLCBp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0K --_000_MW3PR11MB457066589CAE97721BB97D84C1400MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1JTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSb2JlcnQsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gUm9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJhc3p1ay5uZXQm Z3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXVndXN0IDIwMjAgMjE6MTM8YnI+DQo8Yj5Ubzo8 L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0O2tldGFudEBjaXNjby5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7QWxleGFuZGVyLlZhaW5zaHRl aW5AcmJibi5jb20mZ3Q7OyBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFscGVybi5jb20m Z3Q7OyBTaHJhZGRoYSBIZWdkZSAmbHQ7c2hyYWRkaGFAanVuaXBlci5uZXQmZ3Q7OyBFWFQtQW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSAmbHQ7QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbSZndDs7IHNwcmluZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nw cmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLZXRhbiw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIEkgY29tcGxldGVs eSBhZ3JlZSB3aXRoIHlvdXIgbm90ZSB0aGUgY29uc2VxdWVuY2VzIG9mIGl0IGFyZSBwcmV0dHkg c2V2cmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5b S1RdIEkgdW5kZXJzdGFuZC4gV2UgbmVlZCB0byBiZSBtaW5kZnVsIG9mIGltcGxpY2F0aW9ucyBv ZiBwcm90ZWN0aW9uIHNjaGVtZXMgZm9yIHRoZSBTTEFzL2ludGVudCBvZiBTUiBQb2xpY2llcy48 L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Vbmxlc3Mgd2Ugc2lnbmFsIHdoaWNoIHByZWZpeCBTSUQgaXMgcHJvdGVjdGlvbiBlbGln aWJsZSBhbmQgd2hpY2ggaXMgbm90IGhvdyB3b3VsZCBvdGhlciBub2RlcyBrbm93IGlmIHRoZXkg Y2FuIHByb3RlY3QgaXQgb3Igbm90ID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPltLVF0gQ29ycmVjdC4gVG8gYmUgbW9yZSBhY2N1cmF0ZSwgd2UgbmVl ZCB0byBjb25zaWRlciB0aGlzIG1vcmUgaW4gdGhlIGNvbnRleHQgb2YgU0xBIG9yIOKAnGludGVu dOKAnSBvZiBTUiBQb2xpY2llcyBhbmQgd2hpY2ggc2VnbWVudHMgbWF5IGJlIOKAnGJ5cGFzcy1h Ymxl4oCdIGZvciBsb2NhbCBwcm90ZWN0aW9uIGZvciBzb21lIG9mIHRob3NlIFNSIFBvbGljaWVz LiBXZSBhbHNvIGhhdmUgcGF0aC1wcm90ZWN0aW9uDQogbWVjaGFuaXNtcy48L2k+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVt cyB0aGF0IHRvZGF5J3Mgc2FmZSB0aGluZyBpcyBub3QgdG8gYXBwbHkgYW55IG5vZGUgcHJvdGVj dGlvbiBvbiBTUiBmbG93cyBhdCB0aGUgUExScyB0aGVuLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgbGluayBwcm90ZWN0aW9u IE1VU1QgYXNzdXJlIHRoYXQgcGFja2V0cyB3aWxsIGFycml2ZSBhdCB0aGUgbmVpZ2hib3Igbm9k ZSB2aWEgc29tZSBvdGhlciBsaW5rIHJlZ2FyZGxlc3Mgb2YgZnVydGhlciBwYXRoIHRvd2FyZHMg ZGVzdGluYXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT5bS1RdIFllcy4gV2UgaGF2ZSBhIG1lY2hhbmlzbSB0byBpbmRpY2F0ZSB3aGljaCBhZGot U0lEcyBoYXZlIHByb3RlY3Rpb24gKHRoYXQgbWVjaGFuaXNtIG9ubHkgcHJvdmlkZXMgbGluayBw cm90ZWN0aW9uIHRvIGdldCB0byB0aGUgbmVpZ2hib3Igbm9kZSkgc28gdGhlIFNSIFBvbGljeSBj b21wdXRhdGlvbiBpcyBhYmxlIHRvIGluZGljYXRlIHdoZXRoZXIgdGhhdCBzcGVjaWZpYyBsaW5r IGlzIOKAnGJ5cGFzcy1hYmxl4oCdDQogb3Igbm90IGJ5IGl0cyBjaG9pY2Ugb2YgcHJvdGVjdGVk IG9yIHVucHJvdGVjdGVkIGFkai1TSURzIHJlc3BlY3RpdmVseS48bzpwPjwvbzpwPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlRoYW5rcyw8bzpwPjwvbzpwPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+S2V0YW48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBpdCBjb3Jy ZWN0ID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGh4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgQXVnIDE0LCAyMDIwIGF0IDU6MzIgUE0gS2V0YW4gVGFsYXVsaWthciAo a2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudEBjaXNjby5jb20iPmtldGFudEBjaXNj by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBTYXNoYSw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoZSBzZXJ2aWNlIG5vZGUgYWR2ZXJ0aXNlcyBpdHMgb3duIFBy ZWZpeCBTSUQuIFRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgdGhpcyBzZXJ2aWNlIG5vZGUgaW1w bGVtZW50cyBkb2VzIG5vdCByZXF1aXJlIGFueSBjb250ZXh0IChpLmUuIGFsbCBwYWNrZXRzIGFy cml2aW5nIGF0IHRoZSBub2RlIGFyZSBzdWJqZWN0ZWQNCiB0byB0aGF0IHNlcnZpY2UpLiBUaGVy ZWZvcmUgdGhlIHNlcnZpY2Ugbm9kZSBkb2VzIG5vdCBuZWVkIHRvIHJlY2VpdmUgYSBwYWNrZXQg d2l0aCBpdOKAmXMgb3duIFByZWZpeCBTSUQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRodXMsIHdlIGNhbm5vdCBhc3N1bWUgdGhhdCB3aGVuIFBIUCBpcyB1c2VkLCB0aGVuIHRoZSBT SUQgaXMgb25seSBhc3NvY2lhdGVkIHdpdGggYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhvcGUgdGhhdCBjbGFyaWZpZXM/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPktldGFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+IEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDs8YSBocmVmPSJtYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5k ZXIuVmFpbnNodGVpbkByYmJuLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXVn dXN0IDIwMjAgMjA6MjQ8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkg Jmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0 YW50QGNpc2NvLmNvbTwvYT4mZ3Q7OyBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNv bTwvYT4mZ3Q7OyBTaHJhZGRoYSBIZWdkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1 bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+Jmd0OzsN CjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0i X2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBS YXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRl dGVybWluaW5nIGFwcGxpY2FiaWxpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj MjEyMTIxIj5LZXRhbiwgYW5kIGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEy MSI+SSBoYXZlIHN0YXRlZCB0aGF0LCBJTUhPIGFuZCBGV0lXLCBib3RoIEFkai1TSURzIGFuZCBQ cmVmaXggU0lEcyB0aGF0IGFyZSBhZHZlcnRpc2VkIHdpdGggUEhQIGNhbiZuYnNwOyBPTkxZIHJl cHJlc2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgaW4gU1ItTVBMUyAtIGJlY2F1c2UgdGhl IGFkdmVydGlzaW5nIG5vZGUgd2lsbCBub3QgcmVjZWl2ZSB0aGVtIGFuZCB0aGVyZWZvcmUgY2Fu IGhhcmRseSBiZQ0KIGV4cGVjdGVkIHRvIGFzc29jaWF0ZSBhbnkgc2VydmljZSBmdW5jdGlvbiB3 aXRoIHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5UaGlzIGlzIGNvbXBsZW1lbnRhcnkgdG8g d2hhdCB5b3UgaGF2ZSBzYWlkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+SG9wZSB0aGlzIGNsYXJp ZmllcyBteSBwb3NpdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+V2hh dCwgaWYgYW55dGhpbmcsIGRpZCBJIG1pc3M/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMy MTIxMjEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5SZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5TYXNoYTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXYgaWQ9ImdtYWlsLW1fLTU3NTYwNjU0NTU4NDMyNTA5MG1zLW91dGxvb2st bW9iaWxlLXNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HZXQNCjxhIGhy ZWY9Imh0dHBzOi8vYWthLm1zL2doZWkzNiIgdGFyZ2V0PSJfYmxhbmsiPk91dGxvb2sgZm9yIEFu ZHJvaWQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fLTU3NTYw NjU0NTU4NDMyNTA5MGlkLTczZTEzOTZjLTYxNmUtNGM0NS05OGQxLTI1Njc4MGQwMTUzZiI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIy IiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8t NTc1NjA2NTQ1NTg0MzI1MDkwZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkg Jmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0 YW50QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW50Ojwvc3Bhbj48L3N0cm9uZz4g RnJpZGF5LCBBdWd1c3QgMTQsIDIwMjAsIDE2OjIzPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ubzo8L3NwYW4+PC9z dHJvbmc+IEFsZXhhbmRlciBWYWluc2h0ZWluOyBKb2VsIE0uIEhhbHBlcm47IFNocmFkZGhhIEhl Z2RlOw0KPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29t IiB0YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+ OyBSb2JlcnQgUmFzenVrPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DYzo8L3NwYW4+PC9zdHJvbmc+IDxhIGhyZWY9 Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNwcmluZ0BpZXRmLm9y ZzwvYT48YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlN1YmplY3Q6PC9zcGFuPjwvc3Ryb25nPiBSRTogW3NwcmluZ10g U3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl ciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk5PVElDRTogVGhpcyBlbWFpbCB3YXMgcmVjZWl2ZWQgZnJv bSBhbiBFWFRFUk5BTCBzZW5kZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIy IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IaSBTYXNoYSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHRoZSBzZXJ2aWNlIGRv ZXMgbm90IG5lZWQgYW55IGFkZGl0aW9uYWwgY29udGV4dCAoZS5nLiBhIGZpcmV3YWxsIHRoYXQg anVzdCBhcHBsaWVzIGxvY2FsbHkgY29uZmlndXJlZCBkZWZhdWx0IHJ1bGVzIG9uIGl0KSwgdGhl biBJIGRvbuKAmXQgc2VlIHdoeSBQSFAgY291bGQgbm90IGJlIGRvbmUgZm9yIGENCiBQcmVmaXgg U0lEIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2Ugbm9kZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFsc28sIEkgZGlkbuKAmXQgZm9sbG93IHRoZSBwb2ludCB0aGF0IHlvdSB3ZXJlIHRy eWluZyB0byBtYWtlIGFib3V0IEFkai1TSURzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5LZXRhbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQHJiYm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJi bi5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE0IEF1Z3VzdCAyMDIwIDE4OjI0PGJy Pg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWls dG86a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208L2E+ Jmd0OzsgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OzsgQWxleGFu ZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBy YmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPC9h PiZndDs7DQogU2hyYWRkaGEgSGVnZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBqdW5p cGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNocmFkZGhhQGp1bmlwZXIubmV0PC9hPiZndDs7DQo8 YSBocmVmPSJtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdl dD0iX2JsYW5rIj5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4gJmx0Ozxh IGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9i bGFuayI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7OyBSb2JlcnQgUmFz enVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5r Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRl cm1pbmluZyBhcHBsaWNhYmlsaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIx MjEyMSI+SGkgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5SZWdhcmRp bmcgdGhlIHN0YXRlbWVudCAmcXVvdDtQcmVmaXggU0lEIGNvdWxkIGJlIGp1c3QgYSB0b3BvbG9n aWNhbCBpbnN0cnVjdGlvbiBvciBtYXkgYWxzbyBiZSB1c2VkIHRvIHN0ZWVyIHRoZSBmbG93IHRv IGEgbm9kZSB3aGljaCBpcyBhcHBseWluZyBhIHNlcnZpY2UgZnVuY3Rpb24gdG8gaXQmcXVvdDs6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IzIxMjEyMSI+SSB0aGluayB0aGF0IGluIFNSLU1QTFMgYSBOb2RlIFNJRCB0aGF0IGlzIGFkdmVy dGlzZWQgd2l0aCBQSFAgYWNpdG9uIGNhbiBiZSBzYWZlbHkgY29uc2lkZXJlZCBhcyAmcXVvdDtq dXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24mcXVvdDsgYnkgdGhlIFBMUiBiZWNhdXNlIHRo ZSBvcmlnaW5hdGluZyBub2RlIHdpbGwgbm90IHJlY2VpdmUgaXQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMyMTIxMjEiPlRoZSBzYW1lIGFwcGxpZXMgdG8gQWRqLVNESXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojMjEyMTIxIj5NeSAyYy48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJnbWFp bC1tXy01NzU2MDY1NDU1ODQzMjUwOTBtcy1vdXRsb29rLW1vYmlsZS1zaWduYXR1cmUiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R2V0DQo8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzc1YzVZWUJlRWJhRVp3VWNIcENZMW02SDI/dT1odHRwcyUzQSUyRiUyRmFr YS5tcyUyRmdoZWkzNiIgdGFyZ2V0PSJfYmxhbmsiPg0KT3V0bG9vayBmb3IgQW5kcm9pZDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8tNTc1NjA2NTQ1NTg0MzI1 MDkwaWQtNmJmNDRkNTEtMGU2MC00NDhiLWJkZGUtZGM0MTkyNDllZmEyIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5 OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy01NzU2MDY1NDU1 ODQzMjUwOTBkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L3N0cm9uZz4gc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZg0KIG9mIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhy ZWY9Im1haWx0bzprZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5rZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+U2VudDo8L3NwYW4+PC9zdHJvbmc+IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNTowMDxi cj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VG86PC9zcGFuPjwvc3Ryb25nPiBKb2VsIE0uIEhhbHBlcm47IEFsZXhhbmRl ciBWYWluc2h0ZWluOyBTaHJhZGRoYSBIZWdkZTsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPjsgUm9iZXJ0IFJhc3p1azxicj4NCjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2M6 PC9zcGFuPjwvc3Ryb25nPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+DQpzcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0Ojwvc3Bh bj48L3N0cm9uZz4gUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcg YXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQWxs LDxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0byBzaGFyZSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2 ZSBvbiB0aGlzLjxicj4NCjxicj4NCkZpcnN0LCB0aGFua3MgdG8gSm9lbCBmb3IgYnJpbmdpbmcg dXAgdGhlIGRpc2N1c3Npb24uIENsZWFybHkgd2UgbmVlZCBhIHdlbGwtZGVmaW5lZCBhcHBsaWNh YmlsaXR5IHN0YXRlbWVudCBmb3IgZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eSBvZiBwcm90ZWN0 aW9uIGZvciBzZWdtZW50IHVzZWQgaW4gYW4gU1IgUG9saWN5LiBTb21lIG9mIHRoaXMgaXMgY2Fw dHVyZWQgaW4gWzFdLjxicj4NCjxicj4NClRoaXMgaXMgYWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEg UExSLiBCeSBpdCdzIHZlcnkgbmF0dXJlLCB0aGUgUExSIGRvZXMgbm90IGhhdmUgYSBub3Rpb24g b2YgaG93ICZxdW90O3N0cmljdCBvciBub3QmcXVvdDsgaXMgdGhlIFNMQSB0aGF0IGlzIGJlaW5n IHByb3ZpZGVkIGJ5IHRoZSBTUiBQb2xpY3kuIEF3YXJlbmVzcyBvZiB0aGF0IG5vdGlvbiBleGlz dHMgYXQgdGhlIFNSIFBvbGljeSBoZWFkZW5kIGFuZC9vciBjb21wdXRhdGlvbi1ub2RlLjxicj4N Cjxicj4NCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0ZWQgdmFyaWFudHMgb2YgYWRq YWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0byBwaWNrIG9yIHRoZSBvdGhl ciBiYXNlZCBvbiB0aGUgJnF1b3Q7c3RyaWN0bmVzcyZxdW90OyBvZiB0aGUgU0xBIHJlcXVpcmVt ZW50IGZvciBwaWNraW5nIHRoYXQgbGluay4gV2UgZG8gbm90IGhhdmUgc3VjaCBhIG5vdGlvbiBm b3IgUHJlZml4IFNJRHMuIE9uZSBjYW4gc2F5IHRoYXQgd2UgY291bGQgaW50cm9kdWNlDQogc2ln bmFsbGluZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFByZWZpeCBTSUQg Y2FuIGJlIGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5pdHkgZm9y IHRoZSBjb21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3IgZGVwZW5kaW5n IG9uIHRoZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS48YnI+DQo8YnI+DQpJ IGhhdmUgYSBwcm9ibGVtIGFuZCBhIGNvbmNlcm4gaW4gdGhlIGFzc3VtcHRpb24gdGhhdCBQTFJz IGNhbiBhc3N1bWUgdGhhdCB0aGUgY3VycmVudGx5IGRlZmluZWQgdmFyaWFudCBvZiBQcmVmaXgg U0lEcyBpbiBSRkM4NDAyIChhbmQgSUdQIHNwZWNzKSBhcmUgJnF1b3Q7YnlwYXNzLWFibGUmcXVv dDsuPGJyPg0KPGJyPg0KQXMgSm9lbCBhbmQgb3RoZXJzIGhhdmUgYnJvdWdodCBvdXQsIHRoZSBQ cmVmaXggU0lEIGNvdWxkIGJlIGp1c3QgYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbiBvciBtYXkg YWxzbyBiZSB1c2VkIHRvIHN0ZWVyIHRoZSBmbG93IHRvIGEgbm9kZSB3aGljaCBpcyBhcHBseWlu ZyBhIHNlcnZpY2UgZnVuY3Rpb24gdG8gaXQuIEluIG9yZGVyIHRvIHN1cHBvcnQgYSBtaXggb2Yg U1IgUG9saWNpZXMgb2YgZGlmZmVyZW50IFNMQXMgKHN0cmljdCBhbmQgbm90LXN0cmljdCksDQog d2UgbmVlZCB0byBlbmFibGUgdGhlIGNob2ljZSBvZiBTSURzIHRoYXQgaW5kaWNhdGVzIHRvIHRo ZSBQTFIgd2hldGhlciB0aGV5IGFyZSAmcXVvdDtieXBhc3MtYWJsZSZxdW90OyBvciBub3QuPGJy Pg0KPGJyPg0KRm9yIHRoZSBjYXNlcywgd2hlcmUgdGhlIFNSIFBvbGljeSBoYXMgYSBzcGVjaWZp YyBTTEEsIGl0IGlzIHJlcXVpcmVkIGZvciBub2RlcyB0byBkcm9wIHRoZSBwYWNrZXRzIG1lYW50 IGZvciB0aGUgJnF1b3Q7YWN0aXZlIHNlZ21lbnQmcXVvdDsgdGhhbiB0byBieXBhc3MgaXQuIFdo ZW4gdGhpcyBtZWNoYW5pc20gaXMgdXNlZCBhbG9uZyBzaWRlIFNSVEUgcGF0aCBtb25pdG9yaW5n IG1lY2hhbmlzbXMsIGl0IGVuYWJsZXMgdGhlIGhlYWRlbmQgdG8gZGV0ZWN0IHRoZQ0KIGZhaWx1 cmUgYW5kIGZhbGxiYWNrIHRvIGFuIGFsdGVybmF0ZSBwYXRoIHVzaW5nIHRoZSBwYXRoIHByb3Rl Y3Rpb24gYXBwcm9hY2guIFRoaXMgaXMgc29tZXRoaW5nIHRoYXQgaXMgZGVzY3JpYmVkIGFuZCBp biB1c2UgaW4gZGVwbG95bWVudHMgdG9kYXkgWzFdLi48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0K S2V0YW48YnI+DQo8YnI+DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1zNkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRm Lm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4 JTIzc2VjdGlvbi05IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vM1kzZld1TkZZQ2pNSlVpaUFpV3dVbXM2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmll dGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kt MDglMjNzZWN0aW9uLTk8L2E+PGJyPg0KWzJdIDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zNmZDTXJnbUVld0M0YTRBSlJybW43SDZIMj91PWh0dHBzJTNBJTJGJTJGdG9v bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeS0wOCUyM3NlY3Rpb24tOS4zIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzZmQ01yZ21FZXdDNGE0QUpScm1uN0g2SDI/dT1odHRwcyUzQSUyRiUy RnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1wb2xpY3ktMDglMjNzZWN0aW9uLTkuMzwvYT48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuPGJyPg0KU2VudDogMDQgQXVndXN0 IDIwMjAgMjA6MjU8YnI+DQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhh bmRlci5WYWluc2h0ZWluQHJiYm4uY29tPC9hPiZndDs7IFNocmFkZGhhIEhlZ2RlICZsdDs8YSBo cmVmPSJtYWlsdG86c2hyYWRkaGE9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNocmFkZGhhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsN CjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0i X2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBS YXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IEpvZWwg TS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdl dD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTog W3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJy Pg0KPGJyPg0KVGhlcmUgYXJlLCBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgYSBudW1iZXIgb2Ygd2F5 cyB0byBhZGRyZXNzIHRoaXMgZmFtaWx5IG9mIHJlbGF0ZWQgcXVlc3Rpb25zLjxicj4NCldoYXQg c3RydWNrIG1lLCBhbmQgcHJvbXB0ZWQgdGhlIHN0YXJ0aW5nIHF1ZXN0aW9uLCB3YXMgdGhhdCBu b25lIG9mIHRoZW0gd2VyZSBzcGVsbGVkIG91dC4mbmJzcDsgSSBzZWUgbG90cyBvZiBpbnRlcmVz dGluZyBpZGVhcyAvIHByb3Bvc2Fscy48YnI+DQpTb21lIG9mIHRoZW0gYXJlIGNvbXBhdGlibGUg d2l0aCBvdGhlcnMuJm5ic3A7Jm5ic3A7IFNvbWUgYXJlIG5vdC48YnI+DQpJdCB3b3VsZCBiZSBn b29kIGlmIHdlIGNvdWxkIHJlYWNoIGFncmVlbWVudCBvbiBob3cgd2UgdGhvdWdodCBpdCBzaG91 bGQgYmUgaGFuZGxlZC48YnI+DQo8YnI+DQpUaGFuayB5b3UsPGJyPg0KSm9lbDxicj4NCjxicj4N Ck9uIDgvNC8yMDIwIDM6NTQgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOjxicj4NCiZn dDsgSGkgYWxsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIHN0aWxsIG5vdCBzdXJlIHRoYXQg dGhlIHByb2JsZW0gb2YgYnlwYXNzIGdvaW5nIHRocnUgdW5kZXNpcmFibGUgPGJyPg0KJmd0OyBs aW5rcy9ub2RlcyBleGlzdHMgaW4gdGhlIGNhc2Ugb2YgdG9wb2xvZ2ljYWwgU0lEcy48YnI+DQom Z3Q7IDxicj4NCiZndDsgQUZBSUssIEZhY2lsaXR5IFByb3RlY3Rpb24gaW4gUlNWUC1URSBGUlIg KFJGQyA0MDkwPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzNROTJrbkU5WEp1anJmOEJrN29KdnM2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmll dGYub3JnJTJGaHRtbCUyRnJmYzQwOTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vM1E5MmtuRTlYSnVqcmY4Qms3b0p2czZIMj91PWh0dHBzJTNBJTJGJTJG dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjNDA5MDwvYT4mZ3Q7KSBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkNCiBkZXBsb3llZCA8YnI+DQomZ3Q7IGZvciBtYW55IHllYXJzIGJlZm9yZSBTUi1NUExT IGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTigJlzIG1vcmUsIDxicj4NCiZndDsgc2lnbmFsaW5n IG9mIGJ5cGFzcyB0dW5uZWxzIGhlIFBMUiB1c3VhbGx5IGRpZCBub3QgaW5jbHVkZSBhbnkgb2Yg dGhlIDxicj4NCiZndDsgY29uc3RyYWludHMgdXNlZCBmb3IgY29tcHV0aW5nIG9mIGFueSBzcGVj aWZpYyBMU1AgdGhhdCB0aGUgYnlwYXNzIExTUCA8YnI+DQomZ3Q7IHdvdWxkIHByb3RlY3Qg4oCT IGJlY2F1c2UgaW4gdGhlIEZhY2lsaXR5IFByb3RlY3Rpb24gbW9kZSB0aGUgc2FtZSA8YnI+DQom Z3Q7IGJ5cGFzcyBMU1Agd291bGQgYmUgdXNlZCB0byBwcm90ZWN0IG11bHRpcGxlIExTUHMgcGFz c2luZyB0aHJ1IHRoZSA8YnI+DQomZ3Q7IGZhaWxlZCBsaW5rL25vZGUuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7Jm5ic3A7IEZyb20gbXkgUE9WIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlz IGJlaGF2aW9yIGFuZCB0aGF0IDxicj4NCiZndDsgaW50cm9kdWNlZCBieSB0aGUg4oCcYnlwYXNz aW5n4oCdIGRyYWZ0cyBpbiBTUiBpcyB0aGF0LCBpbiB0aGUgY2FzZSBvZiA8YnI+DQomZ3Q7IFJT VlAtVEUsIHRoZSBvcGVyYXRvciB3b3VsZCBleHBsaWNpdGx5IGluZGljYXRlLCBhcyBwYXJ0IG9m IExTUCA8YnI+DQomZ3Q7IHNpZ25hbGluZywgd2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBub3Qg dXNlIEZSUjsgTFNQcyB0aGF0IHdvdWxkIG5vdCA8YnI+DQomZ3Q7IHVzZSBGUlIgd291bGQgdGhl biBkcm9wIHRyYWZmaWMgcmF0aGVyIHRoYW4gZGVsaXZlcmluZyBpdCB0aGUgd3Jvbmcgd2F5Ljxi cj4NCiZndDsgPGJyPg0KJmd0OyBTdWNoIGFuIG9wdGlvbiBpbmRlZWQgZG9lcyBub3QgZXhpc3Qg aW4gU1ItVEUgdG9kYXksIGJ1dCB3b3VsZCBiZSBlYXN5IDxicj4NCiZndDsgdG8gcHJvdmlkZSBp ZiBzbyBkZXNpcmVkIElNSE8uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERpZCBJIG1pc3Mgc29tZXRo aW5nIHN1YnN0YW50aWFsPzxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLCBhbmQgbG90cyBv ZiB0aGFua3MgaW4gYWR2YW5jZSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2FzaGE8YnI+DQomZ3Q7 IDxicj4NCiZndDsgT2ZmaWNlOiArOTcyLTM5MjY2MzAyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENl bGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICs5NzItNTQ5MjY2MzAyPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEVtYWlsOiZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgKkZyb206KiBzcHJpbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgKk9uIEJlaGFsZiBPZiAqU2hyYWRk aGEgSGVnZGU8YnI+DQomZ3Q7ICpTZW50OiogVHVlc2RheSwgQXVndXN0IDQsIDIwMjAgOTo0MSBB TTxicj4NCiZndDsgKlRvOiogPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb208L2E+PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25A bGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2Jl cnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8 YnI+DQomZ3Q7ICpDYzoqIDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcg cHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8YnI+DQomZ3Q7IDxicj4NCiZn dDsgQWxsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlzIGEgdmVyeSBpbnRlcmVzdGluZyBk aXNjdXNzaW9uIGFuZCB0aGFua3MgdG8gSm9lbCBmb3Igc3RhcnRpbmcgPGJyPg0KJmd0OyB0aGlz IGRpc2N1c3Npb24uIElNTywgd2hlbiB0aGVyZSBhcmUgc3RyaWN0IHJlcXVpcmVtZW50cyBvZiBh dm9pZGluZyA8YnI+DQomZ3Q7IGNlcnRhaW4gbm9kZXMvbGlua3MgaXQgY2FuIGJlIHJlYWxpemVk Jm5ic3A7IGVpdGhlciBieSBkZWZpbmluZyBhIGZsZXgtYWxnbyA8YnI+DQomZ3Q7IGF2b2lkaW5n IHRob3NlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vZGVzIGFuZCBsaW5rcyBvciBieSB1c2luZyBh IHN0YWNrIG9mIHVucHJvdGVjdGVkIGFkai1zaWRzIHRoYXQgYXZvaWQgPGJyPg0KJmd0OyByZXN0 cmljdGVkIG5vZGVzIGFuZCBsaW5rcy4gV2hlbiBhIHN0YWNrIG9mIGFkai1zaWRzIGlzIHVzZWQg dG8gPGJyPg0KJmd0OyByZWFsaXplIHRoZSBwYXRoLCB0aGUgaGVhZC1lbmQgYmFzZWQgKHNCRkQp IHByb3RlY3Rpb24gbWVjaGFuaXNtcyBjYW4gYmUgYXBwbGllZC48YnI+DQomZ3Q7IDxicj4NCiZn dDsgSWYgTm9kZS1zaWRzL3ByZWZpeC1zaWQvYW55Y2FzdC1zaWRzIGFyZSB1c2VkIHRvIGJ1aWxk IHRoZSBzdGFjaywgdGhlIDxicj4NCiZndDsgZmFpbHVyZSBldmVudHMgbWF5IGNhdXNlIHRyYWZm aWMgdG8gZ28gdGhyb3VnaCByZXN0cmljdGVkIG5vZGVzIGFuZCA8YnI+DQomZ3Q7IGxpbmtzLiBU aGlzIHdvdWxkIGhhcHBlbiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgYW55IGtpbmQgb2YgcHJvdGVj dGlvbiA8YnI+DQomZ3Q7IGlzIGluIHVzZSBvciBub3QuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJn ZHM8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2hyYWRkaGE8YnI+DQomZ3Q7IDxicj4NCiZndDsgSnVu aXBlciBCdXNpbmVzcyBVc2UgT25seTxicj4NCiZndDsgPGJyPg0KJmd0OyAqRnJvbToqIHNwcmlu ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTIwJTBiIiB0YXJn ZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxicj4NCjwvYT4mZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgKk9uIEJlaGFsZiBPZiAq QW5kcmV3IEFsc3Rvbjxicj4NCiZndDsgKlNlbnQ6KiBUdWVzZGF5LCBBdWd1c3QgNCwgMjAyMCA1 OjQxIEFNPGJyPg0KJmd0OyAqVG86KiBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86 cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKkNjOiogPGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs7IEpvZWwgTS4gSGFscGVybg0KPGJyPg0K Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2Js YW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwv YT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3Rl Y3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpb RXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdKjxicj4NCiZndDsgPGJyPg0K Jmd0OyBSb2JlcnQgdGhpcyBpcyBhY3R1YWxseSBmYXIgbW9yZSBkaWZmaWN1bHQgd2hlbiDigJMg aXQgY2FuIGJlIGFuIGVudGlyZTxicj4NCiZndDsgKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0 IG5lZWQgdG8gYmUgYXZvaWRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgY291bGQgcG90ZW50 aWFsbHkgYmUgbWFkZSB0byB3b3JrIGJ1dCBJ4oCZZCB3b3JyeSB0aGF0IHRvIGRvIHRoaXMg4oCT IDxicj4NCiZndDsgeW914oCZZCBoYXZlIHRvIHN0YWNrIDEwIOKAkyAyMCDigJMgMzAgbmVnYXRp dmUgbGFiZWxzIOKAkyBhbmQgdGhhdCB3b3VsZG7igJl0IDxicj4NCiZndDsgYmUgdmlhYmxlLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBJdOKAmXMgZWFzaWVyIHRvIHVzZSBhbGdvcml0aG1zIGFuZCBh ZGphY2VuY3kgc2lkcyBhbmQgb3RoZXIgc3VjaCB0aGluZ3MgPGJyPg0KJmd0OyB0byBjYWxjdWxh dGUgcGF0aHMg4oCTIHRoZSBiaWdnZXN0IHRyaWNrIGlzIGFib3V0IHRoZSBzdGFjayBkZXB0aC4m bmJzcDsgV2hlbiA8YnI+DQomZ3Q7IHlvdSBoYXZlIHRoaXMgbmVlZCBmb3Igbm9kZSBhdm9pZGFu Y2Ug4oCTIHRoZSBuZWVkIGZvciAxMCsgbGFiZWwgZGVwdGggPGJyPg0KJmd0OyBpcyBjcml0aWNh bCDigJMgdW5sZXNzIHlvdSB3YW5uYSBiZSBhcHBseWluZyBvbmUgaGVsbCBvZiBhIGxvdCBvZiA8 YnI+DQomZ3Q7IGJpbmRpbmcgbGFiZWxzIGFsb25nIHRoZSB3YXkgd2hpY2ggaXMgYSBuaWdodG1h cmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ1dCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaXMg dGhpcyBhIGNvbW1vbiB1c2UgY2FzZSDigJMgaXTigJlzIGEgdXNlIDxicj4NCiZndDsgY2FzZSB0 aGF0IG1vc3Qgb2YgdGhlIHBlb3BsZSBJIGRpc2N1c3MgdGhpcyB3aXRoIGNlcnRhaW4gaGF2ZSDi gJMgSSBjYW50IDxicj4NCiZndDsgY29tbWVudCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFu eW9uZSBlbHNlLCBidXQgZXZlcnkgaW5kaWNhdGlvbiBJIDxicj4NCiZndDsgaGF2ZSBpcyB0aGF0 IHllcyDigJMgaXRzIHNvbWV0aGluZyBwZW9wbGUgbmVlZCwgYW5kIHdhbnQ8YnI+DQomZ3Q7IDxi cj4NCiZndDsgQW5kcmV3PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpGcm9tOiogUm9iZXJ0IFJhc3p1 ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+ cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5u ZXQiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyZndDs8 YnI+DQomZ3Q7ICpTZW50OiogVHVlc2RheSwgNCBBdWd1c3QgMjAyMCAwMToyNzxicj4NCiZndDsg KlRvOiogQW5kcmV3IEFsc3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlx dWlkdGVsZWNvbS5jb20lMjAlMGIiIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tDQo8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86QW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKkNjOiogSm9lbCBN LiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYiIg dGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb20NCjxicj4NCjwvYT4mZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gPGJyPg0KJmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW3Nw cmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IElzIHRoaXMgYSBjb21tb24gdXNlIGNhc2UgaWUuJm5ic3A7ICZxdW90 O2J1dCByYXRoZXIg4oCTIHdoaWNoIG5vZGVzIC8gbmV0d29yayA8YnI+DQomZ3Q7IHNlZ21lbnRz IGl0IGNhbiBuZXZlciB0b3VjaCBvciBmbG93IHRocm91Z2guJnF1b3Q7PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IElmIHNvIHBlcmhhcHMgaXRzIHRpbWUgdG8gZGVmaW5lIG5vdGlvbiBvZiAqbmVnYXRp dmUtU0lEKiBpZS4gbGlzdCBpbiA8YnI+DQomZ3Q7IHRoZSBwYWNrZXQgcmVzb3VyY2VzIHdoaWNo IGdpdmVuJm5ic3A7cGFja2V0IE1VU1Qgbm90IGV2ZXIgdHJhdmVyc2UuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFB1dCBpbiB0aGUgcGFja2V0IHNldCBvZiBub2RlcyBvciBsaW5rcyB3aGljaCB0aGUg cGFja2V0IHNob3VsZCBuZXZlciA8YnI+DQomZ3Q7IHRyYXZlcnNlLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGF0IGdvZXMgaW4gbGluZSBvZiByZWNlbnQgd2F2ZSBvZiBuZWdhdGl2ZSByb3V0aW5n IGltcGxlbWVudGF0aW9uczxicj4NCiZndDsgKFJJRlQpIG9yIGRpc2N1c3Npb25zIChMU1IpPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QsPGJyPg0KJmd0OyBSLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDExOjQ2IFBNIEFuZHJldyBBbHN0b24gPGJyPg0KJmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAl MGIiIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8YnI+ DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU28g4oCTPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE9uZSBvZiB0aGUgdXNlIGNhc2VzLCBpbiBmYWN0LCBzb21lIHZlcnkgbWFqb3IgdXNl IGNhc2VzIGluIGFueTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3ByaW5nIHRl Y2hub2xvZ3kgZm9yIHVzIHJldm9sdmUgYXJvdW5kIHRoZSBmb2xsb3dpbmc8YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYS5UaGUgZXhwbGljaXQgYXZvaWRhbmNl IG9mIGNlcnRhaW4gbm9kZXM8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYi5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gc2VjdGlvbnMgb2YgdGhl IG5ldHdvcms8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW55 dGhpbmcgdGhhdCBjb3VsZCByZXN1bHQgaW4gdGhhdCBleHBsaWNpdCBhdm9pZGFuY2UgYmVpbmcg dmlvbGF0ZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAkyB3b3VsZCBjcmVh dGUsIHNoYWxsIHdlIHNheSBzaWduaWZpY2FudCBwcm9ibGVtcy48YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTXVjaCBvZiB0aGUgdXNlIGNhc2UgaXMgbm90IGEg Y2FzZSBvZiB3aGljaCBub2RlcyB0aGUgcGFja2V0cyBmbG93PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aHJvdWdoIOKAkyBidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5l dHdvcmsgc2VnbWVudHMgaXQgY2FuIG5ldmVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0b3VjaCBvciBmbG93IHRocm91Z2guJm5ic3A7IEVmZmVjdGl2ZWx5LCB0byBiZSB1c2Vk IGFzIGEgdGVjaG5vbG9neSB0bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXZv aWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNv bnMgZm9yIG5lZWRpbmcgc3VjaCBkZWVwIGxhYmVsIHN0YWNrcyDigJM8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMga2luZCBvZiBkZXRhaWxlZCBwYXRoIHByb2dyYW1taW5n IHRlbmRzIHRvIGRlZXBlbiB0aGUgc3RhY2s8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGJlY2F1c2UgeW91IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBleHBsaWNpdC48YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgaXMgYWJzb2x1dGVs eSBjcml0aWNhbCB0byB1cyB0aGF0IHRoaXMgZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDigJM8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCB0aGF0IHdlIGNhbiBhdm9pZCBzaXR1 YXRpb25zIHdoaWNoIGNvdWxkIGNhdXNlIHRyYWZmaWMgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGFjY2lkZW50bHkgaGl0IHRoaW5ncyBleHBsaWNpdGx5IGF2b2lkZWQuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2lzaCBJIGNvdWxk IGJlIG1vcmUgc3BlY2lmaWMgdGhhbiB0aGlzLCBidXQgaXQgaXMgd2hhdCBpdCBpcy48YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZHJldzxicj4NCiZndDsgPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7ICpPbiBCZWhhbGYg T2YgKkpvZWwgTS4gSGFscGVybjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlNl bnQ6KiBNb25kYXksIDMgQXVndXN0IDIwMjAgMjE6MzY8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICpUbzoqIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRA cmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJv YmVydEByYXN6dWsubmV0PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYuLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZ0BpZXRmLi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJp bmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIDxicj4NCiZndDsgYXBwbGljYWJpbGl0eTxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoU2luY2UgdGhlIHRocmVh ZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCByZWl0ZXJhdGluZyB0aGF0IHRoaXMgaXMgYXMgYTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFydGljaXBhbnQsIG5vdCBhIFdHIGNo YWlyLik8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWVzLCB3 ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29y a3MgdGhhdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hvb3NlIHRvIGRyb3Ag cGFja2V0cy4gRm9yIGFsbCBzb3J0cyBvZiByZWFzb25zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSSB0aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9u ZSBtYXkgbm90IHdhbnQgYSByYW5kb208YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHBhdGggcmF0aGVyIHRoYW4gYSBjaG9zZW4gVEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRh bnQgd2UgYmUgY2xlYXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFib3V0IHdo YXQgY29uc3RyYWludHMgbWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUg dGhleTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGF2ZSB0aGlzIHRvb2wgKHBy b3RlY3RpdmUgcmVyb3V0aW5nKSB0aGF0IGlzIGludGVuZGVkIHRvIHByZXNlcnZlIFFvUy48YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGV0J3MgYmUgY2xlYXIu IEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlzIGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQgaXMgYTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJ IGFtIHRyeWluZyB0byBmaWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2Y8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVz Y3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVyeW9uZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZ2V0dGluZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3Qg YmUgdGhlIGJlaGF2aW9yIHRoZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRl c2lyZSwgYnV0IHNvbWV0aW1lcyBpcyB0aGUgYmVzdCB3ZSBjYW4gZG8uKTxicj4NCiZndDsgPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZb3Vycyw8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEpvZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgT24gOC8zLzIwMjAgMjozMCBQTSwgUm9iZXJ0IFJhc3p1ayB3cm90ZTo8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSm9lbCw8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgQXJlIHdlIHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29y a3MmbmJzcDtoZXJlID8gT3IgcGVyaGFwcyBzb21lIGhhcmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2 YXRpb25zIG9yIGRldG5ldHMgPzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBCZWNh dXNlJm5ic3A7aWYgd2UgYXJlIHRhbGtpbmcmbmJzcDthYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2 ZSB0d288YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9ic2VydmF0aW9uczo8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQSkgSWYgeW91IG5lZWQgdG8gdHJhdmVyc2Ug dmlhIGEgc3BlY2lmaWMgbm9kZSAoaWUuIGZpcmV3YWxsKSB5b3U8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGJldHRlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBhcHBseSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4uIEkgZG9uJ3Qg dGhpbmsgSVA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuY2Fwc3VsYXRpb24m bmJzcDtjYW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYmUg aGlqYWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tl dCBpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWdub3JlZC48YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3 aGVyZSB1cG9uIHRvcG9sb2d5IGNoYW5nZSAobGluazxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgb3Igbm9kZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBmYWlsdXJlKSB5b3Ugc3VkZGVubHkmbmJzcDtzdGFydCBkcm9wcGluZyZuYnNwO2Zsb3dz IGluIHNwaXRlIG9mIFNQVCBvZmZlcmluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBwZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRoIDEwIG1zIG1vcmUg aml0dGVyID88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgT3IgYXJlIHNvbWUgU1Ig bWFya2V0aW5nIHNsaWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW48YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc29tZXRoaW5nJm5ic3A7bmV3ID8g V29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3VhcmFudGVlcyw8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcmVzb3VyY2UgcmVzZXJ2YXRp b25zJm5ic3A7PyBJIGhvcGUgbm90Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBU aHgsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFIuPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9uIE1vbiwgQXVn IDMsIDIwMjAgYXQgODoxMCBQTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tJTBiIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNv bTxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tJTIwJTBiPC9hPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBX ZWxsIGxlc3Mgc2VyaW91cyBmb3IgVEUgU0lEcywgSSBhbSBub3Qgc3VyZSB0aGUgcHJvYmxlbSBp czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzdHJpY3RlZDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0byBqdXN0IHNlcnZpY2UgU0lEcy48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFz IHNwZWNpZmllZCB0aGUgcGF0aCB0byBtZWV0IHNvbWUgY29tcGxleCB0ZTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBvYmplY3RpdmUuJm5ic3A7IFRoZSBieXBh c3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dpbmcgd2hhdCB0aG9zZTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjb25zdHJhaW50czxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB3ZXJlLiZuYnNwOyBBbmQgZm9yIHNvbWUga2lu ZHMgb2YgdHJhZmZpYywgaXQgaXMgYmV0dGVyIHRvIGRyb3AgdGhlIHBhY2tldDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0 c2lkZSB0aGUgZW52ZWxvcC4mbmJzcDsgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFuc3dlcjxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0byB0aGlzIGlzICZxdW90O3RvbyBiYWQm cXVvdDsuJm5ic3A7IElmIHNvLCBhcyB3aXRoIHRoZSBkaXN0aW5jdGlvbiByZWdhcmRpbmc8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZpY2U8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbm9kZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3Vs ZG4ndCB3ZT88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgWW91cnMsPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgT24gOC8zLzIwMjAgMjozNiBBTSwgQWxleGFuZGVyIFZhaW5zaHRl aW4gd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgTWFjaCwgSm9lbCBhbmQgYWxsLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsgSSB0aGluayB0aGF0IGluIG1vc3QgY2FzZXM6PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlvbiBi ZXR3ZWVuICZxdW90O3RvcG9sb2dpY2FsJnF1b3Q7IGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7c2VydmljZSZxdW90Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGluc3RydWN0aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVu dHMuIEUuZy46PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBvSUdQ IFByZWZpeCBOb2RlIFNJRHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4gdGhl PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgY29ycmVz cG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMpIHJlcHJlc2VudCB0b3BvbG9naWNhbDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBvU2VydmljZSBTSURzIGZvciBTUnY2IChzZWUgU1J2 NiBCR1AtQmFzZWQgT3ZlcmxheSBTZXJ2aWNlczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNDQ2N5OW1ZNmNNZmJrN1FmamhpQTNSNkgy P3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFm dC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNCUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ0NjeTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBz JTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1i ZXNzLXNydjYtc2VydmljZXMtMDQ8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHQzVhZjJ6M0p6 cGhaRGtQbmNIQVFpNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19o dHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYt YmVzcy1zcnY2LXNlcnZpY2VzLTA0X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5F OEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzRULUwwbmwlMjQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dDNWFmMnoz SnpwaFpEa1BuY0hBUWk2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZf X2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0 Zi1iZXNzLXNydjYtc2VydmljZXMtMDRfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZ TkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNFQtTDBubCUy NDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRyYWZ0 KSB1bnN1cnByaXNpbmdseSByZXByZXNlbnQg4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnM8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDIuU2VnbWVudHMgdGhhdCBy ZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCw8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyB3aGlsZSBzZWdtZW50 cyB0aGF0IHJlcHJlc2VudCBzZXJ2aWNlIGluc3RydWN0aW9ucyByZXF1aXJlPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFsdGVybmF0aXZlPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcHJvdGVjdGlvbiBtZWNoYW5p c21zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgVGhpcyB2aWV3 IHNlZW1zIHRvIGJlIGFsaWduZWQgd2l0aCBSRkMgODQwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUy RnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDIlMGIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1o dHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDI8YnI+DQo8L2E+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzM3UHpVS0FEODJjalN2bVZjR3Zwa2hGNkgyP3U9aHR0cHMlM0ElMkYlMkZ1 cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RnJmYzg0MDJfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhn bTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvMEk0WWJ0bSUyNCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zN1B6VUtBRDgyY2pTdm1WY0d2cGto RjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0 b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMw WXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJ NFlidG0lMjQ8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo YXQgc2F5cyBpbiBTZWN0aW9uIDE6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJhc2Vk IGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsgdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJ R1AtQWRqYWNlbmN5IHNlZ21lbnQgYW5kIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IElHUC1QcmVmaXggc2VnbWVudC48YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNw OyBJbiB0aGUgY29udGV4dCBvZiBhIEJHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5l LCB0d288YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRvcG9sb2dp Y2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBhbmQgdGhl PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsm bmJzcDsgQkdQLVByZWZpeCBzZWdtZW50Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgSW4gdGhlIGNhc2Ugb2YgU1ItTVBMUyB0aGlzIGRpZmZlcmVudGlhdGlvbiBp cyBhc3N1bWVkIGluIFNlY3Rpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgMy40IG9mPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsgdGhlIE5vZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFm TlBzWmRocEV4eHg5NkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1w YXRocy0wNyUyM3NlY3Rpb24tMy40JTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFmTlBzWmRocEV4eHg5NkgyP3U9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmct bm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rpb24tMy40PGJyPg0KPC9h PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zQ3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91PWh0dHBzJTNBJTJG JTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9y ZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1z ci10ZS1wYXRocy0wNyUyQXNlY3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZ dXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdP LVNzbiUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z Q3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZk cmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyQXNl Y3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0 UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNzbiUyNDwvYT4mZ3Q7Jmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRyYWZ0IHRoYXQgc2F5czo8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZu YnNwOyBUaGUgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZp b3VzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZWN0aW9uczxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGRlcGVu ZHMgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgbGFiZWwgaW1tZWRpYXRlbHkgYmVsb3c8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhlIHRvcDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgbGFiZWwgaW4gdGhlIGxhYmVsIHN0 YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElHUCBkb21haW4uJm5ic3A7IFdoZW4gdGhlPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsg cHJvdmlkZXIgZWRnZSByb3V0ZXJzIGV4Y2hhbmdlIHNlcnZpY2UgbGFiZWxzIHZpYSBCR1Agb3Ig c29tZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBvdGhlcjxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5i c3A7IG5vbi1JR1AgbWVjaGFuaXNtIHRoZSBib3R0b20gbGFiZWwgaXMgbm90IHVuZGVyc3Rvb2Qg aW4gdGhlIElHUDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7Jm5ic3A7IGRvbWFpbi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlvbiBt ZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBbUkZDODY3OSAmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFqQTNwTTZUZENF NkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZy ZmM4Njc5JTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNKZnZ0QkFtYVFQTjFqQTNwTTZUZENFNkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5p ZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z NmRNQWp1WVRRb3ZvOGpId21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZy ZmM4Njc5X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzZkTUFqdVlUUW92bzhqSHdtbTNlSnc2 SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODY3OV9fJTNCJTIxJTIxTkV0NnlN YU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhB a1RSRHVpRG84TUdpcFhjJTI0PC9hPiZndDsmZ3Q7XTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0OyBhcHBsaWNhYmxlIHRvIHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdl czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 Jm5ic3A7IHdpbGwgYmUgcmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBUaGUgc2NlbmFyaW9zIGluIHdoaWNoICZu YnNwO2RpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs4oCdIGFuZDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IOKAnHNlcnZpY2XigJ0g aW5zdHJ1Y3Rpb25zIGlzIGJyb2tlbiBhcmUgaW5kZWVkIHByb2JsZW1hdGljLiBFLmcuLDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjb25zaWRlcjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRoZSB1c2UgY2FzZSBp biB3aGljaCBhIE5vZGUgU0lEIGluIHRoZSBFUk8gb2YgYSBTUi1URSBwYXRoPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGlkZW50aWZpZXMgYTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IG5vZGUgdGhhdCBhY3RzIGFz IGEgZmlyZXdhbGwgZm9yIGFsbCBwYWNrZXRzIGl0IHJlY2VpdmVzLCBpLmUuLDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBwcm92aWRlczxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRoZSBmaXJld2FsbCBzZXJ2aWNl IHdpdGhvdXQgYW55IGRlZGljYXRlZCBzZXJ2aWNlIFNJRDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpZGVudGlmeWluZyBpdC48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5v ZGUgU0lEIG9mIHN1Y2ggYSBub2RlIHdvdWxkIGNvbWJpbmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG9wb2xvZ2ljYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBhbmQgc2VydmljZSBpbnN0cnVjdGlvbnMgdGh1 cyBicmVha2luZyB0aGUgZGlmZmVyZW50aWF0aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGJldHdlZW4gdGhlIHR3by48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEkgYW0gbm90IHN1cmUgaWYgdXNhZ2Ugb2Ygc3VjaCDigJxj b21iaW5lZOKAnSBTSURzIGNvdWxkIGJlIHByZXZlbnRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBvciBhdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGxlYXN0IGRpc2NvdXJhZ2VkLjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSWYgbm90LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0 byBpZGVudGlmeSBzdWNoIFNJRHMgaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IGFkdmVydGlzZW1lbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBtZWNoYW5pc21zIHdvdWxkIGJlIHVzZWZ1bCBJTUhPLjxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgTXkgMmMsPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBTYXNoYTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgT2ZmaWNlOiArOTcyLTM5MjY2MzAyPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBDZWxsOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyArOTcyLTU0OTI2NjMwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsgRW1haWw6IDxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb208L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0 bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEZyb206IHNw cmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiIiB0YXJn ZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBi PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7IE9uIEJlaGFsZiBPZiBNYWNoIENo ZW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBTZW50 OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDY6MzAgQU08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYiIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2Vs aGFscGVybi5jb208YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMGIiIHRhcmdldD0iX2JsYW5rIj5tYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYjwvYT4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mZ3Q7Jmd0Ozs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0 Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsg U3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBw bGljYWJpbGl0eTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSGkg Sm9lbCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEkgdGhpbmsg dGhpcyBpcyBhIGdvb2QgcG9pbnQgdGhhdCBtYXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0aGU8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcGFzdC4gQW5kPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSBhbHNvIGRvbid0 IHRoaW5rIHRoZXJlIGlzIGEgJnF1b3Q7Y2FuIGJlIGJ5cGFzc2VkJnF1b3Q7IGluZGljYXRpb24g aW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsg cm91dGluZyBhZHZlcnRpc2VtZW50IGZvciBub3cuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyBJTUhPLCB0aGUgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBieSByb3V0 aW5nIGlzIG5ldXRyYWwsIHN1Y2g8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgaW5mb3JtYXRpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyAoY2FuIG9yIGNhbm5vdCBiZSBieXBhc3NlZCkgaXMgbW9yZSBwYXRoIHNw ZWNpZmljLCB0aHVzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub3JtYWxseSB0 aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBjb250 cm9sbGVyIHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBT SUQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgY2FuIGJlPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgYnlwYXNzZWQu PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBCZXN0IHJlZ2FyZHMs PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBNYWNoPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IEZyb206IHNwcmluZyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3Jn PC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcl MGIlM2UlMjAlM2NtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclM2UiIHRhcmdldD0iX2Js YW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIlM2UlMjAlM2NtYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmclM2U8L2E+Jmd0O108YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE9uIEJlaGFsZiBPZiBKb2VsIE0uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IEhhbHBlcm48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMywg MjAyMCA3OjUxIEFNPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGll dGYub3JnPC9hPiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsmbmJzcDsgJmd0OyBTdWJqZWN0OiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAt IGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgKFdHIENoYWlyIGhhdCBPZmYsIHRoaXMgaXMgbWVyZWx5IGEg bm90ZSBmcm9tIGEgc2xpZ2h0bHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgY29uZnVzZWQgV0c8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgcGFydGljaXBhbnQuKTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBJIGhhdmUgYmVlbiByZWFkaW5nIHRoZSB2YXJpb3Vz IHJlcGFpciBkcmFmdHMsIGFuZCB0aGUgdmFyaW91czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBuZXR3b3JrcyBwcm9ncmFtbWluZyBhbmQgc2Vy dmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgdHJ5aW5nIHRvPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUg Y29tYmluYXRpb24uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNw OyAmZ3Q7IEhvdyBkb2VzIGEgbm9kZSB0aGF0IGlzIGRvaW5nIHNvbWUgZm9ybSBvZiBieXBhc3Mg KHN1cHBvc2UsIGZvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJmd0OyBzaW1wbGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0 aGUgbmV4dCBTSUQgZm9yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IGEgZmFpbGVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmZ3Q7IG5vZGUgTjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRvIHNvPzxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBJZiB0aGUgcGF0aCB3 YXMganVzdCBmb3IgVEUsIHRoZW4gaXQgaXMgJnF1b3Q7c2FmZSZxdW90OyBpZiB0aGUgbmV3IHBh dGg8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbWVldHM8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgdGhlIFRF IGNyaXRlcmlhLiZuYnNwOyBvciBtYXliZSBpdCBpcyBzYWZlIGlmIGl0IGlzIGV2ZW4gY2xvc2Us IGFzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGxvbmcgYXM8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgaXQg aXMgbm90IHVzZWQgZm9yIHRvbyBsb25nLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsmbmJzcDsgJmd0OyBCdXQgd2hhdCBpZiB0aGUgbm9kZSB3ZXJlIGEgRmlyZXdhbGws IGluY2x1ZGVkIHRvIG1lZXQgbGVnYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyByZXF1aXJlbWVudHM/PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IE9yIHdhcyBzb21lIG90aGVyIG5lY2Vzc2FyeSBw cm9ncmFtbWF0aWMgdHJhbnNmb3JtICh3aW5jZSB3ZSBhcmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgZGVsaWJlcmF0ZWx5IHZhZ3VlIGFib3V0 IHdoYXQgbm9kZXMgY2FuIGRvIHdoZW4gYXNrZWQgc3VpdGFibHkuKTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBJcyB0aGVyZSBzb21lICZxdW90O2Nh biBiZSBieXBhc3NlZCZxdW90OyBpbmRpY2F0aW9uIGluIHRoZSByb3V0aW5nPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IGFkdmVydGlzZW1lbnRz IHRoYXQgSSBtaXNzZWQ/PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmZ3Q7IFRoYW5rIHlvdSw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgWW91cnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYu b3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGll dGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyAmbHQ7bWFp bHRvOnNwcmluZ0BpZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWls dG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJo dHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/ dT1odHRwcyUzQSUyNTIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8L2E+PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNRN3ZYMnFXU1VkV1ZjODkyWHVYeTJINkgyP3U9aHR0cHMlM0ElMkYl MkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5j b20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMl9fJTNC SlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3Vv Wkhnd3A2dnBSSE9HdDhBa1RSRHVpRG82SHdQTGlsJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRN3ZYMnFXU1VkV1ZjODkyWHVYeTJINkgyP3U9aHR0 cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5z eW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNB JTJBMl9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdt MHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG82SHdQTGlsJTI0PC9hPiZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdx aFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MiUwYiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZI Mj91PWh0dHBzJTNBJTI1Mjxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0E1QjhIMkZtMXJQbmFa M1N1cGp3cjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIl M0Z1JTNEaHR0cHMlMkEzQSUyQTI1Ml9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5 RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG96b1FpQUhr JTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNBNUI4 SDJGbTFyUG5hWjNTdXBqd3I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMl MkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdD NGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyNTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdr JTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1 aURvem9RaUFIayUyNDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBGJTxhIGhyZWY9Imh0dHA6Ly8yRnd3dy5pZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPjJGd3d3LmlldGYub3JnPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z OU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUy MVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlE by1wUENqdlIlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2Uu Y29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9yZ19fJTNCJTIxJTIxTkV0NnlNYU8t Z2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RS RHVpRG8tcFBDanZSJTI0PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z R1dUOWZ5amFGaTNGY3ZIRHZvb2R2UzZIMj91PWh0dHAlM0ElMkYlMkYyRnd3dy5pZXRmLm9yZyUw YiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zR1dUOWZ5 amFGaTNGY3ZIRHZvb2R2UzZIMj91PWh0dHAlM0ElMkYlMkYyRnd3dy5pZXRmLm9yZzxicj4NCjwv YT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRwcyUzQSUy RiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9yZ19fJTNC JTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhn d3A2dnBSSE9HdDhBa1RSRHVpRG8tcFBDanZSJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdf XyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1 b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLXBQQ2p2UiUyNDwvYT4mZ3Q7Jmd0OyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnNwcmluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8YnI+ DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmcl MGI8L2E+Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVB dlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZzcHJpbmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z Qmh5RXR4NFE3bjc0QmhpUm5mTUp0VDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6 Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTJGJTJBMkZ3d3cuaWV0Zi5vcmclMkEy Rm1haWxtYW4lMkEyRmxpc3RpbmZvJTJBMkZzcHJpbmdfXyUzQkpTVWxKU1VsJTIxJTIxTkV0NnlN YU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhB a1RSRHVpRG8taFIzZ0FEJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzNCaHlFdHg0UTduNzRCaGlSbmZNSnRUNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxk ZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYz NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMkYlMkEyRnd3dy5p ZXRmLm9yZyUyQTJGbWFpbG1hbiUyQTJGbGlzdGluZm8lMkEyRnNwcmluZ19fJTNCSlNVbEpTVWwl MjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3 cDZ2cFJIT0d0OEFrVFJEdWlEby1oUjNnQUQlMjQ8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBOb3RpY2U6IFRoaXMgZS1t YWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgaW5mb3JtYXRpb24gb2YgUmli Ym9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWw8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYW5kL29yPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xl IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRpc2Nsb3N1cmUsIHJlbGlhbmNl IG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZzxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgd2l0aG91dDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgaW50ZW5kZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgdGhlbiBkZWxldGUgYWxsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsgY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLjxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgc3By aW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhz S0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWls bWFuJTJGbGlzdGluZm8lMkZzcHJpbmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9hPjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJG dXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4 RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyNCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVY aDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9f aHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmdfXyUz QiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pI Z3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyNDwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc3ByaW5nIG1haWxp bmcgbGlzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYu b3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YSBocmVm PSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2 SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNR MXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRu U1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYz JTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmlu Z19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hx Z3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9 aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2sl MjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVp RG81S2xQbmJqJTI0PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQ QnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQom Z3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJl WGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyNSUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0 dHBzJTNBJTxicj4NCjwvYT4mZ3Q7IDJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElPGEgaHJlZj0iaHR0cDovLzJGd3d3LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+MkZ3d3cu aWV0Zi5vcmc8L2E+JTJGbWFpbG1hbiUyRmxpc3RpPGJyPg0KJmd0OyBuZm8lMkZzcHJpbmdfXyUz QiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1PGJy Pg0KJmd0OyBvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Jmd0Ozxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsg LS08YnI+DQomZ3Q7IE5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVu aWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbCBhbmQvb3IgPGJyPg0KJmd0OyBwcm9w cmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSBy ZXZpZXcsIDxicj4NCiZndDsgZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5 IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQgPGJyPg0KJmd0OyBleHByZXNzIHBlcm1pc3Np b24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIDxi cj4NCiZndDsgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHRoZW4gZGVsZXRlIGFsbCA8YnI+DQomZ3Q7IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cy48YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IC0tPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJp bmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2Ns aWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lW UEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGc3ByaW5nPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNL eVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBh bGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5Ob3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1l bnRzIG1heSBjb250YWluIGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMu IHRoYXQgaXMgY29uZmlkZW50aWFsDQogYW5kL29yIHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgZGlzY2xvc3VyZSwgcmVs aWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQgZXhw cmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eQ0KIGFuZCB0aGVuIGRlbGV0ZSBhbGwgY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGhyIHNpemU9 IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_MW3PR11MB457066589CAE97721BB97D84C1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 10:33:58 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888E83A100E for ; Fri, 14 Aug 2020 10:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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=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 3mXecz8ysc53 for ; Fri, 14 Aug 2020 10:33:51 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 3F01E3A103D for ; Fri, 14 Aug 2020 10:33:51 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id jp10so10767252ejb.0 for ; Fri, 14 Aug 2020 10:33:51 -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=DqoxO/TxgghmdJeNSihyhj91dZl6Tvk9ZBJEkCpDSkI=; b=dgW3WmQx3XkKU1gDsqKO738kyzxQvetPlgFQ+IsimN/f8dveKTKdtompNODHuhPRSH jsCgoITLozWLypUsB7Sm1M1O3gTksQS57638IaRgXM1UbAjs1S39Gp6vKsIetbLjwHsz 228KrFXaf7NWOOuVv0/nrx6+DjbfkdHxtq8/5SqhZxyrFUfqxPitMqm76UbaTRAYe73K rgGoGrz/xiBzcaowxAxgWgeCDIFip76aLvScSJncuHXUyZLx+xpuJPHhKnMXOV5Yyb8X LPQ6hoVbWSzrSFWr0ymd51Ywu5qYKNBk2THbJ3j4SmpCUd9mgC2SlIHey4H3AUgxtNKn VSSg== 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=DqoxO/TxgghmdJeNSihyhj91dZl6Tvk9ZBJEkCpDSkI=; b=Mi3NaD+ZM9JQGDoXnuEhhL6fdDJskZCCl2dy6F+qnt3/rX4fnww9sDUnRPwuFLcO/6 2WwUh7nyorqqQOS6ihG8VbRw/hGVhmreXO75U3k4I/fmO+d/BmBE2OT8zeKPr0T1NrBP 1uQPG63FugJHW/WlLMefOue/hFAuoNdB9eGTKkqMYSap1w+6gbXs4rkBbpIyB9hzjvu0 j7br05kKCIs8nScm69pHX6atjvwIlDwE7LsH1tHhiaXtT3aqIvTFdJJSKomus4NgIXiG wy9j3BIV/mnrrU6qsJ/BSXG+N1GsMXNSd6sVr274ZV44UO+8NzNW1uplYmNaQJV5UpWG jnnw== X-Gm-Message-State: AOAM532dLcHIx5oPF6MBKhc4ABMNTsz2FE7PUsk3GLXbRZioO1Ev8hgZ 8BnPFQd5mLWDDqfLE69WS6d2BzJrJ52G1FkkQnO3Bg== X-Google-Smtp-Source: ABdhPJwdtIzNFqnnAXt8tAWoPpyGq3W3s6Dhuon5RiZL3JTLPkUqV0spj9H+DLuHwzHEpY2VWqO1bH6g+3mbxgUjauk= X-Received: by 2002:a17:907:94ca:: with SMTP id dn10mr3434112ejc.110.1597426429156; Fri, 14 Aug 2020 10:33:49 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Fri, 14 Aug 2020 19:33:39 +0200 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: Alexander Vainshtein , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dd7f6f05acd9d282" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:33:57 -0000 --000000000000dd7f6f05acd9d282 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ketan, Looks like we are pretty much in sync here. But let me just observe that I purposely did not mention about SR policies as we are not able to signal the intent with the packets itself. So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with information if policies build with using them are bypass eligible or not. I was actually under the impression that this is already there and I am just not aware, but looking deeper indeed I do not see this marking neither in ISIS nor OSPF for prefix SIDs. Is there some work in progress to add it to those protocols or have we just documented need for a short LSR draft ? Thx, R. On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) wrote: > Hi Robert, > > > > Please check inline below. > > > > *From:* Robert Raszuk > *Sent:* 14 August 2020 21:13 > *To:* Ketan Talaulikar (ketant) > *Cc:* Alexander Vainshtein ; Joel M. > Halpern ; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi Ketan, > > > > While I completely agree with your note the consequences of it are pretty > sevre. > > *[KT] I understand. We need to be mindful of implications of protection > schemes for the SLAs/intent of SR Policies.* > > > > Unless we signal which prefix SID is protection eligible and which is not > how would other nodes know if they can protect it or not ? > > *[KT] Correct. To be more accurate, we need to consider this more in the > context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and which segme= nts may be > =E2=80=9Cbypass-able=E2=80=9D for local protection for some of those SR P= olicies. We also > have path-protection mechanisms.* > > > > It seems that today's safe thing is not to apply any node protection on S= R > flows at the PLRs then. > > > > And link protection MUST assure that packets will arrive at the neighbor > node via some other link regardless of further path towards destination. > > *[KT] Yes. We have a mechanism to indicate which adj-SIDs have protection > (that mechanism only provides link protection to get to the neighbor node= ) > so the SR Policy computation is able to indicate whether that specific li= nk > is =E2=80=9Cbypass-able=E2=80=9D or not by its choice of protected or unp= rotected adj-SIDs > respectively.* > > > > *Thanks,* > > *Ketan* > > > > Is it correct ? > > > > Thx > > R > > > > On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) < > ketant@cisco.com> wrote: > > Hi Sasha, > > > > The service node advertises its own Prefix SID. The service function that > this service node implements does not require any context (i.e. all packe= ts > arriving at the node are subjected to that service). Therefore the servic= e > node does not need to receive a packet with it=E2=80=99s own Prefix SID. > > > > Thus, we cannot assume that when PHP is used, then the SID is only > associated with a topological instruction. > > > > Hope that clarifies? > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 20:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Ketan, and all, > > I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are > advertised with PHP can ONLY represent topological instructions in SR-MP= LS > - because the advertising node will not receive them and therefore can > hardly be expected to associate any service function with them. > > > > This is complementary to what you have said. > > > > Hope this clarifies my position. > > What, if anything, did I miss? > > > > Regards, > > Sasha > > > > Get Outlook for Android > > > ------------------------------ > > *From:* Ketan Talaulikar (ketant) > *Sent:* Friday, August 14, 2020, 16:23 > *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* RE: [spring] Spring protection - determining applicability > > > ------------------------------ > > NOTICE: This email was received from an EXTERNAL sender > ------------------------------ > > > > Hi Sasha, > > > > If the service does not need any additional context (e.g. a firewall that > just applies locally configured default rules on it), then I don=E2=80=99= t see why > PHP could not be done for a Prefix SID associated with a service node. > > > > Also, I didn=E2=80=99t follow the point that you were trying to make abou= t > Adj-SIDs. > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 18:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Alexander Vainshtein ; > Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.co= m > ; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi all, > > Regarding the statement "Prefix SID could be just a topological > instruction or may also be used to steer the flow to a node which is > applying a service function to it": > > > > > > I think that in SR-MPLS a Node SID that is advertised with PHP aciton can > be safely considered as "just a topological instruction" by the PLR becau= se > the originating node will not receive it. > > The same applies to Adj-SDIs. > > > > My 2c. > > > > Get Outlook for Android > > > > ------------------------------ > > *From:* spring on behalf of Ketan Talaulikar > (ketant) > *Sent:* Friday, August 14, 2020, 15:00 > *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi All, > > I would like to share a different perspective on this. > > First, thanks to Joel for bringing up the discussion. Clearly we need a > well-defined applicability statement for determining applicability of > protection for segment used in an SR Policy. Some of this is captured in > [1]. > > This is about local repair at a PLR. By it's very nature, the PLR does no= t > have a notion of how "strict or not" is the SLA that is being provided by > the SR Policy. Awareness of that notion exists at the SR Policy headend > and/or computation-node. > > We have protected and un-protected variants of adjacency SIDs to enable > the computation to pick or the other based on the "strictness" of the SLA > requirement for picking that link. We do not have such a notion for Prefi= x > SIDs. One can say that we could introduce signalling (e.g. a B flag) to > indicate whether a Prefix SID can be bypassed or not. This provides the > opportunity for the computation to use one or the other flavor depending = on > the nature of the SLA for the SR Policy. > > I have a problem and a concern in the assumption that PLRs can assume tha= t > the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) a= re > "bypass-able". > > As Joel and others have brought out, the Prefix SID could be just a > topological instruction or may also be used to steer the flow to a node > which is applying a service function to it. In order to support a mix of = SR > Policies of different SLAs (strict and not-strict), we need to enable the > choice of SIDs that indicates to the PLR whether they are "bypass-able" o= r > not. > > For the cases, where the SR Policy has a specific SLA, it is required for > nodes to drop the packets meant for the "active segment" than to bypass i= t. > When this mechanism is used along side SRTE path monitoring mechanisms, i= t > enables the headend to detect the failure and fallback to an alternate pa= th > using the path protection approach. This is something that is described a= nd > in use in deployments today [1].. > > Thanks, > Ketan > > [1] > https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9 > [2] > https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9.3 > > -----Original Message----- > From: spring On Behalf Of Joel M. Halpern > Sent: 04 August 2020 20:25 > To: Alexander Vainshtein ; Shraddha Hegde = < > shraddha=3D40juniper.net@dmarc.ietf.org>; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability > > There are, as far as I can tell, a number of ways to address this family > of related questions. > What struck me, and prompted the starting question, was that none of them > were spelled out. I see lots of interesting ideas / proposals. > Some of them are compatible with others. Some are not. > It would be good if we could reach agreement on how we thought it should > be handled. > > Thank you, > Joel > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > Hi all, > > > > I am still not sure that the problem of bypass going thru undesirable > > links/nodes exists in the case of topological SIDs. > > > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > > < > https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%= 2Ftools.ietf.org%2Fhtml%2Frfc4090>) > has been successfully deployed > > for many years before SR-MPLS has been introduced. What=E2=80=99s more, > > signaling of bypass tunnels he PLR usually did not include any of the > > constraints used for computing of any specific LSP that the bypass LSP > > would protect =E2=80=93 because in the Facility Protection mode the sam= e > > bypass LSP would be used to protect multiple LSPs passing thru the > > failed link/node. > > > > From my POV the only difference between this behavior and that > > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in = the case of > > RSVP-TE, the operator would explicitly indicate, as part of LSP > > signaling, whether it would or would not use FRR; LSPs that would not > > use FRR would then drop traffic rather than delivering it the wrong way= . > > > > Such an option indeed does not exist in SR-TE today, but would be easy > > to provide if so desired IMHO. > > > > Did I miss something substantial? > > > > Regards, and lots of thanks in advance, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* spring *On Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > *To:* EXT-Andrew.Alston@liquidtelecom.com > > ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > All, > > > > This is a very interesting discussion and thanks to Joel for starting > > this discussion. IMO, when there are strict requirements of avoiding > > certain nodes/links it can be realized either by defining a flex-algo > > avoiding those > > > > Nodes and links or by using a stack of unprotected adj-sids that avoid > > restricted nodes and links. When a stack of adj-sids is used to > > realize the path, the head-end based (sBFD) protection mechanisms can b= e > applied. > > > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > > failure events may cause traffic to go through restricted nodes and > > links. This would happen regardless of whether any kind of protection > > is in use or not. > > > > Rgds > > > > Shraddha > > > > Juniper Business Use Only > > > > *From:* spring > >> *On Behalf Of *Andrew Alston > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf.org >; Joel > M. Halpern > > >= > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > *[External Email. Be cautious of content]* > > > > Robert this is actually far more difficult when =E2=80=93 it can be an = entire > > (long) series of nodes that need to be avoided. > > > > It could potentially be made to work but I=E2=80=99d worry that to do t= his =E2=80=93 > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative label= s =E2=80=93 and that wouldn=E2=80=99t > > be viable. > > > > It=E2=80=99s easier to use algorithms and adjacency sids and other such= things > > to calculate paths =E2=80=93 the biggest trick is about the stack depth= . When > > you have this need for node avoidance =E2=80=93 the need for 10+ label = depth > > is critical =E2=80=93 unless you wanna be applying one hell of a lot of > > binding labels along the way which is a nightmare. > > > > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use > > case that most of the people I discuss this with certain have =E2=80=93= I cant > > comment on a global scale, or for anyone else, but every indication I > > have is that yes =E2=80=93 its something people need, and want > > > > Andrew > > > > *From:* Robert Raszuk >> > > *Sent:* Tuesday, 4 August 2020 01:27 > > *To:* Andrew Alston > < > mailto:Andrew.Alston@liquidtelecom.com >= > > > *Cc:* Joel M. Halpern > >>; spring@ietf.org > > > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Is this a common use case ie. "but rather =E2=80=93 which nodes / netw= ork > > segments it can never touch or flow through." > > > > If so perhaps its time to define notion of *negative-SID* ie. list in > > the packet resources which given packet MUST not ever traverse. > > > > Put in the packet set of nodes or links which the packet should never > > traverse. > > > > That goes in line of recent wave of negative routing implementations > > (RIFT) or discussions (LSR) > > > > Best, > > R. > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > < > mailto:Andrew.Alston@liquidtelecom.com >= > > wrote: > > > > So =E2=80=93 > > > > One of the use cases, in fact, some very major use cases in any > > spring technology for us revolve around the following > > > > a.The explicit avoidance of certain nodes > > > > b.The explicit avoidance of certain sections of the network > > > > Anything that could result in that explicit avoidance being violate= d > > =E2=80=93 would create, shall we say significant problems. > > > > Much of the use case is not a case of which nodes the packets flow > > through =E2=80=93 but rather =E2=80=93 which nodes / network segmen= ts it can never > > touch or flow through. Effectively, to be used as a technology to > > avoid certain things for specific reasons. > > > > This is also one of the reasons for needing such deep label stacks = =E2=80=93 > > this kind of detailed path programming tends to deepen the stack > > because you sometimes have to be pretty explicit. > > > > It is absolutely critical to us that this functionality is there = =E2=80=93 > > and that we can avoid situations which could cause traffic to > > accidently hit things explicitly avoided. > > > > I wish I could be more specific than this, but it is what it is. > > > > Thanks > > > > Andrew > > > > *From:* spring > >> *On Behalf Of *Joel M. Halpern > > *Sent:* Monday, 3 August 2020 21:36 > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf..org > > > *Subject:* Re: [spring] Spring protection - determining > > applicability > > > > (Since the thread has gotten long enough, reiterating that this is > as a > > participant, not a WG chair.) > > > > Yes, we are talking IP networks. And yes, I have seen IP networks > that > > choose to drop packets. For all sorts of reasons. > > I think there are likely other reasons why one may not want a rando= m > > path rather than a chosen TE path. I think it is important we be > clear > > about what constraints may be / are violated when we tell people th= ey > > have this tool (protective rerouting) that is intended to preserve > QoS. > > > > Let's be clear. I am not arguing that this is not a good idea. It i= s > a > > good idea. And useful. I am trying to figure otu what combination o= f > > additional mechanisms and clear descriptions will lead to everyone > > getting the behavior they expect (which may not be the behavior the= y > > desire, but sometimes is the best we can do.) > > > > Yours, > > Joel > > > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > > Joel, > > > > > > Are we still talking about IP networks here ? Or perhaps some ha= rd > > > slicing with real resource reservations or detnets ? > > > > > > Because if we are talking about IP networking I have two > > observations: > > > > > > A) If you need to traverse via a specific node (ie. firewall) yo= u > > better > > > apply IP encapsulation to that node.. I don't think IP > > encapsulation can > > > be hijacked today such that destination address of the packet is > > ignored. > > > > > > B) Have you seen any IP network where upon topology change (link > > or node > > > failure) you suddenly start dropping flows in spite of SPT > offering > > > perhaps few ms longer path with 10 ms more jitter ? > > > > > > Or are some SR marketing slides promise to turn IP networks in > > > something new ? Worse ... do they mention path quality guarantee= s, > > > resource reservations ? I hope not. > > > > > > Thx, > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern < > jmh@joelhalpern.com > > >> >> wrote: > > > > > > Well less serious for TE SIDs, I am not sure the problem is > > restricted > > > to just service SIDs. > > > > > > Suppose that the PCE has specified the path to meet some complex > te > > > objective. The bypass node has no way of knowing what those > > > constraints > > > were. And for some kinds of traffic, it is better to drop the > packet > > > than to deliver it outside the envelop. I suspect that the righ= t > > > answer > > > to this is "too bad". If so, as with the distinction regarding > > service > > > nodes, we should say so, shouldn't we? > > > > > > Yours, > > > Joel > > > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > > Mach, Joel and all, > > > > > > > > I think that in most cases: > > > > > > > > 1.There is clear differentiation between "topological" and > > "service" > > > > instructions in SID advertisements. E.g.: > > > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > > corresponding IGP advertisements) represent topological > > instructions > > > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > < > https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04 > > > > < > https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQ= AtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24 > >> > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D inst= ructions > > > > > > > > 2.Segments that represent topological instructions can be > bypassed, > > > > while segments that represent service instructions require > > > alternative > > > > protection mechanisms. > > > > > > > > This view seems to be aligned with RFC 8402 > > > > < > https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Frfc8402 > > > > < > https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24 > >> > > that says in Section 1: > > > > > > > > In the context of an IGP-based distributed control plane, > two > > > > > > > > topological segments are defined: the IGP-Adjacency segment an= d > the > > > > > > > > IGP-Prefix segment. > > > > > > > > In the context of a BGP-based distributed control plane, t= wo > > > > > > > > topological segments are defined: the BGP peering segment and > the > > > > > > > > BGP-Prefix segment. > > > > > > > > In the case of SR-MPLS this differentiation is assumed in > Section > > > 3.4 of > > > > the Node Protection for SR-TE Path > > > > > > > > > < > https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-f= or-sr-te-paths-07%23section-3.4 > > > > < > https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 9wO-Ssn%24 > >> > > > > > > > draft that says: > > > > > > > > The node protection mechanism described in the previous > > sections > > > > > > > > depends on the assumption that the label immediately below > > > the top > > > > > > > > label in the label stack is understood in the IGP domain. Whe= n > the > > > > > > > > provider edge routers exchange service labels via BGP or > some > > > other > > > > > > > > non-IGP mechanism the bottom label is not understood in th= e > IGP > > > > > > > > domain. > > > > > > > > The egress node protection mechanisms described in the dra= ft > > > > > > > > [RFC8679 < > https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679 > > > > < > https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fr= fc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRH= OGt8AkTRDuiDo8MGipXc%24 > >>] > > is > > > > applicable to this use case and no additional changes > > > > > > > > will be required for SR based networks > > > > > > > > The scenarios in which differentiation between =E2=80=9Ctopol= ogical=E2=80=9D > and > > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed pr= oblematic. E.g., > > > consider > > > > the use case in which a Node SID in the ERO of a SR-TE path > > > identifies a > > > > node that acts as a firewall for all packets it receives, i.e.= , > > > provides > > > > the firewall service without any dedicated service SID > > > identifying it. > > > > One could say that the Node SID of such a node would combine > > > topological > > > > and service instructions thus breaking the differentiation > > > between the two. > > > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs= could be > prevented > > > or at > > > > least discouraged. > > > > > > > > If not, providing an ability to identify such SIDs in the > > > advertisement > > > > mechanisms would be useful IMHO. > > > > > > > > My 2c, > > > > > > > > Sasha > > > > > > > > Office: +972-39266302 > > > > > > > > Cell: +972-549266302 > > > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > > > > > > > -----Original Message----- > > > > From: spring > >> > > >> On > Behalf Of Mach Chen > > > > Sent: Monday, August 3, 2020 6:30 AM > > > > To: Joel M. Halpern > >> >>; > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > Subject: Re: [spring] Spring protection - determining > applicability > > > > > > > > Hi Joel, > > > > > > > > I think this is a good point that may not be discussed in the > > > past. And > > > > I also don't think there is a "can be bypassed" indication in > the > > > > routing advertisement for now. > > > > > > > > IMHO, the information advertised by routing is neutral, such > > > information > > > > (can or cannot be bypassed) is more path specific, thus > > normally the > > > > controller should be responsible for deciding whether/which SI= D > > > can be > > > > bypassed. > > > > > > > > Best regards, > > > > > > > > Mach > > > > > > > > > -----Original Message----- > > > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > > > > < > mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%= 3e > >] > > On Behalf Of Joel M. > > > > > > > > > Halpern > > > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > > > To: spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > Subject: [spring] Spring protection - determining > applicability > > > > > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > > confused WG > > > > > > > > > participant.) > > > > > > > > > > > > > > > > > > I have been reading the various repair drafts, and the > various > > > > > > > > > networks programming and service programming draft, and I a= m > > > trying to > > > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, > for > > > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID f= or > > > a failed > > > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new > path > > > meets > > > > > > > > > the TE criteria. or maybe it is safe if it is even close, = as > > > long as > > > > > > > > > it is not used for too long. > > > > > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet lega= l > > > > requirements? > > > > > > > > > Or was some other necessary programmatic transform (wince w= e > are > > > > > > > > > deliberately vague about what nodes can do when asked > suitably.) > > > > > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > Yours, > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > spring mailing list > > > > > > > > > spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2 > > > < > https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8= E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24 > > > > > > > > > > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2 > > > > < > https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW= 9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE= 8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24 > >> > > > > > > > > > F%2Fwww.ietf.org > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > > > > > < > https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%= 2F2Fwww.ietf.org > > > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > >>%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > > > > > > > spring mailing list > > > > > > > > spring@ietf.org > > > > > = >> > >> > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flisti= nfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0= wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24 > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Notice: This e-mail together with any attachments may contain > > > > information of Ribbon Communications Inc. that is confidential > > > and/or > > > > proprietary for the sole use of the intended recipient. Any > review, > > > > disclosure, reliance or distribution by others or forwarding > > without > > > > express permission is strictly prohibited. If you are not the > > > intended > > > > recipient, please notify the sender immediately and then delet= e > all > > > > copies, including any attachments. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti > > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > ---------------------------------------------------------------------- > > -- > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > ---------------------------------------------------------------------- > > -- > > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > ------------------------------ > > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. that is confidential and/or proprietary for > the sole use of the intended recipient. Any review, disclosure, reliance = or > distribution by others or forwarding without express permission is strict= ly > prohibited. If you are not the intended recipient, please notify the send= er > immediately and then delete all copies, including any attachments. > ------------------------------ > > > > --000000000000dd7f6f05acd9d282 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ketan,

Looks like we are pretty much in= sync here.=C2=A0

But let me just observe that I p= urposely=C2=A0did not mention about SR policies as we are not able to signa= l the intent with the packets itself.=C2=A0

So all= we have there is SIDs. BSIDs or prefix SIDs need to be flooded with inform= ation if policies build with using them are bypass eligible or not.=C2=A0

I was actually under the impression that this is al= ready there and I am just not aware, but looking deeper indeed I do not see= this marking neither in ISIS nor OSPF for prefix SIDs.=C2=A0
Is there some work in progress to add it to those protocols or = have we just documented need=C2=A0for a short LSR draft=C2=A0 ?=C2=A0
=

Thx,
R.


On Fri, Aug 14, 2= 020 at 6:17 PM Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:

Hi Robert,

=C2=A0

Please check inline below.

=C2=A0

From: Robert Raszuk <robert@raszuk.net>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= u>

=C2=A0

Hi Ketan,

=C2=A0

While I completely agree with your note the conseque= nces of it are pretty sevre.=C2=A0

[KT] I understand. We need to be mindful of im= plications of protection schemes for the SLAs/intent of SR Policies.

=C2=A0

Unless we signal which prefix SID is protection elig= ible and which is not how would other nodes know if they can protect it or = not ?=C2=A0

[KT] Correct. To be more accurate, we need to = consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR = Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for local = protection for some of those SR Policies. We also have path-protection mechanisms.

=C2=A0

It seems that today's safe thing is not to apply= any node protection on SR flows at the PLRs then.=C2=A0

=C2=A0

And link protection MUST assure that packets will ar= rive at the neighbor node via some other link regardless of further path to= wards destination.=C2=A0

[KT] Yes. We have a mechanism to indicate whic= h adj-SIDs have protection (that mechanism only provides link protection to= get to the neighbor node) so the SR Policy computation is able to indicate= whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its choice of protected or unprotected adj-SIDs respectively.=

=C2=A0

Thanks,

Ketan

=C2=A0

Is it correct ?=C2=A0

=C2=A0

Thx

R

=C2=A0

On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:

Hi Sasha,

=C2=A0

The service node advertises its own Prefix SID. The = service function that this service node implements does not require any con= text (i.e. all packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a pa= cket with it=E2=80=99s own Prefix SID.

=C2=A0

Thus, we cannot assume that when PHP is used, then t= he SID is only associated with a topological instruction.

=C2=A0

Hope that clarifies?

=C2=A0

Thanks,

Ketan

=C2=A0

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

Ketan, and all,

I have stated that, IMHO and FWIW, both= Adj-SIDs and Prefix SIDs that are advertised with PHP can=C2=A0 ONLY repre= sent topological instructions in SR-MPLS - because the advertising node wil= l not receive them and therefore can hardly be expected to associate any service function with them.=

=C2=A0

This is complementary to what you have = said.

=C2=A0

Hope this clarifies my position.=

What, if anything, did I miss?

=C2=A0

Regards,

Sasha

=C2=A0

Get Outlook for Android=

=C2=A0

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Friday, August 14, 2020, 16:23
To: = Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
Cc: = spring@ietf.org
Subject: RE: [spring] Spring protection - determining applicability

=C2=A0

NOTICE: This email was received from an EXTERNAL sen= der

=C2=A0

Hi Sasha,

=C2=A0

If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don=E2=80=99t see why PHP could not be done for a Prefix SID associated with a service node.

=C2=A0

Also, I didn=E2=80=99t follow the point that you wer= e trying to make about Adj-SIDs.

=C2=A0

Thanks,

Ketan

=C2=A0

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

Hi all,

Regarding the statement "Prefix SI= D could be just a topological instruction or may also be used to steer the = flow to a node which is applying a service function to it":<= /u>

=C2=A0

=C2=A0

I think that in SR-MPLS a Node SID that= is advertised with PHP aciton can be safely considered as "just a top= ological instruction" by the PLR because the originating node will not= receive it.

The same applies to Adj-SDIs.=

=C2=A0

My 2c.

=C2=A0

Get Outlook for Android

=C2=A0

From: spring <spring-bounces@ietf.org> on behalf of Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>=
Sent: Friday, August 14, 2020, 15:00
To: = Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
Cc: = spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability

=C2=A0

Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does = not have a notion of how "strict or not" is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Polic= y headend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
[2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of= related questions.
What struck me, and prompted the starting question, was that none of them w= ere spelled out.=C2=A0 I see lots of interesting ideas / proposals.
Some of them are compatible with others.=C2=A0=C2=A0 Some are not.
It would be good if we could reach agreement on how we thought it should be= handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirable =
> links/nodes exists in the case of topological SIDs.
>
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
> <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
> for many years before SR-MPLS has been introduced. What=E2=80=99s more= ,
> signaling of bypass tunnels he PLR usually did not include any of the =
> constraints used for computing of any specific LSP that the bypass LSP=
> would protect =E2=80=93 because in the Facility Protection mode the sa= me
> bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>=C2=A0 From my POV the only difference between this behavior and that <= br> > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use FRR; LSPs that would not =
> use FRR would then drop traffic rather than delivering it the wrong wa= y.
>
> Such an option indeed does not exist in SR-TE today, but would be easy=
> to provide if so desired IMHO.
>
> Did I miss something substantial?
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
>
> Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
> *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> All,
>
> This is a very interesting discussion and thanks to Joel for starting =
> this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized=C2=A0 either by defining a flex= -algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avoid=
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
> failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org
> <m= ailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern
> <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> *[External Email. Be cautious of content]*
>
> Robert this is actually far more difficult when =E2=80=93 it can be an= entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93
> you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t
> be viable.
>
> It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things
> to calculate paths =E2=80=93 the biggest trick is about the stack dept= h.=C2=A0 When
> you have this need for node avoidance =E2=80=93 the need for 10+ label= depth
> is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
> case that most of the people I discuss this with certain have =E2=80= =93 I cant
> comment on a global scale, or for anyone else, but every indication I =
> have is that yes =E2=80=93 its something people need, and want
>
> Andrew
>
> *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
> <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org > <mailto:spring= @ietf.org>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> Is this a common use case ie.=C2=A0 "but rather =E2=80=93 which n= odes / network
> segments it can never touch or flow through."
>
> If so perhaps its time to define notion of *negative-SID* ie. list in =
> the packet resources which given=C2=A0packet MUST not ever traverse. >
> Put in the packet set of nodes or links which the packet should never =
> traverse.
>
> That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston@liquidtelecom.com
> <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
>
>=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93
>
>=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very major= use cases in any
>=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve around the fo= llowing
>
>=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain nodes
>
>=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain sections o= f the network
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that explicit av= oidance being violated
>=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say significa= nt problems.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case of which no= des the packets flow
>=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 which n= odes / network segments it can never
>=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effectively, to b= e used as a technology to
>=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific reasons.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for needing su= ch deep label stacks =E2=80=93
>=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming tends t= o deepen the stack
>=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pretty explic= it.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this func= tionality is there =E2=80=93
>=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations which could c= ause traffic to
>=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly avoided.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than this, but= it is what it is.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Thanks
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Andrew
>
>=C2=A0=C2=A0=C2=A0=C2=A0 *From:* spring <spring-bounces@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> *On Behal= f Of *Joel M. Halpern
>=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36
>=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
>=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring@ietf..org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: [spring] Spring protection - de= termining
> applicability
>
>=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long enough, reit= erating that this is as a
>=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.)
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
>=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. For all sorts of reaso= ns.
>=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons why one= may not want a random
>=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. I think it = is important we be clear
>=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are violated w= hen we tell people they
>=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerouting) that is = intended to preserve QoS.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing that this= is not a good idea. It is a
>=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying to figure o= tu what combination of
>=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descriptions w= ill lead to everyone
>=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (which may no= t be the behavior they
>=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can do.)<= br> >
>=C2=A0=C2=A0=C2=A0=C2=A0 Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0 Joel
>
>=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about IP netwo= rks=C2=A0here ? Or perhaps some hard
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reservat= ions or detnets ?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talking=C2= =A0about IP networking I have two
>=C2=A0=C2=A0=C2=A0=C2=A0 observations:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via a sp= ecific node (ie. firewall) you
>=C2=A0=C2=A0=C2=A0=C2=A0 better
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to that node= .. I don't think IP
>=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that destina= tion address of the packet is
>=C2=A0=C2=A0=C2=A0=C2=A0 ignored.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP network whe= re upon topology change (link
>=C2=A0=C2=A0=C2=A0=C2=A0 or node
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0start dr= opping=C2=A0flows in spite of SPT offering
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path with 10 = ms more jitter ?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing slides pro= mise to turn IP networks in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new ? Worse ... do t= hey mention path quality guarantees,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0? I hope= not.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R.
>=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%20%0b>> <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">mailto:jmh@joelhalp= ern.com>> wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SIDs, I am= not sure the problem is
>=C2=A0=C2=A0=C2=A0=C2=A0 restricted
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has specified = the path to meet some complex te
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass node ha= s no way of knowing what those
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some kinds of t= raffic, it is better to drop the packet
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside the enve= lop.=C2=A0 I suspect that the right
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is "too bad".=C2= =A0 If so, as with the distinction regarding
>=C2=A0=C2=A0=C2=A0=C2=A0 service
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn= 9;t we?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most cases: >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differentiati= on between "topological" and
>=C2=A0=C2=A0=C2=A0=C2=A0 "service"
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID advertisem= ents. E.g.:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP advertisemen= ts) represent topological
>=C2=A0=C2=A0=C2=A0=C2=A0 instructions
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
>=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 <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3GC5a= f2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F= datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 4T-L0nl%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent topo= logical instructions can be bypassed,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that represent = service instructions require
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be aligned = with RFC 8402
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0 that says in Section 1:
>=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 In the cont= ext of an IGP-based distributed control plane, two
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the IGP-Adjacency segment and the
>=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 IGP-Prefix = segment.
>=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 In the cont= ext of a BGP-based distributed control plane, two
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the BGP peering segment and the
>=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 BGP-Prefix = segment.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this di= fferentiation is assumed in Section
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for SR-TE = Path
>=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 <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdr= aft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21= %21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9= wO-Ssn%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft that says:
>=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 The node pr= otection mechanism described in the previous
>=C2=A0=C2=A0=C2=A0=C2=A0 sections
>=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 depends on = the assumption that the label immediately below
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack is un= derstood in the IGP domain.=C2=A0 When the
>=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 provider ed= ge routers exchange service labels via BGP or some
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other
>=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 non-IGP mec= hanism the bottom label is not understood in the IGP
>=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 domain.
>=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 The egress = node protection mechanisms described in the draft
>=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 [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u= =3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2F= doc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
>=C2=A0=C2=A0=C2=A0=C2=A0 is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use case an= d no additional changes
>=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 will be req= uired for SR based networks
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2=A0d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a Node S= ID in the ERO of a SR-TE path
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firewall f= or all packets it receives, i.e.,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service without a= ny dedicated service SID
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the Node SI= D of such a node would combine
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus = breaking the differentiation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ability t= o identify such SIDs in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMH= O.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein@ecitele.com
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:Alexander.Vainshtein@ecitele.com>=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:Alexander.Vainshtein@ecitele.= com>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > -----Original Message-----
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > From: spring <spring-bounces@ietf.org<= br> >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org%0b>>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2020 6= :30 AM
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern <jmh@joelhalpern.com >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.co= m>>;
>=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: [spring] Spring p= rotection - determining applicability
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good point t= hat may not be discussed in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there i= s a "can be bypassed" indication in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now.=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information advertis= ed by routing is neutral, such
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypassed) is= more path specific, thus
>=C2=A0=C2=A0=C2=A0=C2=A0 normally the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be responsib= le for deciding whether/which SID
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Messa= ge-----
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > From: spring [mailt= o:spring-bounc= es@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring-bounces@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>] >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, Augus= t 3, 2020 7:51 AM
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Subject: [spring] S= pring protection - determining applicability
>=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 > (WG Chair hat Off, = this is merely a note from a slightly
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.)
>=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 > I have been reading= the various repair drafts, and the various
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programmin= g and service programming draft, and I am
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspe= ct of the combination.
>=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 > How does a node tha= t is doing some form of bypass (suppose, for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is N= ode N2 deciding to bypass the next SID for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know that = it is safe to do so?
>=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 > If the path was jus= t for TE, then it is "safe" if the new path
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2= =A0 or maybe it is safe if it is even close, as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used for = too long.
>=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 > But what if the nod= e were a Firewall, included to meet legal
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other n= ecessary programmatic transform (wince we are
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague = about what nodes can do when asked suitably.)
>=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 > Is there some "= ;can be bypassed" indication in the routing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements that= I missed?
>=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 > Thank you,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel
>=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=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing list=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
>=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=A0 https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3Q= 7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A= %2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2= __%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt= 8AkTRDuiDo6HwPLil%24>
>=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 <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.c= om/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http= s%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A= %2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6v= pRHOGt8AkTRDuiDozoQiAHk%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > F%2Fwww.ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.sy= mantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktim= e.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%= 2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1o= iQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2F= listinfo%2Fspring
>=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 > > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org> <mailto:spring@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>> >=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 https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRn= fMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sym= antec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.o= rg%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yu= sx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>=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=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0 ----------------------------------------------= --------------------------
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Notice: This e-mail together w= ith any attachments may contain
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Communic= ations Inc. that is confidential
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole use o= f the intended recipient. Any review,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distri= bution by others or forwarding
>=C2=A0=C2=A0=C2=A0=C2=A0 without
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly= prohibited. If you are not the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify the s= ender immediately and then delete all
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attachme= nts.
>=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=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>=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 > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>=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 spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0
> <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
> 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> ----------------------------------------------------------------------=
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or =
> proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
> recipient, please notify the sender immediately and then delete all > copies, including any attachments.
> ----------------------------------------------------------------------=
> --

_______________________________________________
spring mailing list
spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring

=C2=A0

=C2=A0

Notice: This e-mail together with any attachments may contain inform= ation of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review,= disclosure, reliance or distribution by others or forwarding without expre= ss permission is strictly prohibited. If you are not the intended recipient= , please notify the sender immediately and then delete all copies, including any attachments.

=C2=A0

--000000000000dd7f6f05acd9d282-- From nobody Fri Aug 14 10:35:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9A83A1218; Fri, 14 Aug 2020 10:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.497 X-Spam-Level: X-Spam-Status: No, score=-9.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ND0dVjoF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RuFtsJsW 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 WyR7PCYcwAXT; Fri, 14 Aug 2020 10:35:17 -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 0D63D3A11AA; Fri, 14 Aug 2020 10:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21754; q=dns/txt; s=iport; t=1597426515; x=1598636115; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mQm6VhsIS/CGOlQzAZ4PMaJkLj3+V0j0Di41SjAZejg=; b=ND0dVjoFaywz87gjnqea2JURUKQ7mrlOA+SCgeKEMpI6E1w/WLah0/KK 4ssot5HjvP7syMLmTmGl8UzjGAHDsKcxzkPMy3WJJlj6zCrvoHuxNeDi/ KrSmLSPbtx/8mrvWY/DRynq5V7qfvEyuunGudoI5+cyL5YV5rOr86gvUi c=; IronPort-PHdr: =?us-ascii?q?9a23=3A5nuVlhMVhAEunsAOvcEl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK813kTWXJ7A4PVBzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXleFzJuXa16HgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6CQAByzZf/5hdJa1eHgEBCxIMQIJ?= =?us-ascii?q?tLyMuB3BYLywKhgqBaQONVJhngUKBEQNVCwEBAQwBARgBCQsCBAEBgW2CXwK?= =?us-ascii?q?CRwIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQECAgEBEAsQEwEBKgEBCAM?= =?us-ascii?q?BDwIBCBEEAQEhBwcnCxQJCAEBBAENBQgagn8EAoF+TQMuAQ6oAQKBOYhhdIE?= =?us-ascii?q?0gwEBAQWBMwEDAgKDZQMVgg4DBoE4gnGKLBqBQT+BEAFDgk0+gjoiAQEBAQE?= =?us-ascii?q?WgQw8DBgHCQKDEoItj3chiUycTgqCYohjkV2Cf4lbBZNAkjiBbIhWlHoCBAI?= =?us-ascii?q?EBQIOAQEFgWojDYFKcBU7gmkTPRcCDY18IwwXg06FFIVCdAIBAQEyAgYKAQE?= =?us-ascii?q?DCXyPFQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,313,1592870400"; d="scan'208,217";a="813862290" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 17:34:58 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EHYvME020443 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 17:34:57 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 12:34:57 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 12:34:56 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 12:34:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j+4UqBPTD98UyPj0MUy6Dv5ZdmHW6xvxR+q7A+zJs5KQx+fOvE+5rVKSdnSgbxhxZ+wKAb24Dv75WW3Sv1B8qf+iR9TOZnmm5uS6PhuB0WROomVlLHkpvqvRcKRdU2WtFDRypUXuCJv5EmIoVZgGZ+ih8jGUxfEUhBC3FamJ6zIGangS2soe6c9a8B7q5rcwwoXTW9AuIZXPLaHeXoW/dOCLfbaWVA55lvEdmihmfwPTTJtQKYJHs+uAxlbHO+8z65ruZE2e39iNnqX4qxCho8I6oAgWQkFFIfuDm724a1BUwXpYQOZyZ4Sqi2anOeC0Bgglg7xDYwKjP2TY29S/cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=52dRNzyCxs6JvbALg36a/WnS29FlSGQFLXAPRDSOkB4=; b=JQF+yOASFdKW6MK5TFiVi4MvQ3NM3RetH3YX7MnhEUS7v8cSWvQ+IsPwuTzjwQuwJBp5cx/Tw8Nnvwd+aO7RItBADYkuFn8dI6qNzS7hgprRhsk+OBWdkcW2HoDbFn6KFRKUZqf4g+NPCBWEl97e0fZUOVkM7i3yQDofIFXpiu48AvDpNyfqbnaUxGqMsIImfgNwvhHBewbYjPslY8C65IOekYsyKQ25J4OTmH6YCEOBflGByJbPDhphBP4G+WQmXrKsQRVvZMhT/i+Fc7lv+dhoBfJS8pgzj4s0YEoB7eZKNlsPdhJ+CSvLkG22PmugAtiNJCJUhJ56qJQSC5TKfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=52dRNzyCxs6JvbALg36a/WnS29FlSGQFLXAPRDSOkB4=; b=RuFtsJsWftB5xSHklPSCB7em71O3fKn5mfe59hxY3lVhcT8+47wcS0E4x0JS+asFnZN0Xr690LYSAY3JwP1ZVOluIdR588fZN98lk13mcZ4+dQyDBFTYWxqg840NNb2uW+ZRr+olDZxUHIh1ye+LXeVB/iGFwH67fkUOum9ICgg= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4521.namprd11.prod.outlook.com (2603:10b6:303:55::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 17:34:54 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 17:34:54 +0000 From: "Ketan Talaulikar (ketant)" To: "Thomas.Graf@swisscom.com" , "hannes@gredler.at" CC: "lsr@ietf.org" , SPRING WG Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AdZktQw6qX35tZ6KQpiaZtLipXAiTwAxTF+AAHUFTIACvTCesA== Date: Fri, 14 Aug 2020 17:34:54 +0000 Message-ID: References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> In-Reply-To: <1419364510.2875.1596208917648@ss002890> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: swisscom.com; dkim=none (message not signed) header.d=none;swisscom.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0519285f-3710-4c50-1dc8-08d840785b6f x-ms-traffictypediagnostic: MW3PR11MB4521: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pJm2invDUBgTeI6Byid++v+/YYkB+fTkcVh4V6Mgkd5kTbKooMccxNimU1P/MP6/+imVEylmv8wlXC6PVdNkKs1FmwxOOrZ/aHFwyV/53KpFewc9Wp/O/cf5DOLCZEjRilL3slyDQHQjjW3AsgYphCaQi74P0Jm3RTKJayiojKOwMjv1QKpufCQ8QBfh1rrHa2UnFIviuzQQVhmYcbu249Ggqz3pW9qYq+R+adpdwtkxNVY4gfY+LX7B4Q9kRRKtPDmbVFvLBrketIo3xwGIwBFdgZc2dVolEkwp1rl6D0LpyI0KuRnJK1AYnD014lS2cToFSP59FNd1z/vSSelUPCRklrnlwv7po2gD5iXajjDOPaIDdEa07aUz1dPwMCNETVuhZC3XcYKgM23CsAm0lg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(396003)(366004)(136003)(346002)(19627235002)(5660300002)(166002)(4326008)(966005)(33656002)(52536014)(7696005)(8676002)(316002)(55016002)(54906003)(2906002)(76116006)(186003)(478600001)(6506007)(64756008)(66946007)(66476007)(9686003)(53546011)(8936002)(66446008)(83380400001)(26005)(71200400001)(86362001)(110136005)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: QCjTAIgJ+CUMCNQ251Pu6lvjOOWyqTh9KpyDMdN53mSxYi/hZGsmLIXT3m9Z8qGplM6+E6jjHhT0vFsh1oWbLXUC6EQUxahwZOKe6JhlrxOPcr0OeMcic/QE+0WHnVoAo/v5p8yf4nAymocnaj8FC1n9xqa6jS73F0DjuWI/NJf1Xkk190XfE7IdtQtpOVIJWaDuEy3T4QYdM0XNqnmMMhS/5FXEEab/+ACZe+SfEPmYBKCyxZx54kNpzr6ZzbYExSyZ+kcdau7/Y52p24OTtlu5nnLPEdi4FIoxbGaxvORKIPH0lG0GnPVpxMcWjHvQPyUkTfZloip/17JpiC2GO4zjkX53TXksEMS5QU/YP6bW0rG+P1DuDzraFhC0Opm+SY0SHIicsryd4qEDcs+gZVpYtjA465rdmLXgaComFabgd7KB6ZD4w2cU2TjJ5e0Lm1cQ8Ds9QiCi5QQiLoN/0y0s0NWDfb6se9h3BeE+/c8QNYTL8bJCizFgfLR8IsmkjYnyVNICbE7VpRBQIdgAm6dNHkvWMBv6czVTkCvMWJypOcEW3vcQ7CMQVQiE9vv4eT/w8gH84yJ6AAi5lRJ5bJanr7h/tZ2sDdEZ8JD/LzPXGIejPDmZPmQV24760PN2xtExCXTsZnq6Vkgfm7Vqig== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570F20CFE2C0E46C8D4B2DEC1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0519285f-3710-4c50-1dc8-08d840785b6f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 17:34:54.4230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ngNRlwDyEhvH2TnSAQj/H403ZQsna3lVtXsL5NIJsLdGS76qL+Dx5UvWIwsK16BbkwGLtxOWZdz7O4scvWHkQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4521 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:35:26 -0000 --_000_MW3PR11MB4570F20CFE2C0E46C8D4B2DEC1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr On Behalf Of Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update.. Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_MW3PR11MB4570F20CFE2C0E46C8D4B2DEC1400MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

< also= copying Spring WG for their review/inputs >

&nbs= p;

Hi Thomas= /All,

&nbs= p;

I have re= viewed the draft and would like to share a different perspective.

&nbs= p;

What or h= ow much value be there on determining whether a SR Prefix SID was signalled= /programmed on a node via OSPFv2/OSPFv3/ISIS – what matters and is mo= re important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and learning the same = prefix from different IGPs. IPFIX may be picking this information from a FI= B in some implementation where the protocol does not matter and this inform= ation is not available therein.

&nbs= p;

On some n= odes, the same Prefix SID may be learnt via both BGP and IGP – what w= ould we use/show?

&nbs= p;

I would r= ecommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peer= ing SID and so on … for the MPLS Label Type.

&nbs= p;

This also= takes away the need for the second table that is being proposed to a large= extent. For that table proposal, it is very difficult and in some cases no= t possible to different between Prefix and Node and Anycast SID. Many of these types are control plane elements a= nd we can be sure more get added. Is there really much value in differentia= tion between say an Adjacency SID and LAN Adjacency SID?<= /p>

&nbs= p;

Could we = evaluate the implementation overhead and complexity of this level of catego= rization/information in IPFIX against their value in flow analysis to perha= ps consider a middle ground?

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Thomas.Graf@swisscom.com
Sent: 31 July 2020 20:52
To: hannes@gredler.at
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Hi Hannes,

 =

Thanks a lot for = the feedback. Yes, makes completely sense. Will take it for the next update= ..

 =

Best Wishes<= /o:p>

Thomas=

 

 =

From: Hannes Gredler <hannes@= gredler.at>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Thomas,

 

I have one comment/suggestion t= o Paragraph 4 (IANA Considerations).

 

Please add also a code point fo= r BGP Prefix-SID - it’s quite popular in DC deployments.

 

thanks,

 

/hannes

=  

On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

 

Dear lsr,

 

I presented the following draft=

 

Export of MPLS Segment Routing = Label Type Information in IP Flow Information Export (IPFIX)

 

at the spring working group at = IETF 108 yesterday

 

and today at OPSAWG where I cal= l for adoption.

 

This draft adds additional segm= ent routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 an= d OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

 

I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link state routing protocols and mpls data plane.

 

I am looking forward to your fe= edback and input.

 

Best Wishes

Thomas Graf

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

 

--_000_MW3PR11MB4570F20CFE2C0E46C8D4B2DEC1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 10:46:03 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C183A1016 for ; Fri, 14 Aug 2020 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ada90hgv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZMMxARqp 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 b1xWXlWKnfBM for ; Fri, 14 Aug 2020 10:45:55 -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 826F03A0FF3 for ; Fri, 14 Aug 2020 10:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=166358; q=dns/txt; s=iport; t=1597427155; x=1598636755; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FBuY7X0u8w58CBB3FzGdIOcKz9X48X+zT7oJ42aGL/U=; b=ada90hgvQrjyY6uc+DxuGpdK2j8ff8OekuAB/OETiNMQ6EAj5G2kDamc MvKJAnII7E0jw6JZcDobUM1UDwsFvaA2dlGA0N886/4vpqa2vxcyYNGht T41FPsv84z8XgR4lU1wu32oRzvZWuSCYS+ecSSzLqK4wDmIlthgzGnDrt Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A5HhIcBXNLyTium9jMO51Og3nB37V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyFuehNkPjLsObmVHBTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBuHSp/yMRXB?= =?us-ascii?q?PyKVk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBQBczDZf/5tdJa1UChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggqBIy8pKAdwWC8sCoQtg0YDjVSBApdlgUKBEQNQAgMLAQE?= =?us-ascii?q?BDAEBGAEJBwQCBAEBhAhEAheCMAIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXE?= =?us-ascii?q?BAQEEAQEQCAEIChMBASwBCgELAgICAQgRBAEBASABBgMCAgIUEQsUCQgCBA4?= =?us-ascii?q?FCBqDAAWBfk0DLgEOp3oCgTmIYXaBMoMBAQEFgTMBAwIOAw8vgxgYgg4JBYE?= =?us-ascii?q?zgnGDYIQtgQGBHhqBQT8maQEBQ4FPLhs1PoJcAQECAQEVgREBBwsBIwUHCQg?= =?us-ascii?q?HAQUBCQIGglkzgi2PRQcSBwMGKoIvPIZhgx+IPZByCoJiiGOFfFCFCIYJgn8?= =?us-ascii?q?2bYg4kR6CJ4VWiwmFQ4ZYhTmLFYQsAgQCBAUCDgEBBYFAKiMNWnBwFTuCaQk?= =?us-ascii?q?WMRcCDYhahUUMF4ECAQKCSYQ+VoVCdAIBAQEVARwCBgEJAQEDCXyNYAWBMAE?= =?us-ascii?q?0XAEB?= X-IronPort-AV: E=Sophos;i="5.76,313,1592870400"; d="scan'208,217";a="544962558" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Aug 2020 17:45:52 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07EHjqCn014123 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2020 17:45:52 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 12:45:51 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 14 Aug 2020 12:45:51 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 14 Aug 2020 12:45:51 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XqOW+qU/qF8crRSL2Qjlly090X8lhqaD2LVRzWJ5YxyGUpyJHmpD4khiN90jvlGZg2CbTOWDzQypezfyDVDGW2kFVk7o7bIMO0ZQFWC4nA6gdzUvr/Nq5X1PgK6uSKpKJrGvQdjj873ZG2uDN1NSW0Qm9Ypof+da3z4fw92V2T2XtUUQb3lnMwG3gxQH+Ud/q2OeU/wRSPv9eBbzFsXdlReuQs0N4lgd45MzgxAnELZv0d+UUGTsj8Rwvl4olpFDhEw1zj0MDel9QnsqwDG9qFlKrwadt7g1+xax/aOLTtFx5zUhXmVgIhNS78B/oQTkt9N/mQ5A+3RW69FwMtDZ2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FBuY7X0u8w58CBB3FzGdIOcKz9X48X+zT7oJ42aGL/U=; b=og13ZQkcJsNv2WxZhU4QttRJw/EagaLrZaJgVR+Mlrgcqf5usVEMb89ghZxIFkvGjd7BFo1NwTPTE5LCoqFmQM3WaelZONDtGBglaQ1gqF2du9Z4lWnNxJ10Wfk+kJMjqztpuF7f4Uo+aE//19PrUKRdeosJcnQ+fvFCZHNOqQqKPaZYpsEw2ilBhe5UASlo+oMwox6ZT2xjGk1Wlema2XmISe6MeTT74RVIvW6uXTf48uYU0xvOKvhtcoxodAtYTmXvz/Bg95R4wlbu6uoVx4m3xxyLYkZbKiajOIhMXoA/rKx0j34XJBqp4TOdTT5RQuUuzLXZ76/5RwPrSt3s7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FBuY7X0u8w58CBB3FzGdIOcKz9X48X+zT7oJ42aGL/U=; b=ZMMxARqp/hSZovMo/TWpCiWqm4o2sDmRksNbfyTmlnGqNS9aqtsOQ9U9gEgFUJcvP+GrPWGc+rzev7J3eIouiuxtfnl+1XOl2fTB8s+FwKaurhtkPQ4ebLHHrxd0ns42gPqp2ZqMAcWJQ4d7IJMu57JRFgS+B4iN/veq7yhjynQ= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1775.namprd11.prod.outlook.com (2603:10b6:300:10e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Fri, 14 Aug 2020 17:45:48 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::658f:69a3:2fc5:d430%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 17:45:48 +0000 From: "Ketan Talaulikar (ketant)" To: Robert Raszuk CC: Alexander Vainshtein , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfGJGLEw80LFEa7R79kiStyh6klun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAFLgAgAB1eACAD4BY8IAAFTmAgAAGD1CAABtZgIAACTzggAAEVwCAAAYyoIAAGNWAgAAA2VA= Date: Fri, 14 Aug 2020 17:45:48 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdf8b5e7-97b5-4eb6-c23b-08d84079e15b x-ms-traffictypediagnostic: MWHPR11MB1775: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2512; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CXtih5n5ol+MLHkOMTiVLqE7hautLA3tAp1BCZ218n9uKCGAbaDLHEdyGt7wgA+BI9ecYrqJB1ea0O2yml5qwbIeIUhDjvaDskGljyVblBk7Lwv2PLNnE7xFS/jxm7ZoZeMNQJi/iWB/4M62gGT4eu4AWX8D0gKBff0YiLxftZXTSOnhDiE+Yq8RED2XxLl+i3GOzottQysO44ET+1ILwRUV2SzqA/1DRzSNvHOTIZTfVkwc2yVNhjJVfZj6QMlS89a9zF5tP96ggd1QuND3Wshdlr3wLunQ5pOpFnj/q03zglyAyZSAWWgeNx/9cIlgUdLJWGuwI5gomDwRPv29hOs5NFoHwoT+EFjBskvRXdPlzMQfl4u1RwLsFZkk7tBc9rGtdOgT8B/gQZOgf9nhaw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(376002)(366004)(346002)(45080400002)(4326008)(7696005)(86362001)(6506007)(186003)(71200400001)(30864003)(53546011)(66946007)(5660300002)(66446008)(26005)(9686003)(8676002)(8936002)(9326002)(76116006)(966005)(2906002)(83380400001)(52536014)(316002)(478600001)(55016002)(6916009)(66476007)(66556008)(64756008)(33656002)(166002)(54906003)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JNaULhWsRaQPofDNMHtBZLrPlhyKBN/Gu0jCWRHiVykY+wu0LYGSX30FyVRW9NC9D6lwjxIyJ9dMh3lT3/KT+4uIxkUdtn6KH+jbE812S8rqU4P7+6baY0HDtP+0BwGb/GqCSsFdRV2mLGuXT84cHRqezh09ZEGppVBFd643NibPoVkNJojMPEqJdMPUeFsz+7X1XwVqJx+cldYvulopICt07eIJNingoy38ZjTxsw016Pe7D5Tq3ng/jBPnuygoVz7e2jlX/9jsJwG499wIEhrdHW8YzNs7qUVns92p5HDMzsSCJ9VrsuNwUdbiccHXN4CD02gbMzmTvqdp9Zgj0OnxFsTjN6mXFhGGPXx1XM8upIWJqg52BcPu4XfnsdvbnQ9unOi4t6NvO3boyl1ynMeZ2PuJbloPnf6HHLVUJ3g6Q3qGzoobflv62vqt2kYmUzkAeYU4OfkxRzcYRcUF8TLLO3iooz3ycPFDI51iUc9FHPFuPklGo/S9NWxctevS9TYhlK61Y65q0eIFSMTgNYKGl/8eMqPVecXtgkXvpiVSefUFZyXCJTu2I7cA+NYFMYJ9sOYMFEkjf9SC7qUlZmfuSTV5N6K1OZ0VOAeNqRbg1su9If4GnD1DgzTdgksHLjnP+CUi5g9kScTLiparAA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570250AC1693BD65241A638C1400MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdf8b5e7-97b5-4eb6-c23b-08d84079e15b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 17:45:48.6727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b7ALhKPldXumNghigAH95H5Y26mWjj5A8SdPSmYqR4sU4VdNuE5KfSS4g2LvACEEQEK9FKD9HaXaEeQfUICV3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1775 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:46:02 -0000 --_000_MW3PR11MB4570250AC1693BD65241A638C1400MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpXZSBkbyBub3QgaGF2ZSBhIHNpZ25hbGxpbmcgbWVjaGFuaXNtIGluIElH UHMgdG9kYXkgdG8gaW5kaWNhdGUgYSDigJxieXBhc3MtYWJsZeKAnSBpbmRpY2F0aW9uIGZvciBQ cmVmaXggU0lEcy4gSWYgdGhlcmUgd2FzIGEgZGVzaXJlIGZvciBpdCwgYW4gSUdQIGV4dGVuc2lv biB3b3VsZCBiZSByZXF1aXJlZCAodGhlcmUgaXMgbm9uZSBpbiBwcm9ncmVzcyBBRkFJSykuIE5v dGUgdGhhdCB0aGlzIHJlc3VsdHMgaW4gZG91YmxpbmcgdGhlIHByZWZpeCBTSUQgc2NhbGUgKGds b2JhbCBsYWJlbHMpIGluIHRoZSBuZXR3b3JrLiBTbyBJIHdvdWxkIG5vdCBnbyBhYm91dCB0aGlz IHRyaXZpYWxseS4NCg0KSSB0aGluayBpdCBoZWxwcyB0byBnZXQgbW9yZSBpbnB1dHMgYW5kIHBl cnNwZWN0aXZlcyBmcm9tIG9wZXJhdG9ycyBvbiB0aGVpciB2aWV3cyBmb3IgZG9pbmcgYSBieXBh c3MgdmlhIGxvY2FsIHByb3RlY3Rpb24gZm9yIHNlZ21lbnRzIGluIGFuIFNSIFBvbGljeS4gVGhl cmUgbWF5IGJlIHRob3NlIHRoYXQgcHJlZmVyIGVuZC10by1lbmQgcGF0aCBwcm90ZWN0aW9uIHVz aW5nIGEgZmFsbGJhY2sgcGF0aCB0aGF0IGlzIHNheSBkaXNqb2ludCB3aXRoIHRoZSBwcmltYXJ5 IGJ1dCBwcm92aWRlcyBhbiBhcHByb3ByaWF0ZSBTTEEvaW50ZW50Pw0KDQpUaGFua3MsDQpLZXRh bg0KDQpGcm9tOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NClNlbnQ6IDE0IEF1 Z3VzdCAyMDIwIDIzOjA0DQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNp c2NvLmNvbT4NCkNjOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5A cmJibi5jb20+OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBTaHJhZGRo YSBIZWdkZSA8c2hyYWRkaGFAanVuaXBlci5uZXQ+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0 ZWxlY29tLmNvbSA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IHNwcmluZ0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5p bmcgYXBwbGljYWJpbGl0eQ0KDQpLZXRhbiwNCg0KTG9va3MgbGlrZSB3ZSBhcmUgcHJldHR5IG11 Y2ggaW4gc3luYyBoZXJlLg0KDQpCdXQgbGV0IG1lIGp1c3Qgb2JzZXJ2ZSB0aGF0IEkgcHVycG9z ZWx5IGRpZCBub3QgbWVudGlvbiBhYm91dCBTUiBwb2xpY2llcyBhcyB3ZSBhcmUgbm90IGFibGUg dG8gc2lnbmFsIHRoZSBpbnRlbnQgd2l0aCB0aGUgcGFja2V0cyBpdHNlbGYuDQoNClNvIGFsbCB3 ZSBoYXZlIHRoZXJlIGlzIFNJRHMuIEJTSURzIG9yIHByZWZpeCBTSURzIG5lZWQgdG8gYmUgZmxv b2RlZCB3aXRoIGluZm9ybWF0aW9uIGlmIHBvbGljaWVzIGJ1aWxkIHdpdGggdXNpbmcgdGhlbSBh cmUgYnlwYXNzIGVsaWdpYmxlIG9yIG5vdC4NCg0KSSB3YXMgYWN0dWFsbHkgdW5kZXIgdGhlIGlt cHJlc3Npb24gdGhhdCB0aGlzIGlzIGFscmVhZHkgdGhlcmUgYW5kIEkgYW0ganVzdCBub3QgYXdh cmUsIGJ1dCBsb29raW5nIGRlZXBlciBpbmRlZWQgSSBkbyBub3Qgc2VlIHRoaXMgbWFya2luZyBu ZWl0aGVyIGluIElTSVMgbm9yIE9TUEYgZm9yIHByZWZpeCBTSURzLg0KDQpJcyB0aGVyZSBzb21l IHdvcmsgaW4gcHJvZ3Jlc3MgdG8gYWRkIGl0IHRvIHRob3NlIHByb3RvY29scyBvciBoYXZlIHdl IGp1c3QgZG9jdW1lbnRlZCBuZWVkIGZvciBhIHNob3J0IExTUiBkcmFmdCAgPw0KDQpUaHgsDQpS Lg0KDQoNCk9uIEZyaSwgQXVnIDE0LCAyMDIwIGF0IDY6MTcgUE0gS2V0YW4gVGFsYXVsaWthciAo a2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+IHdyb3Rl Og0KSGkgUm9iZXJ0LA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBSb2Jl cnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0K U2VudDogMTQgQXVndXN0IDIwMjAgMjE6MTMNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQp IDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lzY28uY29tPj4NCkNjOiBBbGV4YW5k ZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQHJiYm4uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxw ZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8c2hy YWRkaGFAanVuaXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj47IEVYVC1BbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1 aWR0ZWxlY29tLmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFu ZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+Pjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24g LSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCkhpIEtldGFuLA0KDQpXaGlsZSBJIGNvbXBs ZXRlbHkgYWdyZWUgd2l0aCB5b3VyIG5vdGUgdGhlIGNvbnNlcXVlbmNlcyBvZiBpdCBhcmUgcHJl dHR5IHNldnJlLg0KW0tUXSBJIHVuZGVyc3RhbmQuIFdlIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiBp bXBsaWNhdGlvbnMgb2YgcHJvdGVjdGlvbiBzY2hlbWVzIGZvciB0aGUgU0xBcy9pbnRlbnQgb2Yg U1IgUG9saWNpZXMuDQoNClVubGVzcyB3ZSBzaWduYWwgd2hpY2ggcHJlZml4IFNJRCBpcyBwcm90 ZWN0aW9uIGVsaWdpYmxlIGFuZCB3aGljaCBpcyBub3QgaG93IHdvdWxkIG90aGVyIG5vZGVzIGtu b3cgaWYgdGhleSBjYW4gcHJvdGVjdCBpdCBvciBub3QgPw0KW0tUXSBDb3JyZWN0LiBUbyBiZSBt b3JlIGFjY3VyYXRlLCB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoaXMgbW9yZSBpbiB0aGUgY29udGV4 dCBvZiBTTEEgb3Ig4oCcaW50ZW504oCdIG9mIFNSIFBvbGljaWVzIGFuZCB3aGljaCBzZWdtZW50 cyBtYXkgYmUg4oCcYnlwYXNzLWFibGXigJ0gZm9yIGxvY2FsIHByb3RlY3Rpb24gZm9yIHNvbWUg b2YgdGhvc2UgU1IgUG9saWNpZXMuIFdlIGFsc28gaGF2ZSBwYXRoLXByb3RlY3Rpb24gbWVjaGFu aXNtcy4NCg0KSXQgc2VlbXMgdGhhdCB0b2RheSdzIHNhZmUgdGhpbmcgaXMgbm90IHRvIGFwcGx5 IGFueSBub2RlIHByb3RlY3Rpb24gb24gU1IgZmxvd3MgYXQgdGhlIFBMUnMgdGhlbi4NCg0KQW5k IGxpbmsgcHJvdGVjdGlvbiBNVVNUIGFzc3VyZSB0aGF0IHBhY2tldHMgd2lsbCBhcnJpdmUgYXQg dGhlIG5laWdoYm9yIG5vZGUgdmlhIHNvbWUgb3RoZXIgbGluayByZWdhcmRsZXNzIG9mIGZ1cnRo ZXIgcGF0aCB0b3dhcmRzIGRlc3RpbmF0aW9uLg0KW0tUXSBZZXMuIFdlIGhhdmUgYSBtZWNoYW5p c20gdG8gaW5kaWNhdGUgd2hpY2ggYWRqLVNJRHMgaGF2ZSBwcm90ZWN0aW9uICh0aGF0IG1lY2hh bmlzbSBvbmx5IHByb3ZpZGVzIGxpbmsgcHJvdGVjdGlvbiB0byBnZXQgdG8gdGhlIG5laWdoYm9y IG5vZGUpIHNvIHRoZSBTUiBQb2xpY3kgY29tcHV0YXRpb24gaXMgYWJsZSB0byBpbmRpY2F0ZSB3 aGV0aGVyIHRoYXQgc3BlY2lmaWMgbGluayBpcyDigJxieXBhc3MtYWJsZeKAnSBvciBub3QgYnkg aXRzIGNob2ljZSBvZiBwcm90ZWN0ZWQgb3IgdW5wcm90ZWN0ZWQgYWRqLVNJRHMgcmVzcGVjdGl2 ZWx5Lg0KDQpUaGFua3MsDQpLZXRhbg0KDQpJcyBpdCBjb3JyZWN0ID8NCg0KVGh4DQpSDQoNCk9u IEZyaSwgQXVnIDE0LCAyMDIwIGF0IDU6MzIgUE0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8 a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgU2Fz aGEsDQoNClRoZSBzZXJ2aWNlIG5vZGUgYWR2ZXJ0aXNlcyBpdHMgb3duIFByZWZpeCBTSUQuIFRo ZSBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgdGhpcyBzZXJ2aWNlIG5vZGUgaW1wbGVtZW50cyBkb2Vz IG5vdCByZXF1aXJlIGFueSBjb250ZXh0IChpLmUuIGFsbCBwYWNrZXRzIGFycml2aW5nIGF0IHRo ZSBub2RlIGFyZSBzdWJqZWN0ZWQgdG8gdGhhdCBzZXJ2aWNlKS4gVGhlcmVmb3JlIHRoZSBzZXJ2 aWNlIG5vZGUgZG9lcyBub3QgbmVlZCB0byByZWNlaXZlIGEgcGFja2V0IHdpdGggaXTigJlzIG93 biBQcmVmaXggU0lELg0KDQpUaHVzLCB3ZSBjYW5ub3QgYXNzdW1lIHRoYXQgd2hlbiBQSFAgaXMg dXNlZCwgdGhlbiB0aGUgU0lEIGlzIG9ubHkgYXNzb2NpYXRlZCB3aXRoIGEgdG9wb2xvZ2ljYWwg aW5zdHJ1Y3Rpb24uDQoNCkhvcGUgdGhhdCBjbGFyaWZpZXM/DQoNClRoYW5rcywNCktldGFuDQoN CkZyb206IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNv bTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+Pg0KU2VudDogMTQgQXVndXN0 IDIwMjAgMjA6MjQNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28u Y29tPG1haWx0bzprZXRhbnRAY2lzY28uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxo YWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8 c2hyYWRkaGFAanVuaXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj47IEVYVC1B bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRv OkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0 QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5v cmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcg cHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KS2V0YW4sIGFuZCBhbGws DQpJIGhhdmUgc3RhdGVkIHRoYXQsIElNSE8gYW5kIEZXSVcsIGJvdGggQWRqLVNJRHMgYW5kIFBy ZWZpeCBTSURzIHRoYXQgYXJlIGFkdmVydGlzZWQgd2l0aCBQSFAgY2FuICBPTkxZIHJlcHJlc2Vu dCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgaW4gU1ItTVBMUyAtIGJlY2F1c2UgdGhlIGFkdmVy dGlzaW5nIG5vZGUgd2lsbCBub3QgcmVjZWl2ZSB0aGVtIGFuZCB0aGVyZWZvcmUgY2FuIGhhcmRs eSBiZSBleHBlY3RlZCB0byBhc3NvY2lhdGUgYW55IHNlcnZpY2UgZnVuY3Rpb24gd2l0aCB0aGVt Lg0KDQpUaGlzIGlzIGNvbXBsZW1lbnRhcnkgdG8gd2hhdCB5b3UgaGF2ZSBzYWlkLg0KDQpIb3Bl IHRoaXMgY2xhcmlmaWVzIG15IHBvc2l0aW9uLg0KV2hhdCwgaWYgYW55dGhpbmcsIGRpZCBJIG1p c3M/DQoNClJlZ2FyZHMsDQpTYXNoYQ0KDQpHZXQgT3V0bG9vayBmb3IgQW5kcm9pZDxodHRwczov L2FrYS5tcy9naGVpMzY+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t OiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRh bnRAY2lzY28uY29tPj4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNjoyMw0KVG86 IEFsZXhhbmRlciBWYWluc2h0ZWluOyBKb2VsIE0uIEhhbHBlcm47IFNocmFkZGhhIEhlZ2RlOyBF WFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20+OyBSb2JlcnQgUmFzenVrDQpDYzogc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpOT1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4g RVhURVJOQUwgc2VuZGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpIaSBT YXNoYSwNCg0KSWYgdGhlIHNlcnZpY2UgZG9lcyBub3QgbmVlZCBhbnkgYWRkaXRpb25hbCBjb250 ZXh0IChlLmcuIGEgZmlyZXdhbGwgdGhhdCBqdXN0IGFwcGxpZXMgbG9jYWxseSBjb25maWd1cmVk IGRlZmF1bHQgcnVsZXMgb24gaXQpLCB0aGVuIEkgZG9u4oCZdCBzZWUgd2h5IFBIUCBjb3VsZCBu b3QgYmUgZG9uZSBmb3IgYSBQcmVmaXggU0lEIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2Ugbm9k ZS4NCg0KQWxzbywgSSBkaWRu4oCZdCBmb2xsb3cgdGhlIHBvaW50IHRoYXQgeW91IHdlcmUgdHJ5 aW5nIHRvIG1ha2UgYWJvdXQgQWRqLVNJRHMuDQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IEFs ZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbTxtYWlsdG86 QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+Pg0KU2VudDogMTQgQXVndXN0IDIwMjAgMTg6 MjQNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0 bzprZXRhbnRAY2lzY28uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNv bTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxl eGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJi Ym4uY29tPj47IFNocmFkZGhhIEhlZ2RlIDxzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hy YWRkaGFAanVuaXBlci5uZXQ+PjsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208 bWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPiA8QW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bT4+OyBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1 ay5uZXQ+Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGlj YWJpbGl0eQ0KDQpIaSBhbGwsDQpSZWdhcmRpbmcgdGhlIHN0YXRlbWVudCAiUHJlZml4IFNJRCBj b3VsZCBiZSBqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNl ZCB0byBzdGVlciB0aGUgZmxvdyB0byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNl IGZ1bmN0aW9uIHRvIGl0IjoNCg0KDQpJIHRoaW5rIHRoYXQgaW4gU1ItTVBMUyBhIE5vZGUgU0lE IHRoYXQgaXMgYWR2ZXJ0aXNlZCB3aXRoIFBIUCBhY2l0b24gY2FuIGJlIHNhZmVseSBjb25zaWRl cmVkIGFzICJqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24iIGJ5IHRoZSBQTFIgYmVjYXVz ZSB0aGUgb3JpZ2luYXRpbmcgbm9kZSB3aWxsIG5vdCByZWNlaXZlIGl0Lg0KVGhlIHNhbWUgYXBw bGllcyB0byBBZGotU0RJcy4NCg0KTXkgMmMuDQoNCkdldCBPdXRsb29rIGZvciBBbmRyb2lkPGh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNzVjNVlZQmVFYmFFWndVY0hwQ1kxbTZIMj91 PWh0dHBzJTNBJTJGJTJGYWthLm1zJTJGZ2hlaTM2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgS2V0YW4gVGFsYXVsaWthciAo a2V0YW50KSA8a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzprZXRhbnQ9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTQsIDIw MjAsIDE1OjAwDQpUbzogSm9lbCBNLiBIYWxwZXJuOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgU2hy YWRkaGEgSGVnZGU7IEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpF WFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IFJvYmVydCBSYXN6dWsNCkNjOiBz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3By aW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KSGkg QWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gc2hhcmUgYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUgb24g dGhpcy4NCg0KRmlyc3QsIHRoYW5rcyB0byBKb2VsIGZvciBicmluZ2luZyB1cCB0aGUgZGlzY3Vz c2lvbi4gQ2xlYXJseSB3ZSBuZWVkIGEgd2VsbC1kZWZpbmVkIGFwcGxpY2FiaWxpdHkgc3RhdGVt ZW50IGZvciBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5IG9mIHByb3RlY3Rpb24gZm9yIHNlZ21l bnQgdXNlZCBpbiBhbiBTUiBQb2xpY3kuIFNvbWUgb2YgdGhpcyBpcyBjYXB0dXJlZCBpbiBbMV0u DQoNClRoaXMgaXMgYWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkgbmF0 dXJlLCB0aGUgUExSIGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICJzdHJpY3Qgb3Igbm90 IiBpcyB0aGUgU0xBIHRoYXQgaXMgYmVpbmcgcHJvdmlkZWQgYnkgdGhlIFNSIFBvbGljeS4gQXdh cmVuZXNzIG9mIHRoYXQgbm90aW9uIGV4aXN0cyBhdCB0aGUgU1IgUG9saWN5IGhlYWRlbmQgYW5k L29yIGNvbXB1dGF0aW9uLW5vZGUuDQoNCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0 ZWQgdmFyaWFudHMgb2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0 byBwaWNrIG9yIHRoZSBvdGhlciBiYXNlZCBvbiB0aGUgInN0cmljdG5lc3MiIG9mIHRoZSBTTEEg cmVxdWlyZW1lbnQgZm9yIHBpY2tpbmcgdGhhdCBsaW5rLiBXZSBkbyBub3QgaGF2ZSBzdWNoIGEg bm90aW9uIGZvciBQcmVmaXggU0lEcy4gT25lIGNhbiBzYXkgdGhhdCB3ZSBjb3VsZCBpbnRyb2R1 Y2Ugc2lnbmFsbGluZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFByZWZp eCBTSUQgY2FuIGJlIGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5p dHkgZm9yIHRoZSBjb21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3IgZGVw ZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS4NCg0KSSBo YXZlIGEgcHJvYmxlbSBhbmQgYSBjb25jZXJuIGluIHRoZSBhc3N1bXB0aW9uIHRoYXQgUExScyBj YW4gYXNzdW1lIHRoYXQgdGhlIGN1cnJlbnRseSBkZWZpbmVkIHZhcmlhbnQgb2YgUHJlZml4IFNJ RHMgaW4gUkZDODQwMiAoYW5kIElHUCBzcGVjcykgYXJlICJieXBhc3MtYWJsZSIuDQoNCkFzIEpv ZWwgYW5kIG90aGVycyBoYXZlIGJyb3VnaHQgb3V0LCB0aGUgUHJlZml4IFNJRCBjb3VsZCBiZSBq dXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVl ciB0aGUgZmxvdyB0byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9u IHRvIGl0LiBJbiBvcmRlciB0byBzdXBwb3J0IGEgbWl4IG9mIFNSIFBvbGljaWVzIG9mIGRpZmZl cmVudCBTTEFzIChzdHJpY3QgYW5kIG5vdC1zdHJpY3QpLCB3ZSBuZWVkIHRvIGVuYWJsZSB0aGUg Y2hvaWNlIG9mIFNJRHMgdGhhdCBpbmRpY2F0ZXMgdG8gdGhlIFBMUiB3aGV0aGVyIHRoZXkgYXJl ICJieXBhc3MtYWJsZSIgb3Igbm90Lg0KDQpGb3IgdGhlIGNhc2VzLCB3aGVyZSB0aGUgU1IgUG9s aWN5IGhhcyBhIHNwZWNpZmljIFNMQSwgaXQgaXMgcmVxdWlyZWQgZm9yIG5vZGVzIHRvIGRyb3Ag dGhlIHBhY2tldHMgbWVhbnQgZm9yIHRoZSAiYWN0aXZlIHNlZ21lbnQiIHRoYW4gdG8gYnlwYXNz IGl0LiBXaGVuIHRoaXMgbWVjaGFuaXNtIGlzIHVzZWQgYWxvbmcgc2lkZSBTUlRFIHBhdGggbW9u aXRvcmluZyBtZWNoYW5pc21zLCBpdCBlbmFibGVzIHRoZSBoZWFkZW5kIHRvIGRldGVjdCB0aGUg ZmFpbHVyZSBhbmQgZmFsbGJhY2sgdG8gYW4gYWx0ZXJuYXRlIHBhdGggdXNpbmcgdGhlIHBhdGgg cHJvdGVjdGlvbiBhcHByb2FjaC4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyBkZXNjcmliZWQg YW5kIGluIHVzZSBpbiBkZXBsb3ltZW50cyB0b2RheSBbMV0uLg0KDQpUaGFua3MsDQpLZXRhbg0K DQpbMV0gaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3 VW1zNkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05DQpbMl0gaHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2ZkNNcmdtRWV3QzRhNEFKUnJtbjdINkgyP3U9aHR0 cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05LjMNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2Vu dDogMDQgQXVndXN0IDIwMjAgMjA6MjUNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFu ZGVyLlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4u Y29tPj47IFNocmFkZGhhIEhlZ2RlIDxzaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYu b3JnPG1haWx0bzpzaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPj47IEVYVC1B bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRv OkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0 QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5v cmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxw ZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQpTdWJqZWN0OiBSZTogW3Nwcmlu Z10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNClRoZXJl IGFyZSwgYXMgZmFyIGFzIEkgY2FuIHRlbGwsIGEgbnVtYmVyIG9mIHdheXMgdG8gYWRkcmVzcyB0 aGlzIGZhbWlseSBvZiByZWxhdGVkIHF1ZXN0aW9ucy4NCldoYXQgc3RydWNrIG1lLCBhbmQgcHJv bXB0ZWQgdGhlIHN0YXJ0aW5nIHF1ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2VyZSBz cGVsbGVkIG91dC4gIEkgc2VlIGxvdHMgb2YgaW50ZXJlc3RpbmcgaWRlYXMgLyBwcm9wb3NhbHMu DQpTb21lIG9mIHRoZW0gYXJlIGNvbXBhdGlibGUgd2l0aCBvdGhlcnMuICAgU29tZSBhcmUgbm90 Lg0KSXQgd291bGQgYmUgZ29vZCBpZiB3ZSBjb3VsZCByZWFjaCBhZ3JlZW1lbnQgb24gaG93IHdl IHRob3VnaHQgaXQgc2hvdWxkIGJlIGhhbmRsZWQuDQoNClRoYW5rIHlvdSwNCkpvZWwNCg0KT24g OC80LzIwMjAgMzo1NCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+IEhpIGFsbCwN Cj4NCj4gSSBhbSBzdGlsbCBub3Qgc3VyZSB0aGF0IHRoZSBwcm9ibGVtIG9mIGJ5cGFzcyBnb2lu ZyB0aHJ1IHVuZGVzaXJhYmxlDQo+IGxpbmtzL25vZGVzIGV4aXN0cyBpbiB0aGUgY2FzZSBvZiB0 b3BvbG9naWNhbCBTSURzLg0KPg0KPiBBRkFJSywgRmFjaWxpdHkgUHJvdGVjdGlvbiBpbiBSU1ZQ LVRFIEZSUiAoUkZDIDQwOTANCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTky a25FOVhKdWpyZjhCazdvSnZzNkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0 bWwlMkZyZmM0MDkwPikgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IGRlcGxveWVkDQo+IGZvciBtYW55 IHllYXJzIGJlZm9yZSBTUi1NUExTIGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTigJlzIG1vcmUs DQo+IHNpZ25hbGluZyBvZiBieXBhc3MgdHVubmVscyBoZSBQTFIgdXN1YWxseSBkaWQgbm90IGlu Y2x1ZGUgYW55IG9mIHRoZQ0KPiBjb25zdHJhaW50cyB1c2VkIGZvciBjb21wdXRpbmcgb2YgYW55 IHNwZWNpZmljIExTUCB0aGF0IHRoZSBieXBhc3MgTFNQDQo+IHdvdWxkIHByb3RlY3Qg4oCTIGJl Y2F1c2UgaW4gdGhlIEZhY2lsaXR5IFByb3RlY3Rpb24gbW9kZSB0aGUgc2FtZQ0KPiBieXBhc3Mg TFNQIHdvdWxkIGJlIHVzZWQgdG8gcHJvdGVjdCBtdWx0aXBsZSBMU1BzIHBhc3NpbmcgdGhydSB0 aGUNCj4gZmFpbGVkIGxpbmsvbm9kZS4NCj4NCj4gIEZyb20gbXkgUE9WIHRoZSBvbmx5IGRpZmZl cmVuY2UgYmV0d2VlbiB0aGlzIGJlaGF2aW9yIGFuZCB0aGF0DQo+IGludHJvZHVjZWQgYnkgdGhl IOKAnGJ5cGFzc2luZ+KAnSBkcmFmdHMgaW4gU1IgaXMgdGhhdCwgaW4gdGhlIGNhc2Ugb2YNCj4g UlNWUC1URSwgdGhlIG9wZXJhdG9yIHdvdWxkIGV4cGxpY2l0bHkgaW5kaWNhdGUsIGFzIHBhcnQg b2YgTFNQDQo+IHNpZ25hbGluZywgd2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBub3QgdXNlIEZS UjsgTFNQcyB0aGF0IHdvdWxkIG5vdA0KPiB1c2UgRlJSIHdvdWxkIHRoZW4gZHJvcCB0cmFmZmlj IHJhdGhlciB0aGFuIGRlbGl2ZXJpbmcgaXQgdGhlIHdyb25nIHdheS4NCj4NCj4gU3VjaCBhbiBv cHRpb24gaW5kZWVkIGRvZXMgbm90IGV4aXN0IGluIFNSLVRFIHRvZGF5LCBidXQgd291bGQgYmUg ZWFzeQ0KPiB0byBwcm92aWRlIGlmIHNvIGRlc2lyZWQgSU1ITy4NCj4NCj4gRGlkIEkgbWlzcyBz b21ldGhpbmcgc3Vic3RhbnRpYWw/DQo+DQo+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBp biBhZHZhbmNlLA0KPg0KPiBTYXNoYQ0KPg0KPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4NCj4g Q2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPg0KPiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ DQo+DQo+ICpGcm9tOiogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpTaHJhZGRoYSBIZWdkZQ0KPiAq U2VudDoqIFR1ZXNkYXksIEF1Z3VzdCA0LCAyMDIwIDk6NDEgQU0NCj4gKlRvOiogRVhULUFuZHJl dy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tPg0KPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86 QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+OyBSb2JlcnQgUmFzenVrIDxyb2JlcnRA cmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqQ2M6KiBzcHJpbmdAaWV0 Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxo YWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0K Pg0KPiBBbGwsDQo+DQo+IFRoaXMgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5k IHRoYW5rcyB0byBKb2VsIGZvciBzdGFydGluZw0KPiB0aGlzIGRpc2N1c3Npb24uIElNTywgd2hl biB0aGVyZSBhcmUgc3RyaWN0IHJlcXVpcmVtZW50cyBvZiBhdm9pZGluZw0KPiBjZXJ0YWluIG5v ZGVzL2xpbmtzIGl0IGNhbiBiZSByZWFsaXplZCAgZWl0aGVyIGJ5IGRlZmluaW5nIGEgZmxleC1h bGdvDQo+IGF2b2lkaW5nIHRob3NlDQo+DQo+IE5vZGVzIGFuZCBsaW5rcyBvciBieSB1c2luZyBh IHN0YWNrIG9mIHVucHJvdGVjdGVkIGFkai1zaWRzIHRoYXQgYXZvaWQNCj4gcmVzdHJpY3RlZCBu b2RlcyBhbmQgbGlua3MuIFdoZW4gYSBzdGFjayBvZiBhZGotc2lkcyBpcyB1c2VkIHRvDQo+IHJl YWxpemUgdGhlIHBhdGgsIHRoZSBoZWFkLWVuZCBiYXNlZCAoc0JGRCkgcHJvdGVjdGlvbiBtZWNo YW5pc21zIGNhbiBiZSBhcHBsaWVkLg0KPg0KPiBJZiBOb2RlLXNpZHMvcHJlZml4LXNpZC9hbnlj YXN0LXNpZHMgYXJlIHVzZWQgdG8gYnVpbGQgdGhlIHN0YWNrLCB0aGUNCj4gZmFpbHVyZSBldmVu dHMgbWF5IGNhdXNlIHRyYWZmaWMgdG8gZ28gdGhyb3VnaCByZXN0cmljdGVkIG5vZGVzIGFuZA0K PiBsaW5rcy4gVGhpcyB3b3VsZCBoYXBwZW4gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFueSBraW5k IG9mIHByb3RlY3Rpb24NCj4gaXMgaW4gdXNlIG9yIG5vdC4NCj4NCj4gUmdkcw0KPg0KPiBTaHJh ZGRoYQ0KPg0KPiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+DQo+ICpGcm9tOiogc3ByaW5n IDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y ZyUyMCUwYj4+IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9m ICpBbmRyZXcgQWxzdG9uDQo+ICpTZW50OiogVHVlc2RheSwgQXVndXN0IDQsIDIwMjAgNTo0MSBB TQ0KPiAqVG86KiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0 QHJhc3p1ay5uZXQ+IDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqQ2M6KiBzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ OyBKb2VsIE0uIEhhbHBlcm4NCj4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0Oiog UmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eQ0KPg0KPiAqW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XSoNCj4NCj4g Um9iZXJ0IHRoaXMgaXMgYWN0dWFsbHkgZmFyIG1vcmUgZGlmZmljdWx0IHdoZW4g4oCTIGl0IGNh biBiZSBhbiBlbnRpcmUNCj4gKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0IG5lZWQgdG8gYmUg YXZvaWRlZC4NCj4NCj4gSXQgY291bGQgcG90ZW50aWFsbHkgYmUgbWFkZSB0byB3b3JrIGJ1dCBJ 4oCZZCB3b3JyeSB0aGF0IHRvIGRvIHRoaXMg4oCTDQo+IHlvdeKAmWQgaGF2ZSB0byBzdGFjayAx MCDigJMgMjAg4oCTIDMwIG5lZ2F0aXZlIGxhYmVscyDigJMgYW5kIHRoYXQgd291bGRu4oCZdA0K PiBiZSB2aWFibGUuDQo+DQo+IEl04oCZcyBlYXNpZXIgdG8gdXNlIGFsZ29yaXRobXMgYW5kIGFk amFjZW5jeSBzaWRzIGFuZCBvdGhlciBzdWNoIHRoaW5ncw0KPiB0byBjYWxjdWxhdGUgcGF0aHMg 4oCTIHRoZSBiaWdnZXN0IHRyaWNrIGlzIGFib3V0IHRoZSBzdGFjayBkZXB0aC4gIFdoZW4NCj4g eW91IGhhdmUgdGhpcyBuZWVkIGZvciBub2RlIGF2b2lkYW5jZSDigJMgdGhlIG5lZWQgZm9yIDEw KyBsYWJlbCBkZXB0aA0KPiBpcyBjcml0aWNhbCDigJMgdW5sZXNzIHlvdSB3YW5uYSBiZSBhcHBs eWluZyBvbmUgaGVsbCBvZiBhIGxvdCBvZg0KPiBiaW5kaW5nIGxhYmVscyBhbG9uZyB0aGUgd2F5 IHdoaWNoIGlzIGEgbmlnaHRtYXJlLg0KPg0KPiBCdXQgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24s IGlzIHRoaXMgYSBjb21tb24gdXNlIGNhc2Ug4oCTIGl04oCZcyBhIHVzZQ0KPiBjYXNlIHRoYXQg bW9zdCBvZiB0aGUgcGVvcGxlIEkgZGlzY3VzcyB0aGlzIHdpdGggY2VydGFpbiBoYXZlIOKAkyBJ IGNhbnQNCj4gY29tbWVudCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFueW9uZSBlbHNlLCBi dXQgZXZlcnkgaW5kaWNhdGlvbiBJDQo+IGhhdmUgaXMgdGhhdCB5ZXMg4oCTIGl0cyBzb21ldGhp bmcgcGVvcGxlIG5lZWQsIGFuZCB3YW50DQo+DQo+IEFuZHJldw0KPg0KPiAqRnJvbToqIFJvYmVy dCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4gPG1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQo+ICpTZW50OiogVHVlc2RheSwgNCBBdWd1c3QgMjAy MCAwMToyNw0KPiAqVG86KiBBbmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVj b20uY29tDQo8bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGI+PiA8 bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+Pg0KPiAqQ2M6KiBKb2VsIE0u IEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20NCjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSUyMCUwYj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICpT dWJqZWN0OiogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBw bGljYWJpbGl0eQ0KPg0KPiBJcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNlIGllLiAgImJ1dCByYXRo ZXIg4oCTIHdoaWNoIG5vZGVzIC8gbmV0d29yaw0KPiBzZWdtZW50cyBpdCBjYW4gbmV2ZXIgdG91 Y2ggb3IgZmxvdyB0aHJvdWdoLiINCj4NCj4gSWYgc28gcGVyaGFwcyBpdHMgdGltZSB0byBkZWZp bmUgbm90aW9uIG9mICpuZWdhdGl2ZS1TSUQqIGllLiBsaXN0IGluDQo+IHRoZSBwYWNrZXQgcmVz b3VyY2VzIHdoaWNoIGdpdmVuIHBhY2tldCBNVVNUIG5vdCBldmVyIHRyYXZlcnNlLg0KPg0KPiBQ dXQgaW4gdGhlIHBhY2tldCBzZXQgb2Ygbm9kZXMgb3IgbGlua3Mgd2hpY2ggdGhlIHBhY2tldCBz aG91bGQgbmV2ZXINCj4gdHJhdmVyc2UuDQo+DQo+IFRoYXQgZ29lcyBpbiBsaW5lIG9mIHJlY2Vu dCB3YXZlIG9mIG5lZ2F0aXZlIHJvdXRpbmcgaW1wbGVtZW50YXRpb25zDQo+IChSSUZUKSBvciBk aXNjdXNzaW9ucyAoTFNSKQ0KPg0KPiBCZXN0LA0KPiBSLg0KPg0KPiBPbiBNb24sIEF1ZyAzLCAy MDIwIGF0IDExOjQ2IFBNIEFuZHJldyBBbHN0b24NCj4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20NCjxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSUyMCUwYj4+ IDxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+IHdyb3RlOg0KPg0KPiAg ICAgU28g4oCTDQo+DQo+ICAgICBPbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2 ZXJ5IG1ham9yIHVzZSBjYXNlcyBpbiBhbnkNCj4gICAgIHNwcmluZyB0ZWNobm9sb2d5IGZvciB1 cyByZXZvbHZlIGFyb3VuZCB0aGUgZm9sbG93aW5nDQo+DQo+ICAgICBhLlRoZSBleHBsaWNpdCBh dm9pZGFuY2Ugb2YgY2VydGFpbiBub2Rlcw0KPg0KPiAgICAgYi5UaGUgZXhwbGljaXQgYXZvaWRh bmNlIG9mIGNlcnRhaW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdvcmsNCj4NCj4gICAgIEFueXRoaW5n IHRoYXQgY291bGQgcmVzdWx0IGluIHRoYXQgZXhwbGljaXQgYXZvaWRhbmNlIGJlaW5nIHZpb2xh dGVkDQo+ICAgICDigJMgd291bGQgY3JlYXRlLCBzaGFsbCB3ZSBzYXkgc2lnbmlmaWNhbnQgcHJv YmxlbXMuDQo+DQo+ICAgICBNdWNoIG9mIHRoZSB1c2UgY2FzZSBpcyBub3QgYSBjYXNlIG9mIHdo aWNoIG5vZGVzIHRoZSBwYWNrZXRzIGZsb3cNCj4gICAgIHRocm91Z2gg4oCTIGJ1dCByYXRoZXIg 4oCTIHdoaWNoIG5vZGVzIC8gbmV0d29yayBzZWdtZW50cyBpdCBjYW4gbmV2ZXINCj4gICAgIHRv dWNoIG9yIGZsb3cgdGhyb3VnaC4gIEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5v bG9neSB0bw0KPiAgICAgYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNvbnMu DQo+DQo+ICAgICBUaGlzIGlzIGFsc28gb25lIG9mIHRoZSByZWFzb25zIGZvciBuZWVkaW5nIHN1 Y2ggZGVlcCBsYWJlbCBzdGFja3Mg4oCTDQo+ICAgICB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgcGF0 aCBwcm9ncmFtbWluZyB0ZW5kcyB0byBkZWVwZW4gdGhlIHN0YWNrDQo+ICAgICBiZWNhdXNlIHlv dSBzb21ldGltZXMgaGF2ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuDQo+DQo+ICAgICBJdCBpcyBh YnNvbHV0ZWx5IGNyaXRpY2FsIHRvIHVzIHRoYXQgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIHRoZXJl IOKAkw0KPiAgICAgYW5kIHRoYXQgd2UgY2FuIGF2b2lkIHNpdHVhdGlvbnMgd2hpY2ggY291bGQg Y2F1c2UgdHJhZmZpYyB0bw0KPiAgICAgYWNjaWRlbnRseSBoaXQgdGhpbmdzIGV4cGxpY2l0bHkg YXZvaWRlZC4NCj4NCj4gICAgIEkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgdGhhbiB0 aGlzLCBidXQgaXQgaXMgd2hhdCBpdCBpcy4NCj4NCj4gICAgIFRoYW5rcw0KPg0KPiAgICAgQW5k cmV3DQo+DQo+ICAgICAqRnJvbToqIHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZz4+ICpPbiBCZWhhbGYgT2YgKkpvZWwgTS4gSGFscGVybg0KPiAgICAgKlNl bnQ6KiBNb25kYXksIDMgQXVndXN0IDIwMjAgMjE6MzYNCj4gICAgICpUbzoqIFJvYmVydCBSYXN6 dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4gPG1haWx0bzpy b2JlcnRAcmFzenVrLm5ldD4+DQo+ICAgICAqQ2M6KiBzcHJpbmdAaWV0Zi4ub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi4ub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICpTdWJqZWN0 OiogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcNCj4gYXBwbGlj YWJpbGl0eQ0KPg0KPiAgICAgKFNpbmNlIHRoZSB0aHJlYWQgaGFzIGdvdHRlbiBsb25nIGVub3Vn aCwgcmVpdGVyYXRpbmcgdGhhdCB0aGlzIGlzIGFzIGENCj4gICAgIHBhcnRpY2lwYW50LCBub3Qg YSBXRyBjaGFpci4pDQo+DQo+ICAgICBZZXMsIHdlIGFyZSB0YWxraW5nIElQIG5ldHdvcmtzLiBB bmQgeWVzLCBJIGhhdmUgc2VlbiBJUCBuZXR3b3JrcyB0aGF0DQo+ICAgICBjaG9vc2UgdG8gZHJv cCBwYWNrZXRzLiBGb3IgYWxsIHNvcnRzIG9mIHJlYXNvbnMuDQo+ICAgICBJIHRoaW5rIHRoZXJl IGFyZSBsaWtlbHkgb3RoZXIgcmVhc29ucyB3aHkgb25lIG1heSBub3Qgd2FudCBhIHJhbmRvbQ0K PiAgICAgcGF0aCByYXRoZXIgdGhhbiBhIGNob3NlbiBURSBwYXRoLiBJIHRoaW5rIGl0IGlzIGlt cG9ydGFudCB3ZSBiZSBjbGVhcg0KPiAgICAgYWJvdXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUg LyBhcmUgdmlvbGF0ZWQgd2hlbiB3ZSB0ZWxsIHBlb3BsZSB0aGV5DQo+ICAgICBoYXZlIHRoaXMg dG9vbCAocHJvdGVjdGl2ZSByZXJvdXRpbmcpIHRoYXQgaXMgaW50ZW5kZWQgdG8gcHJlc2VydmUg UW9TLg0KPg0KPiAgICAgTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlz IGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQgaXMgYQ0KPiAgICAgZ29vZCBpZGVhLiBBbmQgdXNlZnVs LiBJIGFtIHRyeWluZyB0byBmaWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2YNCj4gICAgIGFk ZGl0aW9uYWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBl dmVyeW9uZQ0KPiAgICAgZ2V0dGluZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1h eSBub3QgYmUgdGhlIGJlaGF2aW9yIHRoZXkNCj4gICAgIGRlc2lyZSwgYnV0IHNvbWV0aW1lcyBp cyB0aGUgYmVzdCB3ZSBjYW4gZG8uKQ0KPg0KPiAgICAgWW91cnMsDQo+ICAgICBKb2VsDQo+DQo+ ICAgICBPbiA4LzMvMjAyMCAyOjMwIFBNLCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KPiAgICAgID4g Sm9lbCwNCj4gICAgICA+DQo+ICAgICAgPiBBcmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBu ZXR3b3JrcyBoZXJlID8gT3IgcGVyaGFwcyBzb21lIGhhcmQNCj4gICAgICA+IHNsaWNpbmcgd2l0 aCByZWFsIHJlc291cmNlIHJlc2VydmF0aW9ucyBvciBkZXRuZXRzID8NCj4gICAgICA+DQo+ICAg ICAgPiBCZWNhdXNlIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtpbmcgSSBoYXZl IHR3bw0KPiAgICAgb2JzZXJ2YXRpb25zOg0KPiAgICAgID4NCj4gICAgICA+IEEpIElmIHlvdSBu ZWVkIHRvIHRyYXZlcnNlIHZpYSBhIHNwZWNpZmljIG5vZGUgKGllLiBmaXJld2FsbCkgeW91DQo+ ICAgICBiZXR0ZXINCj4gICAgICA+IGFwcGx5IElQIGVuY2Fwc3VsYXRpb24gdG8gdGhhdCBub2Rl Li4gSSBkb24ndCB0aGluayBJUA0KPiAgICAgZW5jYXBzdWxhdGlvbiBjYW4NCj4gICAgICA+IGJl IGhpamFja2VkIHRvZGF5IHN1Y2ggdGhhdCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBwYWNr ZXQgaXMNCj4gICAgIGlnbm9yZWQuDQo+ICAgICAgPg0KPiAgICAgID4gQikgSGF2ZSB5b3Ugc2Vl biBhbnkgSVAgbmV0d29yayB3aGVyZSB1cG9uIHRvcG9sb2d5IGNoYW5nZSAobGluaw0KPiAgICAg b3Igbm9kZQ0KPiAgICAgID4gZmFpbHVyZSkgeW91IHN1ZGRlbmx5IHN0YXJ0IGRyb3BwaW5nIGZs b3dzIGluIHNwaXRlIG9mIFNQVCBvZmZlcmluZw0KPiAgICAgID4gcGVyaGFwcyBmZXcgbXMgbG9u Z2VyIHBhdGggd2l0aCAxMCBtcyBtb3JlIGppdHRlciA/DQo+ICAgICAgPg0KPiAgICAgID4gT3Ig YXJlIHNvbWUgU1IgbWFya2V0aW5nIHNsaWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3Mg aW4NCj4gICAgICA+IHNvbWV0aGluZyBuZXcgPyBXb3JzZSAuLi4gZG8gdGhleSBtZW50aW9uIHBh dGggcXVhbGl0eSBndWFyYW50ZWVzLA0KPiAgICAgID4gcmVzb3VyY2UgcmVzZXJ2YXRpb25zID8g SSBob3BlIG5vdC4NCj4gICAgICA+DQo+ICAgICAgPiBUaHgsDQo+ICAgICAgPiBSLg0KPiAgICAg ID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAg ICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4gT24gTW9uLCBBdWcgMywgMjAyMCBh dCA4OjEwIFBNIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tJTBiPj4gICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUy MCUwYj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KPiAgICAgID4NCj4g ICAgICA+IFdlbGwgbGVzcyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRoZSBw cm9ibGVtIGlzDQo+ICAgICByZXN0cmljdGVkDQo+ICAgICAgPiB0byBqdXN0IHNlcnZpY2UgU0lE cy4NCj4gICAgICA+DQo+ICAgICAgPiBTdXBwb3NlIHRoYXQgdGhlIFBDRSBoYXMgc3BlY2lmaWVk IHRoZSBwYXRoIHRvIG1lZXQgc29tZSBjb21wbGV4IHRlDQo+ICAgICAgPiBvYmplY3RpdmUuICBU aGUgYnlwYXNzIG5vZGUgaGFzIG5vIHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2UNCj4gICAgICA+ IGNvbnN0cmFpbnRzDQo+ICAgICAgPiB3ZXJlLiAgQW5kIGZvciBzb21lIGtpbmRzIG9mIHRyYWZm aWMsIGl0IGlzIGJldHRlciB0byBkcm9wIHRoZSBwYWNrZXQNCj4gICAgICA+IHRoYW4gdG8gZGVs aXZlciBpdCBvdXRzaWRlIHRoZSBlbnZlbG9wLiAgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0DQo+ ICAgICAgPiBhbnN3ZXINCj4gICAgICA+IHRvIHRoaXMgaXMgInRvbyBiYWQiLiAgSWYgc28sIGFz IHdpdGggdGhlIGRpc3RpbmN0aW9uIHJlZ2FyZGluZw0KPiAgICAgc2VydmljZQ0KPiAgICAgID4g bm9kZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT8NCj4gICAgICA+DQo+ICAgICAg PiBZb3VycywNCj4gICAgICA+IEpvZWwNCj4gICAgICA+DQo+ICAgICAgPiBPbiA4LzMvMjAyMCAy OjM2IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gICAgICA+ID4gTWFjaCwgSm9l bCBhbmQgYWxsLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJIHRoaW5rIHRoYXQgaW4gbW9zdCBj YXNlczoNCj4gICAgICA+ID4NCj4gICAgICA+ID4gMS5UaGVyZSBpcyBjbGVhciBkaWZmZXJlbnRp YXRpb24gYmV0d2VlbiAidG9wb2xvZ2ljYWwiIGFuZA0KPiAgICAgInNlcnZpY2UiDQo+ICAgICAg PiA+IGluc3RydWN0aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46DQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+IG9JR1AgUHJlZml4IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZp ZWQgYXMgc3VjaCBpbiB0aGUNCj4gICAgICA+ID4gY29ycmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNl bWVudHMpIHJlcHJlc2VudCB0b3BvbG9naWNhbA0KPiAgICAgaW5zdHJ1Y3Rpb25zDQo+ICAgICAg PiA+DQo+ICAgICAgPiA+IG9TZXJ2aWNlIFNJRHMgZm9yIFNSdjYgKHNlZSBTUnY2IEJHUC1CYXNl ZCBPdmVybGF5IFNlcnZpY2VzDQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgPGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ0NjeTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBz JTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1i ZXNzLXNydjYtc2VydmljZXMtMDQNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0ND Y3k5bVk2Y01mYms3UWZqaGlBM1I2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0JTBiPj4g ICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dDNWFmMnozSnpwaFpEa1BuY0hB UWk2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJG ZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYt c2VydmljZXMtMDRfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0 UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNFQtTDBubCUyND4+DQo+ICAgICAg Pg0KPiAgICAgID4gPiBkcmFmdCkgdW5zdXJwcmlzaW5nbHkgcmVwcmVzZW50IOKAnHNlcnZpY2Xi gJ0gaW5zdHJ1Y3Rpb25zDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IDIuU2VnbWVudHMgdGhhdCBy ZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCwNCj4gICAg ICA+ID4gd2hpbGUgc2VnbWVudHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMg cmVxdWlyZQ0KPiAgICAgID4gYWx0ZXJuYXRpdmUNCj4gICAgICA+ID4gcHJvdGVjdGlvbiBtZWNo YW5pc21zLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBUaGlzIHZpZXcgc2VlbXMgdG8gYmUgYWxp Z25lZCB3aXRoIFJGQyA4NDAyDQo+ICAgICAgPiA+IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vMzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmll dGYub3JnJTJGaHRtbCUyRnJmYzg0MDINCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v MzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRnJmYzg0MDIlMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zN1B6VUtBRDgyY2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5j b20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyX18l M0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9a SGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJNFlidG0lMjQ+Pg0KPiAgICAgdGhhdCBzYXlzIGluIFNl Y3Rpb24gMToNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIEluIHRoZSBjb250ZXh0IG9mIGFu IElHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28NCj4gICAgICA+ID4NCj4g ICAgICA+ID4gdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNl bmN5IHNlZ21lbnQgYW5kIHRoZQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSUdQLVByZWZp eCBzZWdtZW50Lg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSW4gdGhlIGNvbnRleHQgb2Yg YSBCR1AtYmFzZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwgdHdvDQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJp bmcgc2VnbWVudCBhbmQgdGhlDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBCR1AtUHJlZml4 IHNlZ21lbnQuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMg dGhpcyBkaWZmZXJlbnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uDQo+ICAgICAgPiAzLjQg b2YNCj4gICAgICA+ID4gdGhlIE5vZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aA0KPiAgICAg ID4gPg0KPiAgICAgID4NCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0pi U1dHeDVEQWZOUHNaZGhwRXh4eDk2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9y LXNyLXRlLXBhdGhzLTA3JTIzc2VjdGlvbi0zLjQNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vM0piU1dHeDVEQWZOUHNaZGhwRXh4eDk2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFj a2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3Rl Y3Rpb24tZm9yLXNyLXRlLXBhdGhzLTA3JTIzc2VjdGlvbi0zLjQlMGI+PiAgICAgPGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91PWh0dHBz JTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5p ZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9u LWZvci1zci10ZS1wYXRocy0wNyUyQXNlY3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdr JTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1 aURvOXdPLVNzbiUyND4+DQo+ICAgICAgPg0KPiAgICAgID4gPiBkcmFmdCB0aGF0IHNheXM6DQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBUaGUgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbSBk ZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzDQo+ICAgICBzZWN0aW9ucw0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgICAgZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBsYWJlbCBpbW1l ZGlhdGVseSBiZWxvdw0KPiAgICAgID4gdGhlIHRvcA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBs YWJlbCBpbiB0aGUgbGFiZWwgc3RhY2sgaXMgdW5kZXJzdG9vZCBpbiB0aGUgSUdQIGRvbWFpbi4g IFdoZW4gdGhlDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBwcm92aWRlciBlZGdlIHJvdXRl cnMgZXhjaGFuZ2Ugc2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBzb21lDQo+ICAgICAgPiBvdGhl cg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgbm9uLUlHUCBtZWNoYW5pc20gdGhlIGJvdHRv bSBsYWJlbCBpcyBub3QgdW5kZXJzdG9vZCBpbiB0aGUgSUdQDQo+ICAgICAgPiA+DQo+ICAgICAg PiA+ICAgICBkb21haW4uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBUaGUgZWdyZXNzIG5v ZGUgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQNCj4gICAgICA+ ID4NCj4gICAgICA+ID4gICAgIFtSRkM4Njc5IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vM0pmdnRCQW1hUVBOMWpBM3BNNlRkQ0U2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2Vy LmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRnJmYzg2NzkNCjxodHRwczovL2NsaWNrdGltZS5zeW1h bnRlYy5jb20vM0pmdnRCQW1hUVBOMWpBM3BNNlRkQ0U2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRnJmYzg2NzklMGI+PiAgICAgPGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmRNQWp1WVRRb3ZvOGpId21tM2VKdzZIMj91PWh0dHBz JTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5p ZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMw WXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzhN R2lwWGMlMjQ+Pl0NCj4gICAgIGlzDQo+ICAgICAgPiA+IGFwcGxpY2FibGUgdG8gdGhpcyB1c2Ug Y2FzZSBhbmQgbm8gYWRkaXRpb25hbCBjaGFuZ2VzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAg ICB3aWxsIGJlIHJlcXVpcmVkIGZvciBTUiBiYXNlZCBuZXR3b3Jrcw0KPiAgICAgID4gPg0KPiAg ICAgID4gPiBUaGUgc2NlbmFyaW9zIGluIHdoaWNoICBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiDi gJx0b3BvbG9naWNhbOKAnSBhbmQNCj4gICAgICA+ID4g4oCcc2VydmljZeKAnSBpbnN0cnVjdGlv bnMgaXMgYnJva2VuIGFyZSBpbmRlZWQgcHJvYmxlbWF0aWMuIEUuZy4sDQo+ICAgICAgPiBjb25z aWRlcg0KPiAgICAgID4gPiB0aGUgdXNlIGNhc2UgaW4gd2hpY2ggYSBOb2RlIFNJRCBpbiB0aGUg RVJPIG9mIGEgU1ItVEUgcGF0aA0KPiAgICAgID4gaWRlbnRpZmllcyBhDQo+ICAgICAgPiA+IG5v ZGUgdGhhdCBhY3RzIGFzIGEgZmlyZXdhbGwgZm9yIGFsbCBwYWNrZXRzIGl0IHJlY2VpdmVzLCBp LmUuLA0KPiAgICAgID4gcHJvdmlkZXMNCj4gICAgICA+ID4gdGhlIGZpcmV3YWxsIHNlcnZpY2Ug d2l0aG91dCBhbnkgZGVkaWNhdGVkIHNlcnZpY2UgU0lEDQo+ICAgICAgPiBpZGVudGlmeWluZyBp dC4NCj4gICAgICA+ID4gT25lIGNvdWxkIHNheSB0aGF0IHRoZSBOb2RlIFNJRCBvZiBzdWNoIGEg bm9kZSB3b3VsZCBjb21iaW5lDQo+ICAgICAgPiB0b3BvbG9naWNhbA0KPiAgICAgID4gPiBhbmQg c2VydmljZSBpbnN0cnVjdGlvbnMgdGh1cyBicmVha2luZyB0aGUgZGlmZmVyZW50aWF0aW9uDQo+ ICAgICAgPiBiZXR3ZWVuIHRoZSB0d28uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgYW0gbm90 IHN1cmUgaWYgdXNhZ2Ugb2Ygc3VjaCDigJxjb21iaW5lZOKAnSBTSURzIGNvdWxkIGJlIHByZXZl bnRlZA0KPiAgICAgID4gb3IgYXQNCj4gICAgICA+ID4gbGVhc3QgZGlzY291cmFnZWQuDQo+ICAg ICAgPiA+DQo+ICAgICAgPiA+IElmIG5vdCwgcHJvdmlkaW5nIGFuIGFiaWxpdHkgdG8gaWRlbnRp Znkgc3VjaCBTSURzIGluIHRoZQ0KPiAgICAgID4gYWR2ZXJ0aXNlbWVudA0KPiAgICAgID4gPiBt ZWNoYW5pc21zIHdvdWxkIGJlIHVzZWZ1bCBJTUhPLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBN eSAyYywNCj4gICAgICA+ID4NCj4gICAgICA+ID4gU2FzaGENCj4gICAgICA+ID4NCj4gICAgICA+ ID4gT2ZmaWNlOiArOTcyLTM5MjY2MzAyDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IENlbGw6ICAg ICAgKzk3Mi01NDkyNjYzMDINCj4gICAgICA+ID4NCj4gICAgICA+ID4gRW1haWw6IEFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4NCj4gICAgIDxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ DQo+ICAgICAgPiA8bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPiAg ICAgID4gPg0KPiAgICAgID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgICAgID4g PiBGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnJTBiPj4gICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcl MGI+Pg0KPiAgICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBP ZiBNYWNoIENoZW4NCj4gICAgICA+ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMw IEFNDQo+ICAgICAgPiA+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20N CjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYj4+ICAgICA8bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20lMGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PjsNCj4gICAgIHNwcmlu Z0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9y Zz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA+IFN1YmplY3Q6IFJlOiBbc3By aW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4gICAg ICA+ID4NCj4gICAgICA+ID4gSGkgSm9lbCwNCj4gICAgICA+ID4NCj4gICAgICA+ID4gSSB0aGlu ayB0aGlzIGlzIGEgZ29vZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZQ0K PiAgICAgID4gcGFzdC4gQW5kDQo+ICAgICAgPiA+IEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSBp cyBhICJjYW4gYmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlDQo+ICAgICAgPiA+IHJvdXRp bmcgYWR2ZXJ0aXNlbWVudCBmb3Igbm93Lg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJTUhPLCB0 aGUgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBieSByb3V0aW5nIGlzIG5ldXRyYWwsIHN1Y2gNCj4g ICAgICA+IGluZm9ybWF0aW9uDQo+ICAgICAgPiA+IChjYW4gb3IgY2Fubm90IGJlIGJ5cGFzc2Vk KSBpcyBtb3JlIHBhdGggc3BlY2lmaWMsIHRodXMNCj4gICAgIG5vcm1hbGx5IHRoZQ0KPiAgICAg ID4gPiBjb250cm9sbGVyIHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhl ci93aGljaCBTSUQNCj4gICAgICA+IGNhbiBiZQ0KPiAgICAgID4gPiBieXBhc3NlZC4NCj4gICAg ICA+ID4NCj4gICAgICA+ID4gQmVzdCByZWdhcmRzLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBN YWNoDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgICA+ IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ICAgICA8bWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnJTBiJTNlJTIwJTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn JTNlPl0NCj4gICAgIE9uIEJlaGFsZiBPZiBKb2VsIE0uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICA+IEhhbHBlcm4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gU2VudDogTW9uZGF5LCBBdWd1 c3QgMywgMjAyMCA3OjUxIEFNDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFRvOiBzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ DQo+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+IDxtYWlsdG86c3ByaW5n QGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnPj4+DQo+ICAgICAgPiA+DQo+ICAgICAg PiA+ICA+IFN1YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcg YXBwbGljYWJpbGl0eQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgPiAoV0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20g YSBzbGlnaHRseQ0KPiAgICAgID4gY29uZnVzZWQgV0cNCj4gICAgICA+ID4NCj4gICAgICA+ID4g ID4gcGFydGljaXBhbnQuKQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0K PiAgICAgID4gPiAgPiBJIGhhdmUgYmVlbiByZWFkaW5nIHRoZSB2YXJpb3VzIHJlcGFpciBkcmFm dHMsIGFuZCB0aGUgdmFyaW91cw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBuZXR3b3JrcyBw cm9ncmFtbWluZyBhbmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW0NCj4gICAg ICA+IHRyeWluZyB0bw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBmaWd1cmUgb3V0IG9uZSBh c3BlY3Qgb2YgdGhlIGNvbWJpbmF0aW9uLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAg ICAgID4gPg0KPiAgICAgID4gPiAgPiBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21l IGZvcm0gb2YgYnlwYXNzIChzdXBwb3NlLCBmb3INCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4g c2ltcGxpY2l0eSwgaXQgaXMgTm9kZSBOMiBkZWNpZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lE IGZvcg0KPiAgICAgID4gYSBmYWlsZWQNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gbm9kZSBO Mykga25vdyB0aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IElmIHRoZSBwYXRoIHdhcyBqdXN0IGZvciBU RSwgdGhlbiBpdCBpcyAic2FmZSIgaWYgdGhlIG5ldyBwYXRoDQo+ICAgICAgPiBtZWV0cw0KPiAg ICAgID4gPg0KPiAgICAgID4gPiAgPiB0aGUgVEUgY3JpdGVyaWEuICBvciBtYXliZSBpdCBpcyBz YWZlIGlmIGl0IGlzIGV2ZW4gY2xvc2UsIGFzDQo+ICAgICAgPiBsb25nIGFzDQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+ICA+IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy4NCj4gICAgICA+ID4N Cj4gICAgICA+ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gQnV0IHdoYXQgaWYgdGhl IG5vZGUgd2VyZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsDQo+ICAgICAgPiA+ IHJlcXVpcmVtZW50cz8NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gT3Igd2FzIHNvbWUgb3Ro ZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0cmFuc2Zvcm0gKHdpbmNlIHdlIGFyZQ0KPiAgICAg ID4gPg0KPiAgICAgID4gPiAgPiBkZWxpYmVyYXRlbHkgdmFndWUgYWJvdXQgd2hhdCBub2RlcyBj YW4gZG8gd2hlbiBhc2tlZCBzdWl0YWJseS4pDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IElzIHRoZXJlIHNvbWUgImNhbiBiZSBieXBhc3NlZCIg aW5kaWNhdGlvbiBpbiB0aGUgcm91dGluZw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBhZHZl cnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAg ICAgID4gPg0KPiAgICAgID4gPiAgPiBUaGFuayB5b3UsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICA+IFlvdXJzLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBKb2VsDQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+ IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcl MjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiPj4gICAgIDxtYWlsdG86c3ByaW5nQGlldGYu b3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+Pg0KPiAgICAgID4gPg0KPiAgICAgID4g PiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMl M0ElMjUyPg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTd2WDJxV1NV ZFdWYzg5Mlh1WHkySDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9f aHR0cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2 UDQ2SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZ dXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNkh3 UExpbCUyND4NCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyDQo8 aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0Nkgy P3U9aHR0cHMlM0ElMjUyJTBiPj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v M0E1QjhIMkZtMXJQbmFaM1N1cGp3cjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6 Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTI1Ml9fJTNCSlNVJTIxJTIxTkV0NnlN YU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhB a1RSRHVpRG96b1FpQUhrJTI0Pj4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gRiUyRnd3dy5p ZXRmLm9yZzxodHRwOi8vMkZ3d3cuaWV0Zi5vcmc+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1 cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUy MU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZw UkhPR3Q4QWtUUkR1aURvLXBQQ2p2UiUyND4NCj4gICAgICA+IDxodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vM0dXVDlmeWphRmkzRmN2SER2b29kdlM2SDI/dT1odHRwJTNBJTJGJTJGMkZ3 d3cuaWV0Zi5vcmcNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dXVDlmeWphRmkz RmN2SER2b29kdlM2SDI/dT1odHRwJTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmclMGI+PiAgICAgPGh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91 PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3Lmll dGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQ+PiUyRm1haWxtYW4lMkZs aXN0aW5mbyUyRnNwcmluZw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBz cHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAg IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAg Pg0KPiAgICAgaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdD NGVBdlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZzcHJpbmcNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0JoeUV0 eDRRN243NEJoaVJuZk1KdFQ2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMl MkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdD NGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyRiUyQTJGd3d3LmlldGYub3JnJTJBMkZtYWls bWFuJTJBMkZsaXN0aW5mbyUyQTJGc3ByaW5nX18lM0JKU1VsSlNVbCUyMSUyMU5FdDZ5TWFPLWdr JTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1 aURvLWhSM2dBRCUyND4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4gICAg ICA+ID4NCj4gICAgICA+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICA+ID4gTm90aWNl OiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0K PiAgICAgID4gPiBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0 IGlzIGNvbmZpZGVudGlhbA0KPiAgICAgID4gYW5kL29yDQo+ICAgICAgPiA+IHByb3ByaWV0YXJ5 IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywN Cj4gICAgICA+ID4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVy cyBvciBmb3J3YXJkaW5nDQo+ICAgICB3aXRob3V0DQo+ICAgICAgPiA+IGV4cHJlc3MgcGVybWlz c2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4gICAgICA+ IGludGVuZGVkDQo+ICAgICAgPiA+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwNCj4gICAgICA+ID4gY29waWVzLCBpbmNs dWRpbmcgYW55IGF0dGFjaG1lbnRzLg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0 DQo+ICAgICAgPiA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA+ IGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZI Mj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3By aW5nDQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcx Rzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRw cyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIx JTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2 dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Pg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAg ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAg ICAgPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5n QGlldGYub3JnPg0KPiAgICAgID4gaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhz S0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWls bWFuJTJGbGlzdGluZm8lMkZzcHJpbmcNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVu c2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFB dFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQ+DQo+ICAgICAg Pg0KPg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgIHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIGh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0 dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+ DQo+IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdF cTE2SDI/dT1odHRwcyUzQSUNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5T VFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyNSUwYj4+IDJGJTJGdXJsZGVmZW5zZS5j b20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmc8aHR0cDovLzJGd3d3LmlldGYub3Jn PiUyRm1haWxtYW4lMkZsaXN0aQ0KPiBuZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdr JTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1DQo+IG9aSGd3cDZ2cFJIT0d0OEFr VFJEdWlEbzVLbFBuYmolMjQ+DQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gTm90 aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFp bg0KPiBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNv bmZpZGVudGlhbCBhbmQvb3INCj4gcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LA0KPiBkaXNjbG9zdXJlLCByZWxpYW5jZSBv ciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dA0KPiBleHByZXNz IHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkDQo+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCB0aGVuIGRlbGV0ZSBhbGwNCj4gY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz Lg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z UTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v M1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1l bnRzIG1heSBjb250YWluIGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMu IHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNl IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIGRpc2Nsb3N1cmUsIHJlbGlh bmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0IGV4cHJl c3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHRoZW4gZGVsZXRlIGFsbCBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo= --_000_MW3PR11MB4570250AC1693BD65241A638C1400MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tSU4iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgUm9iZXJ0LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSBk byBub3QgaGF2ZSBhIHNpZ25hbGxpbmcgbWVjaGFuaXNtIGluIElHUHMgdG9kYXkgdG8gaW5kaWNh dGUgYSDigJxieXBhc3MtYWJsZeKAnSBpbmRpY2F0aW9uIGZvciBQcmVmaXggU0lEcy4gSWYgdGhl cmUgd2FzIGEgZGVzaXJlIGZvciBpdCwgYW4gSUdQIGV4dGVuc2lvbiB3b3VsZCBiZSByZXF1aXJl ZCAodGhlcmUgaXMgbm9uZSBpbiBwcm9ncmVzcw0KIEFGQUlLKS4gTm90ZSB0aGF0IHRoaXMgcmVz dWx0cyBpbiBkb3VibGluZyB0aGUgcHJlZml4IFNJRCBzY2FsZSAoZ2xvYmFsIGxhYmVscykgaW4g dGhlIG5ldHdvcmsuIFNvIEkgd291bGQgbm90IGdvIGFib3V0IHRoaXMgdHJpdmlhbGx5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5JIHRoaW5rIGl0IGhlbHBzIHRvIGdldCBtb3JlIGlucHV0cyBhbmQgcGVyc3BlY3RpdmVzIGZy b20gb3BlcmF0b3JzIG9uIHRoZWlyIHZpZXdzIGZvciBkb2luZyBhIGJ5cGFzcyB2aWEgbG9jYWwg cHJvdGVjdGlvbiBmb3Igc2VnbWVudHMgaW4gYW4gU1IgUG9saWN5LiBUaGVyZSBtYXkgYmUgdGhv c2UgdGhhdCBwcmVmZXIgZW5kLXRvLWVuZA0KIHBhdGggcHJvdGVjdGlvbiB1c2luZyBhIGZhbGxi YWNrIHBhdGggdGhhdCBpcyBzYXkgZGlzam9pbnQgd2l0aCB0aGUgcHJpbWFyeSBidXQgcHJvdmlk ZXMgYW4gYXBwcm9wcmlhdGUgU0xBL2ludGVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+S2V0YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiPiBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDsNCjxi cj4NCjxiPlNlbnQ6PC9iPiAxNCBBdWd1c3QgMjAyMCAyMzowNDxicj4NCjxiPlRvOjwvYj4gS2V0 YW4gVGFsYXVsaWthciAoa2V0YW50KSAmbHQ7a2V0YW50QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDtBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJu LmNvbSZndDs7IEpvZWwgTS4gSGFscGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7IFNo cmFkZGhhIEhlZ2RlICZsdDtzaHJhZGRoYUBqdW5pcGVyLm5ldCZndDs7IEVYVC1BbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tICZsdDtBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29t Jmd0Ozsgc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBT cHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktldGFuLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va3MgbGlrZSB3ZSBhcmUgcHJldHR5IG11 Y2ggaW4gc3luYyBoZXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgbGV0IG1lIGp1c3Qgb2JzZXJ2ZSB0aGF0IEkgcHVycG9z ZWx5Jm5ic3A7ZGlkIG5vdCBtZW50aW9uIGFib3V0IFNSIHBvbGljaWVzIGFzIHdlIGFyZSBub3Qg YWJsZSB0byBzaWduYWwgdGhlIGludGVudCB3aXRoIHRoZSBwYWNrZXRzIGl0c2VsZi4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28g YWxsIHdlIGhhdmUgdGhlcmUgaXMgU0lEcy4gQlNJRHMgb3IgcHJlZml4IFNJRHMgbmVlZCB0byBi ZSBmbG9vZGVkIHdpdGggaW5mb3JtYXRpb24gaWYgcG9saWNpZXMgYnVpbGQgd2l0aCB1c2luZyB0 aGVtIGFyZSBieXBhc3MgZWxpZ2libGUgb3Igbm90LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBhY3R1YWxseSB1bmRlciB0 aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMgaXMgYWxyZWFkeSB0aGVyZSBhbmQgSSBhbSBqdXN0IG5v dCBhd2FyZSwgYnV0IGxvb2tpbmcgZGVlcGVyIGluZGVlZCBJIGRvIG5vdCBzZWUgdGhpcyBtYXJr aW5nIG5laXRoZXIgaW4gSVNJUyBub3IgT1NQRiBmb3IgcHJlZml4IFNJRHMuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoZXJl IHNvbWUgd29yayBpbiBwcm9ncmVzcyB0byBhZGQgaXQgdG8gdGhvc2UgcHJvdG9jb2xzIG9yIGhh dmUgd2UganVzdCBkb2N1bWVudGVkIG5lZWQmbmJzcDtmb3IgYSBzaG9ydCBMU1IgZHJhZnQmbmJz cDsgPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaHgsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEZyaSwgQXVnIDE0LCAyMDIwIGF0IDY6MTcgUE0gS2V0YW4gVGFsYXVsaWth ciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudEBjaXNjby5jb20iPmtldGFudEBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBSb2JlcnQsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJvYmVydCBS YXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxNCBBdWd1 c3QgMjAyMCAyMToxMzxicj4NCjxiPlRvOjwvYj4gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5rZXRh bnRAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEFsZXhhbmRlciBWYWluc2h0ZWlu ICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20iIHRhcmdl dD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbTwvYT4mZ3Q7OyBKb2VsIE0u IEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9 Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7OyBTaHJhZGRoYSBIZWdkZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+c2hy YWRkaGFAanVuaXBlci5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25A bGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgS2V0YW4s PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpbGUg SSBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91ciBub3RlIHRoZSBjb25zZXF1ZW5jZXMgb2YgaXQg YXJlIHByZXR0eSBzZXZyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PGk+W0tUXSBJIHVuZGVyc3RhbmQuIFdlIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiBp bXBsaWNhdGlvbnMgb2YgcHJvdGVjdGlvbiBzY2hlbWVzIGZvciB0aGUgU0xBcy9pbnRlbnQgb2Yg U1IgUG9saWNpZXMuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlVubGVzcyB3ZSBzaWduYWwgd2hpY2ggcHJlZml4IFNJRCBp cyBwcm90ZWN0aW9uIGVsaWdpYmxlIGFuZCB3aGljaCBpcyBub3QgaG93IHdvdWxkIG90aGVyIG5v ZGVzIGtub3cgaWYgdGhleSBjYW4gcHJvdGVjdCBpdCBvciBub3QgPyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5bS1RdIENvcnJlY3QuIFRvIGJlIG1v cmUgYWNjdXJhdGUsIHdlIG5lZWQgdG8gY29uc2lkZXIgdGhpcyBtb3JlIGluIHRoZSBjb250ZXh0 IG9mIFNMQSBvciDigJxpbnRlbnTigJ0gb2YgU1IgUG9saWNpZXMgYW5kIHdoaWNoIHNlZ21lbnRz IG1heSBiZSDigJxieXBhc3MtYWJsZeKAnSBmb3IgbG9jYWwgcHJvdGVjdGlvbg0KIGZvciBzb21l IG9mIHRob3NlIFNSIFBvbGljaWVzLiBXZSBhbHNvIGhhdmUgcGF0aC1wcm90ZWN0aW9uIG1lY2hh bmlzbXMuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkl0IHNlZW1zIHRoYXQgdG9kYXkncyBzYWZlIHRoaW5nIGlzIG5vdCB0 byBhcHBseSBhbnkgbm9kZSBwcm90ZWN0aW9uIG9uIFNSIGZsb3dzIGF0IHRoZSBQTFJzIHRoZW4u Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5BbmQgbGluayBwcm90ZWN0aW9uIE1VU1QgYXNzdXJlIHRoYXQgcGFja2V0cyB3aWxs IGFycml2ZSBhdCB0aGUgbmVpZ2hib3Igbm9kZSB2aWEgc29tZSBvdGhlciBsaW5rIHJlZ2FyZGxl c3Mgb2YgZnVydGhlciBwYXRoIHRvd2FyZHMgZGVzdGluYXRpb24uJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPltLVF0gWWVzLiBXZSBoYXZlIGEgbWVj aGFuaXNtIHRvIGluZGljYXRlIHdoaWNoIGFkai1TSURzIGhhdmUgcHJvdGVjdGlvbiAodGhhdCBt ZWNoYW5pc20gb25seSBwcm92aWRlcyBsaW5rIHByb3RlY3Rpb24gdG8gZ2V0IHRvIHRoZSBuZWln aGJvciBub2RlKSBzbyB0aGUgU1IgUG9saWN5IGNvbXB1dGF0aW9uDQogaXMgYWJsZSB0byBpbmRp Y2F0ZSB3aGV0aGVyIHRoYXQgc3BlY2lmaWMgbGluayBpcyDigJxieXBhc3MtYWJsZeKAnSBvciBu b3QgYnkgaXRzIGNob2ljZSBvZiBwcm90ZWN0ZWQgb3IgdW5wcm90ZWN0ZWQgYWRqLVNJRHMgcmVz cGVjdGl2ZWx5LjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxpPlRoYW5rcyw8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48aT5LZXRhbjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JcyBpdCBjb3JyZWN0ID8mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoeDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBGcmksIEF1ZyAxNCwgMjAyMCBhdCA1OjMyIFBNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkg Jmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0 YW50QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBTYXNoYSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZSBzZXJ2aWNlIG5vZGUgYWR2ZXJ0aXNlcyBpdHMgb3duIFByZWZpeCBTSUQuIFRo ZSBzZXJ2aWNlIGZ1bmN0aW9uIHRoYXQgdGhpcyBzZXJ2aWNlIG5vZGUgaW1wbGVtZW50cyBkb2Vz IG5vdCByZXF1aXJlIGFueSBjb250ZXh0IChpLmUuIGFsbCBwYWNrZXRzIGFycml2aW5nIGF0IHRo ZSBub2RlIGFyZSBzdWJqZWN0ZWQNCiB0byB0aGF0IHNlcnZpY2UpLiBUaGVyZWZvcmUgdGhlIHNl cnZpY2Ugbm9kZSBkb2VzIG5vdCBuZWVkIHRvIHJlY2VpdmUgYSBwYWNrZXQgd2l0aCBpdOKAmXMg b3duIFByZWZpeCBTSUQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRodXMsIHdlIGNh bm5vdCBhc3N1bWUgdGhhdCB3aGVuIFBIUCBpcyB1c2VkLCB0aGVuIHRoZSBTSUQgaXMgb25seSBh c3NvY2lhdGVkIHdpdGggYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhvcGUgdGhhdCBjbGFyaWZpZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPktldGFu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AcmJibi5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVp bkByYmJuLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXVndXN0IDIwMjAgMjA6 MjQ8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9 Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50QGNpc2NvLmNv bTwvYT4mZ3Q7OyBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7OyBT aHJhZGRoYSBIZWdkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0IiB0 YXJnZXQ9Il9ibGFuayI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFp bHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBSYXN6dWsgJmx0Ozxh IGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEBy YXN6dWsubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFw cGxpY2FiaWxpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5LZXRh biwgYW5kIGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+SSBoYXZlIHN0 YXRlZCB0aGF0LCBJTUhPIGFuZCBGV0lXLCBib3RoIEFkai1TSURzIGFuZCBQcmVmaXggU0lEcyB0 aGF0IGFyZSBhZHZlcnRpc2VkIHdpdGggUEhQIGNhbiZuYnNwOyBPTkxZIHJlcHJlc2VudCB0b3Bv bG9naWNhbCBpbnN0cnVjdGlvbnMgaW4gU1ItTVBMUyAtIGJlY2F1c2UgdGhlIGFkdmVydGlzaW5n IG5vZGUgd2lsbCBub3QgcmVjZWl2ZSB0aGVtIGFuZCB0aGVyZWZvcmUgY2FuIGhhcmRseSBiZQ0K IGV4cGVjdGVkIHRvIGFzc29jaWF0ZSBhbnkgc2VydmljZSBmdW5jdGlvbiB3aXRoIHRoZW0uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjojMjEyMTIxIj5UaGlzIGlzIGNvbXBsZW1lbnRhcnkgdG8gd2hhdCB5b3UgaGF2 ZSBzYWlkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+SG9wZSB0aGlzIGNsYXJpZmllcyBteSBwb3Np dGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+V2hhdCwgaWYgYW55dGhp bmcsIGRpZCBJIG1pc3M/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5SZWdhcmRzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5TYXNoYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgaWQ9ImdtYWlsLW1fLTE2OTk1MjI0MTk1NDYzMDA2NDNnbWFpbC1tXy01NzU2MDY1NDU1ODQz MjUwOTBtcy1vdXRsb29rLW1vYmlsZS1zaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+R2V0DQo8YSBocmVmPSJodHRwczovL2FrYS5tcy9naGVpMzYiIHRhcmdldD0iX2JsYW5r Ij5PdXRsb29rIGZvciBBbmRyb2lkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJnbWFpbC1tXy0xNjk5NTIyNDE5NTQ2MzAwNjQzZ21haWwtbV8tNTc1NjA2NTQ1NTg0MzI1MDkw aWQtNzNlMTM5NmMtNjE2ZS00YzQ1LTk4ZDEtMjU2NzgwZDAxNTNmIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUi IGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy0xNjk5NTIyNDE5NTQ2 MzAwNjQzZ21haWwtbV8tNTc1NjA2NTQ1NTg0MzI1MDkwZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+IEtldGFuIFRhbGF1 bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+a2V0YW50QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW50Ojwv c3Bhbj48L3N0cm9uZz4gRnJpZGF5LCBBdWd1c3QgMTQsIDIwMjAsIDE2OjIzPGJyPg0KPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Ubzo8L3NwYW4+PC9zdHJvbmc+IEFsZXhhbmRlciBWYWluc2h0ZWluOyBKb2VsIE0uIEhhbHBl cm47IFNocmFkZGhhIEhlZ2RlOw0KPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxp cXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb208L2E+OyBSb2JlcnQgUmFzenVrPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DYzo8L3NwYW4+PC9z dHJvbmc+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YmplY3Q6PC9zcGFuPjwvc3Ryb25n PiBSRTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmls aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0 ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50 ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5PVElDRTogVGhpcyBlbWFpbCB3 YXMgcmVjZWl2ZWQgZnJvbSBhbiBFWFRFUk5BTCBzZW5kZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSBTYXNoYSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklm IHRoZSBzZXJ2aWNlIGRvZXMgbm90IG5lZWQgYW55IGFkZGl0aW9uYWwgY29udGV4dCAoZS5nLiBh IGZpcmV3YWxsIHRoYXQganVzdCBhcHBsaWVzIGxvY2FsbHkgY29uZmlndXJlZCBkZWZhdWx0IHJ1 bGVzIG9uIGl0KSwgdGhlbiBJIGRvbuKAmXQgc2VlIHdoeSBQSFAgY291bGQgbm90IGJlIGRvbmUg Zm9yIGENCiBQcmVmaXggU0lEIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2Ugbm9kZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsc28sIEkgZGlkbuKAmXQgZm9sbG93IHRoZSBwb2ludCB0 aGF0IHlvdSB3ZXJlIHRyeWluZyB0byBtYWtlIGFib3V0IEFkai1TSURzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5LZXRhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVy LlZhaW5zaHRlaW5AcmJibi5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE0IEF1Z3Vz dCAyMDIwIDE4OjI0PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZs dDs8YSBocmVmPSJtYWlsdG86a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFu dEBjaXNjby5jb208L2E+Jmd0OzsgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208 L2E+Jmd0OzsgQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5k ZXIuVmFpbnNodGVpbkByYmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0 ZWluQHJiYm4uY29tPC9hPiZndDs7DQogU2hyYWRkaGEgSGVnZGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpzaHJhZGRoYUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNocmFkZGhhQGp1bmlwZXIu bmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20u Y29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4m Z3Q7OyBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQi IHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IzIxMjEyMSI+SGkgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj MjEyMTIxIj5SZWdhcmRpbmcgdGhlIHN0YXRlbWVudCAmcXVvdDtQcmVmaXggU0lEIGNvdWxkIGJl IGp1c3QgYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbiBvciBtYXkgYWxzbyBiZSB1c2VkIHRvIHN0 ZWVyIHRoZSBmbG93IHRvIGEgbm9kZSB3aGljaCBpcyBhcHBseWluZyBhIHNlcnZpY2UgZnVuY3Rp b24gdG8gaXQmcXVvdDs6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IzIxMjEyMSI+SSB0aGluayB0aGF0IGluIFNSLU1QTFMgYSBOb2RlIFNJ RCB0aGF0IGlzIGFkdmVydGlzZWQgd2l0aCBQSFAgYWNpdG9uIGNhbiBiZSBzYWZlbHkgY29uc2lk ZXJlZCBhcyAmcXVvdDtqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24mcXVvdDsgYnkgdGhl IFBMUiBiZWNhdXNlIHRoZSBvcmlnaW5hdGluZyBub2RlIHdpbGwgbm90IHJlY2VpdmUgaXQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPlRoZSBzYW1lIGFwcGxpZXMgdG8gQWRq LVNESXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5NeSAyYy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2IGlkPSJnbWFpbC1tXy0xNjk5NTIyNDE5NTQ2MzAwNjQzZ21haWwtbV8tNTc1NjA2NTQ1 NTg0MzI1MDkwbXMtb3V0bG9vay1tb2JpbGUtc2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkdldA0KPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM3 NWM1WVlCZUViYUVad1VjSHBDWTFtNkgyP3U9aHR0cHMlM0ElMkYlMkZha2EubXMlMkZnaGVpMzYi IHRhcmdldD0iX2JsYW5rIj4NCk91dGxvb2sgZm9yIEFuZHJvaWQ8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fLTE2OTk1MjI0MTk1NDYzMDA2NDNnbWFpbC1tXy01 NzU2MDY1NDU1ODQzMjUwOTBpZC02YmY0NGQ1MS0wZTYwLTQ0OGItYmRkZS1kYzQxOTI0OWVmYTIi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6 ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWls LW1fLTE2OTk1MjI0MTk1NDYzMDA2NDNnbWFpbC1tXy01NzU2MDY1NDU1ODQzMjUwOTBkaXZScGx5 RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L3N0 cm9uZz4gc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs Zg0KIG9mIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRh bnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5rZXRhbnQ9NDBj aXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDo8L3NwYW4+ PC9zdHJvbmc+IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNTowMDxicj4NCjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG86 PC9zcGFuPjwvc3Ryb25nPiBKb2VsIE0uIEhhbHBlcm47IEFsZXhhbmRlciBWYWluc2h0ZWluOyBT aHJhZGRoYSBIZWdkZTsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0 ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVj b20uY29tPC9hPjsgUm9iZXJ0IFJhc3p1azxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2M6PC9zcGFuPjwvc3Ryb25n PiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzcHJp bmdAaWV0Zi5vcmc8L2E+PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0Ojwvc3Bhbj48L3N0cm9uZz4gUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQWxsLDxicj4NCjxicj4NCkkg d291bGQgbGlrZSB0byBzaGFyZSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSBvbiB0aGlzLjxicj4N Cjxicj4NCkZpcnN0LCB0aGFua3MgdG8gSm9lbCBmb3IgYnJpbmdpbmcgdXAgdGhlIGRpc2N1c3Np b24uIENsZWFybHkgd2UgbmVlZCBhIHdlbGwtZGVmaW5lZCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVu dCBmb3IgZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eSBvZiBwcm90ZWN0aW9uIGZvciBzZWdtZW50 IHVzZWQgaW4gYW4gU1IgUG9saWN5LiBTb21lIG9mIHRoaXMgaXMgY2FwdHVyZWQgaW4gWzFdLjxi cj4NCjxicj4NClRoaXMgaXMgYWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZl cnkgbmF0dXJlLCB0aGUgUExSIGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICZxdW90O3N0 cmljdCBvciBub3QmcXVvdDsgaXMgdGhlIFNMQSB0aGF0IGlzIGJlaW5nIHByb3ZpZGVkIGJ5IHRo ZSBTUiBQb2xpY3kuIEF3YXJlbmVzcyBvZiB0aGF0IG5vdGlvbiBleGlzdHMgYXQgdGhlIFNSIFBv bGljeSBoZWFkZW5kIGFuZC9vciBjb21wdXRhdGlvbi1ub2RlLjxicj4NCjxicj4NCldlIGhhdmUg cHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0ZWQgdmFyaWFudHMgb2YgYWRqYWNlbmN5IFNJRHMgdG8g ZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0byBwaWNrIG9yIHRoZSBvdGhlciBiYXNlZCBvbiB0aGUg JnF1b3Q7c3RyaWN0bmVzcyZxdW90OyBvZiB0aGUgU0xBIHJlcXVpcmVtZW50IGZvciBwaWNraW5n IHRoYXQgbGluay4gV2UgZG8gbm90IGhhdmUgc3VjaCBhIG5vdGlvbiBmb3IgUHJlZml4IFNJRHMu IE9uZSBjYW4gc2F5IHRoYXQgd2UgY291bGQgaW50cm9kdWNlDQogc2lnbmFsbGluZyAoZS5nLiBh IEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFByZWZpeCBTSUQgY2FuIGJlIGJ5cGFzc2Vk IG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHRoZSBjb21wdXRhdGlv biB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3IgZGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUg b2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS48YnI+DQo8YnI+DQpJIGhhdmUgYSBwcm9ibGVt IGFuZCBhIGNvbmNlcm4gaW4gdGhlIGFzc3VtcHRpb24gdGhhdCBQTFJzIGNhbiBhc3N1bWUgdGhh dCB0aGUgY3VycmVudGx5IGRlZmluZWQgdmFyaWFudCBvZiBQcmVmaXggU0lEcyBpbiBSRkM4NDAy IChhbmQgSUdQIHNwZWNzKSBhcmUgJnF1b3Q7YnlwYXNzLWFibGUmcXVvdDsuPGJyPg0KPGJyPg0K QXMgSm9lbCBhbmQgb3RoZXJzIGhhdmUgYnJvdWdodCBvdXQsIHRoZSBQcmVmaXggU0lEIGNvdWxk IGJlIGp1c3QgYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbiBvciBtYXkgYWxzbyBiZSB1c2VkIHRv IHN0ZWVyIHRoZSBmbG93IHRvIGEgbm9kZSB3aGljaCBpcyBhcHBseWluZyBhIHNlcnZpY2UgZnVu Y3Rpb24gdG8gaXQuIEluIG9yZGVyIHRvIHN1cHBvcnQgYSBtaXggb2YgU1IgUG9saWNpZXMgb2Yg ZGlmZmVyZW50IFNMQXMgKHN0cmljdCBhbmQgbm90LXN0cmljdCksDQogd2UgbmVlZCB0byBlbmFi bGUgdGhlIGNob2ljZSBvZiBTSURzIHRoYXQgaW5kaWNhdGVzIHRvIHRoZSBQTFIgd2hldGhlciB0 aGV5IGFyZSAmcXVvdDtieXBhc3MtYWJsZSZxdW90OyBvciBub3QuPGJyPg0KPGJyPg0KRm9yIHRo ZSBjYXNlcywgd2hlcmUgdGhlIFNSIFBvbGljeSBoYXMgYSBzcGVjaWZpYyBTTEEsIGl0IGlzIHJl cXVpcmVkIGZvciBub2RlcyB0byBkcm9wIHRoZSBwYWNrZXRzIG1lYW50IGZvciB0aGUgJnF1b3Q7 YWN0aXZlIHNlZ21lbnQmcXVvdDsgdGhhbiB0byBieXBhc3MgaXQuIFdoZW4gdGhpcyBtZWNoYW5p c20gaXMgdXNlZCBhbG9uZyBzaWRlIFNSVEUgcGF0aCBtb25pdG9yaW5nIG1lY2hhbmlzbXMsIGl0 IGVuYWJsZXMgdGhlIGhlYWRlbmQgdG8gZGV0ZWN0IHRoZQ0KIGZhaWx1cmUgYW5kIGZhbGxiYWNr IHRvIGFuIGFsdGVybmF0ZSBwYXRoIHVzaW5nIHRoZSBwYXRoIHByb3RlY3Rpb24gYXBwcm9hY2gu IFRoaXMgaXMgc29tZXRoaW5nIHRoYXQgaXMgZGVzY3JpYmVkIGFuZCBpbiB1c2UgaW4gZGVwbG95 bWVudHMgdG9kYXkgWzFdLi48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2V0YW48YnI+DQo8YnI+ DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNq TUpVaWlBaVd3VW1zNkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05IiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1kzZld1TkZZ Q2pNSlVpaUFpV3dVbXM2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTk8 L2E+PGJyPg0KWzJdIDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmZD TXJnbUVld0M0YTRBSlJybW43SDZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZo dG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOCUyM3NlY3Rp b24tOS4zIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v MzZmQ01yZ21FZXdDNGE0QUpScm1uN0g2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDglMjNz ZWN0aW9uLTkuMzwvYT48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhh bGYgT2YgSm9lbCBNLiBIYWxwZXJuPGJyPg0KU2VudDogMDQgQXVndXN0IDIwMjAgMjA6MjU8YnI+ DQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIu VmFpbnNodGVpbkByYmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWlu QHJiYm4uY29tPC9hPiZndDs7IFNocmFkZGhhIEhlZ2RlICZsdDs8YSBocmVmPSJtYWlsdG86c2hy YWRkaGE9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNocmFk ZGhhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0 bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVY VC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRv OkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcu QWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBSYXN6dWsgJmx0OzxhIGhy ZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6 dWsubmV0PC9hPiZndDs8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IEpvZWwgTS4gSGFscGVybiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5n IHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KPGJyPg0KVGhlcmUg YXJlLCBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgYSBudW1iZXIgb2Ygd2F5cyB0byBhZGRyZXNzIHRo aXMgZmFtaWx5IG9mIHJlbGF0ZWQgcXVlc3Rpb25zLjxicj4NCldoYXQgc3RydWNrIG1lLCBhbmQg cHJvbXB0ZWQgdGhlIHN0YXJ0aW5nIHF1ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2Vy ZSBzcGVsbGVkIG91dC4mbmJzcDsgSSBzZWUgbG90cyBvZiBpbnRlcmVzdGluZyBpZGVhcyAvIHBy b3Bvc2Fscy48YnI+DQpTb21lIG9mIHRoZW0gYXJlIGNvbXBhdGlibGUgd2l0aCBvdGhlcnMuJm5i c3A7Jm5ic3A7IFNvbWUgYXJlIG5vdC48YnI+DQpJdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxk IHJlYWNoIGFncmVlbWVudCBvbiBob3cgd2UgdGhvdWdodCBpdCBzaG91bGQgYmUgaGFuZGxlZC48 YnI+DQo8YnI+DQpUaGFuayB5b3UsPGJyPg0KSm9lbDxicj4NCjxicj4NCk9uIDgvNC8yMDIwIDM6 NTQgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOjxicj4NCiZndDsgSGkgYWxsLDxicj4N CiZndDsgPGJyPg0KJmd0OyBJIGFtIHN0aWxsIG5vdCBzdXJlIHRoYXQgdGhlIHByb2JsZW0gb2Yg YnlwYXNzIGdvaW5nIHRocnUgdW5kZXNpcmFibGUgPGJyPg0KJmd0OyBsaW5rcy9ub2RlcyBleGlz dHMgaW4gdGhlIGNhc2Ugb2YgdG9wb2xvZ2ljYWwgU0lEcy48YnI+DQomZ3Q7IDxicj4NCiZndDsg QUZBSUssIEZhY2lsaXR5IFByb3RlY3Rpb24gaW4gUlNWUC1URSBGUlIgKFJGQyA0MDkwPGJyPg0K Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNROTJrbkU5 WEp1anJmOEJrN29KdnM2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RnJmYzQwOTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v M1E5MmtuRTlYSnVqcmY4Qms3b0p2czZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGcmZjNDA5MDwvYT4mZ3Q7KSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkNCiBkZXBsb3ll ZCA8YnI+DQomZ3Q7IGZvciBtYW55IHllYXJzIGJlZm9yZSBTUi1NUExTIGhhcyBiZWVuIGludHJv ZHVjZWQuIFdoYXTigJlzIG1vcmUsIDxicj4NCiZndDsgc2lnbmFsaW5nIG9mIGJ5cGFzcyB0dW5u ZWxzIGhlIFBMUiB1c3VhbGx5IGRpZCBub3QgaW5jbHVkZSBhbnkgb2YgdGhlIDxicj4NCiZndDsg Y29uc3RyYWludHMgdXNlZCBmb3IgY29tcHV0aW5nIG9mIGFueSBzcGVjaWZpYyBMU1AgdGhhdCB0 aGUgYnlwYXNzIExTUCA8YnI+DQomZ3Q7IHdvdWxkIHByb3RlY3Qg4oCTIGJlY2F1c2UgaW4gdGhl IEZhY2lsaXR5IFByb3RlY3Rpb24gbW9kZSB0aGUgc2FtZSA8YnI+DQomZ3Q7IGJ5cGFzcyBMU1Ag d291bGQgYmUgdXNlZCB0byBwcm90ZWN0IG11bHRpcGxlIExTUHMgcGFzc2luZyB0aHJ1IHRoZSA8 YnI+DQomZ3Q7IGZhaWxlZCBsaW5rL25vZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7IEZy b20gbXkgUE9WIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIGJlaGF2aW9yIGFuZCB0 aGF0IDxicj4NCiZndDsgaW50cm9kdWNlZCBieSB0aGUg4oCcYnlwYXNzaW5n4oCdIGRyYWZ0cyBp biBTUiBpcyB0aGF0LCBpbiB0aGUgY2FzZSBvZiA8YnI+DQomZ3Q7IFJTVlAtVEUsIHRoZSBvcGVy YXRvciB3b3VsZCBleHBsaWNpdGx5IGluZGljYXRlLCBhcyBwYXJ0IG9mIExTUCA8YnI+DQomZ3Q7 IHNpZ25hbGluZywgd2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBub3QgdXNlIEZSUjsgTFNQcyB0 aGF0IHdvdWxkIG5vdCA8YnI+DQomZ3Q7IHVzZSBGUlIgd291bGQgdGhlbiBkcm9wIHRyYWZmaWMg cmF0aGVyIHRoYW4gZGVsaXZlcmluZyBpdCB0aGUgd3Jvbmcgd2F5Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBTdWNoIGFuIG9wdGlvbiBpbmRlZWQgZG9lcyBub3QgZXhpc3QgaW4gU1ItVEUgdG9kYXks IGJ1dCB3b3VsZCBiZSBlYXN5IDxicj4NCiZndDsgdG8gcHJvdmlkZSBpZiBzbyBkZXNpcmVkIElN SE8uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERpZCBJIG1pc3Mgc29tZXRoaW5nIHN1YnN0YW50aWFs Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2 YW5jZSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2FzaGE8YnI+DQomZ3Q7IDxicj4NCiZndDsgT2Zm aWNlOiArOTcyLTM5MjY2MzAyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENlbGw6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICs5NzItNTQ5MjY2MzAyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEVt YWlsOiZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgKkZyb206KiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgKk9uIEJlaGFsZiBPZiAqU2hyYWRkaGEgSGVnZGU8YnI+DQom Z3Q7ICpTZW50OiogVHVlc2RheSwgQXVndXN0IDQsIDIwMjAgOTo0MSBBTTxicj4NCiZndDsgKlRv OiogPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0 YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+PGJy Pg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5j b20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZn dDs7IFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQomZ3Q7ICpDYzoq IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+OyBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7 PGJyPg0KJmd0OyAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRl dGVybWluaW5nIGFwcGxpY2FiaWxpdHk8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWxsLDxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaGlzIGlzIGEgdmVyeSBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIGFuZCB0 aGFua3MgdG8gSm9lbCBmb3Igc3RhcnRpbmcgPGJyPg0KJmd0OyB0aGlzIGRpc2N1c3Npb24uIElN Tywgd2hlbiB0aGVyZSBhcmUgc3RyaWN0IHJlcXVpcmVtZW50cyBvZiBhdm9pZGluZyA8YnI+DQom Z3Q7IGNlcnRhaW4gbm9kZXMvbGlua3MgaXQgY2FuIGJlIHJlYWxpemVkJm5ic3A7IGVpdGhlciBi eSBkZWZpbmluZyBhIGZsZXgtYWxnbyA8YnI+DQomZ3Q7IGF2b2lkaW5nIHRob3NlPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IE5vZGVzIGFuZCBsaW5rcyBvciBieSB1c2luZyBhIHN0YWNrIG9mIHVucHJv dGVjdGVkIGFkai1zaWRzIHRoYXQgYXZvaWQgPGJyPg0KJmd0OyByZXN0cmljdGVkIG5vZGVzIGFu ZCBsaW5rcy4gV2hlbiBhIHN0YWNrIG9mIGFkai1zaWRzIGlzIHVzZWQgdG8gPGJyPg0KJmd0OyBy ZWFsaXplIHRoZSBwYXRoLCB0aGUgaGVhZC1lbmQgYmFzZWQgKHNCRkQpIHByb3RlY3Rpb24gbWVj aGFuaXNtcyBjYW4gYmUgYXBwbGllZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgTm9kZS1zaWRz L3ByZWZpeC1zaWQvYW55Y2FzdC1zaWRzIGFyZSB1c2VkIHRvIGJ1aWxkIHRoZSBzdGFjaywgdGhl IDxicj4NCiZndDsgZmFpbHVyZSBldmVudHMgbWF5IGNhdXNlIHRyYWZmaWMgdG8gZ28gdGhyb3Vn aCByZXN0cmljdGVkIG5vZGVzIGFuZCA8YnI+DQomZ3Q7IGxpbmtzLiBUaGlzIHdvdWxkIGhhcHBl biByZWdhcmRsZXNzIG9mIHdoZXRoZXIgYW55IGtpbmQgb2YgcHJvdGVjdGlvbiA8YnI+DQomZ3Q7 IGlzIGluIHVzZSBvciBub3QuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJnZHM8YnI+DQomZ3Q7IDxi cj4NCiZndDsgU2hyYWRkaGE8YnI+DQomZ3Q7IDxicj4NCiZndDsgSnVuaXBlciBCdXNpbmVzcyBV c2UgT25seTxicj4NCiZndDsgPGJyPg0KJmd0OyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTIwJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgKk9uIEJlaGFsZiBPZiAqQW5kcmV3IEFsc3Rvbjxi cj4NCiZndDsgKlNlbnQ6KiBUdWVzZGF5LCBBdWd1c3QgNCwgMjAyMCA1OjQxIEFNPGJyPg0KJmd0 OyAqVG86KiBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5u ZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpyb2JlcnRAcmFz enVrLm5ldDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKkNjOiogPGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5n QGlldGYub3JnPC9hPiZndDs7IEpvZWwgTS4gSGFscGVybg0KPGJyPg0KJmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhh bHBlcm4uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4N CiZndDsgKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1p bmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpbRXh0ZXJuYWwgRW1haWwu IEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdKjxicj4NCiZndDsgPGJyPg0KJmd0OyBSb2JlcnQgdGhp cyBpcyBhY3R1YWxseSBmYXIgbW9yZSBkaWZmaWN1bHQgd2hlbiDigJMgaXQgY2FuIGJlIGFuIGVu dGlyZTxicj4NCiZndDsgKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0IG5lZWQgdG8gYmUgYXZv aWRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgY291bGQgcG90ZW50aWFsbHkgYmUgbWFkZSB0 byB3b3JrIGJ1dCBJ4oCZZCB3b3JyeSB0aGF0IHRvIGRvIHRoaXMg4oCTIDxicj4NCiZndDsgeW91 4oCZZCBoYXZlIHRvIHN0YWNrIDEwIOKAkyAyMCDigJMgMzAgbmVnYXRpdmUgbGFiZWxzIOKAkyBh bmQgdGhhdCB3b3VsZG7igJl0IDxicj4NCiZndDsgYmUgdmlhYmxlLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBJdOKAmXMgZWFzaWVyIHRvIHVzZSBhbGdvcml0aG1zIGFuZCBhZGphY2VuY3kgc2lkcyBh bmQgb3RoZXIgc3VjaCB0aGluZ3MgPGJyPg0KJmd0OyB0byBjYWxjdWxhdGUgcGF0aHMg4oCTIHRo ZSBiaWdnZXN0IHRyaWNrIGlzIGFib3V0IHRoZSBzdGFjayBkZXB0aC4mbmJzcDsgV2hlbiA8YnI+ DQomZ3Q7IHlvdSBoYXZlIHRoaXMgbmVlZCBmb3Igbm9kZSBhdm9pZGFuY2Ug4oCTIHRoZSBuZWVk IGZvciAxMCsgbGFiZWwgZGVwdGggPGJyPg0KJmd0OyBpcyBjcml0aWNhbCDigJMgdW5sZXNzIHlv dSB3YW5uYSBiZSBhcHBseWluZyBvbmUgaGVsbCBvZiBhIGxvdCBvZiA8YnI+DQomZ3Q7IGJpbmRp bmcgbGFiZWxzIGFsb25nIHRoZSB3YXkgd2hpY2ggaXMgYSBuaWdodG1hcmUuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEJ1dCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaXMgdGhpcyBhIGNvbW1vbiB1 c2UgY2FzZSDigJMgaXTigJlzIGEgdXNlIDxicj4NCiZndDsgY2FzZSB0aGF0IG1vc3Qgb2YgdGhl IHBlb3BsZSBJIGRpc2N1c3MgdGhpcyB3aXRoIGNlcnRhaW4gaGF2ZSDigJMgSSBjYW50IDxicj4N CiZndDsgY29tbWVudCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFueW9uZSBlbHNlLCBidXQg ZXZlcnkgaW5kaWNhdGlvbiBJIDxicj4NCiZndDsgaGF2ZSBpcyB0aGF0IHllcyDigJMgaXRzIHNv bWV0aGluZyBwZW9wbGUgbmVlZCwgYW5kIHdhbnQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgQW5kcmV3 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpGcm9tOiogUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5u ZXQ8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2Js YW5rIj5tYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICpTZW50 OiogVHVlc2RheSwgNCBBdWd1c3QgMjAyMCAwMToyNzxicj4NCiZndDsgKlRvOiogQW5kcmV3IEFs c3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20l MjAlMGIiIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8 YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKkNjOiogSm9lbCBNLiBIYWxwZXJuICZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYiIgdGFyZ2V0PSJfYmxhbmsi PmptaEBqb2VsaGFscGVybi5jb20NCjxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPC9hPiZndDsmZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IElzIHRoaXMgYSBjb21tb24gdXNlIGNhc2UgaWUuJm5ic3A7ICZxdW90O2J1dCByYXRoZXIg4oCT IHdoaWNoIG5vZGVzIC8gbmV0d29yayA8YnI+DQomZ3Q7IHNlZ21lbnRzIGl0IGNhbiBuZXZlciB0 b3VjaCBvciBmbG93IHRocm91Z2guJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHNvIHBl cmhhcHMgaXRzIHRpbWUgdG8gZGVmaW5lIG5vdGlvbiBvZiAqbmVnYXRpdmUtU0lEKiBpZS4gbGlz dCBpbiA8YnI+DQomZ3Q7IHRoZSBwYWNrZXQgcmVzb3VyY2VzIHdoaWNoIGdpdmVuJm5ic3A7cGFj a2V0IE1VU1Qgbm90IGV2ZXIgdHJhdmVyc2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFB1dCBpbiB0 aGUgcGFja2V0IHNldCBvZiBub2RlcyBvciBsaW5rcyB3aGljaCB0aGUgcGFja2V0IHNob3VsZCBu ZXZlciA8YnI+DQomZ3Q7IHRyYXZlcnNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IGdvZXMg aW4gbGluZSBvZiByZWNlbnQgd2F2ZSBvZiBuZWdhdGl2ZSByb3V0aW5nIGltcGxlbWVudGF0aW9u czxicj4NCiZndDsgKFJJRlQpIG9yIGRpc2N1c3Npb25zIChMU1IpPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEJlc3QsPGJyPg0KJmd0OyBSLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIEF1ZyAz LCAyMDIwIGF0IDExOjQ2IFBNIEFuZHJldyBBbHN0b24gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGIiIHRhcmdldD0iX2Js YW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8YnI+DQo8L2E+Jmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU28g 4oCTPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uZSBvZiB0 aGUgdXNlIGNhc2VzLCBpbiBmYWN0LCBzb21lIHZlcnkgbWFqb3IgdXNlIGNhc2VzIGluIGFueTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3ByaW5nIHRlY2hub2xvZ3kgZm9yIHVz IHJldm9sdmUgYXJvdW5kIHRoZSBmb2xsb3dpbmc8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYS5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9k ZXM8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYi5UaGUgZXhw bGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdvcms8YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW55dGhpbmcgdGhhdCBjb3Vs ZCByZXN1bHQgaW4gdGhhdCBleHBsaWNpdCBhdm9pZGFuY2UgYmVpbmcgdmlvbGF0ZWQ8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAkyB3b3VsZCBjcmVhdGUsIHNoYWxsIHdlIHNh eSBzaWduaWZpY2FudCBwcm9ibGVtcy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTXVjaCBvZiB0aGUgdXNlIGNhc2UgaXMgbm90IGEgY2FzZSBvZiB3aGljaCBu b2RlcyB0aGUgcGFja2V0cyBmbG93PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aHJvdWdoIOKAkyBidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2VnbWVudHMg aXQgY2FuIG5ldmVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b3VjaCBvciBm bG93IHRocm91Z2guJm5ic3A7IEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9n eSB0bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXZvaWQgY2VydGFpbiB0aGlu Z3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIG5lZWRpbmcg c3VjaCBkZWVwIGxhYmVsIHN0YWNrcyDigJM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoaXMga2luZCBvZiBkZXRhaWxlZCBwYXRoIHByb2dyYW1taW5nIHRlbmRzIHRvIGRlZXBl biB0aGUgc3RhY2s8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlY2F1c2UgeW91 IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBleHBsaWNpdC48YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1 cyB0aGF0IHRoaXMgZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDigJM8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGFuZCB0aGF0IHdlIGNhbiBhdm9pZCBzaXR1YXRpb25zIHdoaWNoIGNv dWxkIGNhdXNlIHRyYWZmaWMgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFj Y2lkZW50bHkgaGl0IHRoaW5ncyBleHBsaWNpdGx5IGF2b2lkZWQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lm aWMgdGhhbiB0aGlzLCBidXQgaXQgaXMgd2hhdCBpdCBpcy48YnI+DQomZ3Q7IDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZHJldzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7ICpPbiBCZWhhbGYgT2YgKkpvZWwgTS4gSGFs cGVybjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlNlbnQ6KiBNb25kYXksIDMg QXVndXN0IDIwMjAgMjE6MzY8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpUbzoq IFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFy Z2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv YmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJvYmVydEByYXN6dWsubmV0 PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqQ2M6KiA8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRm Li5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAt IGRldGVybWluaW5nIDxicj4NCiZndDsgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxv bmcgZW5vdWdoLCByZWl0ZXJhdGluZyB0aGF0IHRoaXMgaXMgYXMgYTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcGFydGljaXBhbnQsIG5vdCBhIFdHIGNoYWlyLik8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWVzLCB3ZSBhcmUgdGFsa2luZyBJ UCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29ya3MgdGhhdDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFs bCBzb3J0cyBvZiByZWFzb25zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0 aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9uZSBtYXkgbm90IHdhbnQg YSByYW5kb208YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGggcmF0aGVyIHRo YW4gYSBjaG9zZW4gVEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXI8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFib3V0IHdoYXQgY29uc3RyYWludHMg bWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUgdGhleTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0 aW5nKSB0aGF0IGlzIGludGVuZGVkIHRvIHByZXNlcnZlIFFvUy48YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3Vp bmcgdGhhdCB0aGlzIGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQgaXMgYTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJIGFtIHRyeWluZyB0byBm aWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2Y8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwg bGVhZCB0byBldmVyeW9uZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ2V0dGlu ZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJlaGF2aW9y IHRoZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2lyZSwgYnV0IHNvbWV0 aW1lcyBpcyB0aGUgYmVzdCB3ZSBjYW4gZG8uKTxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBZb3Vycyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEpvZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gOC8z LzIwMjAgMjozMCBQTSwgUm9iZXJ0IFJhc3p1ayB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSm9lbCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgQXJlIHdlIHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya3MmbmJzcDtoZXJlID8g T3IgcGVyaGFwcyBzb21lIGhhcmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5l dHMgPzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBCZWNhdXNlJm5ic3A7aWYgd2Ug YXJlIHRhbGtpbmcmbmJzcDthYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d288YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9ic2VydmF0aW9uczo8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgQSkgSWYgeW91IG5lZWQgdG8gdHJhdmVyc2UgdmlhIGEgc3BlY2lmaWMg bm9kZSAoaWUuIGZpcmV3YWxsKSB5b3U8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGJldHRlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhcHBs eSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4uIEkgZG9uJ3QgdGhpbmsgSVA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuY2Fwc3VsYXRpb24mbmJzcDtjYW48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYmUgaGlqYWNrZWQgdG9kYXkg c3VjaCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpczxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWdub3JlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3aGVyZSB1cG9uIHRvcG9s b2d5IGNoYW5nZSAobGluazxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3Igbm9k ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBmYWlsdXJlKSB5 b3Ugc3VkZGVubHkmbmJzcDtzdGFydCBkcm9wcGluZyZuYnNwO2Zsb3dzIGluIHNwaXRlIG9mIFNQ VCBvZmZlcmluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBw ZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRoIDEwIG1zIG1vcmUgaml0dGVyID88YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNsaWRl cyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgc29tZXRoaW5nJm5ic3A7bmV3ID8gV29yc2UgLi4uIGRvIHRo ZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3VhcmFudGVlcyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcmVzb3VyY2UgcmVzZXJ2YXRpb25zJm5ic3A7PyBJIGhv cGUgbm90Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBUaHgsPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFIuPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgODox MCBQTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tJTBiIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSUyMCUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t JTIwJTBiPC9hPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7 IHdyb3RlOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBXZWxsIGxlc3Mgc2VyaW91 cyBmb3IgVEUgU0lEcywgSSBhbSBub3Qgc3VyZSB0aGUgcHJvYmxlbSBpczxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzdHJpY3RlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyB0byBqdXN0IHNlcnZpY2UgU0lEcy48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0aGUg cGF0aCB0byBtZWV0IHNvbWUgY29tcGxleCB0ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBvYmplY3RpdmUuJm5ic3A7IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8g d2F5IG9mIGtub3dpbmcgd2hhdCB0aG9zZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBjb25zdHJhaW50czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyB3ZXJlLiZuYnNwOyBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywg aXQgaXMgYmV0dGVyIHRvIGRyb3AgdGhlIHBhY2tldDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lkZSB0aGUgZW52ZWxv cC4mbmJzcDsgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFuc3dlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyB0byB0aGlzIGlzICZxdW90O3RvbyBiYWQmcXVvdDsuJm5ic3A7IElm IHNvLCBhcyB3aXRoIHRoZSBkaXN0aW5jdGlvbiByZWdhcmRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHNlcnZpY2U8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgbm9kZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT88YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgWW91cnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgT24gOC8zLzIwMjAgMjozNiBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgTWFjaCwgSm9lbCBh bmQgYWxsLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSB0aGlu ayB0aGF0IGluIG1vc3QgY2FzZXM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuICZxdW90O3Rv cG9sb2dpY2FsJnF1b3Q7IGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7c2VydmljZSZxdW90Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IGluc3RydWN0aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBvSUdQIFByZWZpeCBOb2RlIFNJ RHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4gdGhlPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgY29ycmVzcG9uZGluZyBJR1AgYWR2 ZXJ0aXNlbWVudHMpIHJlcHJlc2VudCB0b3BvbG9naWNhbDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyBvU2VydmljZSBTSURzIGZvciBTUnY2IChzZWUgU1J2NiBCR1AtQmFzZWQgT3Zl cmxheSBTZXJ2aWNlczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNDQ2N5OW1ZNmNNZmJrN1FmamhpQTNSNkgyP3U9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWJlc3Mtc3J2 Ni1zZXJ2aWNlcy0wNCUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zQ0NjeTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2Vydmlj ZXMtMDQ8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHQzVhZjJ6M0p6cGhaRGtQbmNIQVFpNkgy P3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZp Y2VzLTA0X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzRULUwwbmwlMjQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dDNWFmMnozSnpwaFpEa1BuY0hBUWk2 SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2Vy dmljZXMtMDRfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhn bTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNFQtTDBubCUyNDwvYT4mZ3Q7Jmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRyYWZ0KSB1bnN1cnByaXNpbmds eSByZXByZXNlbnQg4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnM8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9wb2xv Z2ljYWwgaW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2Vu dCBzZXJ2aWNlIGluc3RydWN0aW9ucyByZXF1aXJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGFsdGVybmF0aXZlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcHJvdGVjdGlvbiBtZWNoYW5pc21zLjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgVGhpcyB2aWV3IHNlZW1zIHRvIGJlIGFs aWduZWQgd2l0aCBSRkMgODQwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v MzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRnJmYzg0MDIlMGIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRv b2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDI8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM3 UHpVS0FEODJjalN2bVZjR3Zwa2hGNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUy RnYzJTJGX19odHRwcyUzQSUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDJfXyUzQiUy MSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dw NnZwUkhPR3Q4QWtUUkR1aURvMEk0WWJ0bSUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zN1B6VUtBRDgyY2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUy Rmh0bWwlMkZyZmM4NDAyX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFv aVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJNFlidG0lMjQ8L2E+Jmd0 OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgc2F5cyBpbiBTZWN0 aW9uIDE6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNv bnRyb2wgcGxhbmUsIHR3bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNl Z21lbnQgYW5kIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7Jm5ic3A7IElHUC1QcmVmaXggc2VnbWVudC48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBJbiB0aGUgY29udGV4 dCBvZiBhIEJHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFy ZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBhbmQgdGhlPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgQkdQLVByZWZp eCBzZWdtZW50Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSW4g dGhlIGNhc2Ugb2YgU1ItTVBMUyB0aGlzIGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNl Y3Rpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgMy40IG9m PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgdGhlIE5v ZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFmTlBzWmRocEV4eHg5Nkgy P3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFm dC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rp b24tMy40JTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNKYlNXR3g1REFmTlBzWmRocEV4eHg5NkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5p ZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9u LWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rpb24tMy40PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zQ3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5j b20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwl MkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUy QXNlY3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9p UUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNzbiUyNCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ3JVZ0FSVzhzb21BYnc2 VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJp bmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyQXNlY3Rpb24tMy40X18lM0JJ dyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pI Z3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNzbiUyNDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRyYWZ0IHRoYXQgc2F5czo8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgbm9kZSBw cm90ZWN0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZWN0aW9uczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGRlcGVuZHMgb24gdGhlIGFzc3Vt cHRpb24gdGhhdCB0aGUgbGFiZWwgaW1tZWRpYXRlbHkgYmVsb3c8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhlIHRvcDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsgbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rv b2QgaW4gdGhlIElHUCBkb21haW4uJm5ic3A7IFdoZW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgcHJvdmlkZXIgZWRnZSBy b3V0ZXJzIGV4Y2hhbmdlIHNlcnZpY2UgbGFiZWxzIHZpYSBCR1Agb3Igc29tZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBvdGhlcjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IG5vbi1JR1AgbWVj aGFuaXNtIHRoZSBib3R0b20gbGFiZWwgaXMgbm90IHVuZGVyc3Rvb2QgaW4gdGhlIElHUDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7 IGRvbWFpbi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyZuYnNwOyBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGRlc2Ny aWJlZCBpbiB0aGUgZHJhZnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBbUkZDODY3OSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFqQTNwTTZUZENFNkgyP3U9aHR0cHMlM0El MkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5JTBiIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFq QTNwTTZUZENFNkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUy Rmh0bWwlMkZyZmM4Njc5PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmRNQWp1WVRRb3ZvOGpI d21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5X18lM0IlMjEl MjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2 cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzZkTUFqdVlUUW92bzhqSHdtbTNlSnc2SDI/dT1odHRwcyUzQSUy RiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5v cmclMkZkb2MlMkZodG1sJTJGcmZjODY3OV9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5 RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG84TUdpcFhj JTI0PC9hPiZndDsmZ3Q7XTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXM8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBhcHBsaWNhYmxl IHRvIHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdlczxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHdpbGwgYmUg cmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyBUaGUgc2NlbmFyaW9zIGluIHdoaWNoICZuYnNwO2RpZmZlcmVudGlh dGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs4oCdIGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zIGlz IGJyb2tlbiBhcmUgaW5kZWVkIHByb2JsZW1hdGljLiBFLmcuLDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjb25zaWRlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUg U0lEIGluIHRoZSBFUk8gb2YgYSBTUi1URSBwYXRoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGlkZW50aWZpZXMgYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IG5vZGUgdGhhdCBhY3RzIGFzIGEgZmlyZXdhbGwgZm9y IGFsbCBwYWNrZXRzIGl0IHJlY2VpdmVzLCBpLmUuLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBwcm92aWRlczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRoZSBmaXJld2FsbCBzZXJ2aWNlIHdpdGhvdXQgYW55IGRl ZGljYXRlZCBzZXJ2aWNlIFNJRDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBpZGVudGlmeWluZyBpdC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2gg YSBub2RlIHdvdWxkIGNvbWJpbmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgdG9wb2xvZ2ljYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyBhbmQgc2VydmljZSBpbnN0cnVjdGlvbnMgdGh1cyBicmVha2luZyB0aGUg ZGlmZmVyZW50aWF0aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IGJldHdlZW4gdGhlIHR3by48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IEkgYW0gbm90IHN1cmUgaWYgdXNhZ2Ugb2Ygc3VjaCDigJxjb21iaW5lZOKAnSBTSURz IGNvdWxkIGJlIHByZXZlbnRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBvciBhdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IGxlYXN0IGRpc2NvdXJhZ2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgSWYgbm90LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0byBpZGVudGlmeSBzdWNo IFNJRHMgaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGFkdmVydGlzZW1lbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBtZWNoYW5pc21zIHdvdWxkIGJlIHVzZWZ1bCBJTUhPLjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgTXkgMmMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyBTYXNoYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgT2ZmaWNlOiArOTcyLTM5MjY2MzAyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyBDZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAr OTcyLTU0OTI2NjMwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsg RW1haWw6IDxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPg0KQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEZyb206IHNwcmluZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiPC9hPiZndDsmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsmZ3Q7IE9uIEJlaGFsZiBPZiBNYWNoIENoZW48YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBTZW50OiBNb25kYXksIEF1Z3Vz dCAzLCAyMDIwIDY6MzAgQU08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSUwYiIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208YnI+ DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20lMGIiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSUwYjwvYT4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7 Jmd0Ozs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNw cmluZ0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtz cHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSGkgSm9lbCw8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2Qg cG9pbnQgdGhhdCBtYXkgbm90IGJlIGRpc2N1c3NlZCBpbiB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcGFzdC4gQW5kPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSBhbHNvIGRvbid0IHRoaW5rIHRoZXJlIGlz IGEgJnF1b3Q7Y2FuIGJlIGJ5cGFzc2VkJnF1b3Q7IGluZGljYXRpb24gaW4gdGhlPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcm91dGluZyBhZHZlcnRp c2VtZW50IGZvciBub3cuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyBJTUhPLCB0aGUgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBieSByb3V0aW5nIGlzIG5ldXRyYWws IHN1Y2g8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgaW5mb3Jt YXRpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAo Y2FuIG9yIGNhbm5vdCBiZSBieXBhc3NlZCkgaXMgbW9yZSBwYXRoIHNwZWNpZmljLCB0aHVzPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub3JtYWxseSB0aGU8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBjb250cm9sbGVyIHNob3VsZCBi ZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBTSUQ8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgY2FuIGJlPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgYnlwYXNzZWQuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBNYWNoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IEZy b206IHNwcmluZyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNw cmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIlM2UlMjAlM2NtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclM2UiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIlM2UlMjAlM2NtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmclM2U8L2E+Jmd0O108YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIEJl aGFsZiBPZiBKb2VsIE0uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IEhhbHBlcm48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA3OjUxIEFNPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IFRvOiA8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGll dGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+ bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxicj4NCjwv YT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jmd0OyBTdWJqZWN0OiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFw cGxpY2FiaWxpdHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgKFdHIENoYWlyIGhhdCBPZmYsIHRoaXMgaXMgbWVyZWx5IGEgbm90ZSBmcm9tIGEgc2xp Z2h0bHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgY29uZnVz ZWQgV0c8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgcGFydGljaXBhbnQuKTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJmd0OyBJIGhhdmUgYmVlbiByZWFkaW5nIHRoZSB2YXJpb3VzIHJlcGFpciBkcmFmdHMs IGFuZCB0aGUgdmFyaW91czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0OyBuZXR3b3JrcyBwcm9ncmFtbWluZyBhbmQgc2VydmljZSBwcm9ncmFtbWlu ZyBkcmFmdCwgYW5kIEkgYW08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgdHJ5aW5nIHRvPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBvZiB0aGUgY29tYmluYXRpb24uPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IEhvdyBkb2Vz IGEgbm9kZSB0aGF0IGlzIGRvaW5nIHNvbWUgZm9ybSBvZiBieXBhc3MgKHN1cHBvc2UsIGZvcjxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBzaW1w bGljaXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQgZm9y PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGEgZmFpbGVkPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IG5vZGUg TjMpIGtub3cgdGhhdCBpdCBpcyBzYWZlIHRvIGRvIHNvPzxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBJZiB0aGUgcGF0aCB3YXMganVzdCBmb3IgVEUs IHRoZW4gaXQgaXMgJnF1b3Q7c2FmZSZxdW90OyBpZiB0aGUgbmV3IHBhdGg8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbWVldHM8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgdGhlIFRFIGNyaXRlcmlhLiZuYnNw OyBvciBtYXliZSBpdCBpcyBzYWZlIGlmIGl0IGlzIGV2ZW4gY2xvc2UsIGFzPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGxvbmcgYXM8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgaXQgaXMgbm90IHVzZWQgZm9y IHRvbyBsb25nLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJz cDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jmd0OyBCdXQgd2hhdCBpZiB0aGUgbm9kZSB3ZXJlIGEgRmlyZXdhbGwsIGluY2x1ZGVkIHRvIG1l ZXQgbGVnYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyByZXF1aXJlbWVudHM/PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IE9yIHdhcyBzb21lIG90aGVyIG5lY2Vzc2FyeSBwcm9ncmFtbWF0aWMgdHJh bnNmb3JtICh3aW5jZSB3ZSBhcmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgZGVsaWJlcmF0ZWx5IHZhZ3VlIGFib3V0IHdoYXQgbm9kZXMgY2Fu IGRvIHdoZW4gYXNrZWQgc3VpdGFibHkuKTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsmbmJzcDsgJmd0OyBJcyB0aGVyZSBzb21lICZxdW90O2NhbiBiZSBieXBhc3NlZCZx dW90OyBpbmRpY2F0aW9uIGluIHRoZSByb3V0aW5nPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IGFkdmVydGlzZW1lbnRzIHRoYXQgSSBtaXNzZWQ/ PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IFRoYW5r IHlvdSw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgWW91cnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNw OyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgc3ByaW5n IG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiIiB0YXJn ZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyAmbHQ7bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYu b3JnPC9hPiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTIi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0 S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNRN3ZYMnFXU1VkV1ZjODkyWHVYeTJINkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNv bSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lV a3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMl9fJTNCSlNVJTIxJTIxTkV0NnlN YU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhB a1RSRHVpRG82SHdQTGlsJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzNRN3ZYMnFXU1VkV1ZjODkyWHVYeTJINkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxk ZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYz NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMl9fJTNCSlNVJTIx JTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2 dnBSSE9HdDhBa1RSRHVpRG82SHdQTGlsJTI0PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Ozxh IGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRl QXZQNDZIMj91PWh0dHBzJTNBJTI1MiUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1 Mjxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0E1QjhIMkZtMXJQbmFaM1N1cGp3cjZIMj91PWh0 dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlja3RpbWUu c3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0cHMlMkEz QSUyQTI1Ml9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRR eGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG96b1FpQUhrJTI0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNBNUI4SDJGbTFyUG5hWjNTdXBq d3I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJG Y2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUz RGh0dHBzJTJBM0ElMkEyNTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4 RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvem9RaUFIayUyNDwv YT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJz cDsgJmd0OyBGJTxhIGhyZWY9Imh0dHA6Ly8yRnd3dy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjJGd3d3LmlldGYub3JnPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhH SjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUz QSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVf UjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzlOem5tWUJ0UnVI QVJoR0o1VzVkR0I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0 dHAlM0ElMkYyRnd3dy5pZXRmLm9yZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllO RThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8tcFBDanZSJTI0 PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zR1dUOWZ5amFGaTNGY3ZI RHZvb2R2UzZIMj91PWh0dHAlM0ElMkYlMkYyRnd3dy5pZXRmLm9yZyUwYiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zR1dUOWZ5amFGaTNGY3ZIRHZvb2R2 UzZIMj91PWh0dHAlM0ElMkYlMkYyRnd3dy5pZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2Uu Y29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9yZ19fJTNCJTIxJTIxTkV0NnlNYU8t Z2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RS RHVpRG8tcFBDanZSJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZl bnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5FdDZ5 TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4 QWtUUkR1aURvLXBQQ2p2UiUyNDwvYT4mZ3Q7Jmd0OyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdA aWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUwYiIg dGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUw YiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI8L2E+Jmd0OyZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWls dG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmciIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pX OXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGc3ByaW5nPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQmh5RXR4NFE3bjc0Qmhp Um5mTUp0VDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIl M0Z1JTNEaHR0cHMlMkEzQSUyQTJGJTJBMkZ3d3cuaWV0Zi5vcmclMkEyRm1haWxtYW4lMkEyRmxp c3RpbmZvJTJBMkZzcHJpbmdfXyUzQkpTVWxKU1VsJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5 RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8taFIzZ0FE JTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNCaHlF dHg0UTduNzRCaGlSbmZNSnRUNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYz JTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVH QzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMkYlMkEyRnd3dy5pZXRmLm9yZyUyQTJGbWFp bG1hbiUyQTJGbGlzdGluZm8lMkEyRnNwcmluZ19fJTNCSlNVbEpTVWwlMjElMjFORXQ2eU1hTy1n ayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJE dWlEby1oUjNnQUQlMjQ8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdp dGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRp b25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgYW5kL29yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsgcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlv biBieSBvdGhlcnMgb3IgZm9yd2FyZGluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgd2l0aG91dDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJl IG5vdCB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgaW50 ZW5kZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBy ZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBk ZWxldGUgYWxsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLjxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlz dDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5v cmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3By aW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgPGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlo cUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZzcHJpbmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z TnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz cHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4 MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyNCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZI Mj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cu aWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFP LWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtU UkR1aURvNUtsUG5iaiUyNDwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YSBocmVmPSJtYWlsdG86c3By aW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJp bmdAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YSBocmVmPSJodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQ QnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZH RXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0 NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9H dDhBa1RSRHVpRG81S2xQbmJqJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1 cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThF X1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0PC9h PiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJp bmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+ PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7ICZsdDs8YSBocmVm PSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2 SDI/dT1odHRwcyUzQSUyNSUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTxicj4NCjwv YT4mZ3Q7IDJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElPGEgaHJlZj0iaHR0 cDovLzJGd3d3LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+MkZ3d3cuaWV0Zi5vcmc8L2E+JTJG bWFpbG1hbiUyRmxpc3RpPGJyPg0KJmd0OyBuZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFP LWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1PGJyPg0KJmd0OyBvWkhnd3A2 dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgLS08YnI+DQomZ3Q7IE5v dGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0 aGF0IGlzIGNvbmZpZGVudGlhbCBhbmQvb3IgPGJyPg0KJmd0OyBwcm9wcmlldGFyeSBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIDxicj4NCiZn dDsgZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3 YXJkaW5nIHdpdGhvdXQgPGJyPg0KJmd0OyBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIDxicj4NCiZndDsgcmVjaXBp ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVsZXRl IGFsbCA8YnI+DQomZ3Q7IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy48YnI+DQom Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IC0tPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0 dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9h Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmci IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lN ek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnNwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4N Cjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Ob3Rp Y2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMgY29uZmlk ZW50aWFsDQogYW5kL29yIHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJp YnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdpdGhvdXQgZXhwcmVzcyBwZXJtaXNzaW9u IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseQ0KIGFuZCB0aGVuIGRl bGV0ZSBhbGwgY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRl eHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW3PR11MB4570250AC1693BD65241A638C1400MW3PR11MB4570namp_-- From nobody Fri Aug 14 11:53:58 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAE53A11D6; Fri, 14 Aug 2020 11:53:53 -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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 7jEFyU9LwLku; Fri, 14 Aug 2020 11:53:52 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 2A2AE3A11E3; Fri, 14 Aug 2020 11:53:49 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id c10so5957616pjn.1; Fri, 14 Aug 2020 11:53:49 -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=fFppN0z6+89H7YOWf9YPBmozkPeP71ILw0uP6nJb4Pg=; b=uaTBsmDBSKkFj2kCdp99r2vxajucK6zTlTBRtGacJtWYGRsVP6rIcXFal2ozCokEAN mxdW0uCB+fO1gaCPM6Esj5RrCTUo+uQDP3ne4Tn5CgnpS0qwYjiF7CpT7dpjRFOnbFJf vRcgOMCy9ZaQTSbrnad1f05gVh5OcmBVLL0m/T+9E5w9m1pd0x1cjwUtlI9N73thfnKn QCjuVVMbqycyE01Vig0BxP6zob5aBwusnql8uPbXgQouvHGV+Pgr2vBl3odfUw9jaiHE A3jwsaZNSmfjBUuKNnJLh9swaswHvJrwFEmt4bz4v+Sg7vXEql0dkL0iIFQxW+obo3MQ TvXw== 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=fFppN0z6+89H7YOWf9YPBmozkPeP71ILw0uP6nJb4Pg=; b=XtthGA/wnfTmBrkcZqShiWl38djmZ+1e5nZvwlH+z3QLfIwKovxOsgahkPfC62JvOX b2alMgGHR7N+yV2R45A9Yuobnn7S+4AkWwJTwFIOz3e2eF7/qL+jr60IbjLA98hSSnoj uz30FBfJkuWuR0/SXNSoSPtG7Rtp3E6JCZ2t/zVGAUm4krKNIxSqnYjfPno2c3GfHGOC b1pEkM+FcY7y8l5lc677nCwy1sfK3UoI+xgOlS7g06jWRW/eJj2o1NApfnVyxcu29W1y Vr9e7UtDhRIB/0pLyNJ/eQ/RnuhPHbP3qY/OWq6/l9c+pUtL2yPPqUfd+FtquD66Fa8q X7GA== X-Gm-Message-State: AOAM532+pIM9pWrnhXsulEU3+xM1UqtZZtes5Fo96/zMlsEhYESm0SQI 1CD1R/i+B2Pk6QqDXrX2Pb0= X-Google-Smtp-Source: ABdhPJyxO9r4M8SSuYQwfHWHPu1O09/jTxGNHq6KLoZU0rjEuUHk/vBJKfrLEEcYNeQqIrTJPu2rwA== X-Received: by 2002:a17:902:b402:: with SMTP id x2mr2861371plr.309.1597431228544; Fri, 14 Aug 2020 11:53:48 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id b23sm9796355pfo.12.2020.08.14.11.53.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2020 11:53:47 -0700 (PDT) Date: Fri, 14 Aug 2020 11:53:36 -0700 From: Jeff Tantsura To: "=?utf-8?Q?Thomas.Graf=40swisscom.com?=" , "=?utf-8?Q?hannes=40gredler.at?=" , "Ketan Talaulikar (ketant)" Cc: "=?utf-8?Q?lsr=40ietf.org?=" , SPRING WG Message-ID: <1d8fb113-41c8-46cc-bfa3-54c04d406142@Spark> In-Reply-To: References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> X-Readdle-Message-ID: 1d8fb113-41c8-46cc-bfa3-54c04d406142@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f36ddba_3804823e_1640" Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 18:53:54 -0000 --5f36ddba_3804823e_1640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline In general, I agree with what Ketan said, what=E2=80=99s important - it i= s the value that is being used in forwarding, even if multiple control pl= ane entries exist, think about IGP migrations, or LDP to SR, where more t= han 1 protocol could be distributing the labels/SIDs. I=E2=80=99m not sur= e the =46IB is the right place to collect this data though, since most of= meta-data has already been lost (flattened =46IB structures often contai= n bare minimum) and really heavily depends on the implementation. Cheers, Jeff On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (ketant) , wrote: > < also copying Spring WG for their review/inputs > > > Hi Thomas/All, > > I have reviewed the draft and would like to share a different perspecti= ve. > > What or how much value be there on determining whether a SR Prefix SID = was signalled/programmed on a node via OSP=46v2/OSP=46v3/ISIS =E2=80=93 w= hat matters and is more important is that it is a Prefix SID. Hardly any = deployments would be running multiple protocols and learning the same pre= fix from different IGPs. IP=46IX may be picking this information from a =46= IB in some implementation where the protocol does not matter and this inf= ormation is not available therein. > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 what would we use/show=3F > > I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID= , SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type. > > This also takes away the need for the second table that is being propos= ed to a large extent. =46or that table proposal, it is very difficult and= in some cases not possible to different between Prefix and Node and Anyc= ast SID. Many of these types are control plane elements and we can be sur= e more get added. Is there really much value in differentiation between s= ay an Adjacency SID and LAN Adjacency SID=3F > > Could we evaluate the implementation overhead and complexity of this le= vel of categorization/information in IP=46IX against their value in flow = analysis to perhaps consider a middle ground=3F > > Thanks, > Ketan > > =46rom: Lsr On Behalf Of Thomas.Graf=40swissco= m.com > Sent: 31 July 2020 20:52 > To: hannes=40gredler.at > Cc: lsr=40ietf.org > Subject: Re: =5BLsr=5D draft-tgraf-ipfix-mpls-sr-label-type > > Hi Hannes, > > Thanks a lot for the feedback. Yes, makes completely sense. Will take i= t for the next update... > > Best Wishes > Thomas > > > =46rom: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM > To: Graf Thomas, INI-NET-DC=46 > Cc: lsr=40ietf.org > Subject: Re: =5BLsr=5D draft-tgraf-ipfix-mpls-sr-label-type > > Thomas, > > I have one comment/suggestion to Paragraph 4 (IANA Considerations). > > Please add also a code point for BGP Prefix-SID - it=E2=80=99s quite po= pular in DC deployments. > https://tools.ietf.org/html/rfc8669 > > thanks, > > /hannes > > > On 28.07.2020, at 10:11, Thomas.Graf=40swisscom.com wrote: > > > > Dear lsr, > > > > I presented the following draft > > > > Export of MPLS Segment Routing Label Type Information in IP =46low In= formation Export (IP=46IX) > > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 > > > > at the spring working group at IET=46 108 yesterday > > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow= -information-export-ipfix-00.pdf > > > > and today at OPSAWG where I call for adoption. > > > > This draft adds additional segment routing code points for in the IAN= A IP=46IX registry for IS-IS, OPS=46v2 and OPS=46 v3 and segment routing = SID types to gain further insights into the MPLS-SR forwarding-plane. > > > > I have been asked to not only gather feedback from spring and opsawg = but also from lsr and mpls working groups since these code points are rel= ated to link state routing protocols and mpls data plane. > > > > I am looking forward to your feedback and input. > > > > Best Wishes > > Thomas Graf > > =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 > > =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 > spring mailing list > spring=40ietf.org > https://www.ietf.org/mailman/listinfo/spring --5f36ddba_3804823e_1640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
In general, I agree with what Ketan said, what=E2=80= =99s important - it is the value that is being used in forwarding, even i= f multiple control plane entries exist, think about IGP migrations, or LD= P to SR, where more than 1 protocol could be distributing the labels/SIDs= . I=E2=80=99m not sure the =46IB is the right place to collect this data = though, since most of meta-data has already been lost (flattened =46IB st= ructures often contain bare minimum) and really heavily depends on the im= plementation.&=23160;

Cheers,
Jeff
On Aug 14, 2020, 10:36 AM -0700, Ke= tan Talaulikar (ketant) <ketant=3D40cisco.com=40dmarc.ietf.org>, wr= ote:

< also copying Spring WG for their review/inputs >

&=23160;

Hi Thomas/All,

&=23160;

I have reviewed the draft and would like to share a different perspectiv= e.

&=23160;

What or how much value be there on determining whether a SR Prefix SID w= as signalled/programmed on a node via OSP=46v2/OSP=46v3/ISIS =E2=80=93 wh= at matters and is more important is that it is a Prefix SID. Hardly any d= eployments would be running multiple protocols and learning the same pref= ix from different IGPs. IP=46IX may be picking this information from a =46= IB in some implementation where the protocol does not matter and this inf= ormation is not available therein.

&=23160;

On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 what would we use/show=3F

&=23160;

I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID,= SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type.

&=23160;

This also takes away the need for the second table that is being propose= d to a large extent. =46or that table proposal, it is very difficult and = in some cases not possible to different between Prefix and Node and Anyca= st SID. Many of these types are control plane elements and we can be sure= more get added. Is there really much value in differentiation between sa= y an Adjacency SID and LAN Adjacency SID=3F

&=23160;

Could we evaluate the implementation overhead and complexity of this lev= el of categorization/information in IP=46IX against their value in flow a= nalysis to perhaps consider a middle ground=3F

&=23160;

Thanks,

Ketan

&=23160;

=46rom: L= sr <lsr-bounces=40ietf.org> On Behalf Of Thomas.Graf=40swiss= com.com
Sent: 31 July 2020 20:52
To: hannes=40gredler.at
Cc: lsr=40ietf.org
Subject: Re: =5BLsr=5D draft-tgraf-ipfix-mpls-sr-label-type=

&=23160;

Hi Hannes,

&=23160;

Thanks a lot for the feedback. Yes, makes complet= ely sense. Will take it for the next update...

&=23160;

Best Wishes

Thomas

&=23160;

&=23160;

=46rom: H= annes Gredler <hannes=40gre= dler.at>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DC=46 <Thomas.Graf=40swisscom.com>
Cc: lsr=40ietf.org
= Subject: Re: =5BLsr=5D draft-tgraf-ipfix-mpls-sr-label-type=

&=23160;

Thomas,

&=23160;

I have one comment/suggestion to Paragraph 4 (IANA Considerations).

&=23160;

Please add also a code point for BGP Prefix-SID - it=E2=80=99s quite pop= ular in DC deployments.

&=23160;

thanks,

&=23160;

/hannes

&=23160;

On 28.07.2020, at 10:11, Thomas.Graf=40swisscom.com wrote:

&=23160;

Dear lsr,<= /span>

&=23160;

I presented the following draft

&=23160;

Export of MPLS Segment Routing Label Type Information in IP =46lo= w Information Export (IP=46IX)

&=23160;

at the spring working group at IET=46 108 yesterday

&=23160;

and today at OPSAWG where I call for adoption.

&=23160;

This draft adds additional segment routing code points for in the= IANA IP=46IX registry for IS-IS, OPS=46v2 and OPS=46 v3 and segment rout= ing SID types to gain further insights into the MPLS-SR forwarding-plane.=

&=23160;

I have been asked to not only gather feedback from spring and ops= awg but also from lsr and mpls working groups since these code points are= related to link state routing protocols and mpls data plane.

&=23160;

I am looking forward to your feedback and input.

&=23160;

Best Wishes

Thomas Graf

=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<= br /> Lsr mailing list
 Lsr=40= ietf.org
 https://www.ietf.org/mailman/listinfo/lsr

&=23160;

=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
spring mailing list
spring=40ietf.org
https://www.ietf.org/mailman/listinfo/spring
--5f36ddba_3804823e_1640-- From nobody Fri Aug 14 14:16:14 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7769B3A0B3F for ; Fri, 14 Aug 2020 14:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, PDS_BTC_MSGID=0.998, SPF_HELO_NONE=0.001, 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 S5pPZddeGV-K for ; Fri, 14 Aug 2020 14:15:35 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 910A83A097D for ; Fri, 14 Aug 2020 14:15:35 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id c6so4996231pje.1 for ; Fri, 14 Aug 2020 14:15:35 -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=IyV5khfCDFLuzEz14uBPy7+5Asp0X1Ge3TPSZYcnBa4=; b=fiflXyINmBd5N12Dphl8bG+n/4W6Nfo4pqb0/0VZzjix4LaiQ1t6mm0qLOaSwIxLW8 qklKfkMdbNhE79+95T+yI1vsFagp41085+jnwyu5aqbuZnmT5kK+I04jsOqj65KV+IF7 tPlm25coYptjCKhDYKIw+YOgsQsxQbfoAsEekITXKwfLRf2/B2UCA48kSTAHK9X8Alk0 JnS9fIUSGL9SfhQSLJ7Ki9JfPgIY0Dz1AMbvR1R+dDV0AgjZgi4ch5Fd2r4+UVDwdltD WfY1LegC/4Nte3ziD7X7X35vES7GFq9GUavJuJfY0B30+a+6/kXmRQ7TdAeFUJ/jLUDg cmwg== 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=IyV5khfCDFLuzEz14uBPy7+5Asp0X1Ge3TPSZYcnBa4=; b=sZr9lMpBbFeWYgO4O3kU5OM8RRgf361GazOHQC1BFh5SQ2UsURlGGWUf2ZOx4BsY/X TZQWBCk/tZLai/qUeOEwjWsXM8ALbOH0iGVdARYOBR5SaDJ/BG+oNuziLyw/TTAC+vbM b4Gjio+hCeR/wRckd5crXr1OKauRkvQNGg8Mqmq7PkuOJjx+5SuufI2z6FqBtlaNtbbG +bSTgnJDRuSrM6kFpG9ER2Y33uLeBD74U+t6Ys5hyM5pJXp5AWOPQvY0KG1nyE3BKu2Q apuhjh1eL+VA8yVFS1sbfSG5DC9Ut5NEm5Dc3q5FHAJRRmIwvp0Om8anA+rGuJj7mf3A Malg== X-Gm-Message-State: AOAM531PCHMpaT+7BgDpgg0XQAApzLFUSxU+fv5ss5RrpHpaydMf4DNA rReXMdS2Hc+jBdCvpDC9t0M= X-Google-Smtp-Source: ABdhPJyAK6EVM5lzDe4a3P/GJL64NBSyzIFPyOJhl49v9fCztf0IU7rvGQ79ecPoriQzrgN2tTksLw== X-Received: by 2002:a17:902:bd82:: with SMTP id q2mr3192825pls.226.1597439734663; Fri, 14 Aug 2020 14:15:34 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id f12sm9483998pgr.8.2020.08.14.14.15.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2020 14:15:33 -0700 (PDT) Date: Fri, 14 Aug 2020 14:15:25 -0700 From: Jeff Tantsura To: Robert Raszuk , "Ketan Talaulikar (ketant)" Cc: Alexander Vainshtein , "=?utf-8?Q?spring=40ietf.org?=" , "Joel M. Halpern" , Shraddha Hegde , "=?utf-8?Q?EXT-Andrew.Alston=40liquidtelecom.com?=" Message-ID: <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> In-Reply-To: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> X-Readdle-Message-ID: 2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f36fef2_625558ec_65d7" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 21:15:48 -0000 --5f36fef2_625558ec_65d7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This is very similar to RSVP-TE, path vs link/node protection and usually= dictated by the business logic, the triggers are obviously very differen= t, head-end being notified of the failure on a path and switching to the = backup path vs reaction to a local failure, so same considerations apply:= -more state -pre-reserved resources while -predictable -meets SLA (as good as primary) vs -less state -local -best effort / can cause congestions Cheers, Jeff On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) , wrote: > Hi Robert, > > We do not have a signalling mechanism in IGPs today to indicate a =E2=80= =9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was a desire= for it, an IGP extension would be required (there is none in progress A=46= AIK). Note that this results in doubling the prefix SID scale (global lab= els) in the network. So I would not go about this trivially. > > I think it helps to get more inputs and perspectives from operators on = their views for doing a bypass via local protection for segments in an SR= Policy. There may be those that prefer end-to-end path protection using = a fallback path that is say disjoint with the primary but provides an app= ropriate SLA/intent=3F > > Thanks, > Ketan > > =46rom: Robert Raszuk > Sent: 14 August 2020 23:04 > To: Ketan Talaulikar (ketant) > Cc: Alexander Vainshtein ; Joel M. Hal= pern ; Shraddha Hegde ; EX= T-Andrew.Alston=40liquidtelecom.com ; = spring=40ietf.org > Subject: Re: =5Bspring=5D Spring protection - determining applicability= > > Ketan, > > Looks like we are pretty much in sync here. > > But let me just observe that I purposely=C2=A0did not mention about SR = policies as we are not able to signal the intent with the packets itself.= > > So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded w= ith information if policies build with using them are bypass eligible or = not. > > I was actually under the impression that this is already there and I am= just not aware, but looking deeper indeed I do not see this marking neit= her in ISIS nor OSP=46 for prefix SIDs. > > Is there some work in progress to add it to those protocols or have we = just documented need=C2=A0for a short LSR draft=C2=A0 =3F > > Thx, > R. > > > On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) wrote: > > quote=5Ftype > > Hi Robert, > > > > Please check inline below. > > > > =46rom: Robert Raszuk > > Sent: 14 August 2020 21:13 > > To: Ketan Talaulikar (ketant) > > Cc: Alexander Vainshtein ; Joel M. H= alpern ; Shraddha Hegde ; = EXT-Andrew.Alston=40liquidtelecom.com = ; spring=40ietf.org > > Subject: Re: =5Bspring=5D Spring protection - determining applicabili= ty > > > > Hi Ketan, > > > > While I completely agree with your note the consequences of it are pr= etty sevre. > > =5BKT=5D I understand. We need to be mindful of implications of prote= ction schemes for the SLAs/intent of SR Policies. > > > > Unless we signal which prefix SID is protection eligible and which is= not how would other nodes know if they can protect it or not =3F > > =5BKT=5D Correct. To be more accurate, we need to consider this more = in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and whic= h segments may be =E2=80=9Cbypass-able=E2=80=9D for local protection for = some of those SR Policies. We also have path-protection mechanisms. > > > > It seems that today's safe thing is not to apply any node protection = on SR flows at the PLRs then. > > > > And link protection MUST assure that packets will arrive at the neigh= bor node via some other link regardless of further path towards destinati= on. > > =5BKT=5D Yes. We have a mechanism to indicate which adj-SIDs have pro= tection (that mechanism only provides link protection to get to the neigh= bor node) so the SR Policy computation is able to indicate whether that s= pecific link is =E2=80=9Cbypass-able=E2=80=9D or not by its choice of pro= tected or unprotected adj-SIDs respectively. > > > > Thanks, > > Ketan > > > > Is it correct =3F > > > > Thx > > R > > > > On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) wrote: > > > quote=5Ftype > > > Hi Sasha, > > > > > > The service node advertises its own Prefix SID. The service functio= n that this service node implements does not require any context (i.e. al= l packets arriving at the node are subjected to that service). Therefore = the service node does not need to receive a packet with it=E2=80=99s own = Prefix SID. > > > > > > Thus, we cannot assume that when PHP is used, then the SID is only = associated with a topological instruction. > > > > > > Hope that clarifies=3F > > > > > > Thanks, > > > Ketan > > > > > > =46rom: Alexander Vainshtein > > > Sent: 14 August 2020 20:24 > > > To: Ketan Talaulikar (ketant) ; Joel M. Halpern= ; Shraddha Hegde ; EXT-An= drew.Alston=40liquidtelecom.com ; Robe= rt Raszuk > > > Cc: spring=40ietf.org > > > Subject: Re: =5Bspring=5D Spring protection - determining applicabi= lity > > > > > > Ketan, and all, > > > I have stated that, IMHO and =46WIW, both Adj-SIDs and Prefix SIDs = that are advertised with PHP can=C2=A0 ONLY represent topological instruc= tions in SR-MPLS - because the advertising node will not receive them and= therefore can hardly be expected to associate any service function with = them. > > > > > > This is complementary to what you have said. > > > > > > Hope this clarifies my position. > > > What, if anything, did I miss=3F > > > > > > Regards, > > > Sasha > > > > > > Get Outlook for Android > > > > > > =46rom: Ketan Talaulikar (ketant) > > > Sent: =46riday, August 14, 2020, 16:23 > > > To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andr= ew.Alston=40liquidtelecom.com; Robert Raszuk > > > Cc: spring=40ietf.org > > > Subject: RE: =5Bspring=5D Spring protection - determining applicabi= lity > > > > > > NOTICE: This email was received from an EXTERNAL sender > > > > > > Hi Sasha, > > > > > > If the service does not need any additional context (e.g. a firewal= l that just applies locally configured default rules on it), then I don=E2= =80=99t see why PHP could not be done for a Prefix SID associated with a = service node. > > > > > > Also, I didn=E2=80=99t follow the point that you were trying to mak= e about Adj-SIDs. > > > > > > Thanks, > > > Ketan > > > > > > =46rom: Alexander Vainshtein > > > Sent: 14 August 2020 18:24 > > > To: Ketan Talaulikar (ketant) ; Joel M. Halpern= ; Alexander Vainshtein ; Shraddha Hegde ; EXT-Andrew.Alston=40liq= uidtelecom.com ; Robert Raszuk > > > Cc: spring=40ietf.org > > > Subject: Re: =5Bspring=5D Spring protection - determining applicabi= lity > > > > > > Hi all, > > > Regarding the statement =22Prefix SID could be just a topological i= nstruction or may also be used to steer the flow to a node which is apply= ing a service function to it=22: > > > > > > > > > I think that in SR-MPLS a Node SID that is advertised with PHP acit= on can be safely considered as =22just a topological instruction=22 by th= e PLR because the originating node will not receive it. > > > The same applies to Adj-SDIs. > > > > > > My 2c. > > > > > > Get Outlook for Android > > > > > > =46rom: spring on behalf of Ketan Talau= likar (ketant) > > > Sent: =46riday, August 14, 2020, 15:00 > > > To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andr= ew.Alston=40liquidtelecom.com; Robert Raszuk > > > Cc: spring=40ietf.org > > > Subject: Re: =5Bspring=5D Spring protection - determining applicabi= lity > > > > > > Hi All, > > > > > > I would like to share a different perspective on this. > > > > > > =46irst, thanks to Joel for bringing up the discussion. Clearly we = need a well-defined applicability statement for determining applicability= of protection for segment used in an SR Policy. Some of this is captured= in =5B1=5D. > > > > > > This is about local repair at a PLR. By it's very nature, the PLR d= oes not have a notion of how =22strict or not=22 is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Pol= icy headend and/or computation-node. > > > > > > We have protected and un-protected variants of adjacency SIDs to en= able the computation to pick or the other based on the =22strictness=22 o= f the SLA requirement for picking that link. We do not have such a notion= for Prefix SIDs. One can say that we could introduce signalling (e.g. a = B flag) to indicate whether a Prefix SID can be bypassed or not. This pro= vides the opportunity for the computation to use one or the other flavor = depending on the nature of the SLA for the SR Policy. > > > > > > I have a problem and a concern in the assumption that PLRs can assu= me that the currently defined variant of Prefix SIDs in R=46C8402 (and IG= P specs) are =22bypass-able=22. > > > > > > As Joel and others have brought out, the Prefix SID could be just a= topological instruction or may also be used to steer the flow to a node = which is applying a service function to it. In order to support a mix of = SR Policies of different SLAs (strict and not-strict), we need to enable = the choice of SIDs that indicates to the PLR whether they are =22bypass-a= ble=22 or not. > > > > > > =46or the cases, where the SR Policy has a specific SLA, it is requ= ired for nodes to drop the packets meant for the =22active segment=22 tha= n to bypass it. When this mechanism is used along side SRTE path monitori= ng mechanisms, it enables the headend to detect the failure and fallback = to an alternate path using the path protection approach. This is somethin= g that is described and in use in deployments today =5B1=5D.. > > > > > > Thanks, > > > Ketan > > > > > > =5B1=5D https://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWwUms6H2= =3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-se= gment-routing-policy-08%23section-9 > > > =5B2=5D https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2=3F= u=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segme= nt-routing-policy-08%23section-9.3 > > > > > > -----Original Message----- > > > =46rom: spring On Behalf Of Joel M. Hal= pern > > > Sent: 04 August 2020 20:25 > > > To: Alexander Vainshtein ; Shraddh= a Hegde ; EXT-Andrew.Alston=40= liquidtelecom.com ; Robert Raszuk > > > Cc: spring=40ietf.org; Joel M. Halpern > > > Subject: Re: =5Bspring=5D Spring protection - determining applicabi= lity > > > > > > There are, as far as I can tell, a number of ways to address this f= amily of related questions. > > > What struck me, and prompted the starting question, was that none o= f them were spelled out.=C2=A0 I see lots of interesting ideas / proposal= s. > > > Some of them are compatible with others.=C2=A0=C2=A0 Some are not. > > > It would be good if we could reach agreement on how we thought it s= hould be handled. > > > > > > Thank you, > > > Joel > > > > > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > > > Hi all, > > > > > > > > I am still not sure that the problem of bypass going thru undesir= able > > > > links/nodes exists in the case of topological SIDs. > > > > > > > > A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090 > > > > ) has been successfu= lly deployed > > > > for many years before SR-MPLS has been introduced. What=E2=80=99s= more, > > > > signaling of bypass tunnels he PLR usually did not include any of= the > > > > constraints used for computing of any specific LSP that the bypas= s LSP > > > > would protect =E2=80=93 because in the =46acility Protection mode= the same > > > > bypass LSP would be used to protect multiple LSPs passing thru th= e > > > > failed link/node. > > > > > > > >=C2=A0 =46rom my POV the only difference between this behavior and= that > > > > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is tha= t, in the case of > > > > RSVP-TE, the operator would explicitly indicate, as part of LSP > > > > signaling, whether it would or would not use =46RR; LSPs that wou= ld not > > > > use =46RR would then drop traffic rather than delivering it the w= rong way. > > > > > > > > Such an option indeed does not exist in SR-TE today, but would be= easy > > > > to provide if so desired IMHO. > > > > > > > > Did I miss something substantial=3F > > > > > > > > Regards, and lots of thanks in advance, > > > > > > > > Sasha > > > > > > > > Office: +972-39266302 > > > > > > > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302 > > > > > > > > Email:=C2=A0=C2=A0 Alexander.Vainshtein=40ecitele.com > > > > > > > > *=46rom:* spring *On Behalf Of *Shrad= dha Hegde > > > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > > > *To:* EXT-Andrew.Alston=40liquidtelecom.com > > > > ; Robert Raszuk > > > > *Cc:* spring=40ietf.org; Joel M. Halpern > > > > *Subject:* Re: =5Bspring=5D Spring protection - determining appli= cability > > > > > > > > All, > > > > > > > > This is a very interesting discussion and thanks to Joel for star= ting > > > > this discussion. IMO, when there are strict requirements of avoid= ing > > > > certain nodes/links it can be realized=C2=A0 either by defining a= flex-algo > > > > avoiding those > > > > > > > > Nodes and links or by using a stack of unprotected adj-sids that = avoid > > > > restricted nodes and links. When a stack of adj-sids is used to > > > > realize the path, the head-end based (sB=46D) protection mechanis= ms can be applied. > > > > > > > > If Node-sids/prefix-sid/anycast-sids are used to build the stack,= the > > > > failure events may cause traffic to go through restricted nodes a= nd > > > > links. This would happen regardless of whether any kind of protec= tion > > > > is in use or not. > > > > > > > > Rgds > > > > > > > > Shraddha > > > > > > > > Juniper Business Use Only > > > > > > > > *=46rom:* spring > > > > *On Behalf Of *Andrew Alston > > > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > > > *To:* Robert Raszuk > > > > > *Cc:* spring=40ietf.org ; Joel M. Halpe= rn > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determining appli= cability > > > > > > > > *=5BExternal Email. Be cautious of content=5D* > > > > > > > > Robert this is actually far more difficult when =E2=80=93 it can = be an entire > > > > (long) series of nodes that need to be avoided. > > > > > > > > It could potentially be made to work but I=E2=80=99d worry that t= o do this =E2=80=93 > > > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative= labels =E2=80=93 and that wouldn=E2=80=99t > > > > be viable. > > > > > > > > It=E2=80=99s easier to use algorithms and adjacency sids and othe= r such things > > > > to calculate paths =E2=80=93 the biggest trick is about the stack= depth.=C2=A0 When > > > > you have this need for node avoidance =E2=80=93 the need for 10+ = label depth > > > > is critical =E2=80=93 unless you wanna be applying one hell of a = lot of > > > > binding labels along the way which is a nightmare. > > > > > > > > But to answer your question, is this a common use case =E2=80=93 = it=E2=80=99s a use > > > > case that most of the people I discuss this with certain have =E2= =80=93 I cant > > > > comment on a global scale, or for anyone else, but every indicati= on I > > > > have is that yes =E2=80=93 its something people need, and want > > > > > > > > Andrew > > > > > > > > *=46rom:* Robert Raszuk > > > > > *Sent:* Tuesday, 4 August 2020 01:27 > > > > *To:* Andrew Alston > > > > > > > > *Cc:* Joel M. Halpern > > > >; spring=40ietf.org > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determining appli= cability > > > > > > > > Is this a common use case ie.=C2=A0 =22but rather =E2=80=93 which= nodes / network > > > > segments it can never touch or flow through.=22 > > > > > > > > If so perhaps its time to define notion of *negative-SID* ie. lis= t in > > > > the packet resources which given=C2=A0packet MUST not ever traver= se. > > > > > > > > Put in the packet set of nodes or links which the packet should n= ever > > > > traverse. > > > > > > > > That goes in line of recent wave of negative routing implementati= ons > > > > (RI=46T) or discussions (LSR) > > > > > > > > Best, > > > > R. > > > > > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > > > > > > wrote: > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very = major use cases in any > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve around t= he following > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain nodes= > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain secti= ons of the network > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that explic= it avoidance being violated > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say sign= ificant problems. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case of whi= ch nodes the packets flow > > > >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 wh= ich nodes / network segments it can never > > > >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effectively,= to be used as a technology to > > > >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific reasons= . > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for needi= ng such deep label stacks =E2=80=93 > > > >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming te= nds to deepen the stack > > > >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pretty e= xplicit. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this= functionality is there =E2=80=93 > > > >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations which co= uld cause traffic to > > > >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly avoided.= > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than this= , but it is what it is. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *=46rom:* spring > > >=C2=A0=C2=A0=C2=A0=C2=A0 > *On B= ehalf Of *Joel M. Halpern > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36 > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring=40ietf..org > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: =5Bspring=5D Spring protec= tion - determining > > > > applicability > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long enough,= reiterating that this is as a > > > >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.) > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. And yes,= I have seen IP networks that > > > >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. =46or all sorts o= f reasons. > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons wh= y one may not want a random > > > >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. I thin= k it is important we be clear > > > >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are viola= ted when we tell people they > > > >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerouting) tha= t is intended to preserve QoS. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing that thi= s is not a good idea. It is a > > > >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying to fig= ure otu what combination of > > > >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descripti= ons will lead to everyone > > > >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (which m= ay not be the behavior they > > > >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can = do.) > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yours, > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Joel > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:= > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about IP net= works=C2=A0here =3F Or perhaps some hard > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reserv= ations or detnets =3F > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talking=C2= =A0about IP networking I have two > > > >=C2=A0=C2=A0=C2=A0=C2=A0 observations: > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via a = specific node (ie. firewall) you > > > >=C2=A0=C2=A0=C2=A0=C2=A0 better > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to that no= de.. I don't think IP > > > >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that desti= nation address of the packet is > > > >=C2=A0=C2=A0=C2=A0=C2=A0 ignored. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP network w= here upon topology change (link > > > >=C2=A0=C2=A0=C2=A0=C2=A0 or node > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0start = dropping=C2=A0flows in spite of SPT offering > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path with 1= 0 ms more jitter =3F > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing slides p= romise to turn IP networks in > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new =3F Worse ... = do they mention path quality guarantees, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0=3F I = hope not. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R. > > > >=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10 PM Jo= el M. Halpern > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > wrote: > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SIDs, I = am not sure the problem is > > > >=C2=A0=C2=A0=C2=A0=C2=A0 restricted > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has specifie= d the path to meet some complex te > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass node = has no way of knowing what those > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some kinds of= traffic, it is better to drop the packet > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside the en= velop.=C2=A0 I suspect that the right > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is =22too bad=22.=C2=A0 I= f so, as with the distinction regarding > > > >=C2=A0=C2=A0=C2=A0=C2=A0 service > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn'= t we=3F > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexander Va= inshtein wrote: > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most cases: > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differentiatio= n between =22topological=22 and > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =22service=22 > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID advertiseme= nts. E.g.: > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-S= IDs (identified as such in the > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP advertisement= s) represent topological > > > >=C2=A0=C2=A0=C2=A0=C2=A0 instructions > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (see SRv= 6 BGP-Based Overlay Services > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly represent= =E2=80=9Cservice=E2=80=9D instructions > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent topol= ogical instructions can be bypassed, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that represent s= ervice instructions require > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be aligned w= ith R=46C 8402 > > > >=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 that says in Section 1: > > > >=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 In the conte= xt of an IGP-based distributed control plane, two > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are define= d: the IGP-Adjacency segment and the > > > >=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 IGP-Prefix s= egment. > > > >=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 In the conte= xt of a BGP-based distributed control plane, two > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are define= d: the BGP peering segment and the > > > >=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 BGP-Prefix s= egment. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this dif= ferentiation is assumed in Section > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for SR-TE P= ath > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft that says: > > > >=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 The node pro= tection mechanism described in the previous > > > >=C2=A0=C2=A0=C2=A0=C2=A0 sections > > > >=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 depends on t= he assumption that the label immediately below > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack is und= erstood in the IGP domain.=C2=A0 When the > > > >=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 provider edg= e routers exchange service labels via BGP or some > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other > > > >=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 non-IGP mech= anism the bottom label is not understood in the IGP > > > >=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 domain. > > > >=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 The egress n= ode protection mechanisms described in the draft > > > >=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 =5BR=46C8679= > > >=C2=A0=C2=A0=C2=A0=C2=A0 >=5D > > > >=C2=A0=C2=A0=C2=A0=C2=A0 is > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use case and= no additional changes > > > >=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 will be requ= ired for SR based networks > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2=A0di= fferentiation between =E2=80=9Ctopological=E2=80=9D and > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D instr= uctions is broken are indeed problematic. E.g., > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a Node SI= D in the ERO of a SR-TE path > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firewall fo= r all packets it receives, i.e., > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service without an= y dedicated service SID > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the Node SID= of such a node would combine > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus b= reaking the differentiation > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of such = =E2=80=9Ccombined=E2=80=9D SIDs could be prevented > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ability to= identify such SIDs in the > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMHO= . > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302 > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +972-549266302 > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein=40e= citele.com > > > >=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 > > -----Original Message----- > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =46rom: spring > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > On Be= half Of Mach Chen > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2020 6:= 30 AM > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern > > >=C2=A0=C2=A0=C2=A0=C2=A0 > >; > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: =5Bspring=5D Sprin= g protection - determining applicability > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good point th= at may not be discussed in the > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there is a =22= can be bypassed=22 indication in the > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information advertise= d by routing is neutral, such > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypassed) is = more path specific, thus > > > >=C2=A0=C2=A0=C2=A0=C2=A0 normally the > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be responsibl= e for deciding whether/which SID > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Message--= --- > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46rom: spring =5Bmailt= o:spring-bounces=40ietf.org > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =5D > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, August 3,= 2020 7:51 AM > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring=40ietf.org <= mailto:spring=40ietf.org> > > > >=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 > Subject: =5Bspring=5D S= pring protection - determining applicability > > > >=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 > (WG Chair hat Off, this= is merely a note from a slightly > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.) > > > >=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 > I have been reading the= various repair drafts, and the various > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programming an= d service programming draft, and I am > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspect o= f the combination. > > > >=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 > How does a node that is= doing some form of bypass (suppose, for > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is Node = N2 deciding to bypass the next SID for > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know that it i= s safe to do so=3F > > > >=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 > If the path was just fo= r TE, then it is =22safe=22 if the new path > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2=A0 = or maybe it is safe if it is even close, as > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used for too = long. > > > >=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 > But what if the node we= re a =46irewall, included to meet legal > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements=3F > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other neces= sary programmatic transform (wince we are > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague abou= t what nodes can do when asked suitably.) > > > >=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 > Is there some =22can be= bypassed=22 indication in the routing > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements that I m= issed=3F > > > >=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 > Thank you, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel > > > >=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 > =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 > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing list > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring=40ietf.org > > > >=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=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 https://clicktime.symantec.com/367qhU4KiU= kzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2 > > > >=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=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46%2=46www.ietf.org > > > >=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 >%2=46mailman%2=46l= istinfo%2=46spring > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =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 > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org > > > >=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=A0=C2=A0=C2=A0 https://clicktime.symantec.com/367qhU4KiU= kzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46lis= tinfo%2=46spring > > > >=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=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 > > Notice: This e-mail together wi= th any attachments may contain > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Communica= tions Inc. that is confidential > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole use of= the intended recipient. Any review, > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distrib= ution by others or forwarding > > > >=C2=A0=C2=A0=C2=A0=C2=A0 without > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly = prohibited. If you are not the > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify the se= nder immediately and then delete all > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attachmen= ts. > > > >=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 > > =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 > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symantec.com/= 3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailm= an%2=46listinfo%2=46spring > > > >=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 > =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 > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring mailing list > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring=40ietf.org > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.com/3Q= 1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman= %2=46listinfo%2=46spring > > > >=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 =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 > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring mailing list > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMz= NJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46lis= tinfo%2=46spring > > > > > > > > > > > 2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.or= g%2=46mailman%2=46listi > > > > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oi= QAtQxgm0x0wxqgu > > > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > > > > > > > > > -----------------------------------------------------------------= ----- > > > > -- > > > > Notice: This e-mail together with any attachments may contain > > > > information of Ribbon Communications Inc. that is confidential an= d/or > > > > proprietary for the sole use of the intended recipient. Any revie= w, > > > > disclosure, reliance or distribution by others or forwarding with= out > > > > express permission is strictly prohibited. If you are not the int= ended > > > > recipient, please notify the sender immediately and then delete a= ll > > > > copies, including any attachments. > > > > -----------------------------------------------------------------= ----- > > > > -- > > > > > > =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 > > > spring mailing list > > > spring=40ietf.org > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhtt= ps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > =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 > > > spring mailing list > > > spring=40ietf.org > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhtt= ps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > Notice: This e-mail together with any attachments may contain infor= mation of Ribbon Communications Inc. that is confidential and/or propriet= ary for the sole use of the intended recipient. Any review, disclosure, r= eliance or distribution by others or forwarding without express permissio= n is strictly prohibited. If you are not the intended recipient, please n= otify the sender immediately and then delete all copies, including any at= tachments. > > > > =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 > spring mailing list > spring=40ietf.org > https://www.ietf.org/mailman/listinfo/spring --5f36fef2_625558ec_65d7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
This is very similar to RSVP-TE, path vs link/node = protection and usually dictated by the business logic, the triggers are o= bviously very different, head-end being notified of the failure on a path= and switching to the backup path vs reaction to a local failure, so same= considerations apply:&=23160;
-more state
-pre-reserved resources
while&=23160;
-predictable
-meets SLA (as good as primary)
vs
-less state
-local
-best effort / can cause congestions&=23160;

Cheers,
Jeff
On Aug 14, 2020, 10:46 AM -0700, Ke= tan Talaulikar (ketant) <ketant=3D40cisco.com=40dmarc.ietf.org>, wr= ote:

Hi Robert,

&=23160;

We do not have a signalling mechanism in IGPs today to indicate a =E2=80= =9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was a desire= for it, an IGP extension would be required (there is none in progress A=46= AIK). Note that this results in doubling the prefix SID scale (global lab= els) in the network. So I would not go about this trivially.

&=23160;

I think it helps to get more inputs and perspectives from operators on t= heir views for doing a bypass via local protection for segments in an SR = Policy. There may be those that prefer end-to-end path protection using a= fallback path that is say disjoint with the primary but provides an appr= opriate SLA/intent=3F

&=23160;

Thanks,

Ketan

&=23160;

=46rom: R= obert Raszuk <robert=40raszuk.net>
Sent: 14 August 2020 23:04
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com>; = Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde <shraddh= a=40juniper.net>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Als= ton=40liquidtelecom.com>; spring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Ketan,

&=23160;

Looks like we are pretty much in sync here.&=23= 160;

&=23160;

But let me just observe that I purposely&=2316= 0;did not mention about SR policies as we are not able to signal the inte= nt with the packets itself.&=23160;

&=23160;

So all we have there is SIDs. BSIDs or prefix = SIDs need to be flooded with information if policies build with using the= m are bypass eligible or not.&=23160;

&=23160;

I was actually under the impression that this = is already there and I am just not aware, but looking deeper indeed I do = not see this marking neither in ISIS nor OSP=46 for prefix SIDs.&=23160;<= /p>

&=23160;

Is there some work in progress to add it to th= ose protocols or have we just documented need&=23160;for a short LSR draf= t&=23160; =3F&=23160;

&=23160;

Thx,

R.

&=23160;

&=23160;

On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaul= ikar (ketant) <ketant=40cisc= o.com> wrote:

Hi Robert,

&=23160;

Please check inline below.

&=23160;

=46= rom: Robert Ra= szuk <robert=40raszuk.net>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Hi Ketan,

&=23160;

While I completely agree with your note the consequenc= es of it are pretty sevre.&=23160;

=5BKT=5D I understand. We need to be mindful of = implications of protection schemes for the SLAs/intent of SR Policies.

&=23160;

Unless we signal which prefix SID is protection eligib= le and which is not how would other nodes know if they can protect it or = not =3F&=23160;

=5BKT=5D Correct. To be more accurate, we need t= o consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of= SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for = local protection for some of those SR Policies. We also have path-protect= ion mechanisms.

&=23160;

It seems that today's safe thing is not to apply any n= ode protection on SR flows at the PLRs then.&=23160;

&=23160;

And link protection MUST assure that packets will arri= ve at the neighbor node via some other link regardless of further path to= wards destination.&=23160;

=5BKT=5D Yes. We have a mechanism to indicate wh= ich adj-SIDs have protection (that mechanism only provides link protectio= n to get to the neighbor node) so the SR Policy computation is able to in= dicate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not= by its choice of protected or unprotected adj-SIDs respectively.=

&=23160;

Thanks,

Ketan

&=23160;

Is it correct =3F&=23160;

&=23160;

Thx

R

&=23160;

On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ke= tant) <ketant=40cisco.com> wrote:

Hi Sasha,

&=23160;

The service node advertises its own Prefix SID. The se= rvice function that this service node implements does not require any con= text (i.e. all packets arriving at the node are subjected to that service= ). Therefore the service node does not need to receive a packet with it=E2= =80=99s own Prefix SID.

&=23160;

Thus, we cannot assume that when PHP is used, then the= SID is only associated with a topological instruction.

&=23160;

Hope that clarifies=3F

&=23160;

Thanks,

Ketan

&=23160;

=46= rom: Alexander= Vainshtein <Alexander.Vainshtein=40rbbn.com>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Shraddha Hegde <shraddha=40juniper.ne= t>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.= net>
Cc: spring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

K= etan, and all,

I= have stated that, IMHO and =46WIW, both Adj-SIDs and Prefix SIDs that ar= e advertised with PHP can&=23160; ONLY represent topological instructions= in SR-MPLS - because the advertising node will not receive them and ther= efore can hardly be expected to associate any service function with them.=

&= =23160;

T= his is complementary to what you have said.

&= =23160;

H= ope this clarifies my position.

W= hat, if anything, did I miss=3F

&= =23160;

R= egards,

S= asha

&=23160;

Get Outlook for Android

&=23160;

=46rom: Ketan Talaulikar (ketant) <ketant=40= cisco.com>
Se= nt: =46riday, August 14, 2020, 16:23
To= : Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; = EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk
Cc= : spring=40ietf.org
Su= bject: RE: =5Bspring=5D Spring protection - determining a= pplicability

&=23160;

NOTICE: This email was received from an EXTERNAL sende= r

&=23160;

Hi Sasha,

&=23160;

If the service does not need any additional context (e= .g. a firewall that just applies locally configured default rules on it),= then I don=E2=80=99t see why PHP could not be done for a Prefix SID asso= ciated with a service node.

&=23160;

Also, I didn=E2=80=99t follow the point that you were = trying to make about Adj-SIDs.

&=23160;

Thanks,

Ketan

&=23160;

=46= rom: Alexander= Vainshtein <Alexander.Vainshtein=40rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Alexander Vainshtein <Alexand= er.Vainshtein=40rbbn.com>; Shraddha Hegde <shraddha=40juniper.net<= /a>>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.net= >
Cc: spring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

H= i all,

R= egarding the statement =22Prefix SID could be just a topological instruct= ion or may also be used to steer the flow to a node which is applying a s= ervice function to it=22:

&= =23160;

&= =23160;

I= think that in SR-MPLS a Node SID that is advertised with PHP aciton can = be safely considered as =22just a topological instruction=22 by the PLR b= ecause the originating node will not receive it.

T= he same applies to Adj-SDIs.

&= =23160;

M= y 2c.

&=23160;

Get Outlook for Android

&=23160;

=46rom: spring <spring-bounces=40ietf= .org> on behalf of Ketan Talaulikar (ketant) <ketan= t=3D40cisco.com=40dmarc.ietf.org>
Se= nt: =46riday, August 14, 2020, 15:00
To= : Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; = EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk
Cc= : spring=40ietf.org
Su= bject: Re: =5Bspring=5D Spring protection - determining a= pplicability

&=23160;

Hi All,

I would like to share a different perspective on this.

=46irst, thanks to Joel for bringing up the discussion. Clearly we need a= well-defined applicability statement for determining applicability of pr= otection for segment used in an SR Policy. Some of this is captured in =5B= 1=5D.

This is about local repair at a PLR. By it's very nature, the PLR does no= t have a notion of how =22strict or not=22 is the SLA that is being provi= ded by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable t= he computation to pick or the other based on the =22strictness=22 of the = SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag= ) to indicate whether a Prefix SID can be bypassed or not. This provides = the opportunity for the computation to use one or the other flavor depend= ing on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume tha= t the currently defined variant of Prefix SIDs in R=46C8402 (and IGP spec= s) are =22bypass-able=22.

As Joel and others have brought out, the Prefix SID could be just a topol= ogical instruction or may also be used to steer the flow to a node which = is applying a service function to it. In order to support a mix of SR Pol= icies of different SLAs (strict and not-strict), we need to enable the ch= oice of SIDs that indicates to the PLR whether they are =22bypass-able=22= or not.

=46or the cases, where the SR Policy has a specific SLA, it is required f= or nodes to drop the packets meant for the =22active segment=22 than to b= ypass it. When this mechanism is used along side SRTE path monitoring mec= hanisms, it enables the headend to detect the failure and fallback to an = alternate path using the path protection approach. This is something that= is described and in use in deployments today =5B1=5D..

Thanks,
Ketan

=5B1=5D htt= ps://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2= =46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-pol= icy-08%23section-9
=5B2=5D htt= ps://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46= %2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-policy= -08%23section-9.3

-----Original Message-----
=46rom: spring <spring-bounces=40ietf.org> On Behalf Of Joel M.= Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com>= ;; Shraddha Hegde <shraddha=3D40juniper.net=40dmarc.ie= tf.org>; EXT-Andrew.Alston=40liquidtelecom.com <= ;Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40= raszuk.net>
Cc: spri= ng=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>
Subject: Re: =5Bspring=5D Spring protection - determining applicability
There are, as far as I can tell, a number of ways to address this family = of related questions.
What struck me, and prompted the starting question, was that none of them= were spelled out.&=23160; I see lots of interesting ideas / proposals. Some of them are compatible with others.&=23160;&=23160; Some are not. It would be good if we could reach agreement on how we thought it should = be handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirabl= e
> links/nodes exists in the case of topological SIDs.
>
> A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090
> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs= 6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46rfc4090>) = has been successfully deployed
> for many years before SR-MPLS has been introduced. What=E2=80=99s mo= re,
> signaling of bypass tunnels he PLR usually did not include any of th= e
> constraints used for computing of any specific LSP that the bypass L= SP
> would protect =E2=80=93 because in the =46acility Protection mode th= e same
> bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>&=23160; =46rom my POV the only difference between this behavior and = that
> introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, = in the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use =46RR; LSPs that would = not
> use =46RR would then drop traffic rather than delivering it the wron= g way.
>
> Such an option indeed does not exist in SR-TE today, but would be ea= sy
> to provide if so desired IMHO.
>
> Did I miss something substantial=3F
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:&=23160;&=23160;&=23160;&=23160;&=23160; +972-549266302
>
> Email:&=23160;&=23160; Alexander.Vainshtein=40ecitele.com
>
> *=46rom:* spring <spring-bounces=40ietf.org> *On Behalf Of = *Shraddha Hegde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston=40liquidtelecom.com
> <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk &= lt;rob= ert=40raszuk.net>
> *Cc:* spring=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>
> *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> All,
>
> This is a very interesting discussion and thanks to Joel for startin= g
> this discussion. IMO, when there are strict requirements of avoiding=
> certain nodes/links it can be realized&=23160; either by defining a = flex-algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avo= id
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sB=46D) protection mechanisms = can be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, th= e
> failure events may cause traffic to go through restricted nodes and<= br /> > links. This would happen regardless of whether any kind of protectio= n
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *=46rom:* spring <spring-bounces=40ietf.org
 > = <mailto:spring-bounces=40ietf.org>> *On Behalf Of *Andrew Al= ston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net>>
> *Cc:* spring=40ietf.org <mailto:spring=40ietf.org>; Joel M. Halpern
> <jmh=40joelhalpern.com <mailto:jmh=40joelhalpern.com>> > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> *=5BExternal Email. Be cautious of content=5D*
>
> Robert this is actually far more difficult when =E2=80=93 it can be = an entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=E2=80=99d worry that to d= o this =E2=80=93
> you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative la= bels =E2=80=93 and that wouldn=E2=80=99t
> be viable.
>
> It=E2=80=99s easier to use algorithms and adjacency sids and other s= uch things
> to calculate paths =E2=80=93 the biggest trick is about the stack de= pth.&=23160; When
> you have this need for node avoidance =E2=80=93 the need for 10+ lab= el depth
> is critical =E2=80=93 unless you wanna be applying one hell of a lot= of
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
> case that most of the people I discuss this with certain have =E2=80= =93 I cant
> comment on a global scale, or for anyone else, but every indication = I
> have is that yes =E2=80=93 its something people need, and want
= >
> Andrew
>
> *=46rom:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net= >>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston=40liquidtelecom.= com
 > <mailto:Andrew.Alston=40liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh=40joelhalpern.com
 > <= ;mai= lto:jmh=40joelhalpern.com>>; spring=40ietf.org
> <mailto:spring=40ietf.org>
> *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> Is this a common use case ie.&=23160; =22but rather =E2=80=93 which = nodes / network
> segments it can never touch or flow through.=22
>
> If so perhaps its time to define notion of *negative-SID* ie. list i= n
> the packet resources which given&=23160;packet MUST not ever travers= e.
>
> Put in the packet set of nodes or links which the packet should neve= r
> traverse.
>
> That goes in line of recent wave of negative routing implementations=
> (RI=46T) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston=40liquidtelecom.com
 > &= lt;mailto:Andrew.Alston=40liquidtelecom.com>> wrote:
>
>&=23160;&=23160;&=23160;&=23160; So =E2=80=93
>
>&=23160;&=23160;&=23160;&=23160; One of the use cases, in fact, some = very major use cases in any
>&=23160;&=23160;&=23160;&=23160; spring technology for us revolve aro= und the following
>
>&=23160;&=23160;&=23160;&=23160; a.The explicit avoidance of certain = nodes
>
>&=23160;&=23160;&=23160;&=23160; b.The explicit avoidance of certain = sections of the network
>
>&=23160;&=23160;&=23160;&=23160; Anything that could result in that e= xplicit avoidance being violated
>&=23160;&=23160;&=23160;&=23160; =E2=80=93 would create, shall we say= significant problems.
>
>&=23160;&=23160;&=23160;&=23160; Much of the use case is not a case o= f which nodes the packets flow
>&=23160;&=23160;&=23160;&=23160; through =E2=80=93 but rather =E2=80=93= which nodes / network segments it can never
>&=23160;&=23160;&=23160;&=23160; touch or flow through.&=23160; Effec= tively, to be used as a technology to
>&=23160;&=23160;&=23160;&=23160; avoid certain things for specific re= asons.
>
>&=23160;&=23160;&=23160;&=23160; This is also one of the reasons for = needing such deep label stacks =E2=80=93
>&=23160;&=23160;&=23160;&=23160; this kind of detailed path programmi= ng tends to deepen the stack
>&=23160;&=23160;&=23160;&=23160; because you sometimes have to be pre= tty explicit.
>
>&=23160;&=23160;&=23160;&=23160; It is absolutely critical to us that= this functionality is there =E2=80=93
>&=23160;&=23160;&=23160;&=23160; and that we can avoid situations whi= ch could cause traffic to
>&=23160;&=23160;&=23160;&=23160; accidently hit things explicitly avo= ided.
>
>&=23160;&=23160;&=23160;&=23160; I wish I could be more specific than= this, but it is what it is.
>
>&=23160;&=23160;&=23160;&=23160; Thanks
>
>&=23160;&=23160;&=23160;&=23160; Andrew
>
>&=23160;&=23160;&=23160;&=23160; *=46rom:* spring <spring-bounc= es=40ietf.org
 >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing-bounces=40ietf.org>> *On Behalf Of *Joel M. Halpern
>&=23160;&=23160;&=23160;&=23160; *Sent:* Monday, 3 August 2020 21:36<= br /> >&=23160;&=23160;&=23160;&=23160; *To:* Robert Raszuk <robert=40raszuk.net= <mailto:robert=40raszuk.net>>
>&=23160;&=23160;&=23160;&=23160; *Cc:* spring=40ietf..org <mailto:spring=40ie= tf.org>
>&=23160;&=23160;&=23160;&=23160; *Subject:* Re: =5Bspring=5D Spring p= rotection - determining
> applicability
>
>&=23160;&=23160;&=23160;&=23160; (Since the thread has gotten long en= ough, reiterating that this is as a
>&=23160;&=23160;&=23160;&=23160; participant, not a WG chair.)
>
>&=23160;&=23160;&=23160;&=23160; Yes, we are talking IP networks. And= yes, I have seen IP networks that
>&=23160;&=23160;&=23160;&=23160; choose to drop packets. =46or all so= rts of reasons.
>&=23160;&=23160;&=23160;&=23160; I think there are likely other reaso= ns why one may not want a random
>&=23160;&=23160;&=23160;&=23160; path rather than a chosen TE path. I= think it is important we be clear
>&=23160;&=23160;&=23160;&=23160; about what constraints may be / are = violated when we tell people they
>&=23160;&=23160;&=23160;&=23160; have this tool (protective rerouting= ) that is intended to preserve QoS.
>
>&=23160;&=23160;&=23160;&=23160; Let's be clear. I am not arguing tha= t this is not a good idea. It is a
>&=23160;&=23160;&=23160;&=23160; good idea. And useful. I am trying t= o figure otu what combination of
>&=23160;&=23160;&=23160;&=23160; additional mechanisms and clear desc= riptions will lead to everyone
>&=23160;&=23160;&=23160;&=23160; getting the behavior they expect (wh= ich may not be the behavior they
>&=23160;&=23160;&=23160;&=23160; desire, but sometimes is the best we= can do.)
>
>&=23160;&=23160;&=23160;&=23160; Yours,
>&=23160;&=23160;&=23160;&=23160; Joel
>
>&=23160;&=23160;&=23160;&=23160; On 8/3/2020 2:30 PM, Robert Raszuk w= rote:
>&=23160;&=23160;&=23160;&=23160;&=23160; > Joel,
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Are we still talking ab= out IP networks&=23160;here =3F Or perhaps some hard
>&=23160;&=23160;&=23160;&=23160;&=23160; > slicing with real resou= rce reservations or detnets =3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Because&=23160;if we ar= e talking&=23160;about IP networking I have two
>&=23160;&=23160;&=23160;&=23160; observations:
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > A) If you need to trave= rse via a specific node (ie. firewall) you
>&=23160;&=23160;&=23160;&=23160; better
>&=23160;&=23160;&=23160;&=23160;&=23160; > apply IP encapsulation = to that node.. I don't think IP
>&=23160;&=23160;&=23160;&=23160; encapsulation&=23160;can
>&=23160;&=23160;&=23160;&=23160;&=23160; > be hijacked today such = that destination address of the packet is
>&=23160;&=23160;&=23160;&=23160; ignored.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > B) Have you seen any IP= network where upon topology change (link
>&=23160;&=23160;&=23160;&=23160; or node
>&=23160;&=23160;&=23160;&=23160;&=23160; > failure) you suddenly&=23= 160;start dropping&=23160;flows in spite of SPT offering
>&=23160;&=23160;&=23160;&=23160;&=23160; > perhaps few ms longer p= ath with 10 ms more jitter =3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Or are some SR marketin= g slides promise to turn IP networks in
>&=23160;&=23160;&=23160;&=23160;&=23160; > something&=23160;new =3F= Worse ... do they mention path quality guarantees,
>&=23160;&=23160;&=23160;&=23160;&=23160; > resource reservations&=23= 160;=3F I hope not.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Thx,
>&=23160;&=23160;&=23160;&=23160;&=23160; > R.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > On Mon, Aug 3, 2020 at = 8:10 PM Joel M. Halpern <jmh=40joelhalpern.com
 >&=23160;&=23= 160;&=23160;&=23160; <mailto:jmh=40joelhalpern.com%20%0b>> &= lt;m= ailto:jmh=40joelhalpern.com>> wrote:
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Well less serious for T= E SIDs, I am not sure the problem is
>&=23160;&=23160;&=23160;&=23160; restricted
>&=23160;&=23160;&=23160;&=23160;&=23160; > to just service SIDs. >&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Suppose that the PCE ha= s specified the path to meet some complex te
>&=23160;&=23160;&=23160;&=23160;&=23160; > objective.&=23160; The = bypass node has no way of knowing what those
>&=23160;&=23160;&=23160;&=23160;&=23160; > constraints
>&=23160;&=23160;&=23160;&=23160;&=23160; > were.&=23160; And for s= ome kinds of traffic, it is better to drop the packet
>&=23160;&=23160;&=23160;&=23160;&=23160; > than to deliver it outs= ide the envelop.&=23160; I suspect that the right
>&=23160;&=23160;&=23160;&=23160;&=23160; > answer
>&=23160;&=23160;&=23160;&=23160;&=23160; > to this is =22too bad=22= .&=23160; If so, as with the distinction regarding
>&=23160;&=23160;&=23160;&=23160; service
>&=23160;&=23160;&=23160;&=23160;&=23160; > nodes, we should say so= , shouldn't we=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Yours,
>&=23160;&=23160;&=23160;&=23160;&=23160; > Joel
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > On 8/3/2020 2:36 AM, Al= exander Vainshtein wrote:
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach, Joel and all= ,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I think that in mo= st cases:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > 1.There is clear d= ifferentiation between =22topological=22 and
>&=23160;&=23160;&=23160;&=23160; =22service=22
>&=23160;&=23160;&=23160;&=23160;&=23160; > > instructions in SI= D advertisements. E.g.:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > oIGP Prefix Node S= IDs IGP Adj-SIDs (identified as such in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > corresponding IGP = advertisements) represent topological
>&=23160;&=23160;&=23160;&=23160; instructions
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > oService SIDs for = SRv6 (see SRv6 BGP-Based Overlay Services
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3CCcy9mY6cMfbk7Qfjhi= A3R6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.ietf.org%2=46doc%2=46html%2=46= draft-ietf-bess-srv6-services-04
 >&=23160;&=23160;&=23160;&=23= 160; <https://clickt= ime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2=3Fu=3Dhttps%3A%2=46%2=46urlde= fense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46= html%2=46draft-ietf-bess-srv6-services-04=5F=5F%3B%21%21NEt6yMaO-gk%21S0Y= usx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24&= gt;>
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > draft) unsurprisin= gly represent =E2=80=9Cservice=E2=80=9D instructions
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > 2.Segments that re= present topological instructions can be bypassed,
>&=23160;&=23160;&=23160;&=23160;&=23160; > > while segments tha= t represent service instructions require
>&=23160;&=23160;&=23160;&=23160;&=23160; > alternative
>&=23160;&=23160;&=23160;&=23160;&=23160; > > protection mechani= sms.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > This view seems to= be aligned with R=46C 8402
>&=23160;&=23160;&=23160;&=23160;&=23160; > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2=3Fu=3Dhttps%3A= %2=46%2=46tools.ietf.org%2=46html%2=46rfc8402
 >&=23160;&=231= 60;&=23160;&=23160; <https://clicktime.symantec.com/37PzUK= AD82cjSvmVcGvpkh=466H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46tools.ietf.org%2=46html%2=46rfc8402=5F=5F%3B%21%21NEt6= yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I= 4Ybtm%24>>
>&=23160;&=23160;&=23160;&=23160; that says in Section 1:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of an IGP-based distributed control plane, two
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the IGP-Adjacency segment and the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; IGP-Prefix segment.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of a BGP-based distributed control plane, two
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the BGP peering segment and the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; BGP-Prefix segment.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > In the case of SR-= MPLS this differentiation is assumed in Section
>&=23160;&=23160;&=23160;&=23160;&=23160; > 3.4 of
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the Node Protectio= n for SR-TE Path
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktim= e.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2=3Fu=3Dhttps%3A%2=46%2=46datatra= cker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protection-for= -sr-te-paths-07%23section-3.4
 >&=23160;&=23160;&=23160;&=231= 60; <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ= 16H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= datatracker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protect= ion-for-sr-te-paths-07%2Asection-3.4=5F=5F%3BIw%21%21NEt6yMaO-gk%21S0Yusx= 9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>= >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > draft that says: >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The node protection mechanism described in the previous
>&=23160;&=23160;&=23160;&=23160; sections
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; depends on the assumption that the label immediately below
>&=23160;&=23160;&=23160;&=23160;&=23160; > the top
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > label in the label= stack is understood in the IGP domain.&=23160; When the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; provider edge routers exchange service labels via BGP or some
>&=23160;&=23160;&=23160;&=23160;&=23160; > other
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; non-IGP mechanism the bottom label is not understood in the IGP
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; domain.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The egress node protection mechanisms described in the draft
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; =5BR=46C8679 <https://clicktime.syma= ntec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.i= etf.org%2=46doc%2=46html%2=46rfc8679
 >&=23160;&=23160;&=2316= 0;&=23160; <https://clicktime.symantec.com/36= dMAjuYTQovo8jHwmm3eJw6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46html%2=46rfc8679=5F=5F= %3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo8MGipXc%24>>=5D
>&=23160;&=23160;&=23160;&=23160; is
>&=23160;&=23160;&=23160;&=23160;&=23160; > > applicable to this= use case and no additional changes
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; will be required for SR based networks
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > The scenarios in w= hich &=23160;differentiation between =E2=80=9Ctopological=E2=80=9D and >&=23160;&=23160;&=23160;&=23160;&=23160; > > =E2=80=9Cservice=E2= =80=9D instructions is broken are indeed problematic. E.g.,
>&=23160;&=23160;&=23160;&=23160;&=23160; > consider
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the use case in wh= ich a Node SID in the ERO of a SR-TE path
>&=23160;&=23160;&=23160;&=23160;&=23160; > identifies a
>&=23160;&=23160;&=23160;&=23160;&=23160; > > node that acts as = a firewall for all packets it receives, i.e.,
>&=23160;&=23160;&=23160;&=23160;&=23160; > provides
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the firewall servi= ce without any dedicated service SID
>&=23160;&=23160;&=23160;&=23160;&=23160; > identifying it.
>&=23160;&=23160;&=23160;&=23160;&=23160; > > One could say that= the Node SID of such a node would combine
>&=23160;&=23160;&=23160;&=23160;&=23160; > topological
>&=23160;&=23160;&=23160;&=23160;&=23160; > > and service instru= ctions thus breaking the differentiation
>&=23160;&=23160;&=23160;&=23160;&=23160; > between the two.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I am not sure if u= sage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
>&=23160;&=23160;&=23160;&=23160;&=23160; > or at
>&=23160;&=23160;&=23160;&=23160;&=23160; > > least discouraged.=
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > If not, providing = an ability to identify such SIDs in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > advertisement
>&=23160;&=23160;&=23160;&=23160;&=23160; > > mechanisms would b= e useful IMHO.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > My 2c,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Sasha
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Office: +972-39266= 302
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Cell:&=23160;&=231= 60;&=23160;&=23160;&=23160; +972-549266302
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Email: Alex= ander.Vainshtein=40ecitele.com
>&=23160;&=23160;&=23160;&=23160; <mailto:Alexander.Vainsh= tein=40ecitele.com>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:Ale= xander.Vainshtein=40ecitele.com>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > -----Original Mess= age-----
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =46rom: spring <= ;spring-bounces=40ietf.org
 >&=23160;&=23160;&=23160;&=231= 60; <mailto:spring-bounces=40ietf.org%0b>>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org= >> On Behalf Of Mach Chen
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Sent: Monday, Augu= st 3, 2020 6:30 AM
>&=23160;&=23160;&=23160;&=23160;&=23160; > > To: Joel M. Halper= n <jmh=40joelhalpern.com
 >&=23160;&=23160;&=23160;&=23160;= <mailto:jmh=40joelhalpern.com%0b>> <mailto:jmh=40joelhalpern.= com>>;
>&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Subject: Re: =5Bsp= ring=5D Spring protection - determining applicability
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Hi Joel,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I think this is a = good point that may not be discussed in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > past. And
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I also don't think= there is a =22can be bypassed=22 indication in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > routing advertisem= ent for now.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > IMHO, the informat= ion advertised by routing is neutral, such
>&=23160;&=23160;&=23160;&=23160;&=23160; > information
>&=23160;&=23160;&=23160;&=23160;&=23160; > > (can or cannot be = bypassed) is more path specific, thus
>&=23160;&=23160;&=23160;&=23160; normally the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > controller should = be responsible for deciding whether/which SID
>&=23160;&=23160;&=23160;&=23160;&=23160; > can be
>&=23160;&=23160;&=23160;&=23160;&=23160; > > bypassed.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Best regards,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > -----= Original Message-----
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46ro= m: spring =5Bmailto:spring-bounces=40ietf.org
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring-bounc= es=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org%0b%3e%20%3cmailto:spring-= bounces=40ietf.org%3e>=5D
>&=23160;&=23160;&=23160;&=23160; On Behalf Of Joel M.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Halpe= rn
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Sent:= Monday, August 3, 2020 7:51 AM
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > To: <= a href=3D=22mailto:spring=40ietf.org=22 target=3D=22=5Fblank=22>spring=40= ietf.org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
 >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Subje= ct: =5Bspring=5D Spring protection - determining applicability
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > (WG C= hair hat Off, this is merely a note from a slightly
>&=23160;&=23160;&=23160;&=23160;&=23160; > confused WG
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > parti= cipant.)
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > I hav= e been reading the various repair drafts, and the various
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > netwo= rks programming and service programming draft, and I am
>&=23160;&=23160;&=23160;&=23160;&=23160; > trying to
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > figur= e out one aspect of the combination.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > How d= oes a node that is doing some form of bypass (suppose, for
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > simpl= icity, it is Node N2 deciding to bypass the next SID for
>&=23160;&=23160;&=23160;&=23160;&=23160; > a failed
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > node = N3) know that it is safe to do so=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > If th= e path was just for TE, then it is =22safe=22 if the new path
>&=23160;&=23160;&=23160;&=23160;&=23160; > meets
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > the T= E criteria.&=23160; or maybe it is safe if it is even close, as
>&=23160;&=23160;&=23160;&=23160;&=23160; > long as
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > it is= not used for too long.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > But w= hat if the node were a =46irewall, included to meet legal
>&=23160;&=23160;&=23160;&=23160;&=23160; > > requirements=3F >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Or wa= s some other necessary programmatic transform (wince we are
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > delib= erately vague about what nodes can do when asked suitably.)
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Is th= ere some =22can be bypassed=22 indication in the routing
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > adver= tisements that I missed=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Thank= you,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Yours= ,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Joel<= br /> >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > sprin= g mailing list
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > spring=40ietf= .org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
 >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dh= ttps%3A%2
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892Xu= Xy2H6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%= 2=46clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2= A3A%2A2=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3F= u=3Dhttps%3A%252
 >&=23160;&=23160;&=23160;&=23160; <https://clicktime.sym= antec.com/3A5B8H2=46m1rPnaZ3Supjwr6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.= com%2=46v3%2=46=5F=5Fhttps%3A%2=46clicktime.symantec.com%2=46367qhU4KiUkz= W9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%2A252=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0= Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24= >>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46%<= a href=3D=22http://2=46www.ietf.org=22 target=3D=22=5Fblank=22>2=46www.ie= tf.org
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/39NznmYBtR= uHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5F= http%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5F= R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <https://clicktime.sym= antec.com/3GWT9fyja=46i3=46cvHDvoodvS6H2=3Fu=3Dhttp%3A%2=46%2=462=46www.i= etf.org
 >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symant= ec.com/39NznmYBtRuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%= 2=46v3%2=46=5F=5Fhttp%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<= /a>>>%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org> <mailto:s= pring=40ietf.org
 >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing=40ietf.org%0b>> <mailto:spring=40ietf.org>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT= 6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%= 2A2=46%2A2=46www.ietf.org%2A2=46mailman%2A2=46listinfo%2A2=46spring=5F=5F= %3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Notice: This e-mai= l together with any attachments may contain
>&=23160;&=23160;&=23160;&=23160;&=23160; > > information of Rib= bon Communications Inc. that is confidential
>&=23160;&=23160;&=23160;&=23160;&=23160; > and/or
>&=23160;&=23160;&=23160;&=23160;&=23160; > > proprietary for th= e sole use of the intended recipient. Any review,
>&=23160;&=23160;&=23160;&=23160;&=23160; > > disclosure, relian= ce or distribution by others or forwarding
>&=23160;&=23160;&=23160;&=23160; without
>&=23160;&=23160;&=23160;&=23160;&=23160; > > express permission= is strictly prohibited. If you are not the
>&=23160;&=23160;&=23160;&=23160;&=23160; > intended
>&=23160;&=23160;&=23160;&=23160;&=23160; > > recipient, please = notify the sender immediately and then delete all
>&=23160;&=23160;&=23160;&=23160;&=23160; > > copies, including = any attachments.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dht= tps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://= clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > spring mailing list
>&=23160;&=23160;&=23160;&=23160;&=23160; > spring=40ietf.org <mailto:spring= =40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A= %2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://= clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>
>&=23160;&=23160;&=23160;&=23160; =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
>&=23160;&=23160;&=23160;&=23160; spring mailing list
>&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160;
> <https://clicktime.= symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%
 > 2=46= %2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listi
> nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqgu
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> --------------------------------------------------------------------= --
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/o= r
> proprietary for the sole use of the intended recipient. Any review,<= br /> > disclosure, reliance or distribution by others or forwarding without=
> express permission is strictly prohibited. If you are not the intend= ed
> recipient, please notify the sender immediately and then delete all<= br /> > copies, including any attachments.
> --------------------------------------------------------------------= --
> --

=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
spring mailing list
spring=40= ietf.org
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring
=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
spring mailing list
spring=40= ietf.org
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring

&=23160;

&=23160;

Notice: This e-mail together with any attachments = may contain information of Ribbon Communications Inc. that is confidentia= l and/or proprietary for the sole use of the intended recipient. Any revi= ew, disclosure, reliance or distribution by others or forwarding without = express permission is strictly prohibited. If you are not the intended re= cipient, please notify the sender immediately and then delete all copies,= including any attachments.

&=23160;

=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
spring mailing list
spring=40ietf.org
https://www.ietf.org/mailman/listinfo/spring
--5f36fef2_625558ec_65d7-- From nobody Fri Aug 14 14:31:00 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9101C3A0AA2 for ; Fri, 14 Aug 2020 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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=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 O2QWD4XhzR72 for ; Fri, 14 Aug 2020 14:30:52 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 06C5F3A0AC7 for ; Fri, 14 Aug 2020 14:30:51 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id i6so7847798edy.5 for ; Fri, 14 Aug 2020 14:30:51 -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=TaMBH8C5n8YdZoJM2+rSsoQqD9XNQji1EBiUC/w/sAE=; b=Bmic+5MSWk/hS6ORWuKzJxePL7bltRrtFfwuF8j5zCoeb0Hhg7O8R+c1O9+gQa6pbx 57BDwjCRH+RWlaFuPFIo0IItL79GZG6n7qQoUFaNMROyd2CKYy0iNj5rs3ZsqlJkBvdm Zyc1rz/CEUvWSs48Jmlodk9Tmj16Z0T9WTS3waAmTgq7gdODDZ1vVXhTspS8BbtpuIT1 T531ddmh/+E+ZjzUp9qprVVfke+01dn3z3MDanMtXPOmuTzwqgCjb4REETTyh+3wrV/f LlYCTvttmrpGLUqzahco9mLKDcsRBIQoOKAP2RIkG1y59JgGqsFnO4vD7D+XSLjI5Z0R pc/w== 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=TaMBH8C5n8YdZoJM2+rSsoQqD9XNQji1EBiUC/w/sAE=; b=noSxN4vc+E61LKUOZ8PZVRPum15qK7pe9rYxH6dBPrhqM3Slq4fiBndmLwWuj54Vdx 7VaxdGQOUe7xE2EdudaeCX+qHnyMRa7rS25j7E2dIJDN0xBSbI4JMGYlfeDS8XfDFfpm LZemaUG82sa8Q6Dk6bqUtXo3v4ICknVvVgs7lfCSJ8vsMqrbWAxyxXmdrreb6iBtZja4 YXx6fOAPNzGRzFK0BFIcuWkXYPNDInamLRADhywHlMl0p3rRZPBFNa1FiteJPu8Sbzfl O3b/xJVIT/O1f3viBonh76CP4tDXU4tDPNG5YEuKMBAi4Z0SW0BRnVO6oN/twEYwfcwF v2aA== X-Gm-Message-State: AOAM533I0j4q2tboEIcZJ80fmGsmAKxWpuJgFdLB7b2jAiXfg0+18G3R PnaDUAah74fiYX+gQ8SqzgBJjODGiM8RjKpGVwt9cQ== X-Google-Smtp-Source: ABdhPJxd2x/SWG/4tH2PX7VLlVF99GXkgzFKgbRoQ4Bwzxw4XtVLV8yJd9qnPm3hkz5KwN9VNzbTixVFi2A8n0RL05Q= X-Received: by 2002:aa7:cc85:: with SMTP id p5mr4260376edt.369.1597440649824; Fri, 14 Aug 2020 14:30:49 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> In-Reply-To: <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> From: Robert Raszuk Date: Fri, 14 Aug 2020 23:30:39 +0200 Message-ID: To: Jeff Tantsura Cc: "Ketan Talaulikar (ketant)" , Alexander Vainshtein , "spring@ietf.org" , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" Content-Type: multipart/alternative; boundary="0000000000007b9cc605acdd22ba" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 21:30:59 -0000 --0000000000007b9cc605acdd22ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeff, > This is very similar to RSVP-TE I would rather differ on that statement. See if you are using SR just for TE you are 100% right. But if your SIDs embed additional local SR node processing functions this suddenly becomes a completely different game. Let's keep this in mind in this thread/topic. Kind regards, R. On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura wrote: > This is very similar to RSVP-TE, path vs link/node protection and usually > dictated by the business logic, the triggers are obviously very different= , > head-end being notified of the failure on a path and switching to the > backup path vs reaction to a local failure, so same considerations apply: > -more state > -pre-reserved resources > while > -predictable > -meets SLA (as good as primary) > vs > -less state > -local > -best effort / can cause congestions > > Cheers, > Jeff > On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) 40cisco.com@dmarc.ietf.org>, wrote: > > Hi Robert, > > > > We do not have a signalling mechanism in IGPs today to indicate a > =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was a = desire for it, an > IGP extension would be required (there is none in progress AFAIK). Note > that this results in doubling the prefix SID scale (global labels) in the > network. So I would not go about this trivially. > > > > I think it helps to get more inputs and perspectives from operators on > their views for doing a bypass via local protection for segments in an SR > Policy. There may be those that prefer end-to-end path protection using a > fallback path that is say disjoint with the primary but provides an > appropriate SLA/intent? > > > > Thanks, > > Ketan > > > > *From:* Robert Raszuk > *Sent:* 14 August 2020 23:04 > *To:* Ketan Talaulikar (ketant) > *Cc:* Alexander Vainshtein ; Joel M. > Halpern ; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Ketan, > > > > Looks like we are pretty much in sync here. > > > > But let me just observe that I purposely did not mention about SR policie= s > as we are not able to signal the intent with the packets itself. > > > > So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded wit= h > information if policies build with using them are bypass eligible or not. > > > > I was actually under the impression that this is already there and I am > just not aware, but looking deeper indeed I do not see this marking neith= er > in ISIS nor OSPF for prefix SIDs. > > > > Is there some work in progress to add it to those protocols or have we > just documented need for a short LSR draft ? > > > > Thx, > > R. > > > > > > On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) < > ketant@cisco.com> wrote: > > Hi Robert, > > > > Please check inline below. > > > > *From:* Robert Raszuk > *Sent:* 14 August 2020 21:13 > *To:* Ketan Talaulikar (ketant) > *Cc:* Alexander Vainshtein ; Joel M. > Halpern ; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi Ketan, > > > > While I completely agree with your note the consequences of it are pretty > sevre. > > *[KT] I understand. We need to be mindful of implications of protection > schemes for the SLAs/intent of SR Policies.* > > > > Unless we signal which prefix SID is protection eligible and which is not > how would other nodes know if they can protect it or not ? > > *[KT] Correct. To be more accurate, we need to consider this more in the > context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and which segme= nts may be > =E2=80=9Cbypass-able=E2=80=9D for local protection for some of those SR P= olicies. We also > have path-protection mechanisms.* > > > > It seems that today's safe thing is not to apply any node protection on S= R > flows at the PLRs then. > > > > And link protection MUST assure that packets will arrive at the neighbor > node via some other link regardless of further path towards destination. > > *[KT] Yes. We have a mechanism to indicate which adj-SIDs have protection > (that mechanism only provides link protection to get to the neighbor node= ) > so the SR Policy computation is able to indicate whether that specific li= nk > is =E2=80=9Cbypass-able=E2=80=9D or not by its choice of protected or unp= rotected adj-SIDs > respectively.* > > > > *Thanks,* > > *Ketan* > > > > Is it correct ? > > > > Thx > > R > > > > On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) < > ketant@cisco.com> wrote: > > Hi Sasha, > > > > The service node advertises its own Prefix SID. The service function that > this service node implements does not require any context (i.e. all packe= ts > arriving at the node are subjected to that service). Therefore the servic= e > node does not need to receive a packet with it=E2=80=99s own Prefix SID. > > > > Thus, we cannot assume that when PHP is used, then the SID is only > associated with a topological instruction. > > > > Hope that clarifies? > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 20:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Ketan, and all, > > I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are > advertised with PHP can ONLY represent topological instructions in SR-MP= LS > - because the advertising node will not receive them and therefore can > hardly be expected to associate any service function with them. > > > > This is complementary to what you have said. > > > > Hope this clarifies my position. > > What, if anything, did I miss? > > > > Regards, > > Sasha > > > > Get Outlook for Android > > > ------------------------------ > > *From:* Ketan Talaulikar (ketant) > *Sent:* Friday, August 14, 2020, 16:23 > *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* RE: [spring] Spring protection - determining applicability > > > ------------------------------ > > NOTICE: This email was received from an EXTERNAL sender > ------------------------------ > > > > Hi Sasha, > > > > If the service does not need any additional context (e.g. a firewall that > just applies locally configured default rules on it), then I don=E2=80=99= t see why > PHP could not be done for a Prefix SID associated with a service node. > > > > Also, I didn=E2=80=99t follow the point that you were trying to make abou= t > Adj-SIDs. > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 18:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Alexander Vainshtein ; > Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.co= m > ; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi all, > > Regarding the statement "Prefix SID could be just a topological > instruction or may also be used to steer the flow to a node which is > applying a service function to it": > > > > > > I think that in SR-MPLS a Node SID that is advertised with PHP aciton can > be safely considered as "just a topological instruction" by the PLR becau= se > the originating node will not receive it. > > The same applies to Adj-SDIs. > > > > My 2c. > > > > Get Outlook for Android > > > > ------------------------------ > > *From:* spring on behalf of Ketan Talaulikar > (ketant) > *Sent:* Friday, August 14, 2020, 15:00 > *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi All, > > I would like to share a different perspective on this. > > First, thanks to Joel for bringing up the discussion. Clearly we need a > well-defined applicability statement for determining applicability of > protection for segment used in an SR Policy. Some of this is captured in > [1]. > > This is about local repair at a PLR. By it's very nature, the PLR does no= t > have a notion of how "strict or not" is the SLA that is being provided by > the SR Policy. Awareness of that notion exists at the SR Policy headend > and/or computation-node. > > We have protected and un-protected variants of adjacency SIDs to enable > the computation to pick or the other based on the "strictness" of the SLA > requirement for picking that link. We do not have such a notion for Prefi= x > SIDs. One can say that we could introduce signalling (e.g. a B flag) to > indicate whether a Prefix SID can be bypassed or not. This provides the > opportunity for the computation to use one or the other flavor depending = on > the nature of the SLA for the SR Policy. > > I have a problem and a concern in the assumption that PLRs can assume tha= t > the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) a= re > "bypass-able". > > As Joel and others have brought out, the Prefix SID could be just a > topological instruction or may also be used to steer the flow to a node > which is applying a service function to it. In order to support a mix of = SR > Policies of different SLAs (strict and not-strict), we need to enable the > choice of SIDs that indicates to the PLR whether they are "bypass-able" o= r > not. > > For the cases, where the SR Policy has a specific SLA, it is required for > nodes to drop the packets meant for the "active segment" than to bypass i= t. > When this mechanism is used along side SRTE path monitoring mechanisms, i= t > enables the headend to detect the failure and fallback to an alternate pa= th > using the path protection approach. This is something that is described a= nd > in use in deployments today [1].. > > Thanks, > Ketan > > [1] > https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9 > [2] > https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9.3 > > -----Original Message----- > From: spring On Behalf Of Joel M. Halpern > Sent: 04 August 2020 20:25 > To: Alexander Vainshtein ; Shraddha Hegde = < > shraddha=3D40juniper.net@dmarc.ietf.org>; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability > > There are, as far as I can tell, a number of ways to address this family > of related questions. > What struck me, and prompted the starting question, was that none of them > were spelled out. I see lots of interesting ideas / proposals. > Some of them are compatible with others. Some are not. > It would be good if we could reach agreement on how we thought it should > be handled. > > Thank you, > Joel > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > Hi all, > > > > I am still not sure that the problem of bypass going thru undesirable > > links/nodes exists in the case of topological SIDs. > > > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > > < > https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%= 2Ftools.ietf.org%2Fhtml%2Frfc4090>) > has been successfully deployed > > for many years before SR-MPLS has been introduced. What=E2=80=99s more, > > signaling of bypass tunnels he PLR usually did not include any of the > > constraints used for computing of any specific LSP that the bypass LSP > > would protect =E2=80=93 because in the Facility Protection mode the sam= e > > bypass LSP would be used to protect multiple LSPs passing thru the > > failed link/node. > > > > From my POV the only difference between this behavior and that > > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in = the case of > > RSVP-TE, the operator would explicitly indicate, as part of LSP > > signaling, whether it would or would not use FRR; LSPs that would not > > use FRR would then drop traffic rather than delivering it the wrong way= . > > > > Such an option indeed does not exist in SR-TE today, but would be easy > > to provide if so desired IMHO. > > > > Did I miss something substantial? > > > > Regards, and lots of thanks in advance, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* spring *On Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > *To:* EXT-Andrew.Alston@liquidtelecom.com > > ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > All, > > > > This is a very interesting discussion and thanks to Joel for starting > > this discussion. IMO, when there are strict requirements of avoiding > > certain nodes/links it can be realized either by defining a flex-algo > > avoiding those > > > > Nodes and links or by using a stack of unprotected adj-sids that avoid > > restricted nodes and links. When a stack of adj-sids is used to > > realize the path, the head-end based (sBFD) protection mechanisms can b= e > applied. > > > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > > failure events may cause traffic to go through restricted nodes and > > links. This would happen regardless of whether any kind of protection > > is in use or not. > > > > Rgds > > > > Shraddha > > > > Juniper Business Use Only > > > > *From:* spring > >> *On Behalf Of *Andrew Alston > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf.org >; Joel > M. Halpern > > >= > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > *[External Email. Be cautious of content]* > > > > Robert this is actually far more difficult when =E2=80=93 it can be an = entire > > (long) series of nodes that need to be avoided. > > > > It could potentially be made to work but I=E2=80=99d worry that to do t= his =E2=80=93 > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative label= s =E2=80=93 and that wouldn=E2=80=99t > > be viable. > > > > It=E2=80=99s easier to use algorithms and adjacency sids and other such= things > > to calculate paths =E2=80=93 the biggest trick is about the stack depth= . When > > you have this need for node avoidance =E2=80=93 the need for 10+ label = depth > > is critical =E2=80=93 unless you wanna be applying one hell of a lot of > > binding labels along the way which is a nightmare. > > > > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use > > case that most of the people I discuss this with certain have =E2=80=93= I cant > > comment on a global scale, or for anyone else, but every indication I > > have is that yes =E2=80=93 its something people need, and want > > > > Andrew > > > > *From:* Robert Raszuk >> > > *Sent:* Tuesday, 4 August 2020 01:27 > > *To:* Andrew Alston > < > mailto:Andrew.Alston@liquidtelecom.com >= > > > *Cc:* Joel M. Halpern > >>; spring@ietf.org > > > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Is this a common use case ie. "but rather =E2=80=93 which nodes / netw= ork > > segments it can never touch or flow through." > > > > If so perhaps its time to define notion of *negative-SID* ie. list in > > the packet resources which given packet MUST not ever traverse. > > > > Put in the packet set of nodes or links which the packet should never > > traverse. > > > > That goes in line of recent wave of negative routing implementations > > (RIFT) or discussions (LSR) > > > > Best, > > R. > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > < > mailto:Andrew.Alston@liquidtelecom.com >= > > wrote: > > > > So =E2=80=93 > > > > One of the use cases, in fact, some very major use cases in any > > spring technology for us revolve around the following > > > > a.The explicit avoidance of certain nodes > > > > b.The explicit avoidance of certain sections of the network > > > > Anything that could result in that explicit avoidance being violate= d > > =E2=80=93 would create, shall we say significant problems. > > > > Much of the use case is not a case of which nodes the packets flow > > through =E2=80=93 but rather =E2=80=93 which nodes / network segmen= ts it can never > > touch or flow through. Effectively, to be used as a technology to > > avoid certain things for specific reasons. > > > > This is also one of the reasons for needing such deep label stacks = =E2=80=93 > > this kind of detailed path programming tends to deepen the stack > > because you sometimes have to be pretty explicit. > > > > It is absolutely critical to us that this functionality is there = =E2=80=93 > > and that we can avoid situations which could cause traffic to > > accidently hit things explicitly avoided. > > > > I wish I could be more specific than this, but it is what it is. > > > > Thanks > > > > Andrew > > > > *From:* spring > >> *On Behalf Of *Joel M. Halpern > > *Sent:* Monday, 3 August 2020 21:36 > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf..org > > > *Subject:* Re: [spring] Spring protection - determining > > applicability > > > > (Since the thread has gotten long enough, reiterating that this is > as a > > participant, not a WG chair.) > > > > Yes, we are talking IP networks. And yes, I have seen IP networks > that > > choose to drop packets. For all sorts of reasons. > > I think there are likely other reasons why one may not want a rando= m > > path rather than a chosen TE path. I think it is important we be > clear > > about what constraints may be / are violated when we tell people th= ey > > have this tool (protective rerouting) that is intended to preserve > QoS. > > > > Let's be clear. I am not arguing that this is not a good idea. It i= s > a > > good idea. And useful. I am trying to figure otu what combination o= f > > additional mechanisms and clear descriptions will lead to everyone > > getting the behavior they expect (which may not be the behavior the= y > > desire, but sometimes is the best we can do.) > > > > Yours, > > Joel > > > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > > Joel, > > > > > > Are we still talking about IP networks here ? Or perhaps some ha= rd > > > slicing with real resource reservations or detnets ? > > > > > > Because if we are talking about IP networking I have two > > observations: > > > > > > A) If you need to traverse via a specific node (ie. firewall) yo= u > > better > > > apply IP encapsulation to that node.. I don't think IP > > encapsulation can > > > be hijacked today such that destination address of the packet is > > ignored. > > > > > > B) Have you seen any IP network where upon topology change (link > > or node > > > failure) you suddenly start dropping flows in spite of SPT > offering > > > perhaps few ms longer path with 10 ms more jitter ? > > > > > > Or are some SR marketing slides promise to turn IP networks in > > > something new ? Worse ... do they mention path quality guarantee= s, > > > resource reservations ? I hope not. > > > > > > Thx, > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern < > jmh@joelhalpern.com > > >> >> wrote: > > > > > > Well less serious for TE SIDs, I am not sure the problem is > > restricted > > > to just service SIDs. > > > > > > Suppose that the PCE has specified the path to meet some complex > te > > > objective. The bypass node has no way of knowing what those > > > constraints > > > were. And for some kinds of traffic, it is better to drop the > packet > > > than to deliver it outside the envelop. I suspect that the righ= t > > > answer > > > to this is "too bad". If so, as with the distinction regarding > > service > > > nodes, we should say so, shouldn't we? > > > > > > Yours, > > > Joel > > > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > > Mach, Joel and all, > > > > > > > > I think that in most cases: > > > > > > > > 1.There is clear differentiation between "topological" and > > "service" > > > > instructions in SID advertisements. E.g.: > > > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > > corresponding IGP advertisements) represent topological > > instructions > > > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > < > https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04 > > > > < > https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQ= AtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24 > >> > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D inst= ructions > > > > > > > > 2.Segments that represent topological instructions can be > bypassed, > > > > while segments that represent service instructions require > > > alternative > > > > protection mechanisms. > > > > > > > > This view seems to be aligned with RFC 8402 > > > > < > https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Frfc8402 > > > > < > https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24 > >> > > that says in Section 1: > > > > > > > > In the context of an IGP-based distributed control plane, > two > > > > > > > > topological segments are defined: the IGP-Adjacency segment an= d > the > > > > > > > > IGP-Prefix segment. > > > > > > > > In the context of a BGP-based distributed control plane, t= wo > > > > > > > > topological segments are defined: the BGP peering segment and > the > > > > > > > > BGP-Prefix segment. > > > > > > > > In the case of SR-MPLS this differentiation is assumed in > Section > > > 3.4 of > > > > the Node Protection for SR-TE Path > > > > > > > > > < > https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-f= or-sr-te-paths-07%23section-3.4 > > > > < > https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 9wO-Ssn%24 > >> > > > > > > > draft that says: > > > > > > > > The node protection mechanism described in the previous > > sections > > > > > > > > depends on the assumption that the label immediately below > > > the top > > > > > > > > label in the label stack is understood in the IGP domain. Whe= n > the > > > > > > > > provider edge routers exchange service labels via BGP or > some > > > other > > > > > > > > non-IGP mechanism the bottom label is not understood in th= e > IGP > > > > > > > > domain. > > > > > > > > The egress node protection mechanisms described in the dra= ft > > > > > > > > [RFC8679 < > https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679 > > > > < > https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fr= fc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRH= OGt8AkTRDuiDo8MGipXc%24 > >>] > > is > > > > applicable to this use case and no additional changes > > > > > > > > will be required for SR based networks > > > > > > > > The scenarios in which differentiation between =E2=80=9Ctopol= ogical=E2=80=9D > and > > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed pr= oblematic. E.g., > > > consider > > > > the use case in which a Node SID in the ERO of a SR-TE path > > > identifies a > > > > node that acts as a firewall for all packets it receives, i.e.= , > > > provides > > > > the firewall service without any dedicated service SID > > > identifying it. > > > > One could say that the Node SID of such a node would combine > > > topological > > > > and service instructions thus breaking the differentiation > > > between the two. > > > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs= could be > prevented > > > or at > > > > least discouraged. > > > > > > > > If not, providing an ability to identify such SIDs in the > > > advertisement > > > > mechanisms would be useful IMHO. > > > > > > > > My 2c, > > > > > > > > Sasha > > > > > > > > Office: +972-39266302 > > > > > > > > Cell: +972-549266302 > > > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > > > > > > > -----Original Message----- > > > > From: spring > >> > > >> On > Behalf Of Mach Chen > > > > Sent: Monday, August 3, 2020 6:30 AM > > > > To: Joel M. Halpern > >> >>; > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > Subject: Re: [spring] Spring protection - determining > applicability > > > > > > > > Hi Joel, > > > > > > > > I think this is a good point that may not be discussed in the > > > past. And > > > > I also don't think there is a "can be bypassed" indication in > the > > > > routing advertisement for now. > > > > > > > > IMHO, the information advertised by routing is neutral, such > > > information > > > > (can or cannot be bypassed) is more path specific, thus > > normally the > > > > controller should be responsible for deciding whether/which SI= D > > > can be > > > > bypassed. > > > > > > > > Best regards, > > > > > > > > Mach > > > > > > > > > -----Original Message----- > > > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > > > > < > mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%= 3e > >] > > On Behalf Of Joel M. > > > > > > > > > Halpern > > > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > > > To: spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > Subject: [spring] Spring protection - determining > applicability > > > > > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > > confused WG > > > > > > > > > participant.) > > > > > > > > > > > > > > > > > > I have been reading the various repair drafts, and the > various > > > > > > > > > networks programming and service programming draft, and I a= m > > > trying to > > > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, > for > > > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID f= or > > > a failed > > > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new > path > > > meets > > > > > > > > > the TE criteria. or maybe it is safe if it is even close, = as > > > long as > > > > > > > > > it is not used for too long. > > > > > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet lega= l > > > > requirements? > > > > > > > > > Or was some other necessary programmatic transform (wince w= e > are > > > > > > > > > deliberately vague about what nodes can do when asked > suitably.) > > > > > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > Yours, > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > spring mailing list > > > > > > > > > spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2 > > > < > https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8= E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24 > > > > > > > > > > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2 > > > > < > https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW= 9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE= 8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24 > >> > > > > > > > > > F%2Fwww.ietf.org > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > > > > > < > https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%= 2F2Fwww.ietf.org > > > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > >>%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > > > > > > > spring mailing list > > > > > > > > spring@ietf.org > > > > > >> > >> > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flisti= nfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0= wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24 > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Notice: This e-mail together with any attachments may contain > > > > information of Ribbon Communications Inc. that is confidential > > > and/or > > > > proprietary for the sole use of the intended recipient. Any > review, > > > > disclosure, reliance or distribution by others or forwarding > > without > > > > express permission is strictly prohibited. If you are not the > > > intended > > > > recipient, please notify the sender immediately and then delet= e > all > > > > copies, including any attachments. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti > > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > ---------------------------------------------------------------------- > > -- > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > ---------------------------------------------------------------------- > > -- > > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > ------------------------------ > > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. that is confidential and/or proprietary for > the sole use of the intended recipient. Any review, disclosure, reliance = or > distribution by others or forwarding without express permission is strict= ly > prohibited. If you are not the intended recipient, please notify the send= er > immediately and then delete all copies, including any attachments. > ------------------------------ > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --0000000000007b9cc605acdd22ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeff,

> This is very similar to RSVP= -TE=C2=A0=C2=A0

I would rather differ on that = statement.=C2=A0

See if you are using SR just for = TE you are 100% right.=C2=A0

But if your SIDs embe= d additional local SR node processing functions this suddenly=C2=A0becomes = a completely different game. Let's keep this in mind in this thread/top= ic.=C2=A0

Kind regards,
R.

On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura <jefftant.ietf@gmail.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">
This is very similar to RSVP-TE, path vs link/node protec= tion and usually dictated by the business logic, the triggers are obviously= very different, head-end being notified of the failure on a path and switc= hing to the backup path vs reaction to a local failure, so same considerati= ons apply:=C2=A0
-more state
-pre-reserved resources
while=C2=A0
-predictable
-meets SLA (as good as primary)
vs
-less state
-local
-best effort / can cause congestions=C2=A0

Cheers,
Jeff
On Aug 14, 2020, 10:46 AM -0700, Ketan Ta= laulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>, wrote:

Hi Robert,

=C2=A0

We do not have a signalling mechanism in IGPs = today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SID= s. If there was a desire for it, an IGP extension would be required (there = is none in progress AFAIK). Note that this results in doubling the prefix S= ID scale (global labels) in the network. So I would not go about this trivi= ally.

=C2=A0

I think it helps to get more inputs and perspe= ctives from operators on their views for doing a bypass via local protectio= n for segments in an SR Policy. There may be those that prefer end-to-end p= ath protection using a fallback path that is say disjoint with the primary = but provides an appropriate SLA/intent?

=C2=A0

Thanks,

Ketan

=C2=A0

From: Robert Raszuk <robert@raszuk.net>
Sent: 14 August 2020 23:04
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

Ketan,

=C2=A0

Looks like we are pretty much in sync here.=C2=A0

=C2=A0

But let me just observe that I purposely=C2=A0did no= t mention about SR policies as we are not able to signal the intent with th= e packets itself.=C2=A0

=C2=A0

So all we have there is SIDs. BSIDs or prefix SIDs n= eed to be flooded with information if policies build with using them are by= pass eligible or not.=C2=A0

=C2=A0

I was actually under the impression that this is alr= eady there and I am just not aware, but looking deeper indeed I do not see = this marking neither in ISIS nor OSPF for prefix SIDs.=C2=A0

=C2=A0

Is there some work in progress to add it to those pr= otocols or have we just documented need=C2=A0for a short LSR draft=C2=A0 ?= =C2=A0

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:

Hi Robert,

=C2=A0

Please check inline below.

=C2=A0

From: Robert Raszuk <robert@raszuk.net>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

Hi Ketan,

=C2=A0

While I completely agree with your note the conseque= nces of it are pretty sevre.=C2=A0

[KT] I understand. We need to be mindful of im= plications of protection schemes for the SLAs/intent of SR Policies.

=C2=A0

Unless we signal which prefix SID is protection elig= ible and which is not how would other nodes know if they can protect it or = not ?=C2=A0

[KT] Correct. To be more accurate, we need to = consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR = Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for local = protection for some of those SR Policies. We also have path-protection mech= anisms.

=C2=A0

It seems that today's safe thing is not to apply= any node protection on SR flows at the PLRs then.=C2=A0

=C2=A0

And link protection MUST assure that packets will ar= rive at the neighbor node via some other link regardless of further path to= wards destination.=C2=A0

[KT] Yes. We have a mechanism to indicate whic= h adj-SIDs have protection (that mechanism only provides link protection to= get to the neighbor node) so the SR Policy computation is able to indicate= whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its = choice of protected or unprotected adj-SIDs respectively.

=C2=A0

Thanks,

Ketan

=C2=A0

Is it correct ?=C2=A0

=C2=A0

Thx

R

=C2=A0

On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:

Hi Sasha,

=C2=A0

The service node advertises its own Prefix SID. The = service function that this service node implements does not require any con= text (i.e. all packets arriving at the node are subjected to that service).= Therefore the service node does not need to receive a packet with it=E2=80= =99s own Prefix SID.

=C2=A0

Thus, we cannot assume that when PHP is used, then t= he SID is only associated with a topological instruction.

=C2=A0

Hope that clarifies?

=C2=A0

Thanks,

Ketan

=C2=A0

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com &= lt;And= rew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

Ketan, and all,

I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs= that are advertised with PHP can=C2=A0 ONLY represent topological instruct= ions in SR-MPLS - because the advertising node will not receive them and th= erefore can hardly be expected to associate any service function with them.=

=C2=A0

This is complementary to what you have said.

=C2=A0

Hope this clarifies my position.

What, if anything, did I miss?

=C2=A0

Regards,

Sasha

=C2=A0

Get Outlook for Android

=C2=A0

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Friday, August 14, 2020, 16:23
To: = Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alston@liqu= idtelecom.com; Robert Raszuk
Cc: = spring@ietf.org Subject: RE: [spring] Spring protection - determining applicability

=C2=A0

NOTICE: This email was received from an EXTERNAL sen= der

=C2=A0

Hi Sasha,

=C2=A0

If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don=E2=80=99t see why PHP could not be done for a Prefix SID associ= ated with a service node.

=C2=A0

Also, I didn=E2=80=99t follow the point that you wer= e trying to make about Adj-SIDs.

=C2=A0

Thanks,

Ketan

=C2=A0

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha@juni= per.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidte= lecom.com>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf= .org
Subject: Re: [spring] Spring protection - determining applicability<= /span>

=C2=A0

Hi all,

Regarding the statement "Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it":

=C2=A0

=C2=A0

I think that in SR-MPLS a Node SID that is advertised with PHP a= citon can be safely considered as "just a topological instruction"= ; by the PLR because the originating node will not receive it.

The same applies to Adj-SDIs.

=C2=A0

My 2c.

=C2=A0

Get O= utlook for Android

=C2=A0

From: spring <spring-bounces@ietf.org> on behalf of Ketan Ta= laulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>
Sent: Friday, August 14, 2020, 15:00
To: = Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@liqu= idtelecom.com; Robert Raszuk
Cc: = spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability

=C2=A0

Hi All,

I would like to share a different perspective on this.

First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

This is about local repair at a PLR. By it's very nature, the PLR does = not have a notion of how "strict or not" is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Polic= y headend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) = to indicate whether a Prefix SID can be bypassed or not. This provides the = opportunity for the computation to use one or the other flavor depending on= the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or = not.

For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alte= rnate path using the path protection approach. This is something that is de= scribed and in use in deployments today [1]..

Thanks,
Ketan

[1] https://clicktime.symantec.com/3Y3= fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-iet= f-spring-segment-routing-policy-08%23section-9
[2] https://clicktime.symantec.com/3= 6fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-i= etf-spring-segment-routing-policy-08%23section-9.3

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <= robert@raszuk.net>
Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
Subject: Re: [spring] Spring protection - determining applicability

There are, as far as I can tell, a number of ways to address this family of= related questions.
What struck me, and prompted the starting question, was that none of them w= ere spelled out.=C2=A0 I see lots of interesting ideas / proposals.
Some of them are compatible with others.=C2=A0=C2=A0 Some are not.
It would be good if we could reach agreement on how we thought it should be= handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirable<= br> > links/nodes exists in the case of topological SIDs.
>
> AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
> <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
> for many years before SR-MPLS has been introduced. What=E2=80=99s more= ,
> signaling of bypass tunnels he PLR usually did not include any of the<= br> > constraints used for computing of any specific LSP that the bypass LSP=
> would protect =E2=80=93 because in the Facility Protection mode the sa= me
> bypass LSP would be used to protect multiple LSPs passing thru the
> failed link/node.
>
>=C2=A0 From my POV the only difference between this behavior and that > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use FRR; LSPs that would not<= br> > use FRR would then drop traffic rather than delivering it the wrong wa= y.
>
> Such an option indeed does not exist in SR-TE today, but would be easy=
> to provide if so desired IMHO.
>
> Did I miss something substantial?
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
>
> Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston@liquidtelecom.com
> <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
> *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> All,
>
> This is a very interesting discussion and thanks to Joel for starting<= br> > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized=C2=A0 either by defining a flex= -algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avoid=
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, the<= br> > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection<= br> > is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org
 > <mailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern
> <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> *[External Email. Be cautious of content]*
>
> Robert this is actually far more difficult when =E2=80=93 it can be an= entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93
> you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t
> be viable.
>
> It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things
> to calculate paths =E2=80=93 the biggest trick is about the stack dept= h.=C2=A0 When
> you have this need for node avoidance =E2=80=93 the need for 10+ label= depth
> is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
> case that most of the people I discuss this with certain have =E2=80= =93 I cant
> comment on a global scale, or for anyone else, but every indication I<= br> > have is that yes =E2=80=93 its something people need, and want
>
> Andrew
>
> *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
 > &= lt;mai= lto:Andrew.Alston@liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
 > <mailto:jmh@joelhalpern.com>>= ;; spring@ietf.org=
> <mailto:spring= @ietf.org>
> *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
> Is this a common use case ie.=C2=A0 "but rather =E2=80=93 which n= odes / network
> segments it can never touch or flow through."
>
> If so perhaps its time to define notion of *negative-SID* ie. list in<= br> > the packet resources which given=C2=A0packet MUST not ever traverse. >
> Put in the packet set of nodes or links which the packet should never<= br> > traverse.
>
> That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston@liquidtelecom.com
 > <mailto:Andrew.Alston@li= quidtelecom.com>> wrote:
>
>=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93
>
>=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very major= use cases in any
>=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve around the fo= llowing
>
>=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain nodes
>
>=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain sections o= f the network
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that explicit av= oidance being violated
>=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say significa= nt problems.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case of which no= des the packets flow
>=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 which n= odes / network segments it can never
>=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effectively, to b= e used as a technology to
>=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific reasons.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for needing su= ch deep label stacks =E2=80=93
>=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming tends t= o deepen the stack
>=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pretty explic= it.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this func= tionality is there =E2=80=93
>=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations which could c= ause traffic to
>=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly avoided.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than this, but= it is what it is.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Thanks
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Andrew
>
>=C2=A0=C2=A0=C2=A0=C2=A0 *From:* spring <spring-bounces@ietf.org
 >= =C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> *On Behalf Of *Jo= el M. Halpern
>=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36
>=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
>=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring@ietf..org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: [spring] Spring protection - de= termining
> applicability
>
>=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long enough, reit= erating that this is as a
>=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.)
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
>=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. For all sorts of reaso= ns.
>=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons why one= may not want a random
>=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. I think it = is important we be clear
>=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are violated w= hen we tell people they
>=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerouting) that is = intended to preserve QoS.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing that this= is not a good idea. It is a
>=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying to figure o= tu what combination of
>=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descriptions w= ill lead to everyone
>=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (which may no= t be the behavior they
>=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can do.)<= br> >
>=C2=A0=C2=A0=C2=A0=C2=A0 Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0 Joel
>
>=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about IP netwo= rks=C2=A0here ? Or perhaps some hard
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reservat= ions or detnets ?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talking=C2= =A0about IP networking I have two
>=C2=A0=C2=A0=C2=A0=C2=A0 observations:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via a sp= ecific node (ie. firewall) you
>=C2=A0=C2=A0=C2=A0=C2=A0 better
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to that node= .. I don't think IP
>=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that destina= tion address of the packet is
>=C2=A0=C2=A0=C2=A0=C2=A0 ignored.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP network whe= re upon topology change (link
>=C2=A0=C2=A0=C2=A0=C2=A0 or node
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0start dr= opping=C2=A0flows in spite of SPT offering
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path with 10 = ms more jitter ?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing slides pro= mise to turn IP networks in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new ? Worse ... do t= hey mention path quality guarantees,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0? I hope= not.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R.
>=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
 >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.co= m%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SIDs, I am= not sure the problem is
>=C2=A0=C2=A0=C2=A0=C2=A0 restricted
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has specified = the path to meet some complex te
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass node ha= s no way of knowing what those
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some kinds of t= raffic, it is better to drop the packet
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside the enve= lop.=C2=A0 I suspect that the right
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is "too bad".=C2= =A0 If so, as with the distinction regarding
>=C2=A0=C2=A0=C2=A0=C2=A0 service
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn= 9;t we?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most cases: >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differentiati= on between "topological" and
>=C2=A0=C2=A0=C2=A0=C2=A0 "service"
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID advertisem= ents. E.g.:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP advertisemen= ts) represent topological
>=C2=A0=C2=A0=C2=A0=C2=A0 instructions
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
>=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 <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
 >=C2=A0= =C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3GC5af2z3JzphZDkPnc= HAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ie= tf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-g= k%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24= >>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent topo= logical instructions can be bypassed,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that represent = service instructions require
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be aligned = with RFC 8402
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3= B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDu= iDo0I4Ybtm%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0 that says in Section 1:
>=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 In the cont= ext of an IGP-based distributed control plane, two
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the IGP-Adjacency segment and the
>=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 IGP-Prefix = segment.
>=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 In the cont= ext of a BGP-based distributed control plane, two
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the BGP peering segment and the
>=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 BGP-Prefix = segment.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this di= fferentiation is assumed in Section
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for SR-TE = Path
>=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 <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
 >=C2=A0=C2=A0= =C2=A0=C2=A0 <https://clicktime.s= ymantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv= 3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-nod= e-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>= ;
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft that says:
>=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 The node pr= otection mechanism described in the previous
>=C2=A0=C2=A0=C2=A0=C2=A0 sections
>=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 depends on = the assumption that the label immediately below
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack is un= derstood in the IGP domain.=C2=A0 When the
>=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 provider ed= ge routers exchange service labels via BGP or some
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other
>=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 non-IGP mec= hanism the bottom label is not understood in the IGP
>=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 domain.
>=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 The egress = node protection mechanisms described in the draft
>=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 [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
 >=C2=A0=C2=A0= =C2=A0=C2=A0 <https:= //clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F%2Furlde= fense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__= %3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTR= DuiDo8MGipXc%24>>]
>=C2=A0=C2=A0=C2=A0=C2=A0 is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use case an= d no additional changes
>=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 will be req= uired for SR based networks
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2=A0d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a Node S= ID in the ERO of a SR-TE path
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firewall f= or all packets it receives, i.e.,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service without a= ny dedicated service SID
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the Node SI= D of such a node would combine
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus = breaking the differentiation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ability t= o identify such SIDs in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMH= O.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein@ecitele= .com
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:Alexander.Vainshtein@ecitele.com>=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:Alexander.Vainshtein@ecitele.= com>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > -----Original Message-----
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > From: spring <spring-bounces@ietf.org<= br> >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org%0b>>=
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2020 6= :30 AM
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern <jmh@joelhalpern.com >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern= .com>>;
>=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: [spring] Spring p= rotection - determining applicability
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good point t= hat may not be discussed in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there i= s a "can be bypassed" indication in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now.=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information advertis= ed by routing is neutral, such
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypassed) is= more path specific, thus
>=C2=A0=C2=A0=C2=A0=C2=A0 normally the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be responsib= le for deciding whether/which SID
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Messa= ge-----
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > From: spring [mailt= o:spring-bounc= es@ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring-bounces@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>] >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, Augus= t 3, 2020 7:51 AM
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
 >=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Subject: [spring] S= pring protection - determining applicability
>=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 > (WG Chair hat Off, = this is merely a note from a slightly
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.)
>=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 > I have been reading= the various repair drafts, and the various
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programmin= g and service programming draft, and I am
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspe= ct of the combination.
>=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 > How does a node tha= t is doing some form of bypass (suppose, for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is N= ode N2 deciding to bypass the next SID for
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know that = it is safe to do so?
>=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 > If the path was jus= t for TE, then it is "safe" if the new path
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2= =A0 or maybe it is safe if it is even close, as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used for = too long.
>=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 > But what if the nod= e were a Firewall, included to meet legal
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other n= ecessary programmatic transform (wince we are
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague = about what nodes can do when asked suitably.)
>=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 > Is there some "= ;can be bypassed" indication in the routing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements that= I missed?
>=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 > Thank you,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel
>=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=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing list=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
 >=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>
>=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=A0 https://clicktim= e.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3Q= 7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A= %2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2= __%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt= 8AkTRDuiDo6HwPLil%24>
>=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 <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
 &= gt;=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3A= 5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%= 2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A25= 2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDozoQiAHk%24>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > F%2Fwww.ietf.org
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.sy= mantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6= H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
>=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 > > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org> <mailto:spring@ietf.org
 >=C2=A0=C2=A0= =C2=A0=C2=A0 <ma= ilto:spring@ietf.org%0b>> <mailto:spring@ietf.org>>
>=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 https://clicktime.symantec.com/367qhU4KiUkzW9uG= C4eAvP46H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring=
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRn= fMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sym= antec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.o= rg%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yu= sx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>=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=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0 ----------------------------------------------= --------------------------
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Notice: This e-mail together w= ith any attachments may contain
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Communic= ations Inc. that is confidential
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole use o= f the intended recipient. Any review,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distri= bution by others or forwarding
>=C2=A0=C2=A0=C2=A0=C2=A0 without
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly= prohibited. If you are not the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify the s= ender immediately and then delete all
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attachme= nts.
>=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=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symantec.com/= 3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>=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 > spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.com/3Q1xs= KGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2= Fspring
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>=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 spring mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMzNJCKyV= PByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring=
>=C2=A0=C2=A0=C2=A0=C2=A0
> <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
 > 2F%2Furldefense.com%2Fv3= %2F__https%3A%2Fwww.iet= f.org%2Fmailman%2Flisti
> nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> ----------------------------------------------------------------------=
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or<= br> > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended=
> recipient, please notify the sender immediately and then delete all > copies, including any attachments.
> ----------------------------------------------------------------------=
> --

_______________________________________________
spring mailing list
spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring
_______________________________________________
spring mailing list
spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring

=C2=A0

=C2=A0

Notice: This e-mail together with any attachments may contain inform= ation of Ribbon Communications Inc. that is confidential and/or proprietary= for the sole use of the intended recipient. Any review, disclosure, relian= ce or distribution by others or forwarding without express permission is st= rictly prohibited. If you are not the intended recipient, please notify the= sender immediately and then delete all copies, including any attachments.<= /span>

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring
--0000000000007b9cc605acdd22ba-- From nobody Fri Aug 14 14:44:37 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C383F3A0B5A for ; Fri, 14 Aug 2020 14:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, PDS_BTC_MSGID=0.998, SPF_HELO_NONE=0.001, 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 yqZHNh11r5aC for ; Fri, 14 Aug 2020 14:44:28 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 877133A0B58 for ; Fri, 14 Aug 2020 14:44:28 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id t11so4770130plr.5 for ; Fri, 14 Aug 2020 14:44:28 -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=yZuFNzydNG8iM7VnyoL1/bJ9ZavHMaFrG8N1i+WZYVs=; b=Jh7hlR1b0Rvdr5NNIQ24TELRNz2p5fH9BLyMpqx1hpD+vTwOnDoLtnfcEO6aJvOEQL nmdEwN5w3Os9wBm1mezYahZOiaVcAV3+gTgnge9Kfh58Pu4TViP4Q2+v6zxHrRBSdLI8 RcJAUCV3SfMVz8DO97CKsFdU5nQifJZkPNrddBL7CDVLj4EprAVAntFRFIcocP1dxmdl EanaeLA0Qj2IfBAPcoFAaTP+ZBZs8V49bAb4JlYNMS6jwsCpt7Vjo3eVwX/SNptyy6S5 T1rrmHOwPfamuQJdzAZ/oZO817uYbE0kN9hSoY+/cju6JEeFc8h6ZsE3RcyAn5w7QKSj F67Q== 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=yZuFNzydNG8iM7VnyoL1/bJ9ZavHMaFrG8N1i+WZYVs=; b=qBdolYbKLz8fvqo11l23y2HEvSts3yCyIz8xyN5L6mxfOP60GInn9tDTTRhAQ0cNXW XdoSqtuL/05kh8xOupSK8Qy2r7uKivByyE/xpnvdWRPMl0MvNkREBDlnRGZKlnWBcwMb g5eZCahJNT0/r8eOAXroge1kgbuIFeG3xX6I5v6pyNmb/FOiVDIvD9dZjsby4TuzuWeO WGvsVAqGggcRL3CxWqIHu1FihGPdOw+uWZjvZ4lxVD7GoIMOD8L4j0xNf+qtbbDvO/x1 F0cPpnfEBDR1GV754sc//SFA77Btm2gxGo1vS13CzOWOYtZBmheHOwGxMXNoqN0rZo8j XIgw== X-Gm-Message-State: AOAM531kcIKzMKi1sKkX2dczMNreBzH6IWKmf/kLqJmIeCl8xuuTajZd H017E4BHBY3BQ0cv00wpYcU= X-Google-Smtp-Source: ABdhPJzd2Iso4N8YqyEXlpD0SMDBXyEeveQZafbmkMYM8t/Iu8J461yL8OjhfCuuELE8x1jmlC4YZw== X-Received: by 2002:a17:90a:19c2:: with SMTP id 2mr3720618pjj.6.1597441467684; Fri, 14 Aug 2020 14:44:27 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id y65sm10057086pfb.155.2020.08.14.14.44.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2020 14:44:26 -0700 (PDT) Date: Fri, 14 Aug 2020 14:44:17 -0700 From: Jeff Tantsura To: Robert Raszuk Cc: "Ketan Talaulikar (ketant)" , Alexander Vainshtein , "=?utf-8?Q?spring=40ietf.org?=" , "Joel M. Halpern" , Shraddha Hegde , "=?utf-8?Q?EXT-Andrew.Alston=40liquidtelecom.com?=" Message-ID: <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> In-Reply-To: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> X-Readdle-Message-ID: 19edd13c-8729-4534-b5da-c48a63a74aee@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f3705b9_46e87ccd_65d7" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 21:44:35 -0000 --5f3705b9_46e87ccd_65d7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Robert, Agreed and apologies, hit send before finishing the email (it is =46riday= ) ;-) Path protection in this case make more sense and is much less complex, if in the pathA (A->B->C) node B is a service node, it can=E2=80=99t be b= ypassed (node protected) if the link between A and B breaks however it could have a backup pathB (A->X->C) where X is the service nod= e, potentially synchronizing its state with the node B. To my previous email - at expense of more state, we provide path and serv= ice protection, hence the similarity with RSVP-TE trade-offs. Cheers, Jeff On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , wrot= e: > Jeff, > > > This is very similar to RSVP-TE > > I would rather differ on that statement. > > See if you are using SR just for TE you are 100% right. > > But if your SIDs embed additional local SR node processing functions th= is suddenly=C2=A0becomes a completely different game. Let's keep this in = mind in this thread/topic. > > Kind regards, > R. > > > > On =46ri, Aug 14, 2020 at 11:15 PM Jeff Tantsura wrote: > > > This is very similar to RSVP-TE, path vs link/node protection and u= sually dictated by the business logic, the triggers are obviously very di= fferent, head-end being notified of the failure on a path and switching t= o the backup path vs reaction to a local failure, so same considerations = apply: > > > -more state > > > -pre-reserved resources > > > while > > > -predictable > > > -meets SLA (as good as primary) > > > vs > > > -less state > > > -local > > > -best effort / can cause congestions > > > > > > Cheers, > > > Jeff > > > On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) , wrote: > > > > Hi Robert, > > > > > > > > We do not have a signalling mechanism in IGPs today to indicate a= =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was a= desire for it, an IGP extension would be required (there is none in prog= ress A=46AIK). Note that this results in doubling the prefix SID scale (g= lobal labels) in the network. So I would not go about this trivially. > > > > > > > > I think it helps to get more inputs and perspectives from operato= rs on their views for doing a bypass via local protection for segments in= an SR Policy. There may be those that prefer end-to-end path protection = using a fallback path that is say disjoint with the primary but provides = an appropriate SLA/intent=3F > > > > > > > > Thanks, > > > > Ketan > > > > > > > > =46rom: Robert Raszuk > > > > Sent: 14 August 2020 23:04 > > > > To: Ketan Talaulikar (ketant) > > > > Cc: Alexander Vainshtein ; Joel = M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > Subject: Re: =5Bspring=5D Spring protection - determining applica= bility > > > > > > > > Ketan, > > > > > > > > Looks like we are pretty much in sync here. > > > > > > > > But let me just observe that I purposely=C2=A0did not mention abo= ut SR policies as we are not able to signal the intent with the packets i= tself. > > > > > > > > So all we have there is SIDs. BSIDs or prefix SIDs need to be flo= oded with information if policies build with using them are bypass eligib= le or not. > > > > > > > > I was actually under the impression that this is already there an= d I am just not aware, but looking deeper indeed I do not see this markin= g neither in ISIS nor OSP=46 for prefix SIDs. > > > > > > > > Is there some work in progress to add it to those protocols or ha= ve we just documented need=C2=A0for a short LSR draft=C2=A0 =3F > > > > > > > > Thx, > > > > R. > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) wrote: > > > > > Hi Robert, > > > > > > > > > > Please check inline below. > > > > > > > > > > =46rom: Robert Raszuk > > > > > Sent: 14 August 2020 21:13 > > > > > To: Ketan Talaulikar (ketant) > > > > > Cc: Alexander Vainshtein ; Joe= l M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > Subject: Re: =5Bspring=5D Spring protection - determining appli= cability > > > > > > > > > > Hi Ketan, > > > > > > > > > > While I completely agree with your note the consequences of it = are pretty sevre. > > > > > =5BKT=5D I understand. We need to be mindful of implications of= protection schemes for the SLAs/intent of SR Policies. > > > > > > > > > > Unless we signal which prefix SID is protection eligible and wh= ich is not how would other nodes know if they can protect it or not =3F > > > > > =5BKT=5D Correct. To be more accurate, we need to consider this= more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies an= d which segments may be =E2=80=9Cbypass-able=E2=80=9D for local protectio= n for some of those SR Policies. We also have path-protection mechanisms.= > > > > > > > > > > It seems that today's safe thing is not to apply any node prote= ction on SR flows at the PLRs then. > > > > > > > > > > And link protection MUST assure that packets will arrive at the= neighbor node via some other link regardless of further path towards des= tination. > > > > > =5BKT=5D Yes. We have a mechanism to indicate which adj-SIDs ha= ve protection (that mechanism only provides link protection to get to the= neighbor node) so the SR Policy computation is able to indicate whether = that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its choice = of protected or unprotected adj-SIDs respectively. > > > > > > > > > > Thanks, > > > > > Ketan > > > > > > > > > > Is it correct =3F > > > > > > > > > > Thx > > > > > R > > > > > > > > > > On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) wrote: > > > > > > Hi Sasha, > > > > > > > > > > > > The service node advertises its own Prefix SID. The service f= unction that this service node implements does not require any context (i= .e. all packets arriving at the node are subjected to that service). Ther= efore the service node does not need to receive a packet with it=E2=80=99= s own Prefix SID. > > > > > > > > > > > > Thus, we cannot assume that when PHP is used, then the SID is= only associated with a topological instruction. > > > > > > > > > > > > Hope that clarifies=3F > > > > > > > > > > > > Thanks, > > > > > > Ketan > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > Sent: 14 August 2020 20:24 > > > > > > To: Ketan Talaulikar (ketant) ; Joel M. H= alpern ; Shraddha Hegde ; = EXT-Andrew.Alston=40liquidtelecom.com = ; Robert Raszuk > > > > > > Cc: spring=40ietf.org > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining app= licability > > > > > > > > > > > > Ketan, and all, > > > > > > I have stated that, IMHO and =46WIW, both Adj-SIDs and Prefix= SIDs that are advertised with PHP can=C2=A0 ONLY represent topological i= nstructions in SR-MPLS - because the advertising node will not receive th= em and therefore can hardly be expected to associate any service function= with them. > > > > > > > > > > > > This is complementary to what you have said. > > > > > > > > > > > > Hope this clarifies my position. > > > > > > What, if anything, did I miss=3F > > > > > > > > > > > > Regards, > > > > > > Sasha > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > =46rom: Ketan Talaulikar (ketant) > > > > > > Sent: =46riday, August 14, 2020, 16:23 > > > > > > To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EX= T-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > Cc: spring=40ietf.org > > > > > > Subject: RE: =5Bspring=5D Spring protection - determining app= licability > > > > > > > > > > > > NOTICE: This email was received from an EXTERNAL sender > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > If the service does not need any additional context (e.g. a f= irewall that just applies locally configured default rules on it), then I= don=E2=80=99t see why PHP could not be done for a Prefix SID associated = with a service node. > > > > > > > > > > > > Also, I didn=E2=80=99t follow the point that you were trying = to make about Adj-SIDs. > > > > > > > > > > > > Thanks, > > > > > > Ketan > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > Sent: 14 August 2020 18:24 > > > > > > To: Ketan Talaulikar (ketant) ; Joel M. H= alpern ; Alexander Vainshtein ; Shraddha Hegde ; EXT-Andrew.Alston= =40liquidtelecom.com ; Robert Raszuk <= robert=40raszuk.net> > > > > > > Cc: spring=40ietf.org > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining app= licability > > > > > > > > > > > > Hi all, > > > > > > Regarding the statement =22Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is= applying a service function to it=22: > > > > > > > > > > > > > > > > > > I think that in SR-MPLS a Node SID that is advertised with PH= P aciton can be safely considered as =22just a topological instruction=22= by the PLR because the originating node will not receive it. > > > > > > The same applies to Adj-SDIs. > > > > > > > > > > > > My 2c. > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > =46rom: spring on behalf of Ketan= Talaulikar (ketant) > > > > > > Sent: =46riday, August 14, 2020, 15:00 > > > > > > To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EX= T-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > Cc: spring=40ietf.org > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining app= licability > > > > > > > > > > > > Hi All, > > > > > > > > > > > > I would like to share a different perspective on this. > > > > > > > > > > > > =46irst, thanks to Joel for bringing up the discussion. Clear= ly we need a well-defined applicability statement for determining applica= bility of protection for segment used in an SR Policy. Some of this is ca= ptured in =5B1=5D. > > > > > > > > > > > > This is about local repair at a PLR. By it's very nature, the= PLR does not have a notion of how =22strict or not=22 is the SLA that is= being provided by the SR Policy. Awareness of that notion exists at the = SR Policy headend and/or computation-node. > > > > > > > > > > > > We have protected and un-protected variants of adjacency SIDs= to enable the computation to pick or the other based on the =22strictnes= s=22 of the SLA requirement for picking that link. We do not have such a = notion for Prefix SIDs. One can say that we could introduce signalling (e= .g. a B flag) to indicate whether a Prefix SID can be bypassed or not. Th= is provides the opportunity for the computation to use one or the other f= lavor depending on the nature of the SLA for the SR Policy. > > > > > > > > > > > > I have a problem and a concern in the assumption that PLRs ca= n assume that the currently defined variant of Prefix SIDs in R=46C8402 (= and IGP specs) are =22bypass-able=22. > > > > > > > > > > > > As Joel and others have brought out, the Prefix SID could be = just a topological instruction or may also be used to steer the flow to a= node which is applying a service function to it. In order to support a m= ix of SR Policies of different SLAs (strict and not-strict), we need to e= nable the choice of SIDs that indicates to the PLR whether they are =22by= pass-able=22 or not. > > > > > > > > > > > > =46or the cases, where the SR Policy has a specific SLA, it i= s required for nodes to drop the packets meant for the =22active segment=22= than to bypass it. When this mechanism is used along side SRTE path moni= toring mechanisms, it enables the headend to detect the failure and fallb= ack to an alternate path using the path protection approach. This is some= thing that is described and in use in deployments today =5B1=5D.. > > > > > > > > > > > > Thanks, > > > > > > Ketan > > > > > > > > > > > > =5B1=5D https://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWw= Ums6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spr= ing-segment-routing-policy-08%23section-9 > > > > > > =5B2=5D https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7= H6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-ietf-sprin= g-segment-routing-policy-08%23section-9.3 > > > > > > > > > > > > -----Original Message----- > > > > > > =46rom: spring On Behalf Of Joel = M. Halpern > > > > > > Sent: 04 August 2020 20:25 > > > > > > To: Alexander Vainshtein ; S= hraddha Hegde ; EXT-Andrew.Als= ton=40liquidtelecom.com ; Robert Raszu= k > > > > > > Cc: spring=40ietf.org; Joel M. Halpern > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining app= licability > > > > > > > > > > > > There are, as far as I can tell, a number of ways to address = this family of related questions. > > > > > > What struck me, and prompted the starting question, was that = none of them were spelled out.=C2=A0 I see lots of interesting ideas / pr= oposals. > > > > > > Some of them are compatible with others.=C2=A0=C2=A0 Some are= not. > > > > > > It would be good if we could reach agreement on how we though= t it should be handled. > > > > > > > > > > > > Thank you, > > > > > > Joel > > > > > > > > > > > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I am still not sure that the problem of bypass going thru u= ndesirable > > > > > > > links/nodes exists in the case of topological SIDs. > > > > > > > > > > > > > > A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090= > > > > > > > ) has been succ= essfully deployed > > > > > > > for many years before SR-MPLS has been introduced. What=E2=80= =99s more, > > > > > > > signaling of bypass tunnels he PLR usually did not include = any of the > > > > > > > constraints used for computing of any specific LSP that the= bypass LSP > > > > > > > would protect =E2=80=93 because in the =46acility Protectio= n mode the same > > > > > > > bypass LSP would be used to protect multiple LSPs passing t= hru the > > > > > > > failed link/node. > > > > > > > > > > > > > >=C2=A0 =46rom my POV the only difference between this behavi= or and that > > > > > > > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR = is that, in the case of > > > > > > > RSVP-TE, the operator would explicitly indicate, as part of= LSP > > > > > > > signaling, whether it would or would not use =46RR; LSPs th= at would not > > > > > > > use =46RR would then drop traffic rather than delivering it= the wrong way. > > > > > > > > > > > > > > Such an option indeed does not exist in SR-TE today, but wo= uld be easy > > > > > > > to provide if so desired IMHO. > > > > > > > > > > > > > > Did I miss something substantial=3F > > > > > > > > > > > > > > Regards, and lots of thanks in advance, > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > Office: +972-39266302 > > > > > > > > > > > > > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302 > > > > > > > > > > > > > > Email:=C2=A0=C2=A0 Alexander.Vainshtein=40ecitele.com > > > > > > > > > > > > > > *=46rom:* spring *On Behalf Of = *Shraddha Hegde > > > > > > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > > > > > > *To:* EXT-Andrew.Alston=40liquidtelecom.com > > > > > > > ; Robert Raszuk > > > > > > > *Cc:* spring=40ietf.org; Joel M. Halpern > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determining= applicability > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > This is a very interesting discussion and thanks to Joel fo= r starting > > > > > > > this discussion. IMO, when there are strict requirements of= avoiding > > > > > > > certain nodes/links it can be realized=C2=A0 either by defi= ning a flex-algo > > > > > > > avoiding those > > > > > > > > > > > > > > Nodes and links or by using a stack of unprotected adj-sids= that avoid > > > > > > > restricted nodes and links. When a stack of adj-sids is use= d to > > > > > > > realize the path, the head-end based (sB=46D) protection me= chanisms can be applied. > > > > > > > > > > > > > > If Node-sids/prefix-sid/anycast-sids are used to build the = stack, the > > > > > > > failure events may cause traffic to go through restricted n= odes and > > > > > > > links. This would happen regardless of whether any kind of = protection > > > > > > > is in use or not. > > > > > > > > > > > > > > Rgds > > > > > > > > > > > > > > Shraddha > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > *=46rom:* spring > > > > > > > *On Behalf Of *Andrew A= lston > > > > > > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > > > > > > *To:* Robert Raszuk > > > > > > > > *Cc:* spring=40ietf.org ; Joel M.= Halpern > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determining= applicability > > > > > > > > > > > > > > *=5BExternal Email. Be cautious of content=5D* > > > > > > > > > > > > > > Robert this is actually far more difficult when =E2=80=93 i= t can be an entire > > > > > > > (long) series of nodes that need to be avoided. > > > > > > > > > > > > > > It could potentially be made to work but I=E2=80=99d worry = that to do this =E2=80=93 > > > > > > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 ne= gative labels =E2=80=93 and that wouldn=E2=80=99t > > > > > > > be viable. > > > > > > > > > > > > > > It=E2=80=99s easier to use algorithms and adjacency sids an= d other such things > > > > > > > to calculate paths =E2=80=93 the biggest trick is about the= stack depth.=C2=A0 When > > > > > > > you have this need for node avoidance =E2=80=93 the need fo= r 10+ label depth > > > > > > > is critical =E2=80=93 unless you wanna be applying one hell= of a lot of > > > > > > > binding labels along the way which is a nightmare. > > > > > > > > > > > > > > But to answer your question, is this a common use case =E2=80= =93 it=E2=80=99s a use > > > > > > > case that most of the people I discuss this with certain ha= ve =E2=80=93 I cant > > > > > > > comment on a global scale, or for anyone else, but every in= dication I > > > > > > > have is that yes =E2=80=93 its something people need, and w= ant > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > *=46rom:* Robert Raszuk > > > > > > > > *Sent:* Tuesday, 4 August 2020 01:27 > > > > > > > *To:* Andrew Alston > > > > > > > > > > > > > > *Cc:* Joel M. Halpern > > > > > > >; spring=40ietf.org > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determining= applicability > > > > > > > > > > > > > > Is this a common use case ie.=C2=A0 =22but rather =E2=80=93= which nodes / network > > > > > > > segments it can never touch or flow through.=22 > > > > > > > > > > > > > > If so perhaps its time to define notion of *negative-SID* i= e. list in > > > > > > > the packet resources which given=C2=A0packet MUST not ever = traverse. > > > > > > > > > > > > > > Put in the packet set of nodes or links which the packet sh= ould never > > > > > > > traverse. > > > > > > > > > > > > > > That goes in line of recent wave of negative routing implem= entations > > > > > > > (RI=46T) or discussions (LSR) > > > > > > > > > > > > > > Best, > > > > > > > R. > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93 > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some= very major use cases in any > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve ar= ound the following > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain= nodes > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain= sections of the network > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that = explicit avoidance being violated > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we sa= y significant problems. > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case = of which nodes the packets flow > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80= =93 which nodes / network segments it can never > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effect= ively, to be used as a technology to > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific r= easons. > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for= needing such deep label stacks =E2=80=93 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programm= ing tends to deepen the stack > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pr= etty explicit. > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us tha= t this functionality is there =E2=80=93 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations wh= ich could cause traffic to > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly av= oided. > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific tha= n this, but it is what it is. > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *=46rom:* spring > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 >= *On Behalf Of *Joel M. Halpern > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36= > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring=40ietf..org > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: =5Bspring=5D Spring = protection - determining > > > > > > > applicability > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long e= nough, reiterating that this is as a > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.) > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. An= d yes, I have seen IP networks that > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. =46or all s= orts of reasons. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reas= ons why one may not want a random > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. = I think it is important we be clear > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are= violated when we tell people they > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective reroutin= g) that is intended to preserve QoS. > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing th= at this is not a good idea. It is a > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying = to figure otu what combination of > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear des= criptions will lead to everyone > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (w= hich may not be the behavior they > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best w= e can do.) > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yours, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Joel > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk = wrote: > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about = IP networks=C2=A0here =3F Or perhaps some hard > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource = reservations or detnets =3F > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talk= ing=C2=A0about IP networking I have two > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 observations: > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse = via a specific node (ie. firewall) you > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 better > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to t= hat node.. I don't think IP > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that= destination address of the packet is > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 ignored. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP net= work where upon topology change (link > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 or node > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0= start dropping=C2=A0flows in spite of SPT offering > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path = with 10 ms more jitter =3F > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing sl= ides promise to turn IP networks in > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new =3F Wors= e ... do they mention path quality guarantees, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0= =3F I hope not. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R. > > > > > > >=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10= PM Joel M. Halpern > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > wrote: > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SI= Ds, I am not sure the problem is > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 restricted > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has sp= ecified the path to meet some complex te > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass= node has no way of knowing what those > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some ki= nds of traffic, it is better to drop the packet > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside = the envelop.=C2=A0 I suspect that the right > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is =22too bad=22.=C2= =A0 If so, as with the distinction regarding > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 service > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, sh= ouldn't we=3F > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexan= der Vainshtein wrote: > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most case= s: > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differen= tiation between =22topological=22 and > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =22service=22 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID adver= tisements. E.g.: > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP= Adj-SIDs (identified as such in the > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP adverti= sements) represent topological > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 instructions > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (s= ee SRv6 BGP-Based Overlay Services > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly rep= resent =E2=80=9Cservice=E2=80=9D instructions > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent= topological instructions can be bypassed, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that repre= sent service instructions require > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be ali= gned with R=46C 8402 > > > > > > >=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 that says in Section 1: > > > > > > >=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 In the= context of an IGP-based distributed control plane, two > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are = defined: the IGP-Adjacency segment and the > > > > > > >=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 IGP-Pr= efix segment. > > > > > > >=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 In the= context of a BGP-based distributed control plane, two > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are = defined: the BGP peering segment and the > > > > > > >=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 BGP-Pr= efix segment. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS th= is differentiation is assumed in Section > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for S= R-TE Path > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft that says: > > > > > > >=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 The no= de protection mechanism described in the previous > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 sections > > > > > > >=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 depend= s on the assumption that the label immediately below > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack = is understood in the IGP domain.=C2=A0 When the > > > > > > >=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 provid= er edge routers exchange service labels via BGP or some > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other > > > > > > >=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 non-IG= P mechanism the bottom label is not understood in the IGP > > > > > > >=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 domain= . > > > > > > >=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 The eg= ress node protection mechanisms described in the draft > > > > > > >=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 =5BR=46= C8679 > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 >=5D > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 is > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use ca= se and no additional changes > > > > > > >=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 will b= e required for SR based networks > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2= =A0differentiation between =E2=80=9Ctopological=E2=80=9D and > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D= instructions is broken are indeed problematic. E.g., > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a N= ode SID in the ERO of a SR-TE path > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firew= all for all packets it receives, i.e., > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service with= out any dedicated service SID > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the No= de SID of such a node would combine > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions = thus breaking the differentiation > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of= such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an abil= ity to identify such SIDs in the > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be usefu= l IMHO. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +972-549266302 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshte= in=40ecitele.com > > > > > > >=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 > > -----Original Message----= - > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =46rom: spring > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 >= On Behalf Of Mach Chen > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2= 020 6:30 AM > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > = >; > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: =5Bspring=5D= Spring protection - determining applicability > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good po= int that may not be discussed in the > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there = is a =22can be bypassed=22 indication in the > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for= now. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information adv= ertised by routing is neutral, such > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypasse= d) is more path specific, thus > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 normally the > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be resp= onsible for deciding whether/which SID > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Mes= sage----- > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46rom: spring =5B= mailto:spring-bounces=40ietf.org > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =5D > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M. > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, Aug= ust 3, 2020 7:51 AM > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring=40ietf= .org > > > > > > >=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 > Subject: =5Bsprin= g=5D Spring protection - determining applicability > > > > > > >=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 > (WG Chair hat Off= , this is merely a note from a slightly > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.) > > > > > > >=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 > I have been readi= ng the various repair drafts, and the various > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programm= ing and service programming draft, and I am > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one as= pect of the combination. > > > > > > >=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 > How does a node t= hat is doing some form of bypass (suppose, for > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is= Node N2 deciding to bypass the next SID for > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know tha= t it is safe to do so=3F > > > > > > >=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 > If the path was j= ust for TE, then it is =22safe=22 if the new path > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2= =A0 or maybe it is safe if it is even close, as > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used fo= r too long. > > > > > > >=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 > But what if the n= ode were a =46irewall, included to meet legal > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements=3F > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other= necessary programmatic transform (wince we are > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vagu= e about what nodes can do when asked suitably.) > > > > > > >=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 > Is there some =22= can be bypassed=22 indication in the routing > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements th= at I missed=3F > > > > > > >=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 > Thank you, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel > > > > > > >=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 > =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 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing li= st > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring=40ietf.org= > > > > > > >=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=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 https://clicktime.symantec.com/367q= hU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2 > > > > > > >=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=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46%2=46www.ietf.= org > > > > > > >=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 >%2=46mailm= an%2=46listinfo%2=46spring > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =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 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org > > > > > > >=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=A0=C2=A0=C2=A0 https://clicktime.symantec.com/367q= hU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2= =46listinfo%2=46spring > > > > > > >=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=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 > > Notice: This e-mail toget= her with any attachments may contain > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Com= munications Inc. that is confidential > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole = use of the intended recipient. Any review, > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or d= istribution by others or forwarding > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 without > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is str= ictly prohibited. If you are not the > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify = the sender immediately and then delete all > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any att= achments. > > > > > > >=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 > > =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 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symante= c.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46= mailman%2=46listinfo%2=46spring > > > > > > >=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 > =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 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring mailing list > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring=40ietf.org > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.= com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46m= ailman%2=46listinfo%2=46spring > > > > > > >=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 =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 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring mailing list > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1x= sKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2= =46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > 2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.i= etf.org%2=46mailman%2=46listi > > > > > > > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5F= R1oiQAtQxgm0x0wxqgu > > > > > > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------= ----------- > > > > > > > -- > > > > > > > Notice: This e-mail together with any attachments may conta= in > > > > > > > information of Ribbon Communications Inc. that is confident= ial and/or > > > > > > > proprietary for the sole use of the intended recipient. Any= review, > > > > > > > disclosure, reliance or distribution by others or forwardin= g without > > > > > > > express permission is strictly prohibited. If you are not t= he intended > > > > > > > recipient, please notify the sender immediately and then de= lete all > > > > > > > copies, including any attachments. > > > > > > > -----------------------------------------------------------= ----------- > > > > > > > -- > > > > > > > > > > > > =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 > > > > > > spring mailing list > > > > > > spring=40ietf.org > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu= =3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > =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 > > > > > > spring mailing list > > > > > > spring=40ietf.org > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu= =3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any attachments may contain= information of Ribbon Communications Inc. that is confidential and/or pr= oprietary for the sole use of the intended recipient. Any review, disclos= ure, reliance or distribution by others or forwarding without express per= mission is strictly prohibited. If you are not the intended recipient, pl= ease notify the sender immediately and then delete all copies, including = any attachments. > > > > > > > > > > =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= > > > > spring mailing list > > > > spring=40ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring --5f3705b9_46e87ccd_65d7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Robert,

Agreed and apologies, hit send before finishing the email (it is =46riday= ) ;-)

Path protection in this case make more sense and is much less complex,&=23= 160;
if in the pathA (A->B->C) node B is a service node, it can=E2=80=99= t be bypassed (node protected) if the link between A and B breaks&=23160;=
however it could have a backup pathB (A->X->C) where X is the servi= ce node, potentially synchronizing its state with the node B.

To my previous email - at expense of more state, we provide path and serv= ice protection, hence the similarity with RSVP-TE trade-offs.

Cheers,
Jeff
On Aug 14, 2020, 2:30 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:
Jeff,

> This is very similar to RSVP-TE&=23160;&=23160;

I would rather differ on that statement.&=23160;

See if you are using SR just for TE you are 100% right.&=23160;

But if your SIDs embed additional local SR node processing functions= this suddenly&=23160;becomes a completely different game. Let's keep thi= s in mind in this thread/topic.&=23160;

Kind regards,
R.


On =46ri, Aug 14, 2020 at= 11:15 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:
This is very similar to RSVP-TE, path vs link/node = protection and usually dictated by the business logic, the triggers are o= bviously very different, head-end being notified of the failure on a path= and switching to the backup path vs reaction to a local failure, so same= considerations apply:&=23160;
-more state
-pre-reserved resources
while&=23160;
-predictable
-meets SLA (as good as primary)
vs
-less state
-local
-best effort / can cause congestions&=23160;

Cheers,
Jeff
On Aug 14, 2020, 10:46 AM -0700, Ke= tan Talaulikar (ketant) <ketant=3D40cisco.com=40dmarc.ietf.org&= gt;, wrote:

Hi Robert,

&=23160;

We do not have a signalling mechanism in= IGPs today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Pr= efix SIDs. If there was a desire for it, an IGP extension would be requir= ed (there is none in progress A=46AIK). Note that this results in doublin= g the prefix SID scale (global labels) in the network. So I would not go = about this trivially.

&=23160;

I think it helps to get more inputs and = perspectives from operators on their views for doing a bypass via local p= rotection for segments in an SR Policy. There may be those that prefer en= d-to-end path protection using a fallback path that is say disjoint with = the primary but provides an appropriate SLA/intent=3F

&=23160;

Thanks,

Ketan

&=23160;

=46rom: R= obert Raszuk <robert=40raszuk.net>
Sent: 14 August 2020 23:04
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Ketan,

&=23160;

Looks like we are pretty much in sync here.&=23= 160;

&=23160;

But let me just observe that I purposely&=2316= 0;did not mention about SR policies as we are not able to signal the inte= nt with the packets itself.&=23160;

&=23160;

So all we have there is SIDs. BSIDs or prefix = SIDs need to be flooded with information if policies build with using the= m are bypass eligible or not.&=23160;

&=23160;

I was actually under the impression that this = is already there and I am just not aware, but looking deeper indeed I do = not see this marking neither in ISIS nor OSP=46 for prefix SIDs.&=23160;<= /p>

&=23160;

Is there some work in progress to add it to th= ose protocols or have we just documented need&=23160;for a short LSR draf= t&=23160; =3F&=23160;

&=23160;

Thx,

R.

&=23160;

&=23160;

On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:

Hi Robert,

&=23160;

Please check inline below.

&=23160;

=46rom: R= obert Raszuk <robert=40raszuk.net>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Hi Ketan,

&=23160;

While I completely agree with your note the co= nsequences of it are pretty sevre.&=23160;

=5BKT=5D I understand. We need to be min= dful of implications of protection schemes for the SLAs/intent of SR Poli= cies.

&=23160;

Unless we signal which prefix SID is protectio= n eligible and which is not how would other nodes know if they can protec= t it or not =3F&=23160;

=5BKT=5D Correct. To be more accurate, w= e need to consider this more in the context of SLA or =E2=80=9Cintent=E2=80= =9D of SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D= for local protection for some of those SR Policies. We also have path-pr= otection mechanisms.

&=23160;

It seems that today's safe thing is not to app= ly any node protection on SR flows at the PLRs then.&=23160;

&=23160;

And link protection MUST assure that packets w= ill arrive at the neighbor node via some other link regardless of further= path towards destination.&=23160;

=5BKT=5D Yes. We have a mechanism to ind= icate which adj-SIDs have protection (that mechanism only provides link p= rotection to get to the neighbor node) so the SR Policy computation is ab= le to indicate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D= or not by its choice of protected or unprotected adj-SIDs respectively.<= /i>

&=23160;

Thanks,

Ketan

&=23160;

Is it correct =3F&=23160;

&=23160;

Thx

R

&=23160;

On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:

Hi Sasha,

&=23160;

The service node advertises its own Prefix SID= . The service function that this service node implements does not require= any context (i.e. all packets arriving at the node are subjected to that= service). Therefore the service node does not need to receive a packet w= ith it=E2=80=99s own Prefix SID.

&=23160;

Thus, we cannot assume that when PHP is used, = then the SID is only associated with a topological instruction.

&=23160;

Hope that clarifies=3F

&=23160;

Thanks,

Ketan

&=23160;

=46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Shraddha Hegde <shraddha=40juniper.ne= t>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.= net>
Cc: spring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Ketan, and all,

I have stated that, IMHO and =46WIW, both Adj-SIDs= and Prefix SIDs that are advertised with PHP can&=23160; ONLY represent = topological instructions in SR-MPLS - because the advertising node will n= ot receive them and therefore can hardly be expected to associate any ser= vice function with them.

&=23160;

This is complementary to what you have said.

&=23160;

Hope this clarifies my position.

What, if anything, did I miss=3F

&=23160;

Regards,

Sasha

&=23160;

Get Outlook for Android

&=23160;

=46rom: Ketan Talaulikar (ketant) <ketant=40cisc= o.com>
Sent: =46riday, August 14, 2020, 16:23
To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk
Cc: sp= ring=40ietf.org
Subject: RE: =5Bspring=5D Spring protection - determining applicability=

&=23160;

NOTICE: This email was received from an EXTERN= AL sender

&=23160;

Hi Sasha,

&=23160;

If the service does not need any additional co= ntext (e.g. a firewall that just applies locally configured default rules= on it), then I don=E2=80=99t see why PHP could not be done for a Prefix = SID associated with a service node.

&=23160;

Also, I didn=E2=80=99t follow the point that y= ou were trying to make about Adj-SIDs.

&=23160;

Thanks,

Ketan

&=23160;

=46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Alexander Vainshtein <Alexand= er.Vainshtein=40rbbn.com>; Shraddha Hegde <shraddha=40juniper.net<= /a>>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.net= >
Cc: spring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Hi all,

Regarding the statement =22Prefix SID could be jus= t a topological instruction or may also be used to steer the flow to a no= de which is applying a service function to it=22:

&=23160;

&=23160;

I think that in SR-MPLS a Node SID that is adverti= sed with PHP aciton can be safely considered as =22just a topological ins= truction=22 by the PLR because the originating node will not receive it.<= /span>

The same applies to Adj-SDIs.

&=23160;

My 2c.

&=23160;

Get Outlook for Android

&=23160;

=46rom: spring <spring-bounces=40ietf.org= > on behalf of Ketan Talaulikar (ketant) <ketant=3D= 40cisco.com=40dmarc.ietf.org>
Sent: =46riday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk
Cc: sp= ring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicability=

&=23160;

Hi All,

I would like to share a different perspective on this.

=46irst, thanks to Joel for bringing up the discussion. Clearly we need a= well-defined applicability statement for determining applicability of pr= otection for segment used in an SR Policy. Some of this is captured in =5B= 1=5D.

This is about local repair at a PLR. By it's very nature, the PLR does no= t have a notion of how =22strict or not=22 is the SLA that is being provi= ded by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable t= he computation to pick or the other based on the =22strictness=22 of the = SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag= ) to indicate whether a Prefix SID can be bypassed or not. This provides = the opportunity for the computation to use one or the other flavor depend= ing on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume tha= t the currently defined variant of Prefix SIDs in R=46C8402 (and IGP spec= s) are =22bypass-able=22.

As Joel and others have brought out, the Prefix SID could be just a topol= ogical instruction or may also be used to steer the flow to a node which = is applying a service function to it. In order to support a mix of SR Pol= icies of different SLAs (strict and not-strict), we need to enable the ch= oice of SIDs that indicates to the PLR whether they are =22bypass-able=22= or not.

=46or the cases, where the SR Policy has a specific SLA, it is required f= or nodes to drop the packets meant for the =22active segment=22 than to b= ypass it. When this mechanism is used along side SRTE path monitoring mec= hanisms, it enables the headend to detect the failure and fallback to an = alternate path using the path protection approach. This is something that= is described and in use in deployments today =5B1=5D..

Thanks,
Ketan

=5B1=5D htt= ps://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2= =46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-pol= icy-08%23section-9
=5B2=5D htt= ps://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46= %2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-policy= -08%23section-9.3

-----Original Message-----
=46rom: spring <spring-bounces=40ietf.org> On Behalf Of Joel M.= Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com>= ;; Shraddha Hegde <shraddha=3D40juniper.net=40dmarc.ie= tf.org>; EXT-Andrew.Alston=40liquidtelecom.com <= ;Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40= raszuk.net>
Cc: spri= ng=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>
Subject: Re: =5Bspring=5D Spring protection - determining applicability
There are, as far as I can tell, a number of ways to address this family = of related questions.
What struck me, and prompted the starting question, was that none of them= were spelled out.&=23160; I see lots of interesting ideas / proposals. Some of them are compatible with others.&=23160;&=23160; Some are not. It would be good if we could reach agreement on how we thought it should = be handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirabl= e
> links/nodes exists in the case of topological SIDs.
>
> A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090
> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs= 6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46rfc4090>) = has been successfully deployed
> for many years before SR-MPLS has been introduced. What=E2=80=99s mo= re,
> signaling of bypass tunnels he PLR usually did not include any of th= e
> constraints used for computing of any specific LSP that the bypass L= SP
> would protect =E2=80=93 because in the =46acility Protection mode th= e same
> bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>&=23160; =46rom my POV the only difference between this behavior and = that
> introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, = in the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use =46RR; LSPs that would = not
> use =46RR would then drop traffic rather than delivering it the wron= g way.
>
> Such an option indeed does not exist in SR-TE today, but would be ea= sy
> to provide if so desired IMHO.
>
> Did I miss something substantial=3F
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:&=23160;&=23160;&=23160;&=23160;&=23160; +972-549266302
>
> Email:&=23160;&=23160; Alexander.Vainshtein=40ecitele.com
>
> *=46rom:* spring <spring-bounces=40ietf.org> *On Behalf Of = *Shraddha Hegde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston=40liquidtelecom.com
> <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk &= lt;rob= ert=40raszuk.net>
> *Cc:* spring=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>
> *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> All,
>
> This is a very interesting discussion and thanks to Joel for startin= g
> this discussion. IMO, when there are strict requirements of avoiding=
> certain nodes/links it can be realized&=23160; either by defining a = flex-algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avo= id
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sB=46D) protection mechanisms = can be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, th= e
> failure events may cause traffic to go through restricted nodes and<= br /> > links. This would happen regardless of whether any kind of protectio= n
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *=46rom:* spring <spring-bounces=40ietf.org
 > = <mailto:spring-bounces=40ietf.org>> *On Behalf Of *Andrew Al= ston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net>>
> *Cc:* spring=40ietf.org <mailto:spring=40ietf.org>; Joel M. Halpern
> <jmh=40joelhalpern.com <mailto:jmh=40joelhalpern.com>> > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> *=5BExternal Email. Be cautious of content=5D*
>
> Robert this is actually far more difficult when =E2=80=93 it can be = an entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=E2=80=99d worry that to d= o this =E2=80=93
> you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative la= bels =E2=80=93 and that wouldn=E2=80=99t
> be viable.
>
> It=E2=80=99s easier to use algorithms and adjacency sids and other s= uch things
> to calculate paths =E2=80=93 the biggest trick is about the stack de= pth.&=23160; When
> you have this need for node avoidance =E2=80=93 the need for 10+ lab= el depth
> is critical =E2=80=93 unless you wanna be applying one hell of a lot= of
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
> case that most of the people I discuss this with certain have =E2=80= =93 I cant
> comment on a global scale, or for anyone else, but every indication = I
> have is that yes =E2=80=93 its something people need, and want
= >
> Andrew
>
> *=46rom:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net= >>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston=40liquidtelecom.= com
 > <mailto:Andrew.Alston=40liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh=40joelhalpern.com
 > <= ;mai= lto:jmh=40joelhalpern.com>>; spring=40ietf.org
> <mailto:spring=40ietf.org>
> *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> Is this a common use case ie.&=23160; =22but rather =E2=80=93 which = nodes / network
> segments it can never touch or flow through.=22
>
> If so perhaps its time to define notion of *negative-SID* ie. list i= n
> the packet resources which given&=23160;packet MUST not ever travers= e.
>
> Put in the packet set of nodes or links which the packet should neve= r
> traverse.
>
> That goes in line of recent wave of negative routing implementations=
> (RI=46T) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston=40liquidtelecom.com
 > &= lt;mailto:Andrew.Alston=40liquidtelecom.com>> wrote:
>
>&=23160;&=23160;&=23160;&=23160; So =E2=80=93
>
>&=23160;&=23160;&=23160;&=23160; One of the use cases, in fact, some = very major use cases in any
>&=23160;&=23160;&=23160;&=23160; spring technology for us revolve aro= und the following
>
>&=23160;&=23160;&=23160;&=23160; a.The explicit avoidance of certain = nodes
>
>&=23160;&=23160;&=23160;&=23160; b.The explicit avoidance of certain = sections of the network
>
>&=23160;&=23160;&=23160;&=23160; Anything that could result in that e= xplicit avoidance being violated
>&=23160;&=23160;&=23160;&=23160; =E2=80=93 would create, shall we say= significant problems.
>
>&=23160;&=23160;&=23160;&=23160; Much of the use case is not a case o= f which nodes the packets flow
>&=23160;&=23160;&=23160;&=23160; through =E2=80=93 but rather =E2=80=93= which nodes / network segments it can never
>&=23160;&=23160;&=23160;&=23160; touch or flow through.&=23160; Effec= tively, to be used as a technology to
>&=23160;&=23160;&=23160;&=23160; avoid certain things for specific re= asons.
>
>&=23160;&=23160;&=23160;&=23160; This is also one of the reasons for = needing such deep label stacks =E2=80=93
>&=23160;&=23160;&=23160;&=23160; this kind of detailed path programmi= ng tends to deepen the stack
>&=23160;&=23160;&=23160;&=23160; because you sometimes have to be pre= tty explicit.
>
>&=23160;&=23160;&=23160;&=23160; It is absolutely critical to us that= this functionality is there =E2=80=93
>&=23160;&=23160;&=23160;&=23160; and that we can avoid situations whi= ch could cause traffic to
>&=23160;&=23160;&=23160;&=23160; accidently hit things explicitly avo= ided.
>
>&=23160;&=23160;&=23160;&=23160; I wish I could be more specific than= this, but it is what it is.
>
>&=23160;&=23160;&=23160;&=23160; Thanks
>
>&=23160;&=23160;&=23160;&=23160; Andrew
>
>&=23160;&=23160;&=23160;&=23160; *=46rom:* spring <spring-bounc= es=40ietf.org
 >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing-bounces=40ietf.org>> *On Behalf Of *Joel M. Halpern
>&=23160;&=23160;&=23160;&=23160; *Sent:* Monday, 3 August 2020 21:36<= br /> >&=23160;&=23160;&=23160;&=23160; *To:* Robert Raszuk <robert=40raszuk.net= <mailto:robert=40raszuk.net>>
>&=23160;&=23160;&=23160;&=23160; *Cc:* spring=40ietf..org <mailto:spring=40ie= tf.org>
>&=23160;&=23160;&=23160;&=23160; *Subject:* Re: =5Bspring=5D Spring p= rotection - determining
> applicability
>
>&=23160;&=23160;&=23160;&=23160; (Since the thread has gotten long en= ough, reiterating that this is as a
>&=23160;&=23160;&=23160;&=23160; participant, not a WG chair.)
>
>&=23160;&=23160;&=23160;&=23160; Yes, we are talking IP networks. And= yes, I have seen IP networks that
>&=23160;&=23160;&=23160;&=23160; choose to drop packets. =46or all so= rts of reasons.
>&=23160;&=23160;&=23160;&=23160; I think there are likely other reaso= ns why one may not want a random
>&=23160;&=23160;&=23160;&=23160; path rather than a chosen TE path. I= think it is important we be clear
>&=23160;&=23160;&=23160;&=23160; about what constraints may be / are = violated when we tell people they
>&=23160;&=23160;&=23160;&=23160; have this tool (protective rerouting= ) that is intended to preserve QoS.
>
>&=23160;&=23160;&=23160;&=23160; Let's be clear. I am not arguing tha= t this is not a good idea. It is a
>&=23160;&=23160;&=23160;&=23160; good idea. And useful. I am trying t= o figure otu what combination of
>&=23160;&=23160;&=23160;&=23160; additional mechanisms and clear desc= riptions will lead to everyone
>&=23160;&=23160;&=23160;&=23160; getting the behavior they expect (wh= ich may not be the behavior they
>&=23160;&=23160;&=23160;&=23160; desire, but sometimes is the best we= can do.)
>
>&=23160;&=23160;&=23160;&=23160; Yours,
>&=23160;&=23160;&=23160;&=23160; Joel
>
>&=23160;&=23160;&=23160;&=23160; On 8/3/2020 2:30 PM, Robert Raszuk w= rote:
>&=23160;&=23160;&=23160;&=23160;&=23160; > Joel,
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Are we still talking ab= out IP networks&=23160;here =3F Or perhaps some hard
>&=23160;&=23160;&=23160;&=23160;&=23160; > slicing with real resou= rce reservations or detnets =3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Because&=23160;if we ar= e talking&=23160;about IP networking I have two
>&=23160;&=23160;&=23160;&=23160; observations:
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > A) If you need to trave= rse via a specific node (ie. firewall) you
>&=23160;&=23160;&=23160;&=23160; better
>&=23160;&=23160;&=23160;&=23160;&=23160; > apply IP encapsulation = to that node.. I don't think IP
>&=23160;&=23160;&=23160;&=23160; encapsulation&=23160;can
>&=23160;&=23160;&=23160;&=23160;&=23160; > be hijacked today such = that destination address of the packet is
>&=23160;&=23160;&=23160;&=23160; ignored.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > B) Have you seen any IP= network where upon topology change (link
>&=23160;&=23160;&=23160;&=23160; or node
>&=23160;&=23160;&=23160;&=23160;&=23160; > failure) you suddenly&=23= 160;start dropping&=23160;flows in spite of SPT offering
>&=23160;&=23160;&=23160;&=23160;&=23160; > perhaps few ms longer p= ath with 10 ms more jitter =3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Or are some SR marketin= g slides promise to turn IP networks in
>&=23160;&=23160;&=23160;&=23160;&=23160; > something&=23160;new =3F= Worse ... do they mention path quality guarantees,
>&=23160;&=23160;&=23160;&=23160;&=23160; > resource reservations&=23= 160;=3F I hope not.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Thx,
>&=23160;&=23160;&=23160;&=23160;&=23160; > R.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > On Mon, Aug 3, 2020 at = 8:10 PM Joel M. Halpern <jmh=40joelhalpern.com
 >&=23160;&=23= 160;&=23160;&=23160; <mailto:jmh=40joelhalpern.com%20%0b>> &= lt;m= ailto:jmh=40joelhalpern.com>> wrote:
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Well less serious for T= E SIDs, I am not sure the problem is
>&=23160;&=23160;&=23160;&=23160; restricted
>&=23160;&=23160;&=23160;&=23160;&=23160; > to just service SIDs. >&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Suppose that the PCE ha= s specified the path to meet some complex te
>&=23160;&=23160;&=23160;&=23160;&=23160; > objective.&=23160; The = bypass node has no way of knowing what those
>&=23160;&=23160;&=23160;&=23160;&=23160; > constraints
>&=23160;&=23160;&=23160;&=23160;&=23160; > were.&=23160; And for s= ome kinds of traffic, it is better to drop the packet
>&=23160;&=23160;&=23160;&=23160;&=23160; > than to deliver it outs= ide the envelop.&=23160; I suspect that the right
>&=23160;&=23160;&=23160;&=23160;&=23160; > answer
>&=23160;&=23160;&=23160;&=23160;&=23160; > to this is =22too bad=22= .&=23160; If so, as with the distinction regarding
>&=23160;&=23160;&=23160;&=23160; service
>&=23160;&=23160;&=23160;&=23160;&=23160; > nodes, we should say so= , shouldn't we=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Yours,
>&=23160;&=23160;&=23160;&=23160;&=23160; > Joel
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > On 8/3/2020 2:36 AM, Al= exander Vainshtein wrote:
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach, Joel and all= ,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I think that in mo= st cases:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > 1.There is clear d= ifferentiation between =22topological=22 and
>&=23160;&=23160;&=23160;&=23160; =22service=22
>&=23160;&=23160;&=23160;&=23160;&=23160; > > instructions in SI= D advertisements. E.g.:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > oIGP Prefix Node S= IDs IGP Adj-SIDs (identified as such in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > corresponding IGP = advertisements) represent topological
>&=23160;&=23160;&=23160;&=23160; instructions
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > oService SIDs for = SRv6 (see SRv6 BGP-Based Overlay Services
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3CCcy9mY6cMfbk7Qfjhi= A3R6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.ietf.org%2=46doc%2=46html%2=46= draft-ietf-bess-srv6-services-04
 >&=23160;&=23160;&=23160;&=23= 160; <https://clickt= ime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2=3Fu=3Dhttps%3A%2=46%2=46urlde= fense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46= html%2=46draft-ietf-bess-srv6-services-04=5F=5F%3B%21%21NEt6yMaO-gk%21S0Y= usx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24&= gt;>
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > draft) unsurprisin= gly represent =E2=80=9Cservice=E2=80=9D instructions
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > 2.Segments that re= present topological instructions can be bypassed,
>&=23160;&=23160;&=23160;&=23160;&=23160; > > while segments tha= t represent service instructions require
>&=23160;&=23160;&=23160;&=23160;&=23160; > alternative
>&=23160;&=23160;&=23160;&=23160;&=23160; > > protection mechani= sms.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > This view seems to= be aligned with R=46C 8402
>&=23160;&=23160;&=23160;&=23160;&=23160; > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2=3Fu=3Dhttps%3A= %2=46%2=46tools.ietf.org%2=46html%2=46rfc8402
 >&=23160;&=231= 60;&=23160;&=23160; <https://clicktime.symantec.com/37PzUK= AD82cjSvmVcGvpkh=466H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46tools.ietf.org%2=46html%2=46rfc8402=5F=5F%3B%21%21NEt6= yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I= 4Ybtm%24>>
>&=23160;&=23160;&=23160;&=23160; that says in Section 1:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of an IGP-based distributed control plane, two
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the IGP-Adjacency segment and the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; IGP-Prefix segment.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of a BGP-based distributed control plane, two
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the BGP peering segment and the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; BGP-Prefix segment.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > In the case of SR-= MPLS this differentiation is assumed in Section
>&=23160;&=23160;&=23160;&=23160;&=23160; > 3.4 of
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the Node Protectio= n for SR-TE Path
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktim= e.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2=3Fu=3Dhttps%3A%2=46%2=46datatra= cker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protection-for= -sr-te-paths-07%23section-3.4
 >&=23160;&=23160;&=23160;&=231= 60; <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ= 16H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= datatracker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protect= ion-for-sr-te-paths-07%2Asection-3.4=5F=5F%3BIw%21%21NEt6yMaO-gk%21S0Yusx= 9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>= >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > draft that says: >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The node protection mechanism described in the previous
>&=23160;&=23160;&=23160;&=23160; sections
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; depends on the assumption that the label immediately below
>&=23160;&=23160;&=23160;&=23160;&=23160; > the top
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > label in the label= stack is understood in the IGP domain.&=23160; When the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; provider edge routers exchange service labels via BGP or some
>&=23160;&=23160;&=23160;&=23160;&=23160; > other
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; non-IGP mechanism the bottom label is not understood in the IGP
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; domain.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The egress node protection mechanisms described in the draft
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; =5BR=46C8679 <https://clicktime.syma= ntec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.i= etf.org%2=46doc%2=46html%2=46rfc8679
 >&=23160;&=23160;&=2316= 0;&=23160; <https://clicktime.symantec.com/36= dMAjuYTQovo8jHwmm3eJw6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46html%2=46rfc8679=5F=5F= %3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo8MGipXc%24>>=5D
>&=23160;&=23160;&=23160;&=23160; is
>&=23160;&=23160;&=23160;&=23160;&=23160; > > applicable to this= use case and no additional changes
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; will be required for SR based networks
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > The scenarios in w= hich &=23160;differentiation between =E2=80=9Ctopological=E2=80=9D and >&=23160;&=23160;&=23160;&=23160;&=23160; > > =E2=80=9Cservice=E2= =80=9D instructions is broken are indeed problematic. E.g.,
>&=23160;&=23160;&=23160;&=23160;&=23160; > consider
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the use case in wh= ich a Node SID in the ERO of a SR-TE path
>&=23160;&=23160;&=23160;&=23160;&=23160; > identifies a
>&=23160;&=23160;&=23160;&=23160;&=23160; > > node that acts as = a firewall for all packets it receives, i.e.,
>&=23160;&=23160;&=23160;&=23160;&=23160; > provides
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the firewall servi= ce without any dedicated service SID
>&=23160;&=23160;&=23160;&=23160;&=23160; > identifying it.
>&=23160;&=23160;&=23160;&=23160;&=23160; > > One could say that= the Node SID of such a node would combine
>&=23160;&=23160;&=23160;&=23160;&=23160; > topological
>&=23160;&=23160;&=23160;&=23160;&=23160; > > and service instru= ctions thus breaking the differentiation
>&=23160;&=23160;&=23160;&=23160;&=23160; > between the two.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I am not sure if u= sage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
>&=23160;&=23160;&=23160;&=23160;&=23160; > or at
>&=23160;&=23160;&=23160;&=23160;&=23160; > > least discouraged.=
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > If not, providing = an ability to identify such SIDs in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > advertisement
>&=23160;&=23160;&=23160;&=23160;&=23160; > > mechanisms would b= e useful IMHO.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > My 2c,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Sasha
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Office: +972-39266= 302
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Cell:&=23160;&=231= 60;&=23160;&=23160;&=23160; +972-549266302
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Email: Alex= ander.Vainshtein=40ecitele.com
>&=23160;&=23160;&=23160;&=23160; <mailto:Alexander.Vainsh= tein=40ecitele.com>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:Ale= xander.Vainshtein=40ecitele.com>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > -----Original Mess= age-----
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =46rom: spring <= ;spring-bounces=40ietf.org
 >&=23160;&=23160;&=23160;&=231= 60; <mailto:spring-bounces=40ietf.org%0b>>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org= >> On Behalf Of Mach Chen
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Sent: Monday, Augu= st 3, 2020 6:30 AM
>&=23160;&=23160;&=23160;&=23160;&=23160; > > To: Joel M. Halper= n <jmh=40joelhalpern.com
 >&=23160;&=23160;&=23160;&=23160;= <mailto:jmh=40joelhalpern.com%0b>> <mailto:jmh=40joelhalpern.= com>>;
>&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Subject: Re: =5Bsp= ring=5D Spring protection - determining applicability
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Hi Joel,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I think this is a = good point that may not be discussed in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > past. And
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I also don't think= there is a =22can be bypassed=22 indication in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > routing advertisem= ent for now.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > IMHO, the informat= ion advertised by routing is neutral, such
>&=23160;&=23160;&=23160;&=23160;&=23160; > information
>&=23160;&=23160;&=23160;&=23160;&=23160; > > (can or cannot be = bypassed) is more path specific, thus
>&=23160;&=23160;&=23160;&=23160; normally the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > controller should = be responsible for deciding whether/which SID
>&=23160;&=23160;&=23160;&=23160;&=23160; > can be
>&=23160;&=23160;&=23160;&=23160;&=23160; > > bypassed.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Best regards,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > -----= Original Message-----
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46ro= m: spring =5Bmailto:spring-bounces=40ietf.org
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring-bounc= es=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org%0b%3e%20%3cmailto:spring-= bounces=40ietf.org%3e>=5D
>&=23160;&=23160;&=23160;&=23160; On Behalf Of Joel M.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Halpe= rn
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Sent:= Monday, August 3, 2020 7:51 AM
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > To: <= a href=3D=22mailto:spring=40ietf.org=22 target=3D=22=5Fblank=22>spring=40= ietf.org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
 >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Subje= ct: =5Bspring=5D Spring protection - determining applicability
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > (WG C= hair hat Off, this is merely a note from a slightly
>&=23160;&=23160;&=23160;&=23160;&=23160; > confused WG
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > parti= cipant.)
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > I hav= e been reading the various repair drafts, and the various
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > netwo= rks programming and service programming draft, and I am
>&=23160;&=23160;&=23160;&=23160;&=23160; > trying to
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > figur= e out one aspect of the combination.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > How d= oes a node that is doing some form of bypass (suppose, for
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > simpl= icity, it is Node N2 deciding to bypass the next SID for
>&=23160;&=23160;&=23160;&=23160;&=23160; > a failed
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > node = N3) know that it is safe to do so=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > If th= e path was just for TE, then it is =22safe=22 if the new path
>&=23160;&=23160;&=23160;&=23160;&=23160; > meets
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > the T= E criteria.&=23160; or maybe it is safe if it is even close, as
>&=23160;&=23160;&=23160;&=23160;&=23160; > long as
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > it is= not used for too long.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > But w= hat if the node were a =46irewall, included to meet legal
>&=23160;&=23160;&=23160;&=23160;&=23160; > > requirements=3F >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Or wa= s some other necessary programmatic transform (wince we are
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > delib= erately vague about what nodes can do when asked suitably.)
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Is th= ere some =22can be bypassed=22 indication in the routing
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > adver= tisements that I missed=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Thank= you,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Yours= ,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Joel<= br /> >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > sprin= g mailing list
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > spring=40ietf= .org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
 >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dh= ttps%3A%2
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892Xu= Xy2H6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%= 2=46clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2= A3A%2A2=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3F= u=3Dhttps%3A%252
 >&=23160;&=23160;&=23160;&=23160; <https://clicktime.sym= antec.com/3A5B8H2=46m1rPnaZ3Supjwr6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.= com%2=46v3%2=46=5F=5Fhttps%3A%2=46clicktime.symantec.com%2=46367qhU4KiUkz= W9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%2A252=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0= Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24= >>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46%<= a href=3D=22http://2=46www.ietf.org=22 target=3D=22=5Fblank=22>2=46www.ie= tf.org
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/39NznmYBtR= uHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5F= http%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5F= R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <https://clicktime.sym= antec.com/3GWT9fyja=46i3=46cvHDvoodvS6H2=3Fu=3Dhttp%3A%2=46%2=462=46www.i= etf.org
 >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symant= ec.com/39NznmYBtRuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%= 2=46v3%2=46=5F=5Fhttp%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<= /a>>>%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org> <mailto:s= pring=40ietf.org
 >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing=40ietf.org%0b>> <mailto:spring=40ietf.org>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT= 6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%= 2A2=46%2A2=46www.ietf.org%2A2=46mailman%2A2=46listinfo%2A2=46spring=5F=5F= %3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Notice: This e-mai= l together with any attachments may contain
>&=23160;&=23160;&=23160;&=23160;&=23160; > > information of Rib= bon Communications Inc. that is confidential
>&=23160;&=23160;&=23160;&=23160;&=23160; > and/or
>&=23160;&=23160;&=23160;&=23160;&=23160; > > proprietary for th= e sole use of the intended recipient. Any review,
>&=23160;&=23160;&=23160;&=23160;&=23160; > > disclosure, relian= ce or distribution by others or forwarding
>&=23160;&=23160;&=23160;&=23160; without
>&=23160;&=23160;&=23160;&=23160;&=23160; > > express permission= is strictly prohibited. If you are not the
>&=23160;&=23160;&=23160;&=23160;&=23160; > intended
>&=23160;&=23160;&=23160;&=23160;&=23160; > > recipient, please = notify the sender immediately and then delete all
>&=23160;&=23160;&=23160;&=23160;&=23160; > > copies, including = any attachments.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dht= tps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://= clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > spring mailing list
>&=23160;&=23160;&=23160;&=23160;&=23160; > spring=40ietf.org <mailto:spring= =40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A= %2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://= clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>
>&=23160;&=23160;&=23160;&=23160; =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
>&=23160;&=23160;&=23160;&=23160; spring mailing list
>&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160;
> <https://clicktime.= symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%
 > 2=46= %2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listi
> nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqgu
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> --------------------------------------------------------------------= --
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/o= r
> proprietary for the sole use of the intended recipient. Any review,<= br /> > disclosure, reliance or distribution by others or forwarding without=
> express permission is strictly prohibited. If you are not the intend= ed
> recipient, please notify the sender immediately and then delete all<= br /> > copies, including any attachments.
> --------------------------------------------------------------------= --
> --

=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
spring mailing list
spring=40= ietf.org
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring
=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
spring mailing list
spring=40= ietf.org
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring

&=23160;

&=23160;

<= /span>

Notice: This e-mail together with any attachments may co= ntain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, di= sclosure, reliance or distribution by others or forwarding without expres= s permission is strictly prohibited. If you are not the intended recipien= t, please notify the sender immediately and then delete all copies, inclu= ding any attachments.

<= /span>

&=23160;

=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
spring mailing list
spring=40= ietf.org
https://www.ietf.org/mailman/listinfo/spring
--5f3705b9_46e87ccd_65d7-- From nobody Fri Aug 14 14:47:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EA53A0B64 for ; Fri, 14 Aug 2020 14:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, PDS_BTC_MSGID=0.998, SPF_HELO_NONE=0.001, 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 xbrFf6d4L-WD for ; Fri, 14 Aug 2020 14:47:36 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 DDA703A0B60 for ; Fri, 14 Aug 2020 14:47:35 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id j21so5144369pgi.9 for ; Fri, 14 Aug 2020 14:47:35 -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=Ub1JN8Hy2IFQm29BYXkjNakWX7jBcYHBI2l3mYTvYZU=; b=QLX7iIeUdc3P2lANkMscmjMhUZICwDm8MVW6bLdtzO/vYewBMYDd1IUlRCyHtN41dP 7cqVzXcTNDCwi22VltJPhewrVtQiOqzjEugmJ1rAQHYzgSGQIOnl7NzMxGr1igKbYAf6 2yWkS7Gqn+Tk5Yh6cV2NDwlGTdwgOOGkAtTzISuHCzs4n7D68jJtaApgNtB7I+69af7U IZCpf6RrYuTNsqCK28tBcp7LniZBLm0c4NkO/PhgrEiLOPZgDGKTc/4NxFH/7X1u/gn+ Ftxu4ZQQbI4L7N+qOfWn0rgiFB+Znln7Rwrx965L9ojOTLBt2lBl05VHnVqjarR7EO01 46tA== 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=Ub1JN8Hy2IFQm29BYXkjNakWX7jBcYHBI2l3mYTvYZU=; b=tysgb1ycvrxOxQLM6Sib3nzi1ZlsHvHL6StSOf5KbHWL4Ifwz+M3EeClxDkmfuId4q rIRml8JlzqmfeWc/XQfD1ZYoerYCDmhllLSD4PkZBdX6Hfo9m0FRlNDQ2z0coTiizbnE jtBj6nOpmBq7d02SGPPshe2lQVyu7gsYYP20HeKPnrqlRzo6J2i0H3TJVJrjPfgvop2e Ezc8/VOgbAEsAwskRdpFAsR73rl7sfAqOorVyjkm2cvshXDj2Qj3n6VxSpCHdZ8xA9JB uEDKyzb7SIr4XvWQvvCEcTijUGZjB9cysyylJnLTqnc/2QOBZ+M4Yp7ZvmYBN8qWkJ7n tLJQ== X-Gm-Message-State: AOAM5310f123ZN24b2d7y547/A8qBZ3yewsgn3nXnT9FGODu9RYrEsqQ QJh8FsgTpaziMYmWct5YyBo= X-Google-Smtp-Source: ABdhPJwfQsgeuvy8X9UHHJkrBG8IjKJXdzEv6ugch4sonrKmfZYWABs4H6/mg/HLshU6paloaMGFdA== X-Received: by 2002:a63:4e56:: with SMTP id o22mr2854193pgl.381.1597441654864; Fri, 14 Aug 2020 14:47:34 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id p9sm8894082pge.39.2020.08.14.14.47.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2020 14:47:33 -0700 (PDT) Date: Fri, 14 Aug 2020 14:47:21 -0700 From: Jeff Tantsura To: Robert Raszuk Cc: "Ketan Talaulikar (ketant)" , Alexander Vainshtein , "=?utf-8?Q?spring=40ietf.org?=" , "Joel M. Halpern" , Shraddha Hegde , "=?utf-8?Q?EXT-Andrew.Alston=40liquidtelecom.com?=" Message-ID: In-Reply-To: <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> X-Readdle-Message-ID: e8dff31f-613e-4224-b784-77fd743f21cf@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f370673_507ed7ab_65d7" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 21:47:41 -0000 --5f370673_507ed7ab_65d7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline PCE computation in this case is trivial too(must traverse node B or node = X) else =46AIL. Cheers, Jeff On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura = , wrote: > Robert, > > Agreed and apologies, hit send before finishing the email (it is =46rid= ay) ;-) > > Path protection in this case make more sense and is much less complex, > if in the pathA (A->B->C) node B is a service node, it can=E2=80=99t be= bypassed (node protected) if the link between A and B breaks > however it could have a backup pathB (A->X->C) where X is the service n= ode, potentially synchronizing its state with the node B. > > To my previous email - at expense of more state, we provide path and se= rvice protection, hence the similarity with RSVP-TE trade-offs. > > Cheers, > Jeff > On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , wr= ote: > > Jeff, > > > > > This is very similar to RSVP-TE > > > > I would rather differ on that statement. > > > > See if you are using SR just for TE you are 100% right. > > > > But if your SIDs embed additional local SR node processing functions = this suddenly=C2=A0becomes a completely different game. Let's keep this i= n mind in this thread/topic. > > > > Kind regards, > > R. > > > > > > > On =46ri, Aug 14, 2020 at 11:15 PM Jeff Tantsura wrote: > > > > This is very similar to RSVP-TE, path vs link/node protection and= usually dictated by the business logic, the triggers are obviously very = different, head-end being notified of the failure on a path and switching= to the backup path vs reaction to a local failure, so same consideration= s apply: > > > > -more state > > > > -pre-reserved resources > > > > while > > > > -predictable > > > > -meets SLA (as good as primary) > > > > vs > > > > -less state > > > > -local > > > > -best effort / can cause congestions > > > > > > > > Cheers, > > > > Jeff > > > > On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) , wrote: > > > > > Hi Robert, > > > > > > > > > > We do not have a signalling mechanism in IGPs today to indicate= a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was= a desire for it, an IGP extension would be required (there is none in pr= ogress A=46AIK). Note that this results in doubling the prefix SID scale = (global labels) in the network. So I would not go about this trivially. > > > > > > > > > > I think it helps to get more inputs and perspectives from opera= tors on their views for doing a bypass via local protection for segments = in an SR Policy. There may be those that prefer end-to-end path protectio= n using a fallback path that is say disjoint with the primary but provide= s an appropriate SLA/intent=3F > > > > > > > > > > Thanks, > > > > > Ketan > > > > > > > > > > =46rom: Robert Raszuk > > > > > Sent: 14 August 2020 23:04 > > > > > To: Ketan Talaulikar (ketant) > > > > > Cc: Alexander Vainshtein ; Joe= l M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > Subject: Re: =5Bspring=5D Spring protection - determining appli= cability > > > > > > > > > > Ketan, > > > > > > > > > > Looks like we are pretty much in sync here. > > > > > > > > > > But let me just observe that I purposely=C2=A0did not mention a= bout SR policies as we are not able to signal the intent with the packets= itself. > > > > > > > > > > So all we have there is SIDs. BSIDs or prefix SIDs need to be f= looded with information if policies build with using them are bypass elig= ible or not. > > > > > > > > > > I was actually under the impression that this is already there = and I am just not aware, but looking deeper indeed I do not see this mark= ing neither in ISIS nor OSP=46 for prefix SIDs. > > > > > > > > > > Is there some work in progress to add it to those protocols or = have we just documented need=C2=A0for a short LSR draft=C2=A0 =3F > > > > > > > > > > Thx, > > > > > R. > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) wrote: > > > > > > Hi Robert, > > > > > > > > > > > > Please check inline below. > > > > > > > > > > > > =46rom: Robert Raszuk > > > > > > Sent: 14 August 2020 21:13 > > > > > > To: Ketan Talaulikar (ketant) > > > > > > Cc: Alexander Vainshtein ; J= oel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining app= licability > > > > > > > > > > > > Hi Ketan, > > > > > > > > > > > > While I completely agree with your note the consequences of i= t are pretty sevre. > > > > > > =5BKT=5D I understand. We need to be mindful of implications = of protection schemes for the SLAs/intent of SR Policies. > > > > > > > > > > > > Unless we signal which prefix SID is protection eligible and = which is not how would other nodes know if they can protect it or not =3F= > > > > > > =5BKT=5D Correct. To be more accurate, we need to consider th= is more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies = and which segments may be =E2=80=9Cbypass-able=E2=80=9D for local protect= ion for some of those SR Policies. We also have path-protection mechanism= s. > > > > > > > > > > > > It seems that today's safe thing is not to apply any node pro= tection on SR flows at the PLRs then. > > > > > > > > > > > > And link protection MUST assure that packets will arrive at t= he neighbor node via some other link regardless of further path towards d= estination. > > > > > > =5BKT=5D Yes. We have a mechanism to indicate which adj-SIDs = have protection (that mechanism only provides link protection to get to t= he neighbor node) so the SR Policy computation is able to indicate whethe= r that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its choic= e of protected or unprotected adj-SIDs respectively. > > > > > > > > > > > > Thanks, > > > > > > Ketan > > > > > > > > > > > > Is it correct =3F > > > > > > > > > > > > Thx > > > > > > R > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <= ketant=40cisco.com> wrote: > > > > > > > Hi Sasha, > > > > > > > > > > > > > > The service node advertises its own Prefix SID. The service= function that this service node implements does not require any context = (i.e. all packets arriving at the node are subjected to that service). Th= erefore the service node does not need to receive a packet with it=E2=80=99= s own Prefix SID. > > > > > > > > > > > > > > Thus, we cannot assume that when PHP is used, then the SID = is only associated with a topological instruction. > > > > > > > > > > > > > > Hope that clarifies=3F > > > > > > > > > > > > > > Thanks, > > > > > > > Ketan > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > Sent: 14 August 2020 20:24 > > > > > > > To: Ketan Talaulikar (ketant) ; Joel M.= Halpern ; Shraddha Hegde = ; EXT-Andrew.Alston=40liquidtelecom.com ; Robert Raszuk > > > > > > > Cc: spring=40ietf.org > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining a= pplicability > > > > > > > > > > > > > > Ketan, and all, > > > > > > > I have stated that, IMHO and =46WIW, both Adj-SIDs and Pref= ix SIDs that are advertised with PHP can=C2=A0 ONLY represent topological= instructions in SR-MPLS - because the advertising node will not receive = them and therefore can hardly be expected to associate any service functi= on with them. > > > > > > > > > > > > > > This is complementary to what you have said. > > > > > > > > > > > > > > Hope this clarifies my position. > > > > > > > What, if anything, did I miss=3F > > > > > > > > > > > > > > Regards, > > > > > > > Sasha > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > =46rom: Ketan Talaulikar (ketant) > > > > > > > Sent: =46riday, August 14, 2020, 16:23 > > > > > > > To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; = EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > Cc: spring=40ietf.org > > > > > > > Subject: RE: =5Bspring=5D Spring protection - determining a= pplicability > > > > > > > > > > > > > > NOTICE: This email was received from an EXTERNAL sender > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > If the service does not need any additional context (e.g. a= firewall that just applies locally configured default rules on it), then= I don=E2=80=99t see why PHP could not be done for a Prefix SID associate= d with a service node. > > > > > > > > > > > > > > Also, I didn=E2=80=99t follow the point that you were tryin= g to make about Adj-SIDs. > > > > > > > > > > > > > > Thanks, > > > > > > > Ketan > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > Sent: 14 August 2020 18:24 > > > > > > > To: Ketan Talaulikar (ketant) ; Joel M.= Halpern ; Alexander Vainshtein ; Shraddha Hegde ; EXT-Andrew.Alst= on=40liquidtelecom.com ; Robert Raszuk= > > > > > > > Cc: spring=40ietf.org > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining a= pplicability > > > > > > > > > > > > > > Hi all, > > > > > > > Regarding the statement =22Prefix SID could be just a topol= ogical instruction or may also be used to steer the flow to a node which = is applying a service function to it=22: > > > > > > > > > > > > > > > > > > > > > I think that in SR-MPLS a Node SID that is advertised with = PHP aciton can be safely considered as =22just a topological instruction=22= by the PLR because the originating node will not receive it. > > > > > > > The same applies to Adj-SDIs. > > > > > > > > > > > > > > My 2c. > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > =46rom: spring on behalf of Ket= an Talaulikar (ketant) > > > > > > > Sent: =46riday, August 14, 2020, 15:00 > > > > > > > To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; = EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > Cc: spring=40ietf.org > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining a= pplicability > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > I would like to share a different perspective on this. > > > > > > > > > > > > > > =46irst, thanks to Joel for bringing up the discussion. Cle= arly we need a well-defined applicability statement for determining appli= cability of protection for segment used in an SR Policy. Some of this is = captured in =5B1=5D. > > > > > > > > > > > > > > This is about local repair at a PLR. By it's very nature, t= he PLR does not have a notion of how =22strict or not=22 is the SLA that = is being provided by the SR Policy. Awareness of that notion exists at th= e SR Policy headend and/or computation-node. > > > > > > > > > > > > > > We have protected and un-protected variants of adjacency SI= Ds to enable the computation to pick or the other based on the =22strictn= ess=22 of the SLA requirement for picking that link. We do not have such = a notion for Prefix SIDs. One can say that we could introduce signalling = (e.g. a B flag) to indicate whether a Prefix SID can be bypassed or not. = This provides the opportunity for the computation to use one or the other= flavor depending on the nature of the SLA for the SR Policy. > > > > > > > > > > > > > > I have a problem and a concern in the assumption that PLRs = can assume that the currently defined variant of Prefix SIDs in R=46C8402= (and IGP specs) are =22bypass-able=22. > > > > > > > > > > > > > > As Joel and others have brought out, the Prefix SID could b= e just a topological instruction or may also be used to steer the flow to= a node which is applying a service function to it. In order to support a= mix of SR Policies of different SLAs (strict and not-strict), we need to= enable the choice of SIDs that indicates to the PLR whether they are =22= bypass-able=22 or not. > > > > > > > > > > > > > > =46or the cases, where the SR Policy has a specific SLA, it= is required for nodes to drop the packets meant for the =22active segmen= t=22 than to bypass it. When this mechanism is used along side SRTE path = monitoring mechanisms, it enables the headend to detect the failure and f= allback to an alternate path using the path protection approach. This is = something that is described and in use in deployments today =5B1=5D.. > > > > > > > > > > > > > > Thanks, > > > > > > > Ketan > > > > > > > > > > > > > > =5B1=5D https://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAi= WwUms6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-ietf-s= pring-segment-routing-policy-08%23section-9 > > > > > > > =5B2=5D https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrm= n7H6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spr= ing-segment-routing-policy-08%23section-9.3 > > > > > > > > > > > > > > -----Original Message----- > > > > > > > =46rom: spring On Behalf Of Joe= l M. Halpern > > > > > > > Sent: 04 August 2020 20:25 > > > > > > > To: Alexander Vainshtein ;= Shraddha Hegde ; EXT-Andrew.A= lston=40liquidtelecom.com ; Robert Ras= zuk > > > > > > > Cc: spring=40ietf.org; Joel M. Halpern > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining a= pplicability > > > > > > > > > > > > > > There are, as far as I can tell, a number of ways to addres= s this family of related questions. > > > > > > > What struck me, and prompted the starting question, was tha= t none of them were spelled out.=C2=A0 I see lots of interesting ideas / = proposals. > > > > > > > Some of them are compatible with others.=C2=A0=C2=A0 Some a= re not. > > > > > > > It would be good if we could reach agreement on how we thou= ght it should be handled. > > > > > > > > > > > > > > Thank you, > > > > > > > Joel > > > > > > > > > > > > > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I am still not sure that the problem of bypass going thru= undesirable > > > > > > > > links/nodes exists in the case of topological SIDs. > > > > > > > > > > > > > > > > A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 40= 90 > > > > > > > > ) has been s= uccessfully deployed > > > > > > > > for many years before SR-MPLS has been introduced. What=E2= =80=99s more, > > > > > > > > signaling of bypass tunnels he PLR usually did not includ= e any of the > > > > > > > > constraints used for computing of any specific LSP that t= he bypass LSP > > > > > > > > would protect =E2=80=93 because in the =46acility Protect= ion mode the same > > > > > > > > bypass LSP would be used to protect multiple LSPs passing= thru the > > > > > > > > failed link/node. > > > > > > > > > > > > > > > >=C2=A0 =46rom my POV the only difference between this beha= vior and that > > > > > > > > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in S= R is that, in the case of > > > > > > > > RSVP-TE, the operator would explicitly indicate, as part = of LSP > > > > > > > > signaling, whether it would or would not use =46RR; LSPs = that would not > > > > > > > > use =46RR would then drop traffic rather than delivering = it the wrong way. > > > > > > > > > > > > > > > > Such an option indeed does not exist in SR-TE today, but = would be easy > > > > > > > > to provide if so desired IMHO. > > > > > > > > > > > > > > > > Did I miss something substantial=3F > > > > > > > > > > > > > > > > Regards, and lots of thanks in advance, > > > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > Office: +972-39266302 > > > > > > > > > > > > > > > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302 > > > > > > > > > > > > > > > > Email:=C2=A0=C2=A0 Alexander.Vainshtein=40ecitele.com > > > > > > > > > > > > > > > > *=46rom:* spring *On Behalf O= f *Shraddha Hegde > > > > > > > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > > > > > > > *To:* EXT-Andrew.Alston=40liquidtelecom.com > > > > > > > > ; Robert Raszuk > > > > > > > > *Cc:* spring=40ietf.org; Joel M. Halpern > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determini= ng applicability > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > This is a very interesting discussion and thanks to Joel = for starting > > > > > > > > this discussion. IMO, when there are strict requirements = of avoiding > > > > > > > > certain nodes/links it can be realized=C2=A0 either by de= fining a flex-algo > > > > > > > > avoiding those > > > > > > > > > > > > > > > > Nodes and links or by using a stack of unprotected adj-si= ds that avoid > > > > > > > > restricted nodes and links. When a stack of adj-sids is u= sed to > > > > > > > > realize the path, the head-end based (sB=46D) protection = mechanisms can be applied. > > > > > > > > > > > > > > > > If Node-sids/prefix-sid/anycast-sids are used to build th= e stack, the > > > > > > > > failure events may cause traffic to go through restricted= nodes and > > > > > > > > links. This would happen regardless of whether any kind o= f protection > > > > > > > > is in use or not. > > > > > > > > > > > > > > > > Rgds > > > > > > > > > > > > > > > > Shraddha > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > > > *=46rom:* spring > > > > > > > > *On Behalf Of *Andrew= Alston > > > > > > > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > > > > > > > *To:* Robert Raszuk > > > > > > > > > *Cc:* spring=40ietf.org ; Joel = M. Halpern > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determini= ng applicability > > > > > > > > > > > > > > > > *=5BExternal Email. Be cautious of content=5D* > > > > > > > > > > > > > > > > Robert this is actually far more difficult when =E2=80=93= it can be an entire > > > > > > > > (long) series of nodes that need to be avoided. > > > > > > > > > > > > > > > > It could potentially be made to work but I=E2=80=99d worr= y that to do this =E2=80=93 > > > > > > > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 = negative labels =E2=80=93 and that wouldn=E2=80=99t > > > > > > > > be viable. > > > > > > > > > > > > > > > > It=E2=80=99s easier to use algorithms and adjacency sids = and other such things > > > > > > > > to calculate paths =E2=80=93 the biggest trick is about t= he stack depth.=C2=A0 When > > > > > > > > you have this need for node avoidance =E2=80=93 the need = for 10+ label depth > > > > > > > > is critical =E2=80=93 unless you wanna be applying one he= ll of a lot of > > > > > > > > binding labels along the way which is a nightmare. > > > > > > > > > > > > > > > > But to answer your question, is this a common use case =E2= =80=93 it=E2=80=99s a use > > > > > > > > case that most of the people I discuss this with certain = have =E2=80=93 I cant > > > > > > > > comment on a global scale, or for anyone else, but every = indication I > > > > > > > > have is that yes =E2=80=93 its something people need, and= want > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > *=46rom:* Robert Raszuk > > > > > > > > > *Sent:* Tuesday, 4 August 2020 01:27 > > > > > > > > *To:* Andrew Alston > > > > > > > > > > > > > > > > *Cc:* Joel M. Halpern > > > > > > > >; spring=40ietf.org > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - determini= ng applicability > > > > > > > > > > > > > > > > Is this a common use case ie.=C2=A0 =22but rather =E2=80=93= which nodes / network > > > > > > > > segments it can never touch or flow through.=22 > > > > > > > > > > > > > > > > If so perhaps its time to define notion of *negative-SID*= ie. list in > > > > > > > > the packet resources which given=C2=A0packet MUST not eve= r traverse. > > > > > > > > > > > > > > > > Put in the packet set of nodes or links which the packet = should never > > > > > > > > traverse. > > > > > > > > > > > > > > > > That goes in line of recent wave of negative routing impl= ementations > > > > > > > > (RI=46T) or discussions (LSR) > > > > > > > > > > > > > > > > Best, > > > > > > > > R. > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93 > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, so= me very major use cases in any > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve = around the following > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certa= in nodes > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certa= in sections of the network > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in tha= t explicit avoidance being violated > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we = say significant problems. > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a cas= e of which nodes the packets flow > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80= =93 which nodes / network segments it can never > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effe= ctively, to be used as a technology to > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific= reasons. > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons f= or needing such deep label stacks =E2=80=93 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path progra= mming tends to deepen the stack > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be = pretty explicit. > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us t= hat this functionality is there =E2=80=93 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations = which could cause traffic to > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly = avoided. > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific t= han this, but it is what it is. > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *=46rom:* spring > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > *On Behalf Of *Joel M. Halpern > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:= 36 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring=40ietf..org > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: =5Bspring=5D Sprin= g protection - determining > > > > > > > > applicability > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long= enough, reiterating that this is as a > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.) > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. = And yes, I have seen IP networks that > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. =46or all= sorts of reasons. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other re= asons why one may not want a random > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path= . I think it is important we be clear > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / a= re violated when we tell people they > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerout= ing) that is intended to preserve QoS. > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing = that this is not a good idea. It is a > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am tryin= g to figure otu what combination of > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear d= escriptions will lead to everyone > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect = (which may not be the behavior they > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best= we can do.) > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yours, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Joel > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszu= k wrote: > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking abou= t IP networks=C2=A0here =3F Or perhaps some hard > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resourc= e reservations or detnets =3F > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are ta= lking=C2=A0about IP networking I have two > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 observations: > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to travers= e via a specific node (ie. firewall) you > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 better > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to= that node.. I don't think IP > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such th= at destination address of the packet is > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 ignored. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP n= etwork where upon topology change (link > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 or node > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0= start dropping=C2=A0flows in spite of SPT offering > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer pat= h with 10 ms more jitter =3F > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing = slides promise to turn IP networks in > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new =3F Wo= rse ... do they mention path quality guarantees, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0= =3F I hope not. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R. > > > > > > > >=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:= 10 PM Joel M. Halpern > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > wrote: > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE = SIDs, I am not sure the problem is > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 restricted > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has = specified the path to meet some complex te > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypa= ss node has no way of knowing what those > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some = kinds of traffic, it is better to drop the packet > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outsid= e the envelop.=C2=A0 I suspect that the right > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is =22too bad=22.= =C2=A0 If so, as with the distinction regarding > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 service > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, = shouldn't we=3F > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alex= ander Vainshtein wrote: > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most ca= ses: > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differ= entiation between =22topological=22 and > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =22service=22 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID adv= ertisements. E.g.: > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs I= GP Adj-SIDs (identified as such in the > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP adver= tisements) represent topological > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 instructions > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 = (see SRv6 BGP-Based Overlay Services > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly r= epresent =E2=80=9Cservice=E2=80=9D instructions > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represe= nt topological instructions can be bypassed, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that rep= resent service instructions require > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be a= ligned with R=46C 8402 > > > > > > > >=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 that says in Section 1: > > > > > > > >=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 In t= he context of an IGP-based distributed control plane, two > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments ar= e defined: the IGP-Adjacency segment and the > > > > > > > >=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 IGP-= Prefix segment. > > > > > > > >=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 In t= he context of a BGP-based distributed control plane, two > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments ar= e defined: the BGP peering segment and the > > > > > > > >=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 BGP-= Prefix segment. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS = this differentiation is assumed in Section > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for= SR-TE Path > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft that says: > > > > > > > >=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 The = node protection mechanism described in the previous > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 sections > > > > > > > >=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 depe= nds on the assumption that the label immediately below > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stac= k is understood in the IGP domain.=C2=A0 When the > > > > > > > >=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 prov= ider edge routers exchange service labels via BGP or some > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other > > > > > > > >=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 non-= IGP mechanism the bottom label is not understood in the IGP > > > > > > > >=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 doma= in. > > > > > > > >=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 The = egress node protection mechanisms described in the draft > > > > > > > >=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 =5BR= =46C8679 > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 >=5D > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 is > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use = case and no additional changes > > > > > > > >=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 will= be required for SR based networks > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which = =C2=A0differentiation between =E2=80=9Ctopological=E2=80=9D and > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D= instructions is broken are indeed problematic. E.g., > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a= Node SID in the ERO of a SR-TE path > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a fir= ewall for all packets it receives, i.e., > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service wi= thout any dedicated service SID > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the = Node SID of such a node would combine > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instruction= s thus breaking the differentiation > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage = of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ab= ility to identify such SIDs in the > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be use= ful IMHO. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +972-549266302 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainsh= tein=40ecitele.com > > > > > > > >=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 > > -----Original Message--= --- > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =46rom: spring > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > On Behalf Of Mach Chen > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3,= 2020 6:30 AM > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 = > >; > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: =5Bspring=5D= Spring protection - determining applicability > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good = point that may not be discussed in the > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think ther= e is a =22can be bypassed=22 indication in the > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement f= or now. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information a= dvertised by routing is neutral, such > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypas= sed) is more path specific, thus > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 normally the > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be re= sponsible for deciding whether/which SID > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original M= essage----- > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46rom: spring = =5Bmailto:spring-bounces=40ietf.org > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =5D > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M. > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, A= ugust 3, 2020 7:51 AM > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring=40ie= tf.org > > > > > > > >=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 > Subject: =5Bspr= ing=5D Spring protection - determining applicability > > > > > > > >=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 > (WG Chair hat O= ff, this is merely a note from a slightly > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.) > > > > > > > >=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 > I have been rea= ding the various repair drafts, and the various > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks progra= mming and service programming draft, and I am > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one = aspect of the combination. > > > > > > > >=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 > How does a node= that is doing some form of bypass (suppose, for > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it = is Node N2 deciding to bypass the next SID for > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know t= hat it is safe to do so=3F > > > > > > > >=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 > If the path was= just for TE, then it is =22safe=22 if the new path > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria= .=C2=A0 or maybe it is safe if it is even close, as > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used = for too long. > > > > > > > >=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 > But what if the= node were a =46irewall, included to meet legal > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements=3F > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some oth= er necessary programmatic transform (wince we are > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately va= gue about what nodes can do when asked suitably.) > > > > > > > >=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 > Is there some =22= can be bypassed=22 indication in the routing > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements = that I missed=3F > > > > > > > >=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 > Thank you, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel > > > > > > > >=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 > =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 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing = list > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring=40ietf.o= rg > > > > > > > >=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=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 https://clicktime.symantec.com/36= 7qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2 > > > > > > > >=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=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46%2=46www.iet= f.org > > > > > > > >=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 >%2=46ma= ilman%2=46listinfo%2=46spring > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =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 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org > > > > > > > >=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=A0=C2=A0=C2=A0 https://clicktime.symantec.com/36= 7qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman= %2=46listinfo%2=46spring > > > > > > > >=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=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 > > Notice: This e-mail tog= ether with any attachments may contain > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon C= ommunications Inc. that is confidential > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sol= e use of the intended recipient. Any review, > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or= distribution by others or forwarding > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 without > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is s= trictly prohibited. If you are not the > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notif= y the sender immediately and then delete all > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any a= ttachments. > > > > > > > >=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 > > =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 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.syman= tec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2= =46mailman%2=46listinfo%2=46spring > > > > > > > >=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 > =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 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring mailing list > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring=40ietf.org > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symante= c.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46= mailman%2=46listinfo%2=46spring > > > > > > > >=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 =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 > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring mailing list > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q= 1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman= %2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > 2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www= .ietf.org%2=46mailman%2=46listi > > > > > > > > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8= E=5FR1oiQAtQxgm0x0wxqgu > > > > > > > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------= ------------- > > > > > > > > -- > > > > > > > > Notice: This e-mail together with any attachments may con= tain > > > > > > > > information of Ribbon Communications Inc. that is confide= ntial and/or > > > > > > > > proprietary for the sole use of the intended recipient. A= ny review, > > > > > > > > disclosure, reliance or distribution by others or forward= ing without > > > > > > > > express permission is strictly prohibited. If you are not= the intended > > > > > > > > recipient, please notify the sender immediately and then = delete all > > > > > > > > copies, including any attachments. > > > > > > > > ---------------------------------------------------------= ------------- > > > > > > > > -- > > > > > > > > > > > > > > =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 > > > > > > > spring mailing list > > > > > > > spring=40ietf.org > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3F= u=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > =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 > > > > > > > spring mailing list > > > > > > > spring=40ietf.org > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3F= u=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any attachments may conta= in information of Ribbon Communications Inc. that is confidential and/or = proprietary for the sole use of the intended recipient. Any review, discl= osure, reliance or distribution by others or forwarding without express p= ermission is strictly prohibited. If you are not the intended recipient, = please notify the sender immediately and then delete all copies, includin= g any attachments. > > > > > > > > > > > > =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 > > > > > spring mailing list > > > > > spring=40ietf.org > > > > > https://www.ietf.org/mailman/listinfo/spring --5f370673_507ed7ab_65d7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
PCE computation in this case is trivial too(must tr= averse node B or node X) else =46AIL.

Cheers,
Jeff
On Aug 14, 2020, 2:44 PM -0700, Jef= f Tantsura <jefftant.ietf=40gmail.com>, wrote:
Robert,

Agreed and apologies, hit send before finishing the email (it is =46riday= ) ;-)

Path protection in this case make more sense and is much less complex,&=23= 160;
if in the pathA (A->B->C) node B is a service node, it can=E2=80=99= t be bypassed (node protected) if the link between A and B breaks&=23160;=
however it could have a backup pathB (A->X->C) where X is the servi= ce node, potentially synchronizing its state with the node B.

To my previous email - at expense of more state, we provide path and serv= ice protection, hence the similarity with RSVP-TE trade-offs.

Cheers,
Jeff
On Aug 14, 2020, 2:30 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:
Jeff,

> This is very similar to RSVP-TE&=23160;&=23160;

I would rather differ on that statement.&=23160;

See if you are using SR just for TE you are 100% right.&=23160;

But if your SIDs embed additional local SR node processing functions= this suddenly&=23160;becomes a completely different game. Let's keep thi= s in mind in this thread/topic.&=23160;

Kind regards,
R.


On =46ri, Aug 14, 2020 at= 11:15 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:
This is very similar to RSVP-TE, path vs link/node = protection and usually dictated by the business logic, the triggers are o= bviously very different, head-end being notified of the failure on a path= and switching to the backup path vs reaction to a local failure, so same= considerations apply:&=23160;
-more state
-pre-reserved resources
while&=23160;
-predictable
-meets SLA (as good as primary)
vs
-less state
-local
-best effort / can cause congestions&=23160;

Cheers,
Jeff
On Aug 14, 2020, 10:46 AM -0700, Ke= tan Talaulikar (ketant) <ketant=3D40cisco.com=40dmarc.ietf.org&= gt;, wrote:

Hi Robert,

&=23160;

We do not have a signalling mechanism in= IGPs today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Pr= efix SIDs. If there was a desire for it, an IGP extension would be requir= ed (there is none in progress A=46AIK). Note that this results in doublin= g the prefix SID scale (global labels) in the network. So I would not go = about this trivially.

&=23160;

I think it helps to get more inputs and = perspectives from operators on their views for doing a bypass via local p= rotection for segments in an SR Policy. There may be those that prefer en= d-to-end path protection using a fallback path that is say disjoint with = the primary but provides an appropriate SLA/intent=3F

&=23160;

Thanks,

Ketan

&=23160;

=46rom: R= obert Raszuk <robert=40raszuk.net>
Sent: 14 August 2020 23:04
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Ketan,

&=23160;

Looks like we are pretty much in sync here.&=23= 160;

&=23160;

But let me just observe that I purposely&=2316= 0;did not mention about SR policies as we are not able to signal the inte= nt with the packets itself.&=23160;

&=23160;

So all we have there is SIDs. BSIDs or prefix = SIDs need to be flooded with information if policies build with using the= m are bypass eligible or not.&=23160;

&=23160;

I was actually under the impression that this = is already there and I am just not aware, but looking deeper indeed I do = not see this marking neither in ISIS nor OSP=46 for prefix SIDs.&=23160;<= /p>

&=23160;

Is there some work in progress to add it to th= ose protocols or have we just documented need&=23160;for a short LSR draf= t&=23160; =3F&=23160;

&=23160;

Thx,

R.

&=23160;

&=23160;

On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:

Hi Robert,

&=23160;

Please check inline below.

&=23160;

=46rom: R= obert Raszuk <robert=40raszuk.net>
Sent: 14 August 2020 21:13
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Hi Ketan,

&=23160;

While I completely agree with your note the co= nsequences of it are pretty sevre.&=23160;

=5BKT=5D I understand. We need to be min= dful of implications of protection schemes for the SLAs/intent of SR Poli= cies.

&=23160;

Unless we signal which prefix SID is protectio= n eligible and which is not how would other nodes know if they can protec= t it or not =3F&=23160;

=5BKT=5D Correct. To be more accurate, w= e need to consider this more in the context of SLA or =E2=80=9Cintent=E2=80= =9D of SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D= for local protection for some of those SR Policies. We also have path-pr= otection mechanisms.

&=23160;

It seems that today's safe thing is not to app= ly any node protection on SR flows at the PLRs then.&=23160;

&=23160;

And link protection MUST assure that packets w= ill arrive at the neighbor node via some other link regardless of further= path towards destination.&=23160;

=5BKT=5D Yes. We have a mechanism to ind= icate which adj-SIDs have protection (that mechanism only provides link p= rotection to get to the neighbor node) so the SR Policy computation is ab= le to indicate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D= or not by its choice of protected or unprotected adj-SIDs respectively.<= /i>

&=23160;

Thanks,

Ketan

&=23160;

Is it correct =3F&=23160;

&=23160;

Thx

R

&=23160;

On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:

Hi Sasha,

&=23160;

The service node advertises its own Prefix SID= . The service function that this service node implements does not require= any context (i.e. all packets arriving at the node are subjected to that= service). Therefore the service node does not need to receive a packet w= ith it=E2=80=99s own Prefix SID.

&=23160;

Thus, we cannot assume that when PHP is used, = then the SID is only associated with a topological instruction.

&=23160;

Hope that clarifies=3F

&=23160;

Thanks,

Ketan

&=23160;

=46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>
Sent: 14 August 2020 20:24
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Shraddha Hegde <shraddha=40juniper.ne= t>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.= net>
Cc: spring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Ketan, and all,

I have stated that, IMHO and =46WIW, both Adj-SIDs= and Prefix SIDs that are advertised with PHP can&=23160; ONLY represent = topological instructions in SR-MPLS - because the advertising node will n= ot receive them and therefore can hardly be expected to associate any ser= vice function with them.

&=23160;

This is complementary to what you have said.

&=23160;

Hope this clarifies my position.

What, if anything, did I miss=3F

&=23160;

Regards,

Sasha

&=23160;

Get Outlook for Android

&=23160;

=46rom: Ketan Talaulikar (ketant) <ketant=40cisc= o.com>
Sent: =46riday, August 14, 2020, 16:23
To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk
Cc: sp= ring=40ietf.org
Subject: RE: =5Bspring=5D Spring protection - determining applicability=

&=23160;

NOTICE: This email was received from an EXTERN= AL sender

&=23160;

Hi Sasha,

&=23160;

If the service does not need any additional co= ntext (e.g. a firewall that just applies locally configured default rules= on it), then I don=E2=80=99t see why PHP could not be done for a Prefix = SID associated with a service node.

&=23160;

Also, I didn=E2=80=99t follow the point that y= ou were trying to make about Adj-SIDs.

&=23160;

Thanks,

Ketan

&=23160;

=46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>
Sent: 14 August 2020 18:24
To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Alexander Vainshtein <Alexand= er.Vainshtein=40rbbn.com>; Shraddha Hegde <shraddha=40juniper.net<= /a>>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.net= >
Cc: spring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility

&=23160;

Hi all,

Regarding the statement =22Prefix SID could be jus= t a topological instruction or may also be used to steer the flow to a no= de which is applying a service function to it=22:

&=23160;

&=23160;

I think that in SR-MPLS a Node SID that is adverti= sed with PHP aciton can be safely considered as =22just a topological ins= truction=22 by the PLR because the originating node will not receive it.<= /span>

The same applies to Adj-SDIs.

&=23160;

My 2c.

&=23160;

Get Outlook for Android

&=23160;

=46rom: spring <spring-bounces=40ietf.org= > on behalf of Ketan Talaulikar (ketant) <ketant=3D= 40cisco.com=40dmarc.ietf.org>
Sent: =46riday, August 14, 2020, 15:00
To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk
Cc: sp= ring=40ietf.org
Subject: Re: =5Bspring=5D Spring protection - determining applicability=

&=23160;

Hi All,

I would like to share a different perspective on this.

=46irst, thanks to Joel for bringing up the discussion. Clearly we need a= well-defined applicability statement for determining applicability of pr= otection for segment used in an SR Policy. Some of this is captured in =5B= 1=5D.

This is about local repair at a PLR. By it's very nature, the PLR does no= t have a notion of how =22strict or not=22 is the SLA that is being provi= ded by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

We have protected and un-protected variants of adjacency SIDs to enable t= he computation to pick or the other based on the =22strictness=22 of the = SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag= ) to indicate whether a Prefix SID can be bypassed or not. This provides = the opportunity for the computation to use one or the other flavor depend= ing on the nature of the SLA for the SR Policy.

I have a problem and a concern in the assumption that PLRs can assume tha= t the currently defined variant of Prefix SIDs in R=46C8402 (and IGP spec= s) are =22bypass-able=22.

As Joel and others have brought out, the Prefix SID could be just a topol= ogical instruction or may also be used to steer the flow to a node which = is applying a service function to it. In order to support a mix of SR Pol= icies of different SLAs (strict and not-strict), we need to enable the ch= oice of SIDs that indicates to the PLR whether they are =22bypass-able=22= or not.

=46or the cases, where the SR Policy has a specific SLA, it is required f= or nodes to drop the packets meant for the =22active segment=22 than to b= ypass it. When this mechanism is used along side SRTE path monitoring mec= hanisms, it enables the headend to detect the failure and fallback to an = alternate path using the path protection approach. This is something that= is described and in use in deployments today =5B1=5D..

Thanks,
Ketan

=5B1=5D htt= ps://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2= =46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-pol= icy-08%23section-9
=5B2=5D htt= ps://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46= %2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-policy= -08%23section-9.3

-----Original Message-----
=46rom: spring <spring-bounces=40ietf.org> On Behalf Of Joel M.= Halpern
Sent: 04 August 2020 20:25
To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com>= ;; Shraddha Hegde <shraddha=3D40juniper.net=40dmarc.ie= tf.org>; EXT-Andrew.Alston=40liquidtelecom.com <= ;Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40= raszuk.net>
Cc: spri= ng=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>
Subject: Re: =5Bspring=5D Spring protection - determining applicability
There are, as far as I can tell, a number of ways to address this family = of related questions.
What struck me, and prompted the starting question, was that none of them= were spelled out.&=23160; I see lots of interesting ideas / proposals. Some of them are compatible with others.&=23160;&=23160; Some are not. It would be good if we could reach agreement on how we thought it should = be handled.

Thank you,
Joel

On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
> Hi all,
>
> I am still not sure that the problem of bypass going thru undesirabl= e
> links/nodes exists in the case of topological SIDs.
>
> A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090
> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs= 6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46rfc4090>) = has been successfully deployed
> for many years before SR-MPLS has been introduced. What=E2=80=99s mo= re,
> signaling of bypass tunnels he PLR usually did not include any of th= e
> constraints used for computing of any specific LSP that the bypass L= SP
> would protect =E2=80=93 because in the =46acility Protection mode th= e same
> bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
>
>&=23160; =46rom my POV the only difference between this behavior and = that
> introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, = in the case of
> RSVP-TE, the operator would explicitly indicate, as part of LSP
> signaling, whether it would or would not use =46RR; LSPs that would = not
> use =46RR would then drop traffic rather than delivering it the wron= g way.
>
> Such an option indeed does not exist in SR-TE today, but would be ea= sy
> to provide if so desired IMHO.
>
> Did I miss something substantial=3F
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:&=23160;&=23160;&=23160;&=23160;&=23160; +972-549266302
>
> Email:&=23160;&=23160; Alexander.Vainshtein=40ecitele.com
>
> *=46rom:* spring <spring-bounces=40ietf.org> *On Behalf Of = *Shraddha Hegde
> *Sent:* Tuesday, August 4, 2020 9:41 AM
> *To:* EXT-Andrew.Alston=40liquidtelecom.com
> <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk &= lt;rob= ert=40raszuk.net>
> *Cc:* spring=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>
> *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> All,
>
> This is a very interesting discussion and thanks to Joel for startin= g
> this discussion. IMO, when there are strict requirements of avoiding=
> certain nodes/links it can be realized&=23160; either by defining a = flex-algo
> avoiding those
>
> Nodes and links or by using a stack of unprotected adj-sids that avo= id
> restricted nodes and links. When a stack of adj-sids is used to
> realize the path, the head-end based (sB=46D) protection mechanisms = can be applied.
>
> If Node-sids/prefix-sid/anycast-sids are used to build the stack, th= e
> failure events may cause traffic to go through restricted nodes and<= br /> > links. This would happen regardless of whether any kind of protectio= n
> is in use or not.
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *=46rom:* spring <spring-bounces=40ietf.org
 > = <mailto:spring-bounces=40ietf.org>> *On Behalf Of *Andrew Al= ston
> *Sent:* Tuesday, August 4, 2020 5:41 AM
> *To:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net>>
> *Cc:* spring=40ietf.org <mailto:spring=40ietf.org>; Joel M. Halpern
> <jmh=40joelhalpern.com <mailto:jmh=40joelhalpern.com>> > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> *=5BExternal Email. Be cautious of content=5D*
>
> Robert this is actually far more difficult when =E2=80=93 it can be = an entire
> (long) series of nodes that need to be avoided.
>
> It could potentially be made to work but I=E2=80=99d worry that to d= o this =E2=80=93
> you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative la= bels =E2=80=93 and that wouldn=E2=80=99t
> be viable.
>
> It=E2=80=99s easier to use algorithms and adjacency sids and other s= uch things
> to calculate paths =E2=80=93 the biggest trick is about the stack de= pth.&=23160; When
> you have this need for node avoidance =E2=80=93 the need for 10+ lab= el depth
> is critical =E2=80=93 unless you wanna be applying one hell of a lot= of
> binding labels along the way which is a nightmare.
>
> But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
> case that most of the people I discuss this with certain have =E2=80= =93 I cant
> comment on a global scale, or for anyone else, but every indication = I
> have is that yes =E2=80=93 its something people need, and want
= >
> Andrew
>
> *=46rom:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net= >>
> *Sent:* Tuesday, 4 August 2020 01:27
> *To:* Andrew Alston <Andrew.Alston=40liquidtelecom.= com
 > <mailto:Andrew.Alston=40liquidtelecom.com>>
> *Cc:* Joel M. Halpern <jmh=40joelhalpern.com
 > <= ;mai= lto:jmh=40joelhalpern.com>>; spring=40ietf.org
> <mailto:spring=40ietf.org>
> *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility
>
> Is this a common use case ie.&=23160; =22but rather =E2=80=93 which = nodes / network
> segments it can never touch or flow through.=22
>
> If so perhaps its time to define notion of *negative-SID* ie. list i= n
> the packet resources which given&=23160;packet MUST not ever travers= e.
>
> Put in the packet set of nodes or links which the packet should neve= r
> traverse.
>
> That goes in line of recent wave of negative routing implementations=
> (RI=46T) or discussions (LSR)
>
> Best,
> R.
>
> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
> <Andrew.Alston=40liquidtelecom.com
 > &= lt;mailto:Andrew.Alston=40liquidtelecom.com>> wrote:
>
>&=23160;&=23160;&=23160;&=23160; So =E2=80=93
>
>&=23160;&=23160;&=23160;&=23160; One of the use cases, in fact, some = very major use cases in any
>&=23160;&=23160;&=23160;&=23160; spring technology for us revolve aro= und the following
>
>&=23160;&=23160;&=23160;&=23160; a.The explicit avoidance of certain = nodes
>
>&=23160;&=23160;&=23160;&=23160; b.The explicit avoidance of certain = sections of the network
>
>&=23160;&=23160;&=23160;&=23160; Anything that could result in that e= xplicit avoidance being violated
>&=23160;&=23160;&=23160;&=23160; =E2=80=93 would create, shall we say= significant problems.
>
>&=23160;&=23160;&=23160;&=23160; Much of the use case is not a case o= f which nodes the packets flow
>&=23160;&=23160;&=23160;&=23160; through =E2=80=93 but rather =E2=80=93= which nodes / network segments it can never
>&=23160;&=23160;&=23160;&=23160; touch or flow through.&=23160; Effec= tively, to be used as a technology to
>&=23160;&=23160;&=23160;&=23160; avoid certain things for specific re= asons.
>
>&=23160;&=23160;&=23160;&=23160; This is also one of the reasons for = needing such deep label stacks =E2=80=93
>&=23160;&=23160;&=23160;&=23160; this kind of detailed path programmi= ng tends to deepen the stack
>&=23160;&=23160;&=23160;&=23160; because you sometimes have to be pre= tty explicit.
>
>&=23160;&=23160;&=23160;&=23160; It is absolutely critical to us that= this functionality is there =E2=80=93
>&=23160;&=23160;&=23160;&=23160; and that we can avoid situations whi= ch could cause traffic to
>&=23160;&=23160;&=23160;&=23160; accidently hit things explicitly avo= ided.
>
>&=23160;&=23160;&=23160;&=23160; I wish I could be more specific than= this, but it is what it is.
>
>&=23160;&=23160;&=23160;&=23160; Thanks
>
>&=23160;&=23160;&=23160;&=23160; Andrew
>
>&=23160;&=23160;&=23160;&=23160; *=46rom:* spring <spring-bounc= es=40ietf.org
 >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing-bounces=40ietf.org>> *On Behalf Of *Joel M. Halpern
>&=23160;&=23160;&=23160;&=23160; *Sent:* Monday, 3 August 2020 21:36<= br /> >&=23160;&=23160;&=23160;&=23160; *To:* Robert Raszuk <robert=40raszuk.net= <mailto:robert=40raszuk.net>>
>&=23160;&=23160;&=23160;&=23160; *Cc:* spring=40ietf..org <mailto:spring=40ie= tf.org>
>&=23160;&=23160;&=23160;&=23160; *Subject:* Re: =5Bspring=5D Spring p= rotection - determining
> applicability
>
>&=23160;&=23160;&=23160;&=23160; (Since the thread has gotten long en= ough, reiterating that this is as a
>&=23160;&=23160;&=23160;&=23160; participant, not a WG chair.)
>
>&=23160;&=23160;&=23160;&=23160; Yes, we are talking IP networks. And= yes, I have seen IP networks that
>&=23160;&=23160;&=23160;&=23160; choose to drop packets. =46or all so= rts of reasons.
>&=23160;&=23160;&=23160;&=23160; I think there are likely other reaso= ns why one may not want a random
>&=23160;&=23160;&=23160;&=23160; path rather than a chosen TE path. I= think it is important we be clear
>&=23160;&=23160;&=23160;&=23160; about what constraints may be / are = violated when we tell people they
>&=23160;&=23160;&=23160;&=23160; have this tool (protective rerouting= ) that is intended to preserve QoS.
>
>&=23160;&=23160;&=23160;&=23160; Let's be clear. I am not arguing tha= t this is not a good idea. It is a
>&=23160;&=23160;&=23160;&=23160; good idea. And useful. I am trying t= o figure otu what combination of
>&=23160;&=23160;&=23160;&=23160; additional mechanisms and clear desc= riptions will lead to everyone
>&=23160;&=23160;&=23160;&=23160; getting the behavior they expect (wh= ich may not be the behavior they
>&=23160;&=23160;&=23160;&=23160; desire, but sometimes is the best we= can do.)
>
>&=23160;&=23160;&=23160;&=23160; Yours,
>&=23160;&=23160;&=23160;&=23160; Joel
>
>&=23160;&=23160;&=23160;&=23160; On 8/3/2020 2:30 PM, Robert Raszuk w= rote:
>&=23160;&=23160;&=23160;&=23160;&=23160; > Joel,
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Are we still talking ab= out IP networks&=23160;here =3F Or perhaps some hard
>&=23160;&=23160;&=23160;&=23160;&=23160; > slicing with real resou= rce reservations or detnets =3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Because&=23160;if we ar= e talking&=23160;about IP networking I have two
>&=23160;&=23160;&=23160;&=23160; observations:
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > A) If you need to trave= rse via a specific node (ie. firewall) you
>&=23160;&=23160;&=23160;&=23160; better
>&=23160;&=23160;&=23160;&=23160;&=23160; > apply IP encapsulation = to that node.. I don't think IP
>&=23160;&=23160;&=23160;&=23160; encapsulation&=23160;can
>&=23160;&=23160;&=23160;&=23160;&=23160; > be hijacked today such = that destination address of the packet is
>&=23160;&=23160;&=23160;&=23160; ignored.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > B) Have you seen any IP= network where upon topology change (link
>&=23160;&=23160;&=23160;&=23160; or node
>&=23160;&=23160;&=23160;&=23160;&=23160; > failure) you suddenly&=23= 160;start dropping&=23160;flows in spite of SPT offering
>&=23160;&=23160;&=23160;&=23160;&=23160; > perhaps few ms longer p= ath with 10 ms more jitter =3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Or are some SR marketin= g slides promise to turn IP networks in
>&=23160;&=23160;&=23160;&=23160;&=23160; > something&=23160;new =3F= Worse ... do they mention path quality guarantees,
>&=23160;&=23160;&=23160;&=23160;&=23160; > resource reservations&=23= 160;=3F I hope not.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Thx,
>&=23160;&=23160;&=23160;&=23160;&=23160; > R.
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > On Mon, Aug 3, 2020 at = 8:10 PM Joel M. Halpern <jmh=40joelhalpern.com
 >&=23160;&=23= 160;&=23160;&=23160; <mailto:jmh=40joelhalpern.com%20%0b>> &= lt;m= ailto:jmh=40joelhalpern.com>> wrote:
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Well less serious for T= E SIDs, I am not sure the problem is
>&=23160;&=23160;&=23160;&=23160; restricted
>&=23160;&=23160;&=23160;&=23160;&=23160; > to just service SIDs. >&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Suppose that the PCE ha= s specified the path to meet some complex te
>&=23160;&=23160;&=23160;&=23160;&=23160; > objective.&=23160; The = bypass node has no way of knowing what those
>&=23160;&=23160;&=23160;&=23160;&=23160; > constraints
>&=23160;&=23160;&=23160;&=23160;&=23160; > were.&=23160; And for s= ome kinds of traffic, it is better to drop the packet
>&=23160;&=23160;&=23160;&=23160;&=23160; > than to deliver it outs= ide the envelop.&=23160; I suspect that the right
>&=23160;&=23160;&=23160;&=23160;&=23160; > answer
>&=23160;&=23160;&=23160;&=23160;&=23160; > to this is =22too bad=22= .&=23160; If so, as with the distinction regarding
>&=23160;&=23160;&=23160;&=23160; service
>&=23160;&=23160;&=23160;&=23160;&=23160; > nodes, we should say so= , shouldn't we=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > Yours,
>&=23160;&=23160;&=23160;&=23160;&=23160; > Joel
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > On 8/3/2020 2:36 AM, Al= exander Vainshtein wrote:
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach, Joel and all= ,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I think that in mo= st cases:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > 1.There is clear d= ifferentiation between =22topological=22 and
>&=23160;&=23160;&=23160;&=23160; =22service=22
>&=23160;&=23160;&=23160;&=23160;&=23160; > > instructions in SI= D advertisements. E.g.:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > oIGP Prefix Node S= IDs IGP Adj-SIDs (identified as such in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > corresponding IGP = advertisements) represent topological
>&=23160;&=23160;&=23160;&=23160; instructions
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > oService SIDs for = SRv6 (see SRv6 BGP-Based Overlay Services
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3CCcy9mY6cMfbk7Qfjhi= A3R6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.ietf.org%2=46doc%2=46html%2=46= draft-ietf-bess-srv6-services-04
 >&=23160;&=23160;&=23160;&=23= 160; <https://clickt= ime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2=3Fu=3Dhttps%3A%2=46%2=46urlde= fense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46= html%2=46draft-ietf-bess-srv6-services-04=5F=5F%3B%21%21NEt6yMaO-gk%21S0Y= usx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24&= gt;>
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > draft) unsurprisin= gly represent =E2=80=9Cservice=E2=80=9D instructions
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > 2.Segments that re= present topological instructions can be bypassed,
>&=23160;&=23160;&=23160;&=23160;&=23160; > > while segments tha= t represent service instructions require
>&=23160;&=23160;&=23160;&=23160;&=23160; > alternative
>&=23160;&=23160;&=23160;&=23160;&=23160; > > protection mechani= sms.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > This view seems to= be aligned with R=46C 8402
>&=23160;&=23160;&=23160;&=23160;&=23160; > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2=3Fu=3Dhttps%3A= %2=46%2=46tools.ietf.org%2=46html%2=46rfc8402
 >&=23160;&=231= 60;&=23160;&=23160; <https://clicktime.symantec.com/37PzUK= AD82cjSvmVcGvpkh=466H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46tools.ietf.org%2=46html%2=46rfc8402=5F=5F%3B%21%21NEt6= yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I= 4Ybtm%24>>
>&=23160;&=23160;&=23160;&=23160; that says in Section 1:
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of an IGP-based distributed control plane, two
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the IGP-Adjacency segment and the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; IGP-Prefix segment.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of a BGP-based distributed control plane, two
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the BGP peering segment and the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; BGP-Prefix segment.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > In the case of SR-= MPLS this differentiation is assumed in Section
>&=23160;&=23160;&=23160;&=23160;&=23160; > 3.4 of
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the Node Protectio= n for SR-TE Path
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktim= e.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2=3Fu=3Dhttps%3A%2=46%2=46datatra= cker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protection-for= -sr-te-paths-07%23section-3.4
 >&=23160;&=23160;&=23160;&=231= 60; <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ= 16H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= datatracker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protect= ion-for-sr-te-paths-07%2Asection-3.4=5F=5F%3BIw%21%21NEt6yMaO-gk%21S0Yusx= 9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>= >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > draft that says: >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The node protection mechanism described in the previous
>&=23160;&=23160;&=23160;&=23160; sections
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; depends on the assumption that the label immediately below
>&=23160;&=23160;&=23160;&=23160;&=23160; > the top
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > label in the label= stack is understood in the IGP domain.&=23160; When the
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; provider edge routers exchange service labels via BGP or some
>&=23160;&=23160;&=23160;&=23160;&=23160; > other
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; non-IGP mechanism the bottom label is not understood in the IGP
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; domain.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The egress node protection mechanisms described in the draft
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; =5BR=46C8679 <https://clicktime.syma= ntec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.i= etf.org%2=46doc%2=46html%2=46rfc8679
 >&=23160;&=23160;&=2316= 0;&=23160; <https://clicktime.symantec.com/36= dMAjuYTQovo8jHwmm3eJw6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46html%2=46rfc8679=5F=5F= %3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo8MGipXc%24>>=5D
>&=23160;&=23160;&=23160;&=23160; is
>&=23160;&=23160;&=23160;&=23160;&=23160; > > applicable to this= use case and no additional changes
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; will be required for SR based networks
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > The scenarios in w= hich &=23160;differentiation between =E2=80=9Ctopological=E2=80=9D and >&=23160;&=23160;&=23160;&=23160;&=23160; > > =E2=80=9Cservice=E2= =80=9D instructions is broken are indeed problematic. E.g.,
>&=23160;&=23160;&=23160;&=23160;&=23160; > consider
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the use case in wh= ich a Node SID in the ERO of a SR-TE path
>&=23160;&=23160;&=23160;&=23160;&=23160; > identifies a
>&=23160;&=23160;&=23160;&=23160;&=23160; > > node that acts as = a firewall for all packets it receives, i.e.,
>&=23160;&=23160;&=23160;&=23160;&=23160; > provides
>&=23160;&=23160;&=23160;&=23160;&=23160; > > the firewall servi= ce without any dedicated service SID
>&=23160;&=23160;&=23160;&=23160;&=23160; > identifying it.
>&=23160;&=23160;&=23160;&=23160;&=23160; > > One could say that= the Node SID of such a node would combine
>&=23160;&=23160;&=23160;&=23160;&=23160; > topological
>&=23160;&=23160;&=23160;&=23160;&=23160; > > and service instru= ctions thus breaking the differentiation
>&=23160;&=23160;&=23160;&=23160;&=23160; > between the two.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I am not sure if u= sage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
>&=23160;&=23160;&=23160;&=23160;&=23160; > or at
>&=23160;&=23160;&=23160;&=23160;&=23160; > > least discouraged.=
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > If not, providing = an ability to identify such SIDs in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > advertisement
>&=23160;&=23160;&=23160;&=23160;&=23160; > > mechanisms would b= e useful IMHO.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > My 2c,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Sasha
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Office: +972-39266= 302
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Cell:&=23160;&=231= 60;&=23160;&=23160;&=23160; +972-549266302
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Email: Alex= ander.Vainshtein=40ecitele.com
>&=23160;&=23160;&=23160;&=23160; <mailto:Alexander.Vainsh= tein=40ecitele.com>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:Ale= xander.Vainshtein=40ecitele.com>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > -----Original Mess= age-----
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =46rom: spring <= ;spring-bounces=40ietf.org
 >&=23160;&=23160;&=23160;&=231= 60; <mailto:spring-bounces=40ietf.org%0b>>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org= >> On Behalf Of Mach Chen
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Sent: Monday, Augu= st 3, 2020 6:30 AM
>&=23160;&=23160;&=23160;&=23160;&=23160; > > To: Joel M. Halper= n <jmh=40joelhalpern.com
 >&=23160;&=23160;&=23160;&=23160;= <mailto:jmh=40joelhalpern.com%0b>> <mailto:jmh=40joelhalpern.= com>>;
>&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Subject: Re: =5Bsp= ring=5D Spring protection - determining applicability
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Hi Joel,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I think this is a = good point that may not be discussed in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > past. And
>&=23160;&=23160;&=23160;&=23160;&=23160; > > I also don't think= there is a =22can be bypassed=22 indication in the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > routing advertisem= ent for now.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > IMHO, the informat= ion advertised by routing is neutral, such
>&=23160;&=23160;&=23160;&=23160;&=23160; > information
>&=23160;&=23160;&=23160;&=23160;&=23160; > > (can or cannot be = bypassed) is more path specific, thus
>&=23160;&=23160;&=23160;&=23160; normally the
>&=23160;&=23160;&=23160;&=23160;&=23160; > > controller should = be responsible for deciding whether/which SID
>&=23160;&=23160;&=23160;&=23160;&=23160; > can be
>&=23160;&=23160;&=23160;&=23160;&=23160; > > bypassed.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Best regards,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > -----= Original Message-----
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46ro= m: spring =5Bmailto:spring-bounces=40ietf.org
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring-bounc= es=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org%0b%3e%20%3cmailto:spring-= bounces=40ietf.org%3e>=5D
>&=23160;&=23160;&=23160;&=23160; On Behalf Of Joel M.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Halpe= rn
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Sent:= Monday, August 3, 2020 7:51 AM
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > To: <= a href=3D=22mailto:spring=40ietf.org=22 target=3D=22=5Fblank=22>spring=40= ietf.org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
 >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Subje= ct: =5Bspring=5D Spring protection - determining applicability
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > (WG C= hair hat Off, this is merely a note from a slightly
>&=23160;&=23160;&=23160;&=23160;&=23160; > confused WG
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > parti= cipant.)
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > I hav= e been reading the various repair drafts, and the various
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > netwo= rks programming and service programming draft, and I am
>&=23160;&=23160;&=23160;&=23160;&=23160; > trying to
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > figur= e out one aspect of the combination.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > How d= oes a node that is doing some form of bypass (suppose, for
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > simpl= icity, it is Node N2 deciding to bypass the next SID for
>&=23160;&=23160;&=23160;&=23160;&=23160; > a failed
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > node = N3) know that it is safe to do so=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > If th= e path was just for TE, then it is =22safe=22 if the new path
>&=23160;&=23160;&=23160;&=23160;&=23160; > meets
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > the T= E criteria.&=23160; or maybe it is safe if it is even close, as
>&=23160;&=23160;&=23160;&=23160;&=23160; > long as
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > it is= not used for too long.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > But w= hat if the node were a =46irewall, included to meet legal
>&=23160;&=23160;&=23160;&=23160;&=23160; > > requirements=3F >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Or wa= s some other necessary programmatic transform (wince we are
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > delib= erately vague about what nodes can do when asked suitably.)
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Is th= ere some =22can be bypassed=22 indication in the routing
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > adver= tisements that I missed=3F
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Thank= you,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Yours= ,
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Joel<= br /> >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > sprin= g mailing list
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > spring=40ietf= .org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
 >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
= >&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dh= ttps%3A%2
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892Xu= Xy2H6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%= 2=46clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2= A3A%2A2=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3F= u=3Dhttps%3A%252
 >&=23160;&=23160;&=23160;&=23160; <https://clicktime.sym= antec.com/3A5B8H2=46m1rPnaZ3Supjwr6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.= com%2=46v3%2=46=5F=5Fhttps%3A%2=46clicktime.symantec.com%2=46367qhU4KiUkz= W9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%2A252=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0= Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24= >>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46%<= a href=3D=22http://2=46www.ietf.org=22 target=3D=22=5Fblank=22>2=46www.ie= tf.org
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/39NznmYBtR= uHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5F= http%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5F= R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > <https://clicktime.sym= antec.com/3GWT9fyja=46i3=46cvHDvoodvS6H2=3Fu=3Dhttp%3A%2=46%2=462=46www.i= etf.org
 >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symant= ec.com/39NznmYBtRuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%= 2=46v3%2=46=5F=5Fhttp%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<= /a>>>%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org> <mailto:s= pring=40ietf.org
 >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing=40ietf.org%0b>> <mailto:spring=40ietf.org>>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT= 6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%= 2A2=46%2A2=46www.ietf.org%2A2=46mailman%2A2=46listinfo%2A2=46spring=5F=5F= %3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo-hR3gAD%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------
>&=23160;&=23160;&=23160;&=23160;&=23160; > > Notice: This e-mai= l together with any attachments may contain
>&=23160;&=23160;&=23160;&=23160;&=23160; > > information of Rib= bon Communications Inc. that is confidential
>&=23160;&=23160;&=23160;&=23160;&=23160; > and/or
>&=23160;&=23160;&=23160;&=23160;&=23160; > > proprietary for th= e sole use of the intended recipient. Any review,
>&=23160;&=23160;&=23160;&=23160;&=23160; > > disclosure, relian= ce or distribution by others or forwarding
>&=23160;&=23160;&=23160;&=23160; without
>&=23160;&=23160;&=23160;&=23160;&=23160; > > express permission= is strictly prohibited. If you are not the
>&=23160;&=23160;&=23160;&=23160;&=23160; > intended
>&=23160;&=23160;&=23160;&=23160;&=23160; > > recipient, please = notify the sender immediately and then delete all
>&=23160;&=23160;&=23160;&=23160;&=23160; > > copies, including = any attachments.
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; > > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t
>&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dht= tps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://= clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; > >
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>&=23160;&=23160;&=23160;&=23160;&=23160; > =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
>&=23160;&=23160;&=23160;&=23160;&=23160; > spring mailing list
>&=23160;&=23160;&=23160;&=23160;&=23160; > spring=40ietf.org <mailto:spring= =40ietf.org> <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160;&=23160; > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A= %2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160; <https://= clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>&=23160;&=23160;&=23160;&=23160;&=23160; >
>
>&=23160;&=23160;&=23160;&=23160; =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
>&=23160;&=23160;&=23160;&=23160; spring mailing list
>&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org>
>&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring
>&=23160;&=23160;&=23160;&=23160;
> <https://clicktime.= symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%
 > 2=46= %2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listi
> nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqgu
> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
>
>
>
> --------------------------------------------------------------------= --
> --
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/o= r
> proprietary for the sole use of the intended recipient. Any review,<= br /> > disclosure, reliance or distribution by others or forwarding without=
> express permission is strictly prohibited. If you are not the intend= ed
> recipient, please notify the sender immediately and then delete all<= br /> > copies, including any attachments.
> --------------------------------------------------------------------= --
> --

=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
spring mailing list
spring=40= ietf.org
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring
=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
spring mailing list
spring=40= ietf.org
https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring

&=23160;

&=23160;

<= /span>

Notice: This e-mail together with any attachments may co= ntain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, di= sclosure, reliance or distribution by others or forwarding without expres= s permission is strictly prohibited. If you are not the intended recipien= t, please notify the sender immediately and then delete all copies, inclu= ding any attachments.

<= /span>

&=23160;

=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
spring mailing list
spring=40= ietf.org
https://www.ietf.org/mailman/listinfo/spring
--5f370673_507ed7ab_65d7-- From nobody Fri Aug 14 19:44:54 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15E23A1529 for ; Fri, 14 Aug 2020 19:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 b1qO86I_dPuY for ; Fri, 14 Aug 2020 19:44:47 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 409523A1525 for ; Fri, 14 Aug 2020 19:44:47 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id j188so5654261vsd.2 for ; Fri, 14 Aug 2020 19:44:47 -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=t9tX6od1fhKwScPZS7Tctme5PuIB5JzeVPipmBsgrwM=; b=VSFJCc0r8x67Q/vZm/R2de0ZN2tXDxAclPq7edXEiT/WdObeMlUArgonm4dhzqLYiG vJHw0edKVDZyjgkRy4Bse5jl1fdsnJ2gJsRNkMCUrDBQz5qcg0JFKwnKeUP5qmU4ux3i yp76ZyBu9JEHduTzzF5lHYUk7h0TzlSkcSrxSChT82gQTQF+2xUD1eiRmNAH1CGRDzCR 3XHT1Pl4BrDrvoM4rB1X90PgnJBIv7fDugih3UT1g8TDB0IDmrUE8uLwpHxdceXGOo6n 1I7ibaXx5tpFjEysneMUwtH2acWGQ+EIpnoB01oSc9WeXCUX1FrmeZ7ZN5kqsnmejMRX PtSQ== 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=t9tX6od1fhKwScPZS7Tctme5PuIB5JzeVPipmBsgrwM=; b=ZNPWbJKh1MKRVdmvwT9TmAia7flj6jxLJ2XoKkfVJ6NvGor/N7zgkv5tNcmvQPb75+ tM9KEQhRSisQyPntE+GAD+rGasDIGciJVw7RhJpeQeD4QfjXhs2uFHIwrrdWnRd5iQmo a91XVIslXpGds0rkcozXTzaGDzpqOOgBbonOKTW2u0ogUfW/DlX4vCBYwVj9fI2vmH0z C9oT51IBSUS099unvQCuo2A8BIyUAzF3oVhpGaGMshjVXklzd0XmS6qzaKFx7VZK4KfV 94Bpb9jMMfYocO7Ywtm11Lri0F20HY9CG4/cgmBeDyHKOQPuYgZNRc7BhqVEop+kexcm EHaw== X-Gm-Message-State: AOAM5319a6tsMDdL6FpUEMH3NzRteGYJ4BRpkd3VeD7O6ACzFN3NgJcQ toQWqfy34TJ4VJ6N2H+0Spi+vwsJPwVW2M0QCqk= X-Google-Smtp-Source: ABdhPJzvVKjQ0XPl05KUaP+UV0D/o9zrresUx21zIHiyHksbXkyPbOlM/DrLFEArR9E0v0KMhacFVBISg/0G+Ogxi8Y= X-Received: by 2002:a67:fbd1:: with SMTP id o17mr3181098vsr.19.1597459485881; Fri, 14 Aug 2020 19:44:45 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> In-Reply-To: From: Gyan Mishra Date: Fri, 14 Aug 2020 22:44:34 -0400 Message-ID: To: Jeff Tantsura Cc: Alexander Vainshtein , "EXT-Andrew.Alston@liquidtelecom.com" , "Joel M. Halpern" , "Ketan Talaulikar (ketant)" , Robert Raszuk , Shraddha Hegde , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000032fa3e05ace18557" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 02:44:53 -0000 --00000000000032fa3e05ace18557 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Catching up on this thread as it is a interesting topic as FRR 1:N link protection, node protection and path protection is critical to operators. There are multiple somewhat orthogonal topics brought up in the discussion. Excluding SR SFC from =E2=80=9Cbypass=E2=80=9D capable node such for applia= nces such as firewalls and load balancer. Makes sense. I would not think SFC would be in a PLR path to merger point but I could be mistaken. The goal of SR is eliminating state and so having TE like state is undesirable. Intent based instantiation of bypass via SR-TE from network feedback at PLR detection node of a failure and make before break pre computed backup paths that can. It would make sense that SR-TE binding SID policy would be appropriate for RSVP like FRR link node or path protection. My thoughts on this topic of SR protection is that don=E2=80=99t we already= have FRR protection natively without requiring SR-TE BSID or any additional undesirable state maintenance with TI-LFA. Thanks Gyan On Fri, Aug 14, 2020 at 5:47 PM Jeff Tantsura wrote: > > > > > > > > > > > > > PCE computation in this case is trivial too(must traverse node B or node > X) else FAIL. > > > > > > > > Cheers, > > Jeff > > > > > > > On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura , > wrote: > > > > > > > Robert, > > > > > > Agreed and apologies, hit send before finishing the email (it is Friday) > ;-) > > > > > > Path protection in this case make more sense and is much less complex, > > > if in the pathA (A->B->C) node B is a service node, it can=E2=80=99t be b= ypassed > (node protected) if the link between A and B breaks > > > however it could have a backup pathB (A->X->C) where X is the service > node, potentially synchronizing its state with the node B. > > > > > > To my previous email - at expense of more state, we provide path and > service protection, hence the similarity with RSVP-TE trade-offs. > > > > > > > > Cheers, > > Jeff > > > > > > > On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , wrote: > > > > > Jeff, > > > > > > This is very similar to RSVP-TE > > > > > > I would rather differ on that statement. > > > > > > See if you are using SR just for TE you are 100% right. > > > > > > But if your SIDs embed additional local SR node processing functions this > suddenly becomes a completely different game. Let's keep this in mind in > this thread/topic. > > > > > > Kind regards, > > > R. > > > > > > > > > > > > > On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura > wrote: > > > >> >> >> >> >> >> This is very similar to RSVP-TE, path vs link/node protection and usuall= y >> dictated by the business logic, the triggers are obviously very differen= t, >> head-end being notified of the failure on a path and switching to the >> backup path vs reaction to a local failure, so same considerations apply= : >> >> >> -more state >> >> >> -pre-reserved resources >> >> >> while >> >> >> -predictable >> >> >> -meets SLA (as good as primary) >> >> >> vs >> >> >> -less state >> >> >> -local >> >> >> -best effort / can cause congestions >> >> >> >> >> >> >> >> Cheers, >> >> Jeff >> >> >> >> >> >> >> On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) > 40cisco.com@dmarc.ietf.org>, wrote: >> >> >> >> >> >> >> Hi Robert, >> >> >> >> >> >> We do not have a signalling mechanism in IGPs today to indicate a >> =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was a= desire for it, an >> IGP extension would be required (there is none in progress AFAIK). Note >> that this results in doubling the prefix SID scale (global labels) in th= e >> network. So I would not go about this trivially. >> >> >> >> >> >> I think it helps to get more inputs and perspectives from operators on >> their views for doing a bypass via local protection for segments in an S= R >> Policy. There may be those that prefer end-to-end path protection using = a >> fallback path that is say disjoint with the primary but provides an >> appropriate SLA/intent? >> >> >> >> >> >> Thanks, >> >> >> Ketan >> >> >> >> >> >> >> >> *From:* Robert Raszuk >> >> >> *Sent:* 14 August 2020 23:04 >> >> >> *To:* Ketan Talaulikar (ketant) >> >> >> *Cc:* Alexander Vainshtein ; Joel M. >> Halpern ; Shraddha Hegde ; >> EXT-Andrew.Alston@liquidtelecom.com ; >> spring@ietf.org >> >> >> *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> >> >> >> >> >> >> >> Ketan, >> >> >> >> >> >> >> >> >> >> >> >> Looks like we are pretty much in sync here. >> >> >> >> >> >> >> >> >> >> >> >> >> >> But let me just observe that I purposely did not mention about SR >> policies as we are not able to signal the intent with the packets itself= . >> >> >> >> >> >> >> >> >> >> >> >> >> >> So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded >> with information if policies build with using them are bypass eligible o= r >> not. >> >> >> >> >> >> >> >> >> >> >> >> >> >> I was actually under the impression that this is already there and I am >> just not aware, but looking deeper indeed I do not see this marking neit= her >> in ISIS nor OSPF for prefix SIDs. >> >> >> >> >> >> >> >> >> >> >> >> >> >> Is there some work in progress to add it to those protocols or have we >> just documented need for a short LSR draft ? >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thx, >> >> >> >> >> >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) < >> ketant@cisco.com> wrote: >> >> >> >> >> >> >> >> >> >> >> Hi Robert, >> >> >> >> >> >> Please check inline below. >> >> >> >> >> >> >> >> *From:* Robert Raszuk >> >> >> *Sent:* 14 August 2020 21:13 >> >> >> *To:* Ketan Talaulikar (ketant) >> >> >> *Cc:* Alexander Vainshtein ; Joel M. >> Halpern ; Shraddha Hegde ; >> EXT-Andrew.Alston@liquidtelecom.com ; >> spring@ietf.org >> >> >> *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> >> >> >> >> >> >> >> Hi Ketan, >> >> >> >> >> >> >> >> >> >> >> >> While I completely agree with your note the consequences of it are prett= y >> sevre. >> >> >> *[KT] I understand. We need to be mindful of implications of protection >> schemes for the SLAs/intent of SR Policies.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> Unless we signal which prefix SID is protection eligible and which is no= t >> how would other nodes know if they can protect it or not ? >> >> >> *[KT] Correct. To be more accurate, we need to consider this more in the >> context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and which segm= ents may be >> =E2=80=9Cbypass-able=E2=80=9D for local protection for some of those SR = Policies. We also >> have path-protection mechanisms.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> It seems that today's safe thing is not to apply any node protection on >> SR flows at the PLRs then. >> >> >> >> >> >> >> >> >> >> >> >> >> >> And link protection MUST assure that packets will arrive at the neighbor >> node via some other link regardless of further path towards destination. >> >> >> *[KT] Yes. We have a mechanism to indicate which adj-SIDs have protectio= n >> (that mechanism only provides link protection to get to the neighbor nod= e) >> so the SR Policy computation is able to indicate whether that specific l= ink >> is =E2=80=9Cbypass-able=E2=80=9D or not by its choice of protected or un= protected adj-SIDs >> respectively.* >> >> >> >> >> >> *Thanks,* >> >> >> *Ketan* >> >> >> >> >> >> >> >> >> >> >> >> >> >> Is it correct ? >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thx >> >> >> >> >> >> >> R >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) < >> ketant@cisco.com> wrote: >> >> >> >> >> >> >> >> >> >> >> Hi Sasha, >> >> >> >> >> >> The service node advertises its own Prefix SID.. The service function >> that this service node implements does not require any context (i.e. all >> packets arriving at the node are subjected to that service). Therefore t= he >> service node does not need to receive a packet with it=E2=80=99s own Pre= fix SID. >> >> >> >> >> >> Thus, we cannot assume that when PHP is used, then the SID is only >> associated with a topological instruction. >> >> >> >> >> >> Hope that clarifies? >> >> >> >> >> >> Thanks, >> >> >> Ketan >> >> >> >> >> >> >> >> >> >> *From:* Alexander Vainshtein >> >> >> *Sent:* 14 August 2020 20:24 >> >> >> *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < >> jmh@joelhalpern.com>; Shraddha Hegde ; >> EXT-Andrew.Alston@liquidtelecom.com ; >> Robert Raszuk >> >> >> *Cc:* spring@ietf.org >> >> >> *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> >> >> >> >> >> >> >> Ketan, and all, >> >> >> I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that ar= e >> advertised with PHP can ONLY represent topological instructions in SR-M= PLS >> - because the advertising node will not receive them and therefore can >> hardly be expected to associate any service function with them. >> >> >> >> >> >> This is complementary to what you have said. >> >> >> >> >> >> Hope this clarifies my position. >> >> >> What, if anything, did I miss? >> >> >> >> >> >> Regards, >> >> >> Sasha >> >> >> >> >> >> >> >> >> >> >> >> Get Outlook for Android >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> >> >> *From:* Ketan Talaulikar (ketant) >> >> >> *Sent:* Friday, August 14, 2020, 16:23 >> >> >> *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; >> EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk >> >> >> *Cc:* spring@ietf.org >> >> >> *Subject:* RE: [spring] Spring protection - determining applicability >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> NOTICE: This email was received from an EXTERNAL sender >> >> >> >> >> ------------------------------ >> >> >> >> >> >> >> >> Hi Sasha, >> >> >> >> >> >> If the service does not need any additional context (e.g. a firewall tha= t >> just applies locally configured default rules on it), then I don=E2=80= =99t see why >> PHP could not be done for a Prefix SID associated with a service node. >> >> >> >> >> >> Also, I didn=E2=80=99t follow the point that you were trying to make abo= ut >> Adj-SIDs. >> >> >> >> >> >> Thanks, >> >> >> Ketan >> >> >> >> >> >> >> >> >> >> *From:* Alexander Vainshtein >> >> >> *Sent:* 14 August 2020 18:24 >> >> >> *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < >> jmh@joelhalpern.com>; Alexander Vainshtein ; >> Shraddha Hegde ; >> EXT-Andrew.Alston@liquidtelecom.com ; >> Robert Raszuk >> >> >> *Cc:* spring@ietf.org >> >> >> *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> >> >> >> >> >> >> >> Hi all, >> >> >> Regarding the statement "Prefix SID could be just a topological >> instruction or may also be used to steer the flow to a node which is >> applying a service function to it": >> >> >> >> >> >> >> >> >> I think that in SR-MPLS a Node SID that is advertised with PHP aciton ca= n >> be safely considered as "just a topological instruction" by the PLR beca= use >> the originating node will not receive it. >> >> >> The same applies to Adj-SDIs. >> >> >> >> >> >> My 2c. >> >> >> >> >> >> >> >> >> >> >> >> Get Outlook for Android >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> >> >> *From:* spring on behalf of Ketan Talaulikar >> (ketant) >> >> >> *Sent:* Friday, August 14, 2020, 15:00 >> >> >> *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; >> EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk >> >> >> *Cc:* spring@ietf.org >> >> >> *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> >> >> >> >> >> >> >> Hi All, >> >> >> >> >> >> I would like to share a different perspective on this. >> >> >> >> >> >> First, thanks to Joel for bringing up the discussion. Clearly we need a >> well-defined applicability statement for determining applicability of >> protection for segment used in an SR Policy. Some of this is captured in >> [1]. >> >> >> >> >> >> This is about local repair at a PLR. By it's very nature, the PLR does >> not have a notion of how "strict or not" is the SLA that is being provid= ed >> by the SR Policy. Awareness of that notion exists at the SR Policy heade= nd >> and/or computation-node. >> >> >> >> >> >> We have protected and un-protected variants of adjacency SIDs to enable >> the computation to pick or the other based on the "strictness" of the SL= A >> requirement for picking that link. We do not have such a notion for Pref= ix >> SIDs. One can say that we could introduce signalling (e.g. a B flag) to >> indicate whether a Prefix SID can be bypassed or not. This provides the >> opportunity for the computation to use one or the other flavor depending= on >> the nature of the SLA for the SR Policy. >> >> >> >> >> >> I have a problem and a concern in the assumption that PLRs can assume >> that the currently defined variant of Prefix SIDs in RFC8402 (and IGP >> specs) are "bypass-able". >> >> >> >> >> >> As Joel and others have brought out, the Prefix SID could be just a >> topological instruction or may also be used to steer the flow to a node >> which is applying a service function to it. In order to support a mix of= SR >> Policies of different SLAs (strict and not-strict), we need to enable th= e >> choice of SIDs that indicates to the PLR whether they are "bypass-able" = or >> not. >> >> >> >> >> >> For the cases, where the SR Policy has a specific SLA, it is required fo= r >> nodes to drop the packets meant for the "active segment" than to bypass = it. >> When this mechanism is used along side SRTE path monitoring mechanisms, = it >> enables the headend to detect the failure and fallback to an alternate p= ath >> using the path protection approach. This is something that is described = and >> in use in deployments today [1].. >> >> >> >> >> >> Thanks, >> >> >> Ketan >> >> >> >> >> >> [1] >> https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2= F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23s= ection-9 >> >> >> [2] >> https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2= F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23s= ection-9.3 >> >> >> >> >> >> -----Original Message----- >> >> >> From: spring On Behalf Of Joel M. Halpern >> >> >> Sent: 04 August 2020 20:25 >> >> >> To: Alexander Vainshtein ; Shraddha Hegde >> ; >> EXT-Andrew.Alston@liquidtelecom.com ; >> Robert Raszuk >> >> >> Cc: spring@ietf.org; Joel M. Halpern >> >> >> Subject: Re: [spring] Spring protection - determining applicability >> >> >> >> >> >> There are, as far as I can tell, a number of ways to address this family >> of related questions. >> >> >> What struck me, and prompted the starting question, was that none of the= m >> were spelled out. I see lots of interesting ideas / proposals. >> >> >> Some of them are compatible with others. Some are not. >> >> >> It would be good if we could reach agreement on how we thought it should >> be handled. >> >> >> >> >> >> Thank you, >> >> >> Joel >> >> >> >> >> >> On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: >> >> >> > Hi all, >> >> >> > >> >> >> > I am still not sure that the problem of bypass going thru undesirable >> >> >> > links/nodes exists in the case of topological SIDs. >> >> >> > >> >> >> > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 >> >> >> > < >> https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Frfc4090>) >> has been successfully deployed >> >> >> > for many years before SR-MPLS has been introduced. What=E2=80=99s more= , >> >> >> > signaling of bypass tunnels he PLR usually did not include any of the >> >> >> > constraints used for computing of any specific LSP that the bypass LSP >> >> >> > would protect =E2=80=93 because in the Facility Protection mode the sa= me >> >> >> > bypass LSP would be used to protect multiple LSPs passing thru the >> >> >> > failed link/node. >> >> >> > >> >> >> > From my POV the only difference between this behavior and that >> >> >> > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of >> >> >> > RSVP-TE, the operator would explicitly indicate, as part of LSP >> >> >> > signaling, whether it would or would not use FRR; LSPs that would not >> >> >> > use FRR would then drop traffic rather than delivering it the wrong wa= y. >> >> >> > >> >> >> > Such an option indeed does not exist in SR-TE today, but would be easy >> >> >> > to provide if so desired IMHO. >> >> >> > >> >> >> > Did I miss something substantial? >> >> >> > >> >> >> > Regards, and lots of thanks in advance, >> >> >> > >> >> >> > Sasha >> >> >> > >> >> >> > Office: +972-39266302 >> >> >> > >> >> >> > Cell: +972-549266302 >> >> >> > >> >> >> > Email: Alexander.Vainshtein@ecitele.com >> >> >> > >> >> >> > *From:* spring *On Behalf Of *Shraddha Hegde >> >> >> > *Sent:* Tuesday, August 4, 2020 9:41 AM >> >> >> > *To:* EXT-Andrew.Alston@liquidtelecom.com >> >> >> > ; Robert Raszuk >> >> >> > *Cc:* spring@ietf.org; Joel M. Halpern >> >> >> > *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> > >> >> >> > All, >> >> >> > >> >> >> > This is a very interesting discussion and thanks to Joel for starting >> >> >> > this discussion. IMO, when there are strict requirements of avoiding >> >> >> > certain nodes/links it can be realized either by defining a flex-algo >> >> >> > avoiding those >> >> >> > >> >> >> > Nodes and links or by using a stack of unprotected adj-sids that avoid >> >> >> > restricted nodes and links. When a stack of adj-sids is used to >> >> >> > realize the path, the head-end based (sBFD) protection mechanisms can >> be applied. >> >> >> > >> >> >> > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the >> >> >> > failure events may cause traffic to go through restricted nodes and >> >> >> > links. This would happen regardless of whether any kind of protection >> >> >> > is in use or not. >> >> >> > >> >> >> > Rgds >> >> >> > >> >> >> > Shraddha >> >> >> > >> >> >> > Juniper Business Use Only >> >> >> > >> >> >> > *From:* spring > > > >> *On Behalf Of *Andrew Alston >> >> >> > *Sent:* Tuesday, August 4, 2020 5:41 AM >> >> >> > *To:* Robert Raszuk > >> >> >> >> > *Cc:* spring@ietf.org >; Joel >> M. Halpern >> >> >> > >> >> >> >> >> > *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> > >> >> >> > *[External Email. Be cautious of content]* >> >> >> > >> >> >> > Robert this is actually far more difficult when =E2=80=93 it can be an= entire >> >> >> > (long) series of nodes that need to be avoided. >> >> >> > >> >> >> > It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93 >> >> >> > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t >> >> >> > be viable. >> >> >> > >> >> >> > It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things >> >> >> > to calculate paths =E2=80=93 the biggest trick is about the stack dept= h. When >> >> >> > you have this need for node avoidance =E2=80=93 the need for 10+ label= depth >> >> >> > is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f >> >> >> > binding labels along the way which is a nightmare. >> >> >> > >> >> >> > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use >> >> >> > case that most of the people I discuss this with certain have =E2=80= =93 I cant >> >> >> > comment on a global scale, or for anyone else, but every indication I >> >> >> > have is that yes =E2=80=93 its something people need, and want >> >> >> > >> >> >> > Andrew >> >> >> > >> >> >> > *From:* Robert Raszuk > >> >> >> >> > *Sent:* Tuesday, 4 August 2020 01:27 >> >> >> > *To:* Andrew Alston > > < >> mailto:Andrew.Alston@liquidtelecom.com >> >> >> >> >> > *Cc:* Joel M. Halpern > > > >>; spring@ietf.org >> >> >> > > >> >> >> > *Subject:* Re: [spring] Spring protection - determining applicability >> >> >> > >> >> >> > Is this a common use case ie. "but rather =E2=80=93 which nodes / net= work >> >> >> > segments it can never touch or flow through." >> >> >> > >> >> >> > If so perhaps its time to define notion of *negative-SID* ie. list in >> >> >> > the packet resources which given packet MUST not ever traverse. >> >> >> > >> >> >> > Put in the packet set of nodes or links which the packet should never >> >> >> > traverse. >> >> >> > >> >> >> > That goes in line of recent wave of negative routing implementations >> >> >> > (RIFT) or discussions (LSR) >> >> >> > >> >> >> > Best, >> >> >> > R. >> >> >> > >> >> >> > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston >> >> >> > > > < >> mailto:Andrew.Alston@liquidtelecom.com = >> >> wrote: >> >> >> > >> >> >> > So =E2=80=93 >> >> >> > >> >> >> > One of the use cases, in fact, some very major use cases in any >> >> >> > spring technology for us revolve around the following >> >> >> > >> >> >> > a.The explicit avoidance of certain nodes >> >> >> > >> >> >> > b.The explicit avoidance of certain sections of the network >> >> >> > >> >> >> > Anything that could result in that explicit avoidance being violat= ed >> >> >> > =E2=80=93 would create, shall we say significant problems. >> >> >> > >> >> >> > Much of the use case is not a case of which nodes the packets flow >> >> >> > through =E2=80=93 but rather =E2=80=93 which nodes / network segme= nts it can never >> >> >> > touch or flow through. Effectively, to be used as a technology to >> >> >> > avoid certain things for specific reasons. >> >> >> > >> >> >> > This is also one of the reasons for needing such deep label stacks= =E2=80=93 >> >> >> > this kind of detailed path programming tends to deepen the stack >> >> >> > because you sometimes have to be pretty explicit. >> >> >> > >> >> >> > It is absolutely critical to us that this functionality is there = =E2=80=93 >> >> >> > and that we can avoid situations which could cause traffic to >> >> >> > accidently hit things explicitly avoided. >> >> >> > >> >> >> > I wish I could be more specific than this, but it is what it is. >> >> >> > >> >> >> > Thanks >> >> >> > >> >> >> > Andrew >> >> >> > >> >> >> > *From:* spring > > > >> *On Behalf Of *Joel M. Halpern >> >> >> > *Sent:* Monday, 3 August 2020 21:36 >> >> >> > *To:* Robert Raszuk > >> >> >> >> > *Cc:* spring@ietf..org > >> >> >> > *Subject:* Re: [spring] Spring protection - determining >> >> >> > applicability >> >> >> > >> >> >> > (Since the thread has gotten long enough, reiterating that this is >> as a >> >> >> > participant, not a WG chair.) >> >> >> > >> >> >> > Yes, we are talking IP networks. And yes, I have seen IP networks >> that >> >> >> > choose to drop packets. For all sorts of reasons. >> >> >> > I think there are likely other reasons why one may not want a rand= om >> >> >> > path rather than a chosen TE path. I think it is important we be >> clear >> >> >> > about what constraints may be / are violated when we tell people >> they >> >> >> > have this tool (protective rerouting) that is intended to preserve >> QoS. >> >> >> > >> >> >> > Let's be clear. I am not arguing that this is not a good idea. It >> is a >> >> >> > good idea. And useful. I am trying to figure otu what combination = of >> >> >> > additional mechanisms and clear descriptions will lead to everyone >> >> >> > getting the behavior they expect (which may not be the behavior th= ey >> >> >> > desire, but sometimes is the best we can do.) >> >> >> > >> >> >> > Yours, >> >> >> > Joel >> >> >> > >> >> >> > On 8/3/2020 2:30 PM, Robert Raszuk wrote: >> >> >> > > Joel, >> >> >> > > >> >> >> > > Are we still talking about IP networks here ? Or perhaps some >> hard >> >> >> > > slicing with real resource reservations or detnets ? >> >> >> > > >> >> >> > > Because if we are talking about IP networking I have two >> >> >> > observations: >> >> >> > > >> >> >> > > A) If you need to traverse via a specific node (ie. firewall) y= ou >> >> >> > better >> >> >> > > apply IP encapsulation to that node.. I don't think IP >> >> >> > encapsulation can >> >> >> > > be hijacked today such that destination address of the packet i= s >> >> >> > ignored. >> >> >> > > >> >> >> > > B) Have you seen any IP network where upon topology change (lin= k >> >> >> > or node >> >> >> > > failure) you suddenly start dropping flows in spite of SPT >> offering >> >> >> > > perhaps few ms longer path with 10 ms more jitter ? >> >> >> > > >> >> >> > > Or are some SR marketing slides promise to turn IP networks in >> >> >> > > something new ? Worse ... do they mention path quality >> guarantees, >> >> >> > > resource reservations ? I hope not. >> >> >> > > >> >> >> > > Thx, >> >> >> > > R. >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern < >> jmh@joelhalpern.com >> > > >> > >> wrote: >> >> >> > > >> >> >> > > Well less serious for TE SIDs, I am not sure the problem is >> >> >> > restricted >> >> >> > > to just service SIDs. >> >> >> > > >> >> >> > > Suppose that the PCE has specified the path to meet some comple= x >> te >> >> >> > > objective. The bypass node has no way of knowing what those >> >> >> > > constraints >> >> >> > > were. And for some kinds of traffic, it is better to drop the >> packet >> >> >> > > than to deliver it outside the envelop. I suspect that the rig= ht >> >> >> > > answer >> >> >> > > to this is "too bad".. If so, as with the distinction regardin= g >> >> >> > service >> >> >> > > nodes, we should say so, shouldn't we? >> >> >> > > >> >> >> > > Yours, >> >> >> > > Joel >> >> >> > > >> >> >> > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: >> >> >> > > > Mach, Joel and all, >> >> >> > > > >> >> >> > > > I think that in most cases: >> >> >> > > > >> >> >> > > > 1.There is clear differentiation between "topological" and >> >> >> > "service" >> >> >> > > > instructions in SID advertisements. E.g.: >> >> >> > > > >> >> >> > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the >> >> >> > > > corresponding IGP advertisements) represent topological >> >> >> > instructions >> >> >> > > > >> >> >> > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services >> >> >> > > > >> >> >> > > >> >> >> > < >> https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2= F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04 >> >> >> > < >> https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2F= draft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oi= QAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24 >> >> >> >> >> > > >> >> >> > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D ins= tructions >> >> >> > > > >> >> >> > > > 2.Segments that represent topological instructions can be >> bypassed, >> >> >> > > > while segments that represent service instructions require >> >> >> > > alternative >> >> >> > > > protection mechanisms. >> >> >> > > > >> >> >> > > > This view seems to be aligned with RFC 8402 >> >> >> > > > < >> https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2= F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >> >> >> > < >> https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B= %21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDui= Do0I4Ybtm%24 >> >> >> >> >> > that says in Section 1: >> >> >> > > > >> >> >> > > > In the context of an IGP-based distributed control plane, >> two >> >> >> > > > >> >> >> > > > topological segments are defined: the IGP-Adjacency segment >> and the >> >> >> > > > >> >> >> > > > IGP-Prefix segment. >> >> >> > > > >> >> >> > > > In the context of a BGP-based distributed control plane, >> two >> >> >> > > > >> >> >> > > > topological segments are defined: the BGP peering segment and >> the >> >> >> > > > >> >> >> > > > BGP-Prefix segment. >> >> >> > > > >> >> >> > > > In the case of SR-MPLS this differentiation is assumed in >> Section >> >> >> > > 3.4 of >> >> >> > > > the Node Protection for SR-TE Path >> >> >> > > > >> >> >> > > >> >> >> > < >> https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2= F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-= for-sr-te-paths-07%23section-3.4 >> >> >> > < >> https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2F= draft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o9wO-Ssn%24 >> >> >> >> >> > > >> >> >> > > > draft that says: >> >> >> > > > >> >> >> > > > The node protection mechanism described in the previous >> >> >> > sections >> >> >> > > > >> >> >> > > > depends on the assumption that the label immediately belo= w >> >> >> > > the top >> >> >> > > > >> >> >> > > > label in the label stack is understood in the IGP domain. >> When the >> >> >> > > > >> >> >> > > > provider edge routers exchange service labels via BGP or >> some >> >> >> > > other >> >> >> > > > >> >> >> > > > non-IGP mechanism the bottom label is not understood in >> the IGP >> >> >> > > > >> >> >> > > > domain. >> >> >> > > > >> >> >> > > > The egress node protection mechanisms described in the >> draft >> >> >> > > > >> >> >> > > > [RFC8679 < >> https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%2= F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679 >> >> >> > < >> https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2F= rfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpR= HOGt8AkTRDuiDo8MGipXc%24 >> >>] >> >> >> > is >> >> >> > > > applicable to this use case and no additional changes >> >> >> > > > >> >> >> > > > will be required for SR based networks >> >> >> > > > >> >> >> > > > The scenarios in which differentiation between =E2=80=9Ctopo= logical=E2=80=9D >> and >> >> >> > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed p= roblematic. E.g., >> >> >> > > consider >> >> >> > > > the use case in which a Node SID in the ERO of a SR-TE path >> >> >> > > identifies a >> >> >> > > > node that acts as a firewall for all packets it receives, i.e= ., >> >> >> > > provides >> >> >> > > > the firewall service without any dedicated service SID >> >> >> > > identifying it. >> >> >> > > > One could say that the Node SID of such a node would combine >> >> >> > > topological >> >> >> > > > and service instructions thus breaking the differentiation >> >> >> > > between the two. >> >> >> > > > >> >> >> > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SID= s could be >> prevented >> >> >> > > or at >> >> >> > > > least discouraged. >> >> >> > > > >> >> >> > > > If not, providing an ability to identify such SIDs in the >> >> >> > > advertisement >> >> >> > > > mechanisms would be useful IMHO. >> >> >> > > > >> >> >> > > > My 2c, >> >> >> > > > >> >> >> > > > Sasha >> >> >> > > > >> >> >> > > > Office: +972-39266302 >> >> >> > > > >> >> >> > > > Cell: +972-549266302 >> >> >> > > > >> >> >> > > > Email: Alexander.Vainshtein@ecitele.com >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > -----Original Message----- >> >> >> > > > From: spring > > > >> >> >> >> > >> On >> Behalf Of Mach Chen >> >> >> > > > Sent: Monday, August 3, 2020 6:30 AM >> >> >> > > > To: Joel M. Halpern > > > >> > >>; >> >> >> > spring@ietf.org > < >> mailto:spring@ietf.org > >> >> >> > > > Subject: Re: [spring] Spring protection - determining >> applicability >> >> >> > > > >> >> >> > > > Hi Joel, >> >> >> > > > >> >> >> > > > I think this is a good point that may not be discussed in the >> >> >> > > past. And >> >> >> > > > I also don't think there is a "can be bypassed" indication in >> the >> >> >> > > > routing advertisement for now. >> >> >> > > > >> >> >> > > > IMHO, the information advertised by routing is neutral, such >> >> >> > > information >> >> >> > > > (can or cannot be bypassed) is more path specific, thus >> >> >> > normally the >> >> >> > > > controller should be responsible for deciding whether/which S= ID >> >> >> > > can be >> >> >> > > > bypassed. >> >> >> > > > >> >> >> > > > Best regards, >> >> >> > > > >> >> >> > > > Mach >> >> >> > > > >> >> >> > > > > -----Original Message----- >> >> >> > > > >> >> >> > > > > From: spring [mailto:spring-bounces@ietf.org >> >> >> > > > >> >> >> > < >> mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org= %3e >> >] >> >> >> > On Behalf Of Joel M. >> >> >> > > > >> >> >> > > > > Halpern >> >> >> > > > >> >> >> > > > > Sent: Monday, August 3, 2020 7:51 AM >> >> >> > > > >> >> >> > > > > To: spring@ietf.org > > >> >> >> > > >> >> >> > > > > < >> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org >> >>> >> >> >> > > > >> >> >> > > > > Subject: [spring] Spring protection - determining >> applicability >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > (WG Chair hat Off, this is merely a note from a slightly >> >> >> > > confused WG >> >> >> > > > >> >> >> > > > > participant.) >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > I have been reading the various repair drafts, and the >> various >> >> >> > > > >> >> >> > > > > networks programming and service programming draft, and I = am >> >> >> > > trying to >> >> >> > > > >> >> >> > > > > figure out one aspect of the combination. >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > How does a node that is doing some form of bypass (suppose= , >> for >> >> >> > > > >> >> >> > > > > simplicity, it is Node N2 deciding to bypass the next SID >> for >> >> >> > > a failed >> >> >> > > > >> >> >> > > > > node N3) know that it is safe to do so? >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > If the path was just for TE, then it is "safe" if the new >> path >> >> >> > > meets >> >> >> > > > >> >> >> > > > > the TE criteria. or maybe it is safe if it is even close, >> as >> >> >> > > long as >> >> >> > > > >> >> >> > > > > it is not used for too long. >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > But what if the node were a Firewall, included to meet leg= al >> >> >> > > > requirements? >> >> >> > > > >> >> >> > > > > Or was some other necessary programmatic transform (wince >> we are >> >> >> > > > >> >> >> > > > > deliberately vague about what nodes can do when asked >> suitably.) >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > Is there some "can be bypassed" indication in the routing >> >> >> > > > >> >> >> > > > > advertisements that I missed? >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > Thank you, >> >> >> > > > >> >> >> > > > > Yours, >> >> >> > > > >> >> >> > > > > Joel >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > > _______________________________________________ >> >> >> > > > >> >> >> > > > > spring mailing list >> >> >> > > > >> >> >> > > > > spring@ietf..org > > >> >> >> > > >> >> >> > > > > < >> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org >> >>> >> >> >> > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > >> >> >> > >> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2 >> >> >> >> > < >> https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUk= zW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE= 8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24 >> >> > >> >> >> > > > >> >> >> > > >> >> >> > < >> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2= 52 >> >> >> > < >> https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYN= E8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24 >> >> >> >> >> > > > >> >> >> > > > > F%2Fwww.ietf.org >> >> >> > < >> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%= 21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 >> >> > >> >> >> > > < >> https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F= %2F2Fwww.ietf.org >> >> >> > < >> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%= 21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 >> >>%2Fmailman%2Flistinfo%2Fspring >> >> >> > > > >> >> >> > > > _______________________________________________ >> >> >> > > > >> >> >> > > > spring mailing list >> >> >> > > > >> >> >> > > > spring@ietf.org > >> >> >> > > > > > >> >> >> >> >> > > > >> >> >> > > > >> >> >> > > >> >> >> > >> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> > < >> https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUk= zW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flist= info%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x= 0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24 >> >> > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > >> >> >> > >> ------------------------------------------------------------------------ >> >> >> > > > Notice: This e-mail together with any attachments may contain >> >> >> > > > information of Ribbon Communications Inc. that is confidentia= l >> >> >> > > and/or >> >> >> > > > proprietary for the sole use of the intended recipient. Any >> review, >> >> >> > > > disclosure, reliance or distribution by others or forwarding >> >> >> > without >> >> >> > > > express permission is strictly prohibited. If you are not the >> >> >> > > intended >> >> >> > > > recipient, please notify the sender immediately and then >> delete all >> >> >> > > > copies, including any attachments. >> >> >> > > > >> >> >> > > >> >> >> > >> ------------------------------------------------------------------------ >> >> >> > > > >> >> >> > > > _______________________________________________ >> >> >> > > > spring mailing list >> >> >> > > > spring@ietf.org > < >> mailto:spring@ietf.org > >> >> >> > > > >> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> > < >> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F= spring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRH= OGt8AkTRDuiDo5KlPnbj%24 >> >> > >> >> >> > > > >> >> >> > > >> >> >> > > _______________________________________________ >> >> >> > > spring mailing list >> >> >> > > spring@ietf.org > < >> mailto:spring@ietf.org > >> >> >> > > >> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> > < >> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F= spring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRH= OGt8AkTRDuiDo5KlPnbj%24 >> >> > >> >> >> > > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > spring mailing list >> >> >> > spring@ietf.org > >> >> >> > >> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> > >> >> >> > > >> >> > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org >> %2Fmailman%2Flisti >> >> >> > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu >> >> >> > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> >> >> >> > >> >> >> > >> >> >> > >> >> >> > ---------------------------------------------------------------------- >> >> >> > -- >> >> >> > Notice: This e-mail together with any attachments may contain >> >> >> > information of Ribbon Communications Inc. that is confidential and/or >> >> >> > proprietary for the sole use of the intended recipient. Any review, >> >> >> > disclosure, reliance or distribution by others or forwarding without >> >> >> > express permission is strictly prohibited. If you are not the intended >> >> >> > recipient, please notify the sender immediately and then delete all >> >> >> > copies, including any attachments. >> >> >> > ---------------------------------------------------------------------- >> >> >> > -- >> >> >> >> >> >> _______________________________________________ >> >> >> spring mailing list >> >> >> spring@ietf.org >> >> >> >> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> _______________________________________________ >> >> >> spring mailing list >> >> >> spring@ietf.org >> >> >> >> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2= F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> Notice: This e-mail together with any attachments may contain informatio= n >> of Ribbon Communications Inc. that is confidential and/or proprietary fo= r >> the sole use of the intended recipient. Any review, disclosure, reliance= or >> distribution by others or forwarding without express permission is stric= tly >> prohibited. If you are not the intended recipient, please notify the sen= der >> immediately and then delete all copies, including any attachments. >> >> >> >> >> ------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> spring mailing list >> >> >> spring@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> >> >> > > > > > > > > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000032fa3e05ace18557 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Catching up on this thread as it is a inte= resting topic as FRR 1:N link protection, node protection and path protecti= on is critical to operators.

There are multiple somewhat orthogonal topics brought up in the discus= sion.

Excluding SR SFC f= rom =E2=80=9Cbypass=E2=80=9D capable node such for appliances such as firew= alls and load balancer.=C2=A0 Makes sense.=C2=A0 I would not think SFC woul= d be in a PLR path to merger point but I could be mistaken.

The goal of SR is eliminating state a= nd so having TE like state is undesirable.=C2=A0
Intent based instantiation of bypass via SR-TE fro= m network feedback at PLR detection node of a failure and make before break= pre computed backup paths that can. =C2=A0=C2=A0
It would make sense that SR-TE binding SID policy= would be appropriate for RSVP like FRR link node or path protection.
=

My thoughts on this topic of = SR protection is that don=E2=80=99t we already have FRR protection natively= without requiring SR-TE BSID or any additional undesirable state maintenan= ce with TI-LFA.

Thanks= =C2=A0

Gyan
On Fri, = Aug 14, 2020 at 5:47 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:












PCE computation in this case is = trivial too(must traverse node B or node X) else FAIL.


<= br>



Cheers,
Jeff






On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura <= jefftant.ietf@= gmail.com>, wrote:






=
Robert,





Agreed and apologies, hit = send before finishing the email (it is Friday) ;-)





P= ath protection in this case make more sense and is much less complex,=C2=A0=


if in the pathA (A->B->C) node B is a service node, it ca= n=E2=80=99t be bypassed (node protected) if the link between A and B breaks= =C2=A0


however it could have a backup pathB (A->X->C) wher= e X is the service node, potentially synchronizing its state with the node = B.





To my previous email - at expense of more state, = we provide path and service protection, hence the similarity with RSVP-TE t= rade-offs.







Cheers,

Jeff






On Aug 14, 2020, 2:30 PM -0700, = Robert Raszuk <ro= bert@raszuk.net>, wrote:




Jeff,




> This is very similar to RSVP-TE=C2=A0=C2=A0





I would rather differ on that st= atement.=C2=A0





See if you are usin= g SR just for TE you are 100% right.=C2=A0




=
But if your SIDs embed additional local SR node processing functio= ns this suddenly=C2=A0becomes a completely different game. Let's keep t= his in mind in this thread/topic.=C2=A0




Kind regards,


R.











On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura &l= t;jefftant.iet= f@gmail.com> wrote:







This is very similar to RSVP-TE, path vs link/node = protection and usually dictated by the business logic, the triggers are obv= iously very different, head-end being notified of the failure on a path and= switching to the backup path vs reaction to a local failure, so same consi= derations apply:=C2=A0


-more state


-pre-reserved reso= urces


while=C2=A0


-predictable


-meets SLA = (as good as primary)


vs


-less state


-local=


-best effort / can cause congestions=C2=A0


<= br>



Cheers,
Jeff






On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) <= ketant=3D40= cisco.com@dmarc.ietf.org>, wrote:



<= br>


Hi Robert,



<= p class=3D"MsoNormal">=C2=A0



We do not have a signalling mechanism in IGPs today to indicate a = =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was a de= sire for it, an IGP extension would be required (there is none in progress = AFAIK). Note that this results in doubling the prefix SID scale (global lab= els) in the network. So I would not go about this trivially.


=

=C2=A0



I think it helps to get more inputs and perspectives from opera= tors on their views for doing a bypass via local protection for segments in= an SR Policy. There may be those that prefer end-to-end path protection us= ing a fallback path that is say disjoint with the primary but provides an a= ppropriate SLA/intent?



=C2= =A0



Thanks,


Ketan



=C2=A0





From: Robert Raszuk <robert@raszuk.net>


Sent: 14 August 2020 23:04


To: Ketan Talaulikar (ketant) <= ketant@cisco.com&= gt;


Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-And= rew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org

Subject: Re: [spring] Spring protection - determining applicab= ility





=C2=A0


=


Ketan,





=C2=A0







Looks like we are pretty much in sync here.=C2=A0







=C2=A0






But let me just observe that I pur= posely=C2=A0did not mention about SR policies as we are not able to signal = the intent with the packets itself.=C2=A0






=C2=A0







So all we have there is SIDs. BSIDs or prefix SIDs nee= d to be flooded with information if policies build with using them are bypa= ss eligible or not.=C2=A0







=C2=A0







I was actually under the impression that this is already there and I a= m just not aware, but looking deeper indeed I do not see this marking neith= er in ISIS nor OSPF for prefix SIDs.=C2=A0






=C2=A0







<= p class=3D"MsoNormal">Is there some work in progress to add it to those pro= tocols or have we just documented need=C2=A0for a short LSR draft=C2=A0 ?= =C2=A0







=C2=A0<= /p>





Thx,






R.






=C2=A0







=C2=A0






=

On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar= (ketant) <ketant@= cisco.com> wrote:










Hi Robert,


=C2=A0



Please ch= eck inline below.



=C2=A0





From: Robert Ras= zuk <robert@raszu= k.net>


Sent: 14 August 2020 21:13


To= : Ketan Talaulikar (ketant) <ketant@cisco.com>


Cc: Alexander Vai= nshtein <Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>; S= hraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.A= lston@liquidtelecom.com>; spring@ietf.org


Subject: Re: [spring] Spr= ing protection - determining applicability





=

=C2=A0





Hi Ketan,





=C2=A0






While I completely agre= e with your note the consequences of it are pretty sevre.=C2=A0



=

[KT] I understand. We need to be mindful of im= plications of protection schemes for the SLAs/intent of SR Policies.







=C2=A0






Unless we signal wh= ich prefix SID is protection eligible and which is not how would other node= s know if they can protect it or not ?=C2=A0



[KT] Correct. To be more accurate, we need to consider this more = in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and which = segments may be =E2=80=9Cbypass-able=E2=80=9D for local protection for some= of those SR Policies. We also have path-protection mechanisms.

=





=C2=A0






It seems that today'= s safe thing is not to apply any node protection on SR flows at the PLRs th= en.=C2=A0







=C2= =A0







And link p= rotection MUST assure that packets will arrive at the neighbor node via som= e other link regardless of further path towards destination.=C2=A0


<= br>

[KT] Yes. We have a mechanism to indicate w= hich adj-SIDs have protection (that mechanism only provides link protection= to get to the neighbor node) so the SR Policy computation is able to indic= ate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by i= ts choice of protected or unprotected adj-SIDs respectively.


=C2=A0



Thanks,



Ketan=







=C2= =A0







Is it corr= ect ?=C2=A0







= =C2=A0







Thx

=





R







=C2=A0




<= br>


On Fri, Aug 14, 2020 at 5:32 PM Keta= n Talaulikar (ketant) <ketant@cisco.com> wrote:





=





Hi Sasha,


<= br>

=C2=A0



The serv= ice node advertises its own Prefix SID.. The service function that this ser= vice node implements does not require any context (i.e. all packets arrivin= g at the node are subjected to that service). Therefore the service node do= es not need to receive a packet with it=E2=80=99s own Prefix SID.


=C2=A0



Thus, we = cannot assume that when PHP is used, then the SID is only associated with a= topological instruction.



=C2=A0


<= br>

Hope that clarifies?



=C2=A0



Thanks,



Ketan



=C2=A0







From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>


= Sent: 14 August 2020 20:24


To: Ketan Talaulikar (keta= nt) <ketant@cisco.= com>; Joel M. Halpern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>;= E= XT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ;; Robert Raszuk <robert@raszuk.net>


Cc: spring@ietf.org


Subject: R= e: [spring] Spring protection - determining applicability






=C2=A0



Ketan, and all,



I have stated that, IMHO= and FWIW, both Adj-SIDs and Prefix SIDs that are advertised with PHP can= =C2=A0 ONLY represent topological instructions in SR-MPLS - because the adv= ertising node will not receive them and therefore can hardly be expected to= associate any service function with them.



=C2= =A0



This is complementary to what you have sai= d.



=C2=A0



Hope th= is clarifies my position.



What, if anything, d= id I miss?



=C2=A0



Regards,



Sasha






<= br>

=C2=A0





Get Outlook for A= ndroid









=C2=A0











From: Ketan Talaulikar (ketant) <= ;ketant@cisco.com= >


Sent= : Friday, August 14, 2020, 16:23


To: Alexander Vains= htein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk


Cc: spring@ietf.org


Subject: RE: [spring] Spring protection -= determining applicability





=C2=A0







NOTICE: This ema= il was received from an EXTERNAL sender







=C2=A0

<= br>


Hi Sasha,



=C2=A0



If the service does no= t need any additional context (e.g. a firewall that just applies locally co= nfigured default rules on it), then I don=E2=80=99t see why PHP could not b= e done for a Prefix SID associated with a service node.



=C2=A0



Also, I didn=E2=80= =99t follow the point that you were trying to make about Adj-SIDs.


<= br>

=C2=A0



Thanks,<= /p>

Ketan



= =C2=A0







From:= Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>


Sent: 14 August 2020 18:24


To: Ke= tan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com>; Alexander V= ainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>= ; = EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com&g= t;; Robert Raszuk <robert@raszuk.net>


Cc: spring@ietf.org


Subject: = Re: [spring] Spring protection - determining applicability






=C2=A0



Hi all,



Regarding the statement "P= refix SID could be just a topological instruction or may also be used to st= eer the flow to a node which is applying a service function to it":



=C2=A0



=C2=A0



I think that in SR-MPLS a Node SID that is adverti= sed with PHP aciton can be safely considered as "just a topological in= struction" by the PLR because the originating node will not receive it= .



The same applies to Adj-SDIs.


=

=C2=A0



My 2c.





=C2=A0





Get Outlook= for Android









=C2=A0











From: spring <spring-bounces@ietf.org> on behalf of Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc= .ietf.org>


Sent: Friday, August 14, 2020, 15:00


To: Jo= el M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@liquid= telecom.com; Robert Raszuk


Cc: spring@ietf.org


Subject: Re: [spring] Spring= protection - determining applicability





=C2=A0





=

Hi All,





I would like to share= a different perspective on this.





First, thanks to J= oel for bringing up the discussion. Clearly we need a well-defined applicab= ility statement for determining applicability of protection for segment use= d in an SR Policy. Some of this is captured in [1].





= This is about local repair at a PLR. By it's very nature, the PLR does = not have a notion of how "strict or not" is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Polic= y headend and/or computation-node.





We have protected= and un-protected variants of adjacency SIDs to enable the computation to p= ick or the other based on the "strictness" of the SLA requirement= for picking that link. We do not have such a notion for Prefix SIDs. One c= an say that we could introduce signalling (e.g. a B flag) to indicate wheth= er a Prefix SID can be bypassed or not. This provides the opportunity for t= he computation to use one or the other flavor depending on the nature of th= e SLA for the SR Policy.





I have a problem and a conc= ern in the assumption that PLRs can assume that the currently defined varia= nt of Prefix SIDs in RFC8402 (and IGP specs) are "bypass-able".




As Joel and others have brought out, the Prefix SID c= ould be just a topological instruction or may also be used to steer the flo= w to a node which is applying a service function to it. In order to support= a mix of SR Policies of different SLAs (strict and not-strict), we need to= enable the choice of SIDs that indicates to the PLR whether they are "= ;bypass-able" or not.





For the cases, where the = SR Policy has a specific SLA, it is required for nodes to drop the packets = meant for the "active segment" than to bypass it. When this mecha= nism is used along side SRTE path monitoring mechanisms, it enables the hea= dend to detect the failure and fallback to an alternate path using the path= protection approach. This is something that is described and in use in dep= loyments today [1]..





Thanks,


Ketan




[1] https://clicktime.= symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2F= html%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9

<= br>[2] https://clicktime.symantec.com= /36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft= -ietf-spring-segment-routing-policy-08%23section-9.3




-----Original Message-----


From: spring <spring-bounces@ietf.org&g= t; On Behalf Of Joel M. Halpern


Sent: 04 August 2020 20:25

To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha = Hegde <shraddha=3D40juniper.net@dmarc.ietf.org>; EXT-Andrew.Alsto= n@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszu= k <robert@raszuk.= net>


Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>


Subject:= Re: [spring] Spring protection - determining applicability



=

There are, as far as I can tell, a number of ways to address this f= amily of related questions.


What struck me, and prompted the sta= rting question, was that none of them were spelled out.=C2=A0 I see lots of= interesting ideas / proposals.


Some of them are compatible with= others.=C2=A0=C2=A0 Some are not.


It would be good if we could = reach agreement on how we thought it should be handled.




=
Thank you,


Joel





On 8/4/2020 3:54 AM, = Alexander Vainshtein wrote:


> Hi all,


>

=
> I am still not sure that the problem of bypass going thru undesira= ble


> links/nodes exists in the case of topological SIDs.
=

>


> AFAIK, Facility Protection in RSVP-TE FRR (RFC= 4090


> <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dh= ttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) has been successfully= deployed


> for many years before SR-MPLS has been introduced= . What=E2=80=99s more,


> signaling of bypass tunnels he PLR u= sually did not include any of the


> constraints used for comp= uting of any specific LSP that the bypass LSP


> would protect= =E2=80=93 because in the Facility Protection mode the same


>= bypass LSP would be used to protect multiple LSPs passing thru the

=
> failed link/node.


>


>=C2=A0 From my PO= V the only difference between this behavior and that


> introd= uced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in the case o= f


> RSVP-TE, the operator would explicitly indicate, as part = of LSP


> signaling, whether it would or would not use FRR; LS= Ps that would not


> use FRR would then drop traffic rather th= an delivering it the wrong way.


>


> Such an opt= ion indeed does not exist in SR-TE today, but would be easy


>= to provide if so desired IMHO.


>


> Did I miss = something substantial?


>


> Regards, and lots of= thanks in advance,


>


> Sasha


>

> Office: +972-39266302


>


> Cell:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302


>


&g= t; Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com


>

> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Heg= de


> *Sent:* Tuesday, August 4, 2020 9:41 AM


> = *To:* EXT-Andrew.Alston@liquidtelecom.com


> <Andrew.Alston@liq= uidtelecom.com>; Robert Raszuk <robert@raszuk.net>


> *Cc:* spring@ietf.org; Joel M= . Halpern <jmh@= joelhalpern.com>


> *Subject:* Re: [spring] Spring prot= ection - determining applicability


>


> All,
=

>


> This is a very interesting discussion and than= ks to Joel for starting


> this discussion. IMO, when there ar= e strict requirements of avoiding


> certain nodes/links it ca= n be realized=C2=A0 either by defining a flex-algo


> avoiding= those


>


> Nodes and links or by using a stack = of unprotected adj-sids that avoid


> restricted nodes and lin= ks. When a stack of adj-sids is used to


> realize the path, t= he head-end based (sBFD) protection mechanisms can be applied.


&= gt;


> If Node-sids/prefix-sid/anycast-sids are used to build = the stack, the


> failure events may cause traffic to go throu= gh restricted nodes and


> links. This would happen regardless= of whether any kind of protection


> is in use or not.

>


> Rgds


>


> Shraddha
=

>


> Juniper Business Use Only


>
<= br>
> *From:* spring <spring-bounces@ietf.org
 > <mailto:spring-bounces@iet= f.org>> *On Behalf Of *Andrew Alston


> *Sent:* Tues= day, August 4, 2020 5:41 AM


> *To:* Robert Raszuk <robert@raszuk.net <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">mailto:robert@raszuk.= net>>


> *Cc:* spring@ietf.org <mailto:spring@ietf.org>; Joel M. Halpern

> <jmh@joe= lhalpern.com <mailto:jmh@joelhalpern.com>>


> *Subject:* Re: [s= pring] Spring protection - determining applicability


>

> *[External Email. Be cautious of content]*


>

> Robert this is actually far more difficult when =E2=80=93 it can = be an entire


> (long) series of nodes that need to be avoided= .


>


> It could potentially be made to work but = I=E2=80=99d worry that to do this =E2=80=93


> you=E2=80=99d h= ave to stack 10 =E2=80=93 20 =E2=80=93 30 negative labels =E2=80=93 and tha= t wouldn=E2=80=99t


> be viable.


>


&g= t; It=E2=80=99s easier to use algorithms and adjacency sids and other such = things


> to calculate paths =E2=80=93 the biggest trick is ab= out the stack depth.=C2=A0 When


> you have this need for node= avoidance =E2=80=93 the need for 10+ label depth


> is critic= al =E2=80=93 unless you wanna be applying one hell of a lot of


&= gt; binding labels along the way which is a nightmare.


>
<= br>
> But to answer your question, is this a common use case =E2=80= =93 it=E2=80=99s a use


> case that most of the people I discu= ss this with certain have =E2=80=93 I cant


> comment on a glo= bal scale, or for anyone else, but every indication I


> have = is that yes =E2=80=93 its something people need, and want


>

> Andrew


>


> *From:* Robert Raszuk= <robert@raszuk.n= et <mailto:ro= bert@raszuk.net>>


> *Sent:* Tuesday, 4 August 2020 = 01:27


> *To:* Andrew Alston <Andrew.Alston@liquidtelecom.c= om
 > <mailto:Andrew.Alston@liquidtelecom.com>>

> *Cc:* Joel M. Halpern <jmh@joelhalpern.com
 > <mailto:jmh@joelhalpern.com>&g= t;; spring@ietf.org


> <= mailto:spring@ietf.org>


> *Subject:* Re: [spring] Spri= ng protection - determining applicability


>


> I= s this a common use case ie.=C2=A0 "but rather =E2=80=93 which nodes /= network


> segments it can never touch or flow through."=


>


> If so perhaps its time to define notion of= *negative-SID* ie. list in


> the packet resources which give= n=C2=A0packet MUST not ever traverse.


>


> Put i= n the packet set of nodes or links which the packet should never

> traverse.


>


> That goes in line of recent= wave of negative routing implementations


> (RIFT) or discuss= ions (LSR)


>


> Best,


> R.

=
>


> On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
<= br>
> <Andrew.Alston@liquidtelecom.com
 > <mailto:Andrew.Al= ston@liquidtelecom.com>> wrote:


>


>= =C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93


>


>=C2=A0= =C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very major use cases= in any


>=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us re= volve around the following


>


>=C2=A0=C2=A0=C2= =A0=C2=A0 a.The explicit avoidance of certain nodes


>

=
>=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain sectio= ns of the network


>


>=C2=A0=C2=A0=C2=A0=C2=A0 A= nything that could result in that explicit avoidance being violated

=
>=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say signi= ficant problems.


>


>=C2=A0=C2=A0=C2=A0=C2=A0 Mu= ch of the use case is not a case of which nodes the packets flow

>=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 which = nodes / network segments it can never


>=C2=A0=C2=A0=C2=A0=C2= =A0 touch or flow through.=C2=A0 Effectively, to be used as a technology to=


>=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific = reasons.


>


>=C2=A0=C2=A0=C2=A0=C2=A0 This is al= so one of the reasons for needing such deep label stacks =E2=80=93

<= br>>=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming tend= s to deepen the stack


>=C2=A0=C2=A0=C2=A0=C2=A0 because you s= ometimes have to be pretty explicit.


>


>=C2=A0= =C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this functionality = is there =E2=80=93


>=C2=A0=C2=A0=C2=A0=C2=A0 and that we can = avoid situations which could cause traffic to


>=C2=A0=C2=A0= =C2=A0=C2=A0 accidently hit things explicitly avoided.


>
<= br>
>=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than th= is, but it is what it is.


>


>=C2=A0=C2=A0=C2=A0= =C2=A0 Thanks


>


>=C2=A0=C2=A0=C2=A0=C2=A0 Andre= w


>


>=C2=A0=C2=A0=C2=A0=C2=A0 *From:* spring &l= t;spring-bo= unces@ietf.org
 >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> *On Behalf Of *Joel M. Halpern


>=C2=A0=C2=A0=C2=A0= =C2=A0 *Sent:* Monday, 3 August 2020 21:36


>=C2=A0=C2=A0=C2= =A0=C2=A0 *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>


>=C2= =A0=C2=A0=C2=A0=C2=A0 *Cc:* spring@ietf..org <mailto:spring@ietf.org>


>=C2=A0=C2=A0=C2= =A0=C2=A0 *Subject:* Re: [spring] Spring protection - determining

> applicability


>


>=C2=A0=C2=A0=C2=A0=C2= =A0 (Since the thread has gotten long enough, reiterating that this is as a=


>=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.)
<= br>
>


>=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP = networks. And yes, I have seen IP networks that


>=C2=A0=C2=A0= =C2=A0=C2=A0 choose to drop packets. For all sorts of reasons.


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons why one = may not want a random


>=C2=A0=C2=A0=C2=A0=C2=A0 path rather t= han a chosen TE path. I think it is important we be clear


>= =C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are violated when = we tell people they


>=C2=A0=C2=A0=C2=A0=C2=A0 have this tool = (protective rerouting) that is intended to preserve QoS.


>

>=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing = that this is not a good idea. It is a


>=C2=A0=C2=A0=C2=A0=C2= =A0 good idea. And useful. I am trying to figure otu what combination of

>=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descr= iptions will lead to everyone


>=C2=A0=C2=A0=C2=A0=C2=A0 getti= ng the behavior they expect (which may not be the behavior they


= >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can do.)<= br>

>


>=C2=A0=C2=A0=C2=A0=C2=A0 Yours,


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0 Joel


>


>=C2=A0=C2= =A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel,


>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we= still talking about IP networks=C2=A0here ? Or perhaps some hard

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reserv= ations or detnets ?


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
<= br>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talki= ng=C2=A0about IP networking I have two


>=C2=A0=C2=A0=C2=A0=C2= =A0 observations:


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via= a specific node (ie. firewall) you


>=C2=A0=C2=A0=C2=A0=C2=A0= better


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsu= lation to that node.. I don't think IP


>=C2=A0=C2=A0=C2= =A0=C2=A0 encapsulation=C2=A0can


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > be hijacked today such that destination address of the packet is

>=C2=A0=C2=A0=C2=A0=C2=A0 ignored.


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = B) Have you seen any IP network where upon topology change (link

>=C2=A0=C2=A0=C2=A0=C2=A0 or node


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > failure) you suddenly=C2=A0start dropping=C2=A0flows in spit= e of SPT offering


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhap= s few ms longer path with 10 ms more jitter ?


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = Or are some SR marketing slides promise to turn IP networks in


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new ? Worse ... do th= ey mention path quality guarantees,


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > resource reservations=C2=A0? I hope not.


>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= > Thx,


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R.

>=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=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 ><= br>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On Mon, Aug 3, 2020 at 8= :10 PM Joel M. Halpern <jmh@joelhalpern.com
 >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joe= lhalpern.com%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > Well less serious for TE SIDs, I am not sure the problem is<= br>

>=C2=A0=C2=A0=C2=A0=C2=A0 restricted


>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > to just service SIDs.


>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &g= t; Suppose that the PCE has specified the path to meet some complex te
<= br>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass = node has no way of knowing what those


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > constraints


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &g= t; were.=C2=A0 And for some kinds of traffic, it is better to drop the pack= et


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it ou= tside the envelop.=C2=A0 I suspect that the right


>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > answer


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > to this is "too bad"..=C2=A0 If so, as with the disti= nction regarding


>=C2=A0=C2=A0=C2=A0=C2=A0 service

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn&#= 39;t we?


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours,


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > Joel


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >= ;


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, A= lexander Vainshtein wrote:


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &g= t; > Mach, Joel and all,


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &= gt; >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think th= at in most cases:


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear dif= ferentiation between "topological" and


>=C2=A0=C2= =A0=C2=A0=C2=A0 "service"


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > > instructions in SID advertisements. E.g.:


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as su= ch in the


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > correspon= ding IGP advertisements) represent topological


>=C2=A0=C2=A0= =C2=A0=C2=A0 instructions


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >= ; >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SID= s for SRv6 (see SRv6 BGP-Based Overlay Services


>=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 <https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
= >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3GC5= af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2= Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o4T-L0nl%24>>


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ><= br>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprising= ly represent =E2=80=9Cservice=E2=80=9D instructions


>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > > 2.Segments that represent topological instructions can be = bypassed,


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while seg= ments that represent service instructions require


>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > alternative


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > > protection mechanisms.


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >= ; > This view seems to be aligned with RFC 8402


>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > > <https://clicktime.symantec.com/345NLCB6TydxuuqUj= tcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
 >=C2= =A0=C2=A0=C2=A0=C2=A0 <https://c= licktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F%2Furldefen= se.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yM= aO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24= >>


>=C2=A0=C2=A0=C2=A0=C2=A0 that says in Section 1= :


>=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 In the context = of an IGP-based distributed control plane, two


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > > topological segments are defined: the IGP-Adjacency segment and t= he


>=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 IGP-Prefix segm= ent.


>=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 In the context= of a BGP-based distributed control plane, two


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > > topological segments are defined: the BGP peering segment and the=


>=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 BGP-Prefix segment= .


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this differ= entiation is assumed in Section


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > 3.4 of


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the= Node Protection for SR-TE Path


>=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 <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx= 96H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spri= ng-node-protection-for-sr-te-paths-07%23section-3.4
 >=C2=A0=C2= =A0=C2=A0=C2=A0 <https://clicktim= e.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%2Furldefense.com%= 2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-= node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21= S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>= >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft that says:


>=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 The node protection mechanism descri= bed in the previous


>=C2=A0=C2=A0=C2=A0=C2=A0 sections

>=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 depends on the assumptio= n that the label immediately below


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > the top


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label= stack is understood in the IGP domain.=C2=A0 When the


>=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 provider edge routers exchange servi= ce labels via BGP or some


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >= ; other


>=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 non-IGP mec= hanism the bottom label is not understood in the IGP


>=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 domain.


>=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 The egress node protection mechanisms described i= n the draft


>=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 [RFC867= 9 <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttp= s%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
 >=C2=A0=C2= =A0=C2=A0=C2=A0 <htt= ps://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F%2Fur= ldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc867= 9__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8A= kTRDuiDo8MGipXc%24>>]


>=C2=A0=C2=A0=C2=A0=C2=A0 is<= br>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this = use case and no additional changes


>=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 will be required for SR based networks


>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > > The scenarios in which =C2=A0differentiation between = =E2=80=9Ctopological=E2=80=9D and


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > > =E2=80=9Cservice=E2=80=9D instructions is broken are indee= d problematic. E.g.,


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > con= sider


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case = in which a Node SID in the ERO of a SR-TE path


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > identifies a


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > > node that acts as a firewall for all packets it receive= s, i.e.,


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service with= out any dedicated service SID


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= > identifying it.


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > &g= t; One could say that the Node SID of such a node would combine


= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological


>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus breaking t= he differentiation


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > betwe= en the two.


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >

=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of = such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented


>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > > least discouraged.


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >= If not, providing an ability to identify such SIDs in the


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement


>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMHO.

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > > My 2c,


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sa= sha


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-54926630= 2


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein@ecitele.com=


>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:Alexander.Vainshtein@eci= tele.com>


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:A= lexander.Vainshtein@ecitele.com>


>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > &= gt; -----Original Message-----


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > > From: spring <spring-bounces@ietf.org
 >=C2=A0=C2=A0=C2=A0= =C2=A0 <= mailto:spring-bounces@ietf.org%0b>>


>=C2=A0=C2=A0= =C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2= 020 6:30 AM


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joe= l M. Halpern <jmh@joelhalpern.com
 >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%= 0b>> <mailto:jmh@joelhalpern.com>>;


>=C2=A0=C2=A0=C2=A0= =C2=A0 spring@ietf.org= <mailto:spring= @ietf.org> <= mailto:spring@ietf.org>


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > > Subject: Re: [spring] Spring protection - determining applica= bility


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel,


>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > > I think this is a good point that may not be discussed in = the


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there = is a "can be bypassed" indication in the


>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now.


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > > IMHO, the information advertised by routing is ne= utral, such


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information<= br>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be b= ypassed) is more path specific, thus


>=C2=A0=C2=A0=C2=A0=C2= =A0 normally the


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > co= ntroller should be responsible for deciding whether/which SID


&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > > bypassed.


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Be= st regards,


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >

=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach


>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > >=C2=A0 > -----Original Message-----


>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > >=C2=A0 > From: spring [mailto:spring-bounces@ietf.org

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring-bounces@ietf.org>
<= br>
>=C2=A0=C2=A0=C2=A0=C2=A0 <mail= to:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e= >]


>=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M.

<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > >=C2=A0 > Sent: Monday, August 3, 2020 7:51 AM


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>


>=C2=A0=C2= =A0=C2=A0=C2=A0 <ma= ilto:spring@ietf.org>


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > <mailto:spring@ietf.org <mailto:spring@ietf.org
= >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%20%3cmailto:= spring@ietf.org>>>


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > Subject: [spring] Spring protection - determining applicability

>=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 > (WG Chair hat Off, this is merely a note from a slightly<= br>

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > >=C2=A0 > participant.)


>=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 > I = have been reading the various repair drafts, and the various


>= ;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > >=C2=A0 > networks programming and service programm= ing draft, and I am


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > tryi= ng to


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspect= of the combination.


>=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 > How does a node that is doing so= me form of bypass (suppose, for


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > simplicity, it is Node N2 deciding to bypass the next SID for

=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed


>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 > >=C2=A0 > node N3) know that it is safe to do so?

=
>=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 > If the path was just for TE, then it is "safe" = if the new path


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2=A0 or may= be it is safe if it is even close, as


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > long as


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > &= gt;


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it i= s not used for too long.


>=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 > But what if the node were a F= irewall, included to meet legal


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > > requirements?


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &= gt; >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 >= Or was some other necessary programmatic transform (wince we are

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague about what nodes= can do when asked suitably.)


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 &g= t;


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Is there some "can= be bypassed" indication in the routing


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >= ; >=C2=A0 > advertisements that I missed?


>=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 > Thank = you,


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>= ;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours,


>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > >=C2=A0 > Joel


>=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=A0=C2=A0=C2= =A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > spring mailing list


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >= ; >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > <= a href=3D"mailto:spring@ietf.org" target=3D"_blank">spring@ietf..org &l= t;mailto:spring@ietf.o= rg>


>=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>


= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
 >=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>

<= br>>=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=A0 https:= //clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
<= br>
>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symante= c.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__= https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%= 2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp= 6vpRHOGt8AkTRDuiDo6HwPLil%24>


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
<= br>
>=C2=A0=C2=A0=C2=A0=C2=A0 <ht= tps://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec= .com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__ht= tps%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A= 3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp= 6vpRHOGt8AkTRDuiDozoQiAHk%24>>


>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > &= gt;=C2=A0 > F%2Fwww.= ietf.org


>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-g= k%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24= >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <https://clicktime.symantec.com/3GWT9fyjaFi= 3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%2F2Fwww.ietf.org
 >=C2=A0=C2=A0=C2= =A0=C2=A0 <https://clicktime.symantec.com/39NznmYB= tRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fww= w.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6= vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring

>=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 > > spring mailing list


&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org>


>=C2=A0=C2=A0=C2=A0=C2= =A0 <mailto:spring@= ietf.org> <mailto:spring@ietf.org
 >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%0b<= /a>>> <mailto= :spring@ietf.org>>


>=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 https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring


>=C2=A0= =C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?= u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com= %2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fma= ilman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E= _R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>


&= gt;=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 > >


&= gt;=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 > > Notice: This e-ma= il together with any attachments may contain


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 > > information of Ribbon Communications Inc. that is= confidential


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or
=

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the so= le use of the intended recipient. Any review,


>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distribution by others= or forwarding


>=C2=A0=C2=A0=C2=A0=C2=A0 without


&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly = prohibited. If you are not the


>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 > intended


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > r= ecipient, please notify the sender immediately and then delete all

<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attac= hments.


>=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=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spri= ng mailing list


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <<= a href=3D"mailto:spring@ietf.org" target=3D"_blank">mailto:spring@ietf.org<= /a>> <mailto:spr= ing@ietf.org>


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >= ; https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%= 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring


>=C2=A0=C2= =A0=C2=A0=C2=A0 <htt= ps://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Fur= ldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring= __%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8Ak= TRDuiDo5KlPnbj%24>


>=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 > spring mailing = list


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org= >


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.sy= mantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmail= man%2Flistinfo%2Fspring


>=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec= .com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__h= ttps%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%= 21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24&g= t;


>=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 spring mailing list

=
>=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org>


>=C2=A0=C2=A0=C2= =A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring


>=C2= =A0=C2=A0=C2=A0=C2=A0


> <h= ttps://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
<= /a> > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti


&g= t; nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu

> oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


>

>


>


> --------------------------------= --------------------------------------


> --


> N= otice: This e-mail together with any attachments may contain


>= ; information of Ribbon Communications Inc. that is confidential and/or
=

> proprietary for the sole use of the intended recipient. Any re= view,


> disclosure, reliance or distribution by others or for= warding without


> express permission is strictly prohibited. = If you are not the intended


> recipient, please notify the se= nder immediately and then delete all


> copies, including any = attachments.


> ----------------------------------------------= ------------------------


> --





________= _______________________________________


spring mailing list
<= br>
spring@ietf.org=


https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring


= _______________________________________________


spring mailing l= ist


spring@= ietf.org


https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhq= Lq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

<= br>


=C2=A0




=C2=A0







Notice: This e-mail togeth= er with any attachments may contain information of Ribbon Communications In= c. that is confidential and/or proprietary for the sole use of the intended= recipient. Any review, disclosure, reliance or distribution by others or f= orwarding without express permission is strictly prohibited. If you are not= the intended recipient, please notify the sender immediately and then dele= te all copies, including any attachments.









=C2=A0























_______________________________________________

spring mailing list


spring@ietf.org


https://www.ietf.org/mailm= an/listinfo/spring






=
















_______________________= ________________________

spring mailing list

spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring

--
=

<= p style=3D"font-size:1em;margin:0px;font-family:"Verizon NHG DS",= Arial,sans-serif;line-height:13px;color:black">Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2= =A0
Silver Spring, MD


--00000000000032fa3e05ace18557-- From nobody Fri Aug 14 20:20:17 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007413A0C30; Fri, 14 Aug 2020 20:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 kg8gVP3OOMJj; Fri, 14 Aug 2020 20:20:09 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3363A0C2D; Fri, 14 Aug 2020 20:20:09 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id k18so2112114uao.11; Fri, 14 Aug 2020 20:20:08 -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=FEp+R/JI1Bq3FuE2kCwbeGZrBFbemir6i9jKFH/ZyT4=; b=JyOAa71kSkgRu0nakqcBwO4WaGHt83SVedUbk35mDVzqUpoPGSQmlIDP0IGA0PN2zG UlcKja2riabuTZHQCfDchm2705PrsU21ZYqD8EamKIjXTAwxyrMyd3uivP4QWCbRezPM YC9M4vunUPqYrM6POuV8br+AKBTYo2OoGlHiIZTbxWPMgovYDyeoYtSCTnFhcQsMdg2g CF/drN9W9TIoMVEsmRW3WgqmECvgnxWptTEBxQ8J98MVSYiaS1M5ri5a+F7BI+a+h4vO 5bgzDlpXAdXVEyQaJmJ2MIpYbAfrI4Aal4c8so7lnGXLnAS6E7R+hckRk9z/fg+tWR6M 2HBA== 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=FEp+R/JI1Bq3FuE2kCwbeGZrBFbemir6i9jKFH/ZyT4=; b=o6/IL/58kDTsKapl0IjfXu0cwmanuAjojDRVjSOgNw1FdLTT4S0RXRxppu8RB0anYu Vn3z/L5Ud/V9VnEvtSlJ7JZeYTuz5ebAVlpyYZhHtzyNU98SodG5ZZJ1EbnHHegAkfJ1 KhZooxWpkCksAKb+mwuALOzpREBoecB2D2yczCHVGbSbk4ZSobrM7/FLMcpQMgTk/qEw 7BN6aM4YKVrQSrPmwSnvChbNRv/HNwB4IH43BUyItsNv5PYgwBKdzXiPzqC77bXFK/mz hLkAfDbdDGxMOTI217svbl7hwO1YoCWPYS3lgU/1ildvATLOOPq9L5lNH0eBfrzCCEbs J2pA== X-Gm-Message-State: AOAM532Sf+AIdWPdFKVQVBQYzUoxkG1qDE0zHKlDAgHuEXRRwOd4hZsL f/GnGY1vYAMQW76y9jcNUXE8YHlU9MYkBEW7lkA= X-Google-Smtp-Source: ABdhPJzTjJazNjt4g9XJ+a9lZFon7hc8k4xLN3wccVvyIWSiJ+TrdSJI1xcoYQZqS5PS0OZx+YJmOhlgCSSbALF1P74= X-Received: by 2002:ab0:2704:: with SMTP id s4mr2858833uao.141.1597461607972; Fri, 14 Aug 2020 20:20:07 -0700 (PDT) MIME-Version: 1.0 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <1d8fb113-41c8-46cc-bfa3-54c04d406142@Spark> In-Reply-To: <1d8fb113-41c8-46cc-bfa3-54c04d406142@Spark> From: Gyan Mishra Date: Fri, 14 Aug 2020 23:19:57 -0400 Message-ID: To: Jeff Tantsura Cc: "Ketan Talaulikar (ketant)" , SPRING WG , "Thomas.Graf@swisscom.com" , "hannes@gredler.at" , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="000000000000af83ad05ace2035e" Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 03:20:12 -0000 --000000000000af83ad05ace2035e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Kethan and Jeff. This draft is extending IPFIX defined in RFC 7011 7012 to support SR segments over IP export. Since SR-MPLS reuses the MPLS data plane, why would the existing IPFIX RFCs also not support SR-MPLS without having to dig into IGP control plane extensions as from an IPFIX perspective the MPLS data plane is still the same and using the same 4 byte MPLS shim used by LDP. Gyan On Fri, Aug 14, 2020 at 2:54 PM Jeff Tantsura wrote: > > > > > > > > > > > > > In general, I agree with what Ketan said, what=E2=80=99s important - it i= s the > value that is being used in forwarding, even if multiple control plane > entries exist, think about IGP migrations, or LDP to SR, where more than = 1 > protocol could be distributing the labels/SIDs.. I=E2=80=99m not sure the= FIB is > the right place to collect this data though, since most of meta-data has > already been lost (flattened FIB structures often contain bare minimum) a= nd > really heavily depends on the implementation. > > > > > > > > Cheers, > > Jeff > > > > > > > On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (ketant) 40cisco.com@dmarc.ietf.org>, wrote: > > > > > > > < also copying Spring WG for their review/inputs > > > > > > > Hi Thomas/All, > > > > > > I have reviewed the draft and would like to share a different perspective= . > > > > > > What or how much value be there on determining whether a SR Prefix SID wa= s > signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matt= ers and is > more important is that it is a Prefix SID. Hardly any deployments would b= e > running multiple protocols and learning the same prefix from different > IGPs. IPFIX may be picking this information from a FIB in some > implementation where the protocol does not matter and this information is > not available therein. > > > > > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 > what would we use/show? > > > > > > I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, > SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type. > > > > > > This also takes away the need for the second table that is being proposed > to a large extent. For that table proposal, it is very difficult and in > some cases not possible to different between Prefix and Node and Anycast > SID. Many of these types are control plane elements and we can be sure mo= re > get added. Is there really much value in differentiation between say an > Adjacency SID and LAN Adjacency SID? > > > > > > Could we evaluate the implementation overhead and complexity of this leve= l > of categorization/information in IPFIX against their value in flow analys= is > to perhaps consider a middle ground? > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* Lsr *On Behalf Of* Thomas.Graf@swisscom.co= m > > > *Sent:* 31 July 2020 20:52 > > > *To:* hannes@gredler.at > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Hannes, > > > > > > Thanks a lot for the feedback. Yes, makes completely sense. Will take it > for the next update... > > > > > > Best Wishes > > > Thomas > > > > > > > > > > > > > > > > > *From:* Hannes Gredler > > > *Sent:* Wednesday, July 29, 2020 9:31 AM > > > *To:* Graf Thomas, INI-NET-DCF > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Thomas, > > > > > > > > > > > > I have one comment/suggestion to Paragraph 4 (IANA Considerations). > > > > > > > > > > > > > > Please add also a code point for BGP Prefix-SID - it=E2=80=99s quite popu= lar in DC > deployments. > > > > > > > https://tools.ietf.org/html/rfc8669 > > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > /hannes > > > > > > > > > > > > > > > > On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: > > > > > > > > > > > > Dear lsr, > > > > > > > > > > > > > > I presented the following draft > > > > > > > > > > > > > > Export of MPLS Segment Routing Label Type Information in IP Flow > Information Export (IPFIX) > > > > > > > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 > > > > > > > > > > > > > > > at the spring working group at IETF 108 yesterday > > > > > > > > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-inf= ormation-export-ipfix-00.pdf > > > > > > > > > > > > > > > and today at OPSAWG where I call for adoption. > > > > > > > > > > > > > > This draft adds additional segment routing code points for in the IANA > IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID type= s > to gain further insights into the MPLS-SR forwarding-plane. > > > > > > > > > > > > > > I have been asked to not only gather feedback from spring and opsawg but > also from lsr and mpls working groups since these code points are related > to link state routing protocols and mpls data plane. > > > > > > > > > > > > > > I am looking forward to your feedback and input. > > > > > > > > > > > > > > Best Wishes > > > > > > > Thomas Graf > > > > > _______________________________________________ > > > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000af83ad05ace2035e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I agree with Kethan and Jeff. =C2=A0
=

This draft is extending IPFIX= defined in RFC 7011 7012 to support SR segments over IP export.

Since SR-MPLS reuses the MPLS data= plane, why would the existing IPFIX RFCs also not support SR-MPLS without = having to dig into IGP control plane extensions as from an IPFIX perspectiv= e the MPLS data plane is still the same and using the same 4 byte MPLS shim= used by LDP. =C2=A0

Gya= n=C2=A0

On Fri, Aug 14, 2020 at 2:54 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:












In general, I agree with = what Ketan said, what=E2=80=99s important - it is the value that is being u= sed in forwarding, even if multiple control plane entries exist, think abou= t IGP migrations, or LDP to SR, where more than 1 protocol could be distrib= uting the labels/SIDs.. I=E2=80=99m not sure the FIB is the right place to = collect this data though, since most of meta-data has already been lost (fl= attened FIB structures often contain bare minimum) and really heavily depen= ds on the implementation.=C2=A0







Cheers,

Jeff





= On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dm= arc.ietf.org>, wrote:






= < also copying Spring WG for their review/inputs >



=

=C2=A0



Hi Thomas/All,



=C2= =A0



I have reviewed the draf= t and would like to share a different perspective.



=C2=A0



What or how much value be there on determining whether a SR Prefix SID wa= s signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matt= ers and is more important is that it is a Prefix SID. Hardly any deployment= s would be running multiple protocols and learning the same prefix from dif= ferent IGPs. IPFIX may be picking this information from a FIB in some imple= mentation where the protocol does not matter and this information is not av= ailable therein.



=C2=A0



On some nodes, the same Prefix S= ID may be learnt via both BGP and IGP =E2=80=93 what would we use/show?



=C2=A0



I would recommend using SR Prefix SID, SR Adjacency = SID, SR Binding SID, SR BGP Peering SID and so on =E2=80=A6 for the MPLS La= bel Type.



=C2=A0

<= br>

This also takes away the need for the s= econd table that is being proposed to a large extent. For that table propos= al, it is very difficult and in some cases not possible to different betwee= n Prefix and Node and Anycast SID. Many of these types are control plane el= ements and we can be sure more get added. Is there really much value in dif= ferentiation between say an Adjacency SID and LAN Adjacency SID?

=

=C2=A0



Could we evaluate the implementation overhead and complexit= y of this level of categorization/information in IPFIX against their value = in flow analysis to perhaps consider a middle ground?



=C2=A0



<= span>Thanks,



Ketan

=C2=A0






From: Lsr <lsr-bounces@ietf.org<= /a>> On Behalf Of Thomas.Graf@swisscom.com


Sent: 31 July= 2020 20:52


To: hannes@gredler.at


Cc: lsr@ietf.org


Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type






=C2=A0



Hi Hannes,


<= br>

=C2=A0



Thanks a lot for the feedback. Yes, makes completely sense. Will take i= t for the next update...



=C2=A0



Best Wishes



<= p class=3D"MsoNormal">Thomas=





=C2=A0





=C2=A0







From: Hannes Gredler <= hannes@gredler.at>


Sent: Wednesday, July 29, 2020 9:31 AM


<= b>To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>


Cc= : lsr@ietf.org

Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type







=C2=A0



Thomas,





=C2=A0







I have one comment/suggestion to Paragr= aph 4 (IANA Considerations).







<= p class=3D"MsoNormal">=C2=A0



<= br>


Please add = also a code point for BGP Prefix-SID - it=E2=80=99s quite popular in DC dep= loyments.








=C2=A0

=





thanks,







=C2=A0






<= br>

/hannes









=C2=A0







On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wro= te:





=C2=A0







Dear lsr,


=




= =C2=A0






I presented the following dr= aft






=C2=A0







Export of MPLS Segment Routing Label Type Information in IP= Flow Information Export (IPFIX)


=




https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04






=C2=A0







at the spring working group at IETF 108 yesterday









=C2=A0


<= br>




and= today at OPSAWG where I call for adoption.







=C2=A0






This draft adds add= itional segment routing code points for in the IANA IPFIX registry for IS-I= S, OPSFv2 and OPSF v3 and segment routing SID types to gain further insight= s into the MPLS-SR forwarding-plane.

=









<= br>

I have been asked to not o= nly gather feedback from spring and opsawg but also from lsr and mpls worki= ng groups since these code points are related to link state routing protoco= ls and mpls data plane.







=C2=A0







I am looking forward to your feedback a= nd input.





=

=C2=A0







Best Wishes

<= br>




Thomas Graf





_______________________________________________
=

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






<= br>


=C2=A0<= /p>





____________________________________= ___________


spring mailing list


spring@ietf.org


https://www.= ietf.org/mailman/listinfo/spring




=




_______________________________________________
Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/mailman/listi= nfo/lsr

--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 50= 2-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD


--000000000000af83ad05ace2035e-- From nobody Fri Aug 14 21:10:35 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788943A0CA4; Fri, 14 Aug 2020 21:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 wm0lBQk0_PL8; Fri, 14 Aug 2020 21:10:30 -0700 (PDT) Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 6AB643A0CA2; Fri, 14 Aug 2020 21:10:29 -0700 (PDT) Received: by mail.swisscom.com; Sat, 15 Aug 2020 06:10:21 +0200 Message-ID: <2022615026.3001869.1597464620979@ss002889> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_3001867_1048957526.1597464620978" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U3q43JTO000Zv7zkUGBWhYJmv7OLT042HkX1FBl+TBZbhihG1njuI0j/L3dOFqKAJ92qaLQbo0FlxF4cE87pK4Ci8qJEZ5utCAD4UHFcCTfdWS+menDp4H2Rc5nOB0imDE+XEkNTu/N1sw8Myo75+GgRRFnKq/gtO7MfosO2DE9CK+Fmc4adopmQDfKMOIZygM/EOvKCyPpZZFOa5IhmYPo0YZL/rTILwy0woXnWRYSLQU8rSAHIeba55sEBQUEpsezl2fDt2TC2TeWYUBfv5xmp3vLE4aesjhfj8fV6oBqBfpkVa6LwPetkarOCwJvh7EPKO3zW8PEmbIUlwgDK1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JKV3GN8sUvmzHbal01uVxx1HA23QMSX71yyoPATUq5o=; b=CNVNbpikgRQhrNGX+WOJw1kDpZD8hPCbE6UPQSONriSTSAlmGzccUmfh5LYLUwAyzVimHq9qmMZuiWBUKvfACCcNbLqoeT1G2om4zpfaLQekYpePibDYBt3gkpBjGgHlopzNUtEbkyna9kcIIOGhxik1QfS40s1b+NlpslPmksMd1T9KqhawgqQrBdWEpqKtpwROJ8Wc38ch0eOF/TL8EP7iR+ic4ql5KL+onsw7UJPaVWPWOycd6GAO9i6F3pC4/ZkmMVZPaiPy8oQ9GLJNQmgelXVi3mtNIpvJXYgDawGW9T3K3EQ/VRHP+MFBcdpMLCHUaT+yRu23SC8RcssTPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , CC: , , Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AQHWZXpAYzBRFTPdWk2PQZUrWhbqXAAxTF+AAHUFTIACvTCesKkdfmZw Date: Sat, 15 Aug 2020 04:10:17 +0000 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [178.199.12.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 77e54d12-fee8-439b-e11a-08d840d11e9d x-ms-traffictypediagnostic: ZR0P278MB0060: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e+Pn9d9UmoNKdKDqfDwBJXTsJfuF5rvgf9dzl3hoP272Njo4nj18uftPodKAU5RJmZs/bvxdsFovZkMD5g3aUQUEa25jAvyJyEn136viaTlUfIBPy25T/+hhW+BPcBAbbVSDiHdJdDL0Ig6HtNZx+Ome2IFKVS2gCu39MRMhOhI054TWx/4lzh6Gm0K8Mdh3FjAEtAgLD2zF1OaKzWObsTqKVhSVhnxrQaCuvp8SS8VZCwASBDaumpKbZazJ0PZ/qHO5zBioKc9YqB0DkVA7aZrdkYL0KkLNtqN5ce4yfq044iJ2uyIjPsD/W8h/qztcyMD0iBS9yXoxl8iqsr3JHB3aUnHFRT6rNL0qFwmaL03B6iOTMiIh1qEmZKKAHkuHdc27ns9XOQ7HQF108oKcRQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(39860400002)(396003)(366004)(53546011)(4326008)(52536014)(10290500003)(66446008)(71200400001)(8676002)(86362001)(5660300002)(9686003)(26005)(55016002)(64756008)(66556008)(66476007)(66946007)(76116006)(6506007)(10300500001)(33656002)(83380400001)(66574015)(966005)(8936002)(110136005)(19627235002)(2906002)(478600001)(166002)(316002)(186003)(7696005)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yNaU6oJt60922Zz6r+eEMC9bs++2+emd4Xy/nKKte38GDIg8D+gaZ8fdJ9dX6qwAuRMtRnLs2E0kRqJbArEKGkv5HrrYsrAVeZgiI3vv3mw26YHLW7tCjlN/CGrk2dpt5movuSFNsaPsU5vh81C51TF3AXQFA09mz9yAfRgr8TxHCZhz4mmNw/LPqHMoUy0Dm8ymexGipMuSNdYwY2aOv1CHCcjkVCPIaDX7Pt6M+IqucW5v0+YSDPWnm2k+LcdagLxQvpo3HrOi6WY/Ec1Erh+UD7R5dmWDnOBd6IGqMRO8k5JcUJp4HsCwWfQTHjW6GXwL5NET4s7MlPoHhJpvofcekEvJFvVOQFPMtGynID+ZdcpF5Rz8ZCpEMAwv0V//rIyaoPpgrXcd7+hE/C6Bdy2q+suxbzMvYJkj7U7iIlDik8hHnMjQEY3XiKRfAkKwp4S7ISukW8F27xtU4xj6NSpkhLOkmGv+VXzG1cHSQK22dWqzXGYGUe9pVZpFYEq7bl02jRE3IeeQwZahiHghMTq7OcCRmqR31Rh4G1jdGhp+NwWTGI2+66tSzkY3Ljfw8bE18tTHVOXXfL4v4cFT6gDYoQLPV0alz1t81i7jkR/wpKhACyTweY/X/tyz+5ngVQ5iShMYI4x/YYeAZjHtCg== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 77e54d12-fee8-439b-e11a-08d840d11e9d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2020 04:10:17.7915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G2DdI5yz3aUDKJNoz0s88gaZ/xAYsYtPuiYhOJFpsue0IItUdAz4yXAKsDdFRenGGO8CrV8NpEuZ1Ifh2BZiyEFcOVDzHebA/gJ95Kk8kOU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0060 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 04:10:34 -0000 ------=_Part_3001867_1048957526.1597464620978 Content-Type: multipart/alternative; boundary="_000_ZR0P278MB0122EAF02F60CF871971534489410ZR0P278MB0122CHEP_" Content-Language: en-US --_000_ZR0P278MB0122EAF02F60CF871971534489410ZR0P278MB0122CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters = and is more important is that it is a Prefix SID. Hardly any deployments wo= uld be running multiple protocols and learning the same prefix from differe= nt IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available= therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not p= ossible to different between Prefix and Node and Anycast SID. Many of these= types are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF ; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update.. Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_ZR0P278MB0122EAF02F60CF871971534489410ZR0P278MB0122CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

 

Thank you very mu= ch for the review and feedback.

 =

  • What or how= much value be there on determining whether a SR Prefix SID was signalled/p= rogrammed on a node via OSPFv2/OSPFv3/ISIS – what matters and is more important is that it is a Prefix SID. Har= dly any deployments would be running multiple protocols and learning the sa= me prefix from different IGPs.

 

As Jeff already pointed out. Mul= tiple IGP labelling protocols are used  in networks when migrations ar= e ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom wh= en we first discovered this shortcoming in vendor implementations. The key = point here, with these additional IPFIX MPLS Label Type identifiers we enab= le the possibility to verify the label protocol migration without taking the label value into the considera= tion.

 

  • IPFIX may b= e picking this information from a FIB in some implementation where the prot= ocol does not matter and this information is not available therein.

 

I am not sure if you have seen t= he presentation in IETF 108 at OPSAWG and SPRING.

https://www.i= etf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-ty= pe-information-in-ipfix-00.pdf

 

Slide 2 shows Cisco as example v= endor which implemented IE 46, MPLS Label Type identifier. There is an open= ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.=

 

I do understand y= our point that not all the vendors are capable to implement IE 46. But that= ’s not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementa= tion can refer to the right code point. With RFC 5102 the decision has been= made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends = the IE 46 registry with the Segment Routing label protocol code points so w= hen OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX im= plementation can point to the right code point.

 

  • On some nod= es, the same Prefix SID may be learnt via both BGP and IGP – what wou= ld we use/show?

 =

In this case the = IE 46 shows the label protocol which was used to program the FIB.

 =

  • = For that table proposal, it is very difficult and in some cases not possibl= e to different between Prefix and Node and Anycast SID. Many of these types= are control plane elements and we can be sure more get added.
    • =

 =

I fully agree. As= a network operator its still hard to understand the architecture and const= raints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what mak= e sense. By purpose, all available SID types are listed in the draft. This = with the aim to start the discussion in the working groups what is possible= what makes sense. I would be interested to get your and also Jeff's feedback.

 =

In above mentione= d slides I described how TI-LFA application would benefit of visibility in = the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which lab= el protocol was used to forward a particular packet, but also which SID typ= e to further understand the intend why this label is being pushed.

 =

I hope this makes= all sense. Looking forward for reply.

 

Best wishes

Thomas

 

From: Ketan Talaulikar (ketant) <ketant@ci= sco.com>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hanne= s@gredler.at
Cc: lsr@ietf.org; SPRING WG <spring@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

< also copying Spring WG for their review/inputs >

 

Hi Thomas/All,

 

I have reviewed the draft and would like to share a different perspec= tive.

 

What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS – what ma= tters and is more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and= learning the same prefix from different IGPs. IPFIX may be picking this in= formation from a FIB in some implementation where the protocol does not mat= ter and this information is not available therein.

 

On some nodes, the same Prefix SID may be learnt via both BGP and IGP= – what would we use/show?

 

I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding S= ID, SR BGP Peering SID and so on … for the MPLS Label Type.

 

This also takes away the need for the second table that is being prop= osed to a large extent. For that table proposal, it is very difficult and i= n some cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control p= lane elements and we can be sure more get added. Is there really much value= in differentiation between say an Adjacency SID and LAN Adjacency SID?

 

Could we evaluate the implementation overhead and complexity of this = level of categorization/information in IPFIX against their value in flow an= alysis to perhaps consider a middle ground?

 

Thanks,

Ketan

 

From: Lsr <lsr-bounces@iet= f.org> On Behalf Of Thomas.Graf= @swisscom.com
Sent: 31 July 2020 20:52
To: hannes@gredler.at
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Hi Hannes,

 

Thanks a lot for = the feedback. Yes, makes completely sense. Will take it for the next update= ..

 =

Best Wishes<= /o:p>

Thomas=

 

 

From: Hannes Gredler <hannes@= gredler.at>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Thomas,

 

I have one comment/suggestion to Paragraph 4 (IANA C= onsiderations).

 

Please add also a code point for BGP Prefix-SID - it= ’s quite popular in DC deployments.

 

thanks,

 

/hannes

 

On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

 

Dear lsr,

 

I presented the following draft=

 

Export of MPLS Segment Routing = Label Type Information in IP Flow Information Export (IPFIX)

 

at the spring working group at = IETF 108 yesterday

 

and today at OPSAWG where I cal= l for adoption.

 

This draft adds additional segm= ent routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 an= d OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

 

I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link state routing protocols and mpls data plane.

 

I am looking forward to your fe= edback and input.

 

Best Wishes

Thomas Graf

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

 

--_000_ZR0P278MB0122EAF02F60CF871971534489410ZR0P278MB0122CHEP_-- ------=_Part_3001867_1048957526.1597464620978 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE1MDQxMDIxWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCBeNZ6H /Kr/fcvga7rGHkj6L4OyqiW4GxojzIJd1XxawDB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAMXav7ZiZwJck4Fnlh+DGFaBPhgs/Kv6QNsoQm+1M5+8aJtP9EM+Q100n V3H14eFH2Jog1NObZigCkoaV3qesXZdjXN9IaEYm4QTjHomuiwWJKkGxIBIJ1Kz6ArQFMB+oz9af q76oOxfz328o7zJRbNcsIzobkOSS7NXcOHGmfk0czCbW24Ch2toTnRrWiriqkN6dhsZrGdTtEKCg mdDoaasYu5dB3Rthm7Z5VD8guZqZrrBE8YdZXi2BCj+v3F/hBgquTOPgxjIWPiazMo9Z4AESQ8qB 7fXI/84G+OkfA0w0bcvLqEF70gXvYmGaHkcoQsGwBrH+8v89PhLwngMeqQAAAAAAAA== ------=_Part_3001867_1048957526.1597464620978-- From nobody Fri Aug 14 21:17:08 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123AA3A02F9; Fri, 14 Aug 2020 21:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 O6TdbcRiVRDP; Fri, 14 Aug 2020 21:16:56 -0700 (PDT) Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (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 A8FCB3A0140; Fri, 14 Aug 2020 21:16:55 -0700 (PDT) Received: by mail.swisscom.com; Sat, 15 Aug 2020 06:16:49 +0200 Message-ID: <2126606014.3001883.1597465008778@ss002889> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_3001881_337086218.1597465008778" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L2nJEj1rYUN9qk5Mkk7qCqx3S37c0vrEE8/D4pGrGTBUTjw9wxbCpS83vjXxy5Z0Mtfe4in4H6j5X1Q0UAzlogbyQ0pzEguf3KXqZkNn3OZFuEqmKKPU3tT3q5Iis9eWOYuvlDNCIPkfjDB5H/NmD8a2knhMb4kea3znRUgoXxrD0zWpTgGI9kqqpet951IbwSlkQM3hgJbUUnINEKpq+1fhQx3EscR85q/Lcg1QqJYtIafSILrSspYGzSUnuZlgIZZcz9Hm3r31IGvp/JWBLgDeNOxJtizZxquGvkxfke+YzQptoFifLcHp5dW5OudlrxvlDhJfqFjQZX8W1+ZJyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eWSeJmRqzMfPcjilOHZpuJAeyxKHjR1ba/cltBht9Sg=; b=Df3Qzxtz41ZuX+4LBW4Aih7m92Z1WM043cMSdet3HVLKArN0D3lUg3MWBOnnluI2NvRvMgMxE+4cmtikz6+aPk7r0gU/YbBdg6HVOowaIg3lh5J0s3llL3emDmJdicW93NFoEMJBG8iHRq21cZQwICp4/MocXck0hom208jxoS1Qlg+1usA+3XhrsLT3o3PWgy8mijLovX6yBZ7LGYnmcunDjBsbX4enoDcqUtcOxzrl1KYaT1zvfS1fbP8Xav1MO/cHcXzPzFKSVm/cDGuFTnMavz5jK085Eew+289aOR9XBmNYbFclOBV8cVHQbLPPNLvODRdPreRtRE4FJitihA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , , CC: , , Thread-Topic: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AQHWZXpAYzBRFTPdWk2PQZUrWhbqXAAxTF+AAHUFTIACvTCesKkc8WcAgACbjBA= Date: Sat, 15 Aug 2020 04:16:25 +0000 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <1d8fb113-41c8-46cc-bfa3-54c04d406142@Spark> In-Reply-To: <1d8fb113-41c8-46cc-bfa3-54c04d406142@Spark> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-08-15T04:16:22.9284516Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=c528d3d5-2ed9-4fc6-b4b2-66e25729e7bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [178.199.12.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db177093-0374-4d6e-02ae-08d840d1f99e x-ms-traffictypediagnostic: ZR0P278MB0060: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tI7aHJPefHAGzyTyr1t5gBCMeE5cBwKJXjViubWuXDn97nOSkUnU8FsblVGa0uMmW5DleZbwR3HdyrKLpzusRORs8drYLOw8DOycNw0cnUBasJ0vpsmdyTl7p98smjaWpAFXpYZKdQt6gw4WPPL+kgVL6CZe2yUP/mkHfX653Yfzj5I4Hm2DvoqxIyeE65cKNZkdWlwdDqDwfEb9uD9IULN0GyXSW/338kb1R3zDKoDm1gl8iBGkIJpzpjDxzrEa6i74Qp51vjFGY8wP9YyErLz3DkgCYTT48rxWOdeM/4sOvurIw9UEdMKFgeyU4wpkhfMJm2xLgLb+9dAQLSlU1aFrCXS7xNc/hWHTpSzdLSa6TAIwcQ/WvS8MO4lHX1z+WqJ3VQl7kT9pK2/N1KOs+A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(110136005)(19627235002)(8936002)(966005)(33656002)(83380400001)(316002)(186003)(54906003)(7696005)(2906002)(478600001)(166002)(71200400001)(8676002)(10290500003)(53546011)(4326008)(52536014)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(10300500001)(6506007)(9686003)(86362001)(5660300002)(26005)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2pTHAFF7UfeovQajdY4VQ8ZKBb0RhLtaP2xsqJZeKURjAJZqD/lo6T1mxLnxk1mH1N6/TUuqsVD/Ql7kpWab/OPI+9ChR505CD+dptHQvAHy4XUS+FKoWvvI3wlUcWW2KLvI7G2VmnCVaTUgg0/jpNCcVG+RGgDQK+3QjUKnn/PNN1LaLdku8tY2Ga/Cb0sD8YIlu/PFf8mI4Y0IQxvhT2yHDdoTptVHXGQON6rAdyj+f1FIFnn/GkSs083HlCtIlQHIfD0d6sUgBbHU7lm79A4Zneostn//Bk9O37NkR88gZjTmC4spACcZuy9PNogLaE4+gkQvgX3PIqXianuudhVCCiK6YyMMyMG3S46zfvl+CQ7Zi6MeXMjcPOvFTFkv2AE95dqKnkO5xYrGwzBXpob+1MB/MKrOYSE4HnZHZx0YMbfdLoPefy5+2C35u1bWewJs4cmW1ZAdkwT8THi8TZixg4y9c6yCY+AHUNjHxYrzzyLpD9meq3J36f2THQRb1ou73U2/OCETIJwmV4tf0dgRtmGlQ170j/spYo1tgL6RMZSrPF+SuuINUiT0u7u/JRyoBwQ+yKmN4wpgWpNYXAfZVnjPAMEpd39zfhAF3AZqYI9ia78ol8eylYIsgh18WS1HPNM7vbEWvqjPod0SeA== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: db177093-0374-4d6e-02ae-08d840d1f99e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2020 04:16:25.1765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q+wBWwkpWyXnk31VPrhRJcWRpHsSmptjtXnG+cTRWGDpThGxO7aldxHjPNaoCe8mW1qSBKuD+bkVfo/Ygou/MwP2d1B7Eqa01IeHvqLG3H8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0060 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 04:16:59 -0000 ------=_Part_3001881_337086218.1597465008778 Content-Type: multipart/alternative; boundary="_000_ZR0P278MB0122B92247AF355C4662219089410ZR0P278MB0122CHEP_" Content-Language: en-US --_000_ZR0P278MB0122B92247AF355C4662219089410ZR0P278MB0122CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeff, Thanks a lot for the review and feedback. Please refer to my feedback to Ketan where elaborated more about why for la= bel protocol migrations IE 46 is useful. * I'm not sure the FIB is the right place to collect this data though, = since most of meta-data has already been lost (flattened FIB structures oft= en contain bare minimum) and really heavily depends on the implementation. I quote from the previous feedback to Ketan: I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. I hope this makes sense. Looking forward to your feedback. Best Wishes Thomas From: Jeff Tantsura Sent: Friday, August 14, 2020 8:54 PM To: Graf Thomas, INI-NET-DCF ; hannes@gredler.at;= Ketan Talaulikar (ketant) Cc: lsr@ietf.org; SPRING WG Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type In general, I agree with what Ketan said, what's important - it is the valu= e that is being used in forwarding, even if multiple control plane entries = exist, think about IGP migrations, or LDP to SR, where more than 1 protocol= could be distributing the labels/SIDs. I'm not sure the FIB is the right p= lace to collect this data though, since most of meta-data has already been = lost (flattened FIB structures often contain bare minimum) and really heavi= ly depends on the implementation. Cheers, Jeff On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (ketant) >, wrote: < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update... Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_ZR0P278MB0122B92247AF355C4662219089410ZR0P278MB0122CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeff,

 

Thanks a lot for = the review and feedback.

 =

Please refer to m= y feedback to Ketan where elaborated more about why for label protocol migr= ations IE 46 is useful.

 =

  • I’m not sure the FIB is the right place to= collect this data though, since most of meta-data has already been lost (f= lattened FIB structures often contain bare minimum) and really heavily depends on the implementation. <= /li>

 =

I quote from the = previous feedback to Ketan:

 =

I am not sure if = you have seen the presentation in IETF 108 at OPSAWG and SPRING.=

https://www.i= etf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-ty= pe-information-in-ipfix-00.pdf

 

Slide 2 shows Cis= co as example vendor which implemented IE 46, MPLS Label Type identifier. T= here is an open ddts where vendor feasibility has been clarified.

 =

I do understand y= our point that not all the vendors are capable to implement IE 46. But that= ’s not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementation can refer to the right co= de point. With RFC 5102 the decision has been made that MPLS Label Type ide= ntifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-= type just extends the IE 46 registry with the Segment Routing label protocol code points so when OSPFv2/OSPFv3/= ISIS SR TLV is used, and IE 46 is supported, the IPFIX implementation can p= oint to the right code point.

 =

I hope this makes= sense. Looking forward to your feedback.

 =

Best Wishes<= /o:p>

Thomas=

 

From: Jeff Tantsura <jefftant.ietf@gmail.com>
Sent: Friday, August 14, 2020 8:54 PM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hanne= s@gredler.at; Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf= .org>
Cc: lsr@ietf.org; SPRING WG <spring@ietf.org>
Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

In general, I agree with what Ketan said, what’= ;s important - it is the value that is being used in forwarding, even if mu= ltiple control plane entries exist, think about IGP migrations, or LDP to S= R, where more than 1 protocol could be distributing the labels/SIDs. I’m not sure the FIB is the right place to collect = this data though, since most of meta-data has already been lost (flattened = FIB structures often contain bare minimum) and really heavily depends on th= e implementation. 

 

Cheers,

Jeff

On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (k= etant) <ketant=3D= 40cisco.com@dmarc.ietf.org>, wrote:

< also copying Sprin= g WG for their review/inputs >

 

Hi Thomas/All,

 

I have reviewed the dra= ft and would like to share a different perspective.

 

What or how much value = be there on determining whether a SR Prefix SID was signalled/programmed on= a node via OSPFv2/OSPFv3/ISIS – what matters and is more important is that it is a Prefix SID. Hardly any deplo= yments would be running multiple protocols and learning the same prefix fro= m different IGPs. IPFIX may be picking this information from a FIB in some = implementation where the protocol does not matter and this information is not available therein.=

 

On some nodes, the same= Prefix SID may be learnt via both BGP and IGP – what would we use/sh= ow?

 

I would recommend using= SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peering SID and so= on … for the MPLS Label Type.

 

This also takes away th= e need for the second table that is being proposed to a large extent. For t= hat table proposal, it is very difficult and in some cases not possible to different between Prefix and Node and An= ycast SID. Many of these types are control plane elements and we can be sur= e more get added. Is there really much value in differentiation between say= an Adjacency SID and LAN Adjacency SID?

 

Could we evaluate the i= mplementation overhead and complexity of this level of categorization/infor= mation in IPFIX against their value in flow analysis to perhaps consider a middle ground?

 

Thanks,

Ketan=

 

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Thomas.Graf= @swisscom.com
Sent: 31 July 2020 20:52
To: hannes@gredler.at
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type<= /o:p>

 

Hi Hannes,

 

Thanks a lot for the feedback. = Yes, makes completely sense. Will take it for the next update...

 

Best Wishes

Thomas

 

 

From: Hannes Gredler <hannes@gredler.at>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type<= /o:p>

 

Thomas,

 

I have one comment/suggestion to Paragraph 4 (IANA Considerations)= .

 

Please add also a code point for BGP Prefix-SID - it’s quite= popular in DC deployments.

 

thanks,

 

/hannes

 

On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wr= ote:

 

Dear lsr,

 

I presented the following draft

 

Export of MPLS Segment Routing Label Type Inf= ormation in IP Flow Information Export (IPFIX)

 

at the spring working group at IETF 108 yeste= rday

 

and today at OPSAWG where I call for adoption= .

 

This draft adds additional segment routing co= de points for in the IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain further insights = into the MPLS-SR forwarding-plane.

 

I have been asked to not only gather feedback= from spring and opsawg but also from lsr and mpls working groups since these code points are related to link state routing p= rotocols and mpls data plane.

 

I am looking forward to your feedback and inp= ut.

 

Best Wishes

Thomas Graf

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

 

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring

--_000_ZR0P278MB0122B92247AF355C4662219089410ZR0P278MB0122CHEP_-- ------=_Part_3001881_337086218.1597465008778 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE1MDQxNjQ4WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCAHuvDJ RPHrYUFoeBKWeKqRMjqzufCsTjVTXujR0H8K1jB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAbH+WozfxSZK+ae84cHiIE1eKol99xbiPUf3LydY/F1zC7hfIEMj1/MFx Ds3QgnsmYz3i0SoDUriEvTc3mSdxbfjOrrhXpo14kSrVoN/uScfZyL1CSCEXNI4j4e791X/1nfB1 LpQR9g5QRTta/B+JZpDa9/DBr5bMFs/YPaU6jIcsvTEO838vAw1vWoS4FXQYsBQz8/sQS6O6RlhN 87YrlWEYlf5N9+9QCgv5xSmHUkxfNq9mM8EIQqBuDYEcEttZZKrn5fMFR1UnxQEd39i48xin+MRk gc6/GZWUWxhUJVawXrzV/UqAdzN60E7KGG5hmqUaQ46/8c66yoDXXlg4VQAAAAAAAA== ------=_Part_3001881_337086218.1597465008778-- From nobody Fri Aug 14 22:09:15 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C43A0593; Fri, 14 Aug 2020 22:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.487 X-Spam-Level: X-Spam-Status: No, score=-9.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=VouzZLP7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wPfWbKl3 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 9vDIcB0eIVGw; Fri, 14 Aug 2020 22:09:00 -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 434213A053E; Fri, 14 Aug 2020 22:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54555; q=dns/txt; s=iport; t=1597468140; x=1598677740; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=juGqy2eElryLK+CSWhBncJW7yjim34P9vBmyKdOHEtI=; b=VouzZLP7unay/VTF3yKr526kvP1/fxhayUqpovtTKjldUJxEOGkNSjl/ wdhft16KiR08wvwqmdOWQpZqt6tn/lrSx0gAuiv2xHo3Eo6ZHgwDXEIjD 4Hl6Wzj3VHfcOdIiyKJa+mehgO+4pNONVGW55LrH7UNkpzZdaENjfwoks 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AtEJ4kRUQpeEMVTxav5ONeVjYapbV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+DuelbivHNuKflH2cH5MXJvHMDdclKUB?= =?us-ascii?q?kIwYUTkhc7CcGIQUv8MLbxbiM8EcgDMT0t/3yyPUVPXsqrYVrUry6p8j8JAR?= =?us-ascii?q?74MEx+IeGmUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DECQD3bDdf/5NdJa1eHgEBCxIMQIJ?= =?us-ascii?q?tLyMuB3BYLywKhgqBaQONVphngUKBEQNQBQsBAQEMAQEYAQkLAgQBAYFtgl8?= =?us-ascii?q?CgkcCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAgIBARALEBMBASoBAQg?= =?us-ascii?q?DAQ8CAQgRAQMBASEBBgcnCxQDBggBAQQBDQUIEQmCfwQCgX5NAy4BDqhYAoE?= =?us-ascii?q?5iGF0gTSDAQEBBYEzAQMCAoNPAxWCDgMGgTiCcYosGoFBP4EQAUOCTT6COiI?= =?us-ascii?q?BAQEBARaBDAU3DBgHCQKDEoItj1YhIQOJSZxOCoJiiGORXYJ/iVsFk0CSOIF?= =?us-ascii?q?siFaUegIEAgQFAg4BAQWBaiMNWnBwFTuCaRM9FwINjXwjDBeDToUUhUJ0AgE?= =?us-ascii?q?BATICBgoBAQMJfI80AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,315,1592870400"; d="scan'208,217";a="539066753" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Aug 2020 05:08:58 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07F58wEU015047 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 15 Aug 2020 05:08:58 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 15 Aug 2020 00:08:58 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 15 Aug 2020 01:08:57 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 15 Aug 2020 01:08:57 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jA6qvRAKVWBE2giRsTM6KjcyQX8KEItpgJJ9PPC7vRQ1OQVHntUxjDBsvRUumKbi3O/F+ZpYC0E41uVrkLfLfk/YdXYi88MKpKNwwtiit8XdKI2USNF1oh0onk2bNi1HdzlYLLfRWHfQYOd7I8IS5zYsi900KNLxkz2DeNoQnZ/ja/+s1U3utHIWEuxCZ2kP9/W1gpDz8cwYfBuGwVZEx8hPIZ6C9LeeFNTnELyL7dRo1BY/quwMRbvZGu5eoKdL0Q/uLBpqelL/3jRjXZu9ZgNh6R2pzFauSobzq0lmbVl3RqZLA0n4a13CvBCYcbedfAwnjMwVMEh8L+LIa0GuOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ixbx9zlBTaBWK5Jvzz85gTje+VwzmqT56hTTOd02jG0=; b=lrbm4AOJgwzjwv2Ra9AHlfz0Fyo+eS20QfL5WB4KlDtDMS/B+nU7Np4pApnFVVvYftFAifespuY3LAlPv/9KU4BPSy+ZHYpwFZPtEC5bGuCOn0qDWP7gHsI/rBc8NAnJDrlcpS1q5I5ru3J3zLGzYsUXgFxs5NI8WKhzvUlc4FvUEmhrMav80A4S3aDulQPBGBR/vz7kfD8M8kTh8QCdKNTfIDrUq2R5dXxcuhfOnaidmgizGv5Ad8aGeKSfnoDZX6gAazZq2lDzAmb/83Mmel61NpgnyqvIF8vp2OhE4Qe1Bu91M47iUXP/DFHmI8gzOVQtDpkMdcc0CgKIXXy+JA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ixbx9zlBTaBWK5Jvzz85gTje+VwzmqT56hTTOd02jG0=; b=wPfWbKl3hp+dhrpXAInFLQIkmtLt6FK/uclpCHDYV8uZmJvvEBc6rhQRMo2g5AM7H+b0v11EM5d54ee5E2b+HuVfz2EJKHrxoGxsc/MeSdcXSRJc0W6Fkoz3bk/ZELruVWhOHyvEjky/YREA0AxJFF998woP7uJFhchbUbKN69k= Received: from SA0PR11MB4576.namprd11.prod.outlook.com (2603:10b6:806:97::10) by SN6PR11MB3086.namprd11.prod.outlook.com (2603:10b6:805:d6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Sat, 15 Aug 2020 05:08:55 +0000 Received: from SA0PR11MB4576.namprd11.prod.outlook.com ([fe80::b58e:83c8:5174:e727]) by SA0PR11MB4576.namprd11.prod.outlook.com ([fe80::b58e:83c8:5174:e727%2]) with mapi id 15.20.3283.022; Sat, 15 Aug 2020 05:08:55 +0000 From: "Ketan Talaulikar (ketant)" To: "Thomas.Graf@swisscom.com" , "hannes@gredler.at" CC: "lsr@ietf.org" , "spring@ietf.org" , "opsawg@ietf.org" Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AdZktQw6qX35tZ6KQpiaZtLipXAiTwAxTF+AAHUFTIACvTCesAAduZCAAAG4RsA= Date: Sat, 15 Aug 2020 05:08:55 +0000 Message-ID: References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> In-Reply-To: <2022615026.3001869.1597464620979@ss002889> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: swisscom.com; dkim=none (message not signed) header.d=none;swisscom.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7b4ba8b7-9e23-49d7-b07e-08d840d94f62 x-ms-traffictypediagnostic: SN6PR11MB3086: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RMCZ+skfPaBLozHC2HfncYNq84F1a7mXwmE7mTHAzL56hU1TAf6tlnvqYxwJsWH9t2OtN3bNoBl09gtPz2ZsD6mncTWhnNJz5t6Gck0XzHZ72vi997OE/Jg1sxLRfFlH3FIvfS7AFfaptEvwUTfGPNy8yoMMNt/qjqx1OPhv9HEQRRKdsgV9e6kkCWaks2JabdRF/0wh4pMJflw/vRbn3+eWrENdbRMObFOw83m2nUcV5G0nXeIlGZMcmFAuZg4/RYkW621xCnEMQNd70dOoxJzeU+XC6DhAZOYU7z5lCLKAY3bG2Nz5ORDf7dbfKYI8KAcfyJMLcTfB0UiKD060sy+9iDj/OeqSYAu4brvQUciMsZHDcmSroECkhKQpCpNDh0pDPNYD0odA/+yQs1PO2g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR11MB4576.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(136003)(396003)(39860400002)(33656002)(55016002)(186003)(110136005)(19627235002)(54906003)(9686003)(166002)(9326002)(71200400001)(6506007)(76116006)(966005)(2906002)(53546011)(66574015)(66946007)(86362001)(8936002)(64756008)(5660300002)(8676002)(4326008)(26005)(316002)(83380400001)(66476007)(66446008)(478600001)(66556008)(52536014)(7696005)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2ohrc4sV0K/qUm1K9fsyr7P+LcoBOYkONvEd5h9+fQS8wn1xpdPNv/nE++kGnaixBp5XxuVfhlRn2XkMX4ll226k3vIigWiutBmYgStS0/lXod7CZhYX1142no8kjjXMuWXtUaU4DfK6lW38WUhjrEw14C9u9qySMT5vw8bSndI4sURiUPMObmpW/Jd+siDpTv2GnIhfxtSxyzEoH3ioH7F+jFtcKD9mSkNBTDrcthZD6dlZNidfSy62cjdYceUfGT9CjPf04wRkMAfT49eIpOiWema9bJ6ui9UWAI/M8jry9LgHip/9mCG5XT+fkhGeIREgaw8QIk9SnbO7C3gRrtq/mhcNunKQUkxx08geiZ7GgnzXGfOgetwYRpFq3W9gvNFSxfN04Vf3eL+1Nmm74IWViEVoNZZ0mhWLBwyCMgupTMLd/iDFxzoiPHEC6y6UZ/ucD5FORY8/rqkG04RXnN63PWuixFk2uZTJ7zWb28EKxgplOPl+vSrTgQzUcr/Pc4eYCJ4mwCVP8IxgL0tLrah0epMfcq2+pFXiAEIgak0z9FZtwkw4YX3BcWOI9zoY7yf5FJF9u/CgpJs+iCZfqje/6+qf03Nd95XLskCBga025MwP449OAn8yPGOGwRc8S3/og0ct1YuKZUJYoFqouQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR11MB45763F383D707E5B6873963DC1410SA0PR11MB4576namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR11MB4576.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4ba8b7-9e23-49d7-b07e-08d840d94f62 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2020 05:08:55.3797 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EtwGqiaTxrc8JdKNZaqZK6ibzpkuNGNEgi+kuKkV2jOvaG/Amz+0e5VmyoqQ+/RtsDrl7xECa1gqxIvMozYBrw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3086 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 05:09:04 -0000 --_000_SA0PR11MB45763F383D707E5B6873963DC1410SA0PR11MB4576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) ; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters = and is more important is that it is a Prefix SID. Hardly any deployments wo= uld be running multiple protocols and learning the same prefix from differe= nt IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available= therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not p= ossible to different between Prefix and Node and Anycast SID. Many of these= types are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update.. Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_SA0PR11MB45763F383D707E5B6873963DC1410SA0PR11MB4576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Thomas= ,

&nbs= p;

I should = have been more clear in my email.

&nbs= p;

The propo= sal/suggestion is to add the following to the IPFIX MPLS Label type identif= ier registry:

  • SR Prefix SID
  • SR Adjacency SID=
  • SR = Binding SID
  • SR BGP Peering SID
  • … and so on

&nbs= p;

This help= s identification of specific SR-MPLS segment types as well as differentiati= ng them from LDP, RSVP-TE, etc.

&nbs= p;

And my qu= estions were:

  1. What value is provided for= IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?
  2. Wha= t value is provided for IPFIX analysis if it was a Adjacency SID or a LAN A= djacency SID?

&nbs= p;

I am aski= ng for WG to weigh the implementation complexities and overheads with the p= roposed details of SR-MPLS segments in IPFIX against the benefit (if any) t= hat they provide for the flow analysis and monitoring.

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredl= er.at
Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Hi Ketan,

 =

Thank you very mu= ch for the review and feedback.

 =

  • What or how much value be = there on determining whether a SR Prefix SID was signalled/programmed on a = node via OSPFv2/OSPFv3/ISIS – what matters and is more important is that it is a Prefix SID. Hardly any deployments w= ould be running multiple protocols and learning the same prefix from differ= ent IGPs.

&nbs= p;

As Jeff already p= ointed out. Multiple IGP labelling protocols are used  in networks whe= n migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swissc= om when we first discovered this shortcoming in vendor implementations. The= key point here, with these additional IPFIX MPLS Label Type identifiers we= enable the possibility to verify the label protocol migration without taking the label value into the consi= deration.

&nbs= p;

  • IPFIX may be picking this = information from a FIB in some implementation where the protocol does not m= atter and this information is not available therein.

&nbs= p;

I am not sure if = you have seen the presentation in IETF 108 at OPSAWG and SPRING.=

https://www.ietf.org/proce= edings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-informatio= n-in-ipfix-00.pdf

&nbs= p;

Slide 2 shows Cis= co as example vendor which implemented IE 46, MPLS Label Type identifier. T= here is an open ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.

 =

I do understand y= our point that not all the vendors are capable to implement IE 46. But that= ’s not the point about the IPFIX IE registry. The IE registry enables that an I= PFIX implementation can refer to the right code point. With RFC 5102 the de= cision has been made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type ju= st extends the IE 46 registry with the Segment Routing label protocol code = points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, t= he IPFIX implementation can point to the right code point.

&nbs= p;

  • On some nodes, the same Pr= efix SID may be learnt via both BGP and IGP – what would we use/show?=

 

In this case the IE 46 shows the= label protocol which was used to program the FIB.

 

  • For that table = proposal, it is very difficult and in some cases not possible to different = between Prefix and Node and Anycast SID. Many of these types are control pl= ane elements and we can be sure more get added.

 =

I fully agree. As= a network operator its still hard to understand the architecture and const= raints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what mak= e sense. By purpose, all available SID types are listed in the draft. This = with the aim to start the discussion in the working groups what is possible= what makes sense. I would be interested to get your and also Jeff's feedback.

 =

In above mentione= d slides I described how TI-LFA application would benefit of visibility in = the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which lab= el protocol was used to forward a particular packet, but also which SID typ= e to further understand the intend why this label is being pushed.

 =

I hope this makes= all sense. Looking forward for reply.

 =

Best wishes<= /o:p>

Thomas=

 =

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
Cc: lsr@ietf.org; SPRING WG <= spring@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

< also= copying Spring WG for their review/inputs >

&nbs= p;

Hi Thomas= /All,

&nbs= p;

I have re= viewed the draft and would like to share a different perspective.

&nbs= p;

What or h= ow much value be there on determining whether a SR Prefix SID was signalled= /programmed on a node via OSPFv2/OSPFv3/ISIS – what matters and is mo= re important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and learning the same = prefix from different IGPs. IPFIX may be picking this information from a FI= B in some implementation where the protocol does not matter and this inform= ation is not available therein.

&nbs= p;

On some n= odes, the same Prefix SID may be learnt via both BGP and IGP – what w= ould we use/show?

&nbs= p;

I would r= ecommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peer= ing SID and so on … for the MPLS Label Type.

&nbs= p;

This also= takes away the need for the second table that is being proposed to a large= extent. For that table proposal, it is very difficult and in some cases no= t possible to different between Prefix and Node and Anycast SID. Many of these types are control plane elements a= nd we can be sure more get added. Is there really much value in differentia= tion between say an Adjacency SID and LAN Adjacency SID?<= /p>

&nbs= p;

Could we = evaluate the implementation overhead and complexity of this level of catego= rization/information in IPFIX against their value in flow analysis to perha= ps consider a middle ground?

&nbs= p;

Thanks,

Ketan

&nbs= p;

From: Lsr <lsr-bounces@iet= f.org> On Behalf Of Thomas.Graf= @swisscom.com
Sent: 31 July 2020 20:52
To: hannes@gredler.at
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Hi Hannes,

 =

Thanks a lot for = the feedback. Yes, makes completely sense. Will take it for the next update= ..

 =

Best Wishes<= /o:p>

Thomas=

 

 =

From: Hannes Gredler <hannes@= gredler.at>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Thomas,

 

I have one comment/suggestion t= o Paragraph 4 (IANA Considerations).

 

Please add also a code point fo= r BGP Prefix-SID - it’s quite popular in DC deployments.

 

thanks,

 

/hannes

=  

On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

 

Dear lsr,

 

I presented the following draft=

 

Export of MPLS Segment Routing = Label Type Information in IP Flow Information Export (IPFIX)

 

at the spring working group at = IETF 108 yesterday

 

and today at OPSAWG where I cal= l for adoption.

 

This draft adds additional segm= ent routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 an= d OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

 

I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link state routing protocols and mpls data plane.

 

I am looking forward to your fe= edback and input.

 

Best Wishes

Thomas Graf

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

 

--_000_SA0PR11MB45763F383D707E5B6873963DC1410SA0PR11MB4576namp_-- From nobody Fri Aug 14 23:01:17 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67213A044F; Fri, 14 Aug 2020 23:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 EMcRfxT-hdk2; Fri, 14 Aug 2020 23:01:09 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 0FA863A07F9; Fri, 14 Aug 2020 23:01:09 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id q13so5737744vsn.9; Fri, 14 Aug 2020 23:01:09 -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=jyc84fiTdO8/jRNPz5IVO6+yNwzxqZAuhRrGDM1VBPo=; b=JCPiz5sDABNh8xRNcxwAseW8ADybnGqqqQLUsrpTndwun/MVl31T7SyktYSQliGvSJ FM6p24etXjoEIi5U6Tx3Uy7fmUNbLzDr7YG4hTDFoiz5E7QxuTdlslpXZmTM7UsPO5Zp Amr8s08/OR1lbXKPnNCP8VZvjhL9q0p4fsH44o/CSQ1NWqvFViDJCCwX5cReDZQFBWYU eBAaP2kUyEV2Ekk6hL8GGJyAjt0YaqgsoKKu2NbVDu6LRvuMp+X4FGnOsQlWvygUGvsB L+cnC8e+qWK4HMbBt83STT0r1DvdPsFCHeVuFJJoZIzBvJTQvesMahdUJBvUoAVupYJB pASw== 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=jyc84fiTdO8/jRNPz5IVO6+yNwzxqZAuhRrGDM1VBPo=; b=Ow8kRz69k5wMdF1x/oOa94415oNEye4E7t4shKhGmgjPFKoq6EccuVqivG1MOhI/Pk vToEQWvxgE86KoEiIUmJwPrc0XF/k6M8yQeos9kFaExBPgr5o4yjPjTzD7KnT5BwdUny JK2R9GbISi1Z24y2ebhv4u8tkg5DSVWn1qZYJg4mGbEzcHsZKe3Y8ylY+yGT+t0g3y+U gn7KopIBd5YyMaGZVOeaZ2Q/Wa3xLNrBdU24yERArg9lQ7bhuVRteokZgqZHwEo7y2I8 9cEEWdbbKcl7Db5lNTuZ/WE8I0EVO1PWZPw/liCbBo8pYQ0FR6ArfNgDbmtoFRJblEvk dh1Q== X-Gm-Message-State: AOAM532eMnR9PNtIgpARG6xDOJybtOIItZw+l9aahneTRjkYnaS9Cl1Z dix4WSqdXcRaAr6m6piXiQo7KCdjvl661GTeUzc= X-Google-Smtp-Source: ABdhPJzNLXw0PIbGmguBCf0pqb1hYO6D1EbnanHOpp6zUpwUUmvpQ49dfcymbmyC/htsw/JdH70GN6OiDcVRZDUJBec= X-Received: by 2002:a67:f941:: with SMTP id u1mr3553088vsq.128.1597471267052; Fri, 14 Aug 2020 23:01:07 -0700 (PDT) MIME-Version: 1.0 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> In-Reply-To: From: Gyan Mishra Date: Sat, 15 Aug 2020 02:00:56 -0400 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: "Thomas.Graf@swisscom.com" , "hannes@gredler.at" , "lsr@ietf.org" , "opsawg@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000695ff105ace443c3" Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 06:01:12 -0000 --000000000000695ff105ace443c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ketan >From an operations perspective at the end of the day the job of IPFIX is to support the various data plane encapsulation types so that the flow graph and fields flow data records can be constructed. So here as long as you are able to capture the flow records, and record the flows over the SR-MPLS data plane then to that end whatever is required to meet that objective to construct capture and record all flows. So that being said I think as long as the data plane encapsulation is captured and supported for SR-MPLS label SID SRGB is supported then I think the objective of the draft is solved. I don=E2=80=99t think adding control= plane complexity into the flow records is necessary to accomplish the objective. I see the point of being able to differentiate topmost label underlay of MPLS label or TE from SR-MPLS. That is as far as you need to go are my thoughts. Kind Regards Gyan On Sat, Aug 15, 2020 at 1:09 AM Ketan Talaulikar (ketant) wrote: > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > I should have been more clear in my email. > > > > > > The proposal/suggestion is to add the following to the IPFIX MPLS Label > type identifier registry: > > > > > > - SR Prefix SID > - SR Adjacency SID > - SR Binding SID > - SR BGP Peering SID > - =E2=80=A6 and so on > > > > > > > This helps identification of specific SR-MPLS segment types as well as > differentiating them from LDP, RSVP-TE, etc. > > > > > > And my questions were: > > > > > > 1. What value is provided for IPFIX analysis if the SR Prefix SID was > being signalled via OSPF or ISIS? > > 2. What value is provided for IPFIX analysis if it was a Adjacency SID > or a LAN Adjacency SID? > > > > > > > I am asking for WG to weigh the implementation complexities and overheads > with the proposed details of SR-MPLS segments in IPFIX against the benefi= t > (if any) that they provide for the flow analysis > > and monitoring. > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* Thomas.Graf@swisscom.com > > > > > *Sent:* 15 August 2020 09:40 > > > *To:* Ketan Talaulikar (ketant) ; hannes@gredler.at > > > *Cc:* lsr@ietf.org; spring@ietf.org; opsawg@ietf.org > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Ketan, > > > > > > Thank you very much for the review and feedback. > > > > > > > > > - What or how much value be there on determining whether a SR Prefix > SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80= =93 what matters > > and is more important is that it is a Prefix SID. Hardly any > deployments would be running multiple protocols and learning the same > prefix from different IGPs. > > > > > > > > As Jeff already pointed out. Multiple IGP labelling protocols are used i= n > networks when migrations are ongoing. Usually in a life cycle. Migrating > > from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at > Swisscom when we first discovered this shortcoming in vendor > implementations. The key point here, with these additional IPFIX MPLS Lab= el > Type identifiers we enable the possibility to verify > > the label protocol migration without taking the label value into the > consideration. > > > > > > > > > - IPFIX may be picking this information from a FIB in some > implementation where the protocol does not matter and this information= is > not available > > therein. > > > > > > > I am not sure if you have seen the presentation in IETF 108 at OPSAWG and > SPRING. > > > > https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-m= pls-sr-label-type-information-in-ipfix-00.pdf > > > > > > Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label > Type identifier. There is an open ddts where vendor feasibility has > > been clarified. Ping me off the list when you like to have more details. > > > > > > I do understand your point that not all the vendors are capable to > implement IE 46. But that=E2=80=99s not the point about the IPFIX IE regi= stry. > > The IE registry enables that an IPFIX implementation can refer to the > right code point. With RFC 5102 the decision has been made that MPLS Labe= l > Type identifier > > make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type > just extends the IE 46 registry with the Segment Routing label protocol > code points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is > supported, the IPFIX implementation can point > > to the right code point. > > > > > > > > > - On some nodes, the same Prefix SID may be learnt via both BGP and > IGP =E2=80=93 what would we use/show? > > > > > > > In this case the IE 46 shows the label protocol which was used to program > the FIB. > > > > > > > > > > - > > For that table proposal, it is very difficult and in some cases not > possible to different between Prefix and Node and Anycast SID. Many of > these types are control plane elements and we can be sure more > > get added. > > > > > > > I fully agree. As a network operator its still hard to understand the > architecture and constraints within a router. When monitoring capabilitie= s > > are discussed at IETF, this is the usual topic. What is possible, what > make sense. By purpose, all available SID types are listed in the draft. > This with the aim to start the discussion in the working groups what is > possible what makes sense. I would be interested > > to get your and also Jeff's feedback. > > > > > > In above mentioned slides I described how TI-LFA application would benefi= t > of visibility in the FIB by showing where Adj-SID was used. This > > should be a simple example why it make sense not only to look at which > label protocol was used to forward a particular packet, but also which SI= D > type to further understand the intend why this label is being pushed. > > > > > > > I hope this makes all sense. Looking forward for reply. > > > > > > Best wishes > > > Thomas > > > > > > > > > > *From:* Ketan Talaulikar (ketant) > > > > > *Sent:* Friday, August 14, 2020 7:35 PM > > > *To:* Graf Thomas, INI-NET-DCF ; > > hannes@gredler.at > > > *Cc:* lsr@ietf.org; SPRING WG > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > < also copying Spring WG for their review/inputs > > > > > > > Hi Thomas/All, > > > > > > I have reviewed the draft and would like to share a different perspective= . > > > > > > What or how much value be there on determining whether a SR Prefix SID wa= s > signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matt= ers and is > more important is that it is a Prefix SID. Hardly > > any deployments would be running multiple protocols and learning the same > prefix from different IGPs. IPFIX may be picking this information from a > FIB in some implementation where the protocol does not matter and this > information is not available therein. > > > > > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 > what would we use/show? > > > > > > I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, > SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type. > > > > > > This also takes away the need for the second table that is being proposed > to a large extent. For that table proposal, it is very difficult and in > some cases not possible to different between Prefix > > and Node and Anycast SID. Many of these types are control plane elements > and we can be sure more get added. Is there really much value in > differentiation between say an Adjacency SID and LAN Adjacency SID? > > > > > > Could we evaluate the implementation overhead and complexity of this leve= l > of categorization/information in IPFIX against their value in flow analys= is > to perhaps consider a middle ground? > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* Lsr > > *On Behalf Of *Thomas.Graf@swisscom.com > > > *Sent:* 31 July 2020 20:52 > > > *To:* hannes@gredler.at > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Hannes, > > > > > > Thanks a lot for the feedback. Yes, makes completely sense. Will take it > for the next update... > > > > > > Best Wishes > > > Thomas > > > > > > > > > > > > > > > > > *From:* Hannes Gredler > > > > > *Sent:* Wednesday, July 29, 2020 9:31 AM > > > *To:* Graf Thomas, INI-NET-DCF > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Thomas, > > > > > > > > > > > > I have one comment/suggestion to Paragraph 4 (IANA Considerations). > > > > > > > > > > > > > > Please add also a code point for BGP Prefix-SID - it=E2=80=99s quite popu= lar in DC > deployments. > > > > > > > https://tools.ietf.org/html/rfc8669 > > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > /hannes > > > > > > > > > > > > > > > > On 28.07.2020, at 10:11, > > Thomas.Graf@swisscom.com wrote: > > > > > > > > > > > > Dear lsr, > > > > > > > > > > > > > > I presented the following draft > > > > > > > > > > > > > > Export of MPLS Segment Routing Label Type Information in IP Flow > Information Export (IPFIX) > > > > > > > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 > > > > > > > > > > > > > > > at the spring working group at IETF 108 yesterday > > > > > > > > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-inf= ormation-export-ipfix-00.pdf > > > > > > > > > > > > > > > and today at OPSAWG where I call for adoption. > > > > > > > > > > > > > > This draft adds additional segment routing code points for in the IANA > IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID type= s > to gain > > further insights into the MPLS-SR forwarding-plane. > > > > > > > > > > > > > > I have been asked to not only gather feedback from spring and opsawg but > also from lsr and mpls working groups since these code points are related > to link > > state routing protocols and mpls data plane. > > > > > > > > > > > > > > I am looking forward to your feedback and input. > > > > > > > > > > > > > > Best Wishes > > > > > > > Thomas Graf > > > > > _______________________________________________ > > > 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 > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000695ff105ace443c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ketan=C2=A0

From an operations perspective at the end of the day t= he job of IPFIX is to support the various data plane encapsulation types so= that the flow graph and fields flow data records can be constructed. =C2= =A0

So here as long as y= ou are able to capture the flow records, and record the flows over the SR-M= PLS data plane then to that end whatever is required to meet that objective= to construct capture and record all flows. =C2=A0
<= br>
So that being said I think as long as the data p= lane encapsulation is captured and supported for SR-MPLS label SID SRGB is = supported then I think the objective of the draft is solved.=C2=A0 I don=E2= =80=99t think adding control plane complexity into the flow records is nece= ssary to accomplish the objective.

I see the point of being able to differentiate topmost label und= erlay of MPLS label or TE from SR-MPLS. =C2=A0

<= /div>
That is as far as you need to go are my thoughts.

Kind Regards=C2=A0

Gyan=C2=A0
=C2=A0

On Sat, Aug 15, 2020 at 1:09 AM Ketan Talaulikar (ketant) &= lt;ketant=3D40cisco.com@dmarc= .ietf.org> wrote:


=













Hi Thomas= ,



=C2= =A0



I should have bee= n more clear in my email.



=C2=A0



<= span>The proposal/suggestion is to add the following to the IPFIX MPLS Labe= l type identifier registry:





  • SR = Prefix SID
  • SR = Adjacency SID
  • = SR Binding SID
  • SR BGP Peering SID
  • = =E2=80=A6 and so on


=C2=A0



This helps identification of specific SR-MPLS segment types as w= ell as differentiating them from LDP, RSVP-TE, etc.

=C2=A0


And my questions were:<= /p>



  1. What value is provided for IPFIX analysis i= f the SR Prefix SID was being signalled via OSPF or ISIS?

    =
  2. What value is provided = for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?=


=C2=A0<= u>



I am asking for WG to= weigh the implementation complexities and overheads with the proposed deta= ils of SR-MPLS segments in IPFIX against the benefit (if any) that they pro= vide for the flow analysis

and monitoring.

=

=C2=A0


Thanks,



Ketan



=C2=A0






<= br>

From: = Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>




= Sent: 15 August 2020 09:40


To: Ketan Talaulikar (keta= nt) <ketant@cisco.= com>; hannes@= gredler.at


Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org


Subject: RE: [Lsr] draft-tgraf= -ipfix-mpls-sr-label-type







=C2=A0



Hi Ketan,



= =C2=A0



Thank you very much for the review and feedback.



=C2=A0





  • What or how m= uch value be there on determining whether a SR Prefix SID was signalled/pro= grammed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matters

    and= is more important is that it is a Prefix SID. Hardly any deployments would= be running multiple protocols and learning the same prefix from different = IGPs.



= =C2=A0



As Jeff already pointed out. Multiple IGP label= ling protocols are used =C2=A0in networks when migrations are ongoing. Usua= lly in a life cycle. Migrating

from LDP to OSPFv2/OSPFv3/ISIS SR TL= V. This is/was also the case at Swisscom when we first discovered this shor= tcoming in vendor implementations. The key point here, with these additiona= l IPFIX MPLS Label Type identifiers we enable the possibility to verify
=
the label protocol migration without taking the label value into the c= onsideration.



= =C2=A0





  • IPFIX may be picking thi= s information from a FIB in some implementation where the protocol does not= matter and this information is not available

    therein.


=C2=A0=



https:= //www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-l= abel-type-information-in-ipfix-00.pdf



<= p class=3D"MsoNormal">=C2=A0



Slide 2 shows Cisco as ex= ample vendor which implemented IE 46, MPLS Label Type identifier. There is = an open ddts where vendor feasibility has

been clarified. Ping me o= ff the list when you like to have more details.


=C2= =A0



I do understand your point that not all the vendors are capable= to implement IE 46. But that=E2=80=99s not the point about the IPFIX IE re= gistry.

The IE registry en= ables that an IPFIX implementation can refer to the right code point. With = RFC 5102 the decision has been made that MPLS Label Type identifier

= make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type ju= st extends the IE 46 registry with the Segment Routing label protocol code = points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, t= he IPFIX implementation can point

to the right code point.



=C2=A0





  • On some nodes, the same Prefix SID may be lear= nt via both BGP and IGP =E2=80=93 what would we use/show?


=C2= =A0



In = this case the IE 46 shows the label protocol which was used to program the = FIB.



=C2=A0






  • For that table proposal, it is very d= ifficult and in some cases not possible to different between Prefix and Nod= e and Anycast SID. Many of these types are control plane elements and we ca= n be sure more

    get added.


    • = =C2=A0



    I fully agree. As a network operator its still hard to under= stand the architecture and constraints within a router. When monitoring cap= abilities

    are discussed at IETF, this is the usual topic. What is p= ossible, what make sense. By purpose, all available SID types are listed in= the draft. This with the aim to start the discussion in the working groups= what is possible what makes sense. I would be interested

    to get yo= ur and also Jeff's feedback.



    =C2=A0



    In = above mentioned slides I described how TI-LFA application would benefit of = visibility in the FIB by showing where Adj-SID was used. This

    shoul= d be a simple example why it make sense not only to look at which label pro= tocol was used to forward a particular packet, but also which SID type to f= urther understand the intend why this label is being pushed.

    =



    =C2=A0



    I hope this makes all sense. Looking forward= for reply.



    =C2=A0



    Best wishes=



    =C2=A0






    From: Ketan Talaulikar (ketant) <ketant@cisco.com>


    <= br>
    Sent: Friday, August 14, 2020 7:35 PM


    To: G= raf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;

    hannes@gredler.at


    Cc:= lsr@ietf.org; SP= RING WG <spring@iet= f.org>


    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-s= r-label-type







    =C2=A0


    < also copying Spring WG for their re= view/inputs >



    =C2=A0



    Hi T= homas/All,



    = =C2=A0



    I have rev= iewed the draft and would like to share a different perspective.<= /u>



    =C2=A0



    What or how much value be there= on determining whether a SR Prefix SID was signalled/programmed on a node = via OSPFv2/OSPFv3/ISIS =E2=80=93 what matters and is more important is that= it is a Prefix SID. Hardly

    any deployments would be running multip= le protocols and learning the same prefix from different IGPs. IPFIX may be= picking this information from a FIB in some implementation where the proto= col does not matter and this information is not available therein.



    =C2=A0



    On some nodes, the same Prefi= x SID may be learnt via both BGP and IGP =E2=80=93 what would we use/show?<= u>



    =C2=A0<= u>



    I would recommend usi= ng SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peering SID and = so on =E2=80=A6 for the MPLS Label Type.



    =C2=A0



    This also takes away the need for the second table tha= t is being proposed to a large extent. For that table proposal, it is very = difficult and in some cases not possible to different between Prefix
    and Node and Anycast SID. Many of these types are control plane elements = and we can be sure more get added. Is there really much value in differenti= ation between say an Adjacency SID and LAN Adjacency SID?



    =C2=A0

    =

    Could we evaluate the implementation o= verhead and complexity of this level of categorization/information in IPFIX= against their value in flow analysis to perhaps consider a middle ground?<= u>



    =C2=A0<= u>



    Thanks,=



    Ketan<= /p>

    =C2=A0


    =




    From: Lsr <lsr-bounces@ietf.org>

    O= n Behalf Of Thomas.Graf@swisscom.com


    Sent: 31 July 2020 20:52<= br>

    To: hannes@gredler.at


    Cc: lsr@ietf.org


    Subject: Re: [Lsr] = draft-tgraf-ipfix-mpls-sr-label-type



    =



    =C2=A0


    Hi Hannes,



    =C2=A0



    Thanks a lot for the feedback. Yes, makes = completely sense. Will take it for the next update...<= /p>

    =C2=A0



    Best Wishes



    Thomas

    <= br>


    = =C2=A0





    =C2=A0



    =




    From: Hannes Gredler <hannes@gredler.at>



    Sent: Wednesday, July 29, 2020 9:31 AM


    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>


    Cc: lsr@ietf.org

    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type







    =C2=A0



    Thomas,




    =

    =C2=A0=







    I have one comment/suggestion to Paragraph 4 (IANA Considerations).=







    =C2=A0



    <= br>


    Please add = also a code point for BGP Prefix-SID - it=E2=80=99s quite popular in DC dep= loyments.









    =C2=A0






    thanks,<= /p>





    =C2=A0







    /hannes

    <= br>






    =C2=A0<= /p>


    <= br>


    On 28.07.2020, = at 10:11,
    Thomas.Graf@swisscom.com     wrote:





    =C2=A0







    Dear lsr,





    =C2=A0







    I pre= sented the following draft=







    =C2=A0



    =




    Expo= rt of MPLS Segment Routing Label Type Information in IP Flow Information Ex= port (IPFIX)









    <= span lang=3D"DE-CH" style=3D"font-size:10.0pt;font-family:"Trebuchet M= S",sans-serif">=C2=A0=







    at the spring working group at IETF 108 yesterday









    =C2=A0







    and t= oday at OPSAWG where I call for adoption.







    =C2=A0







    This draft adds additional segment routing code points for in th= e IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID= types to gain

    further insights into the MPLS-SR forwarding-plane.<= /span>





    <= div>

    =C2=A0







    =

    I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link

    state routing prot= ocols and mpls data plane.    =







    =C2=A0



    =




    I am= looking forward to your feedback and input.=







    =C2=A0<= /span>







    Best Wishes<= /p>





    Thomas Graf


    =


    _________________= ______________________________


    Lsr mailing list


    Lsr@ietf.org


    https://www.ietf.org/mailman/listinfo/lsr








    =C2=A0











_= ______________________________________________

Lsr mailing list
<= br>Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

--

=

Gyan Mishra<= /p>

Network Solution= s Architect= =C2=A0

M 301 502-1347
13101 Colum= bia Pike=C2=A0
Silver Spring, MD


--000000000000695ff105ace443c3-- From nobody Fri Aug 14 23:02:35 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F993A0800; Fri, 14 Aug 2020 23:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 4_tHRxmnhA0e; Fri, 14 Aug 2020 23:02:23 -0700 (PDT) Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 299833A07FC; Fri, 14 Aug 2020 23:02:21 -0700 (PDT) Received: by mail.swisscom.com; Sat, 15 Aug 2020 08:02:14 +0200 Message-ID: <696872714.3003081.1597471334092@ss002889> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_3003079_1519164914.1597471334092" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IF7MFzCqAAATY/NPvPoAJ5GtIfIj10XdDgq8LvJKWDLuA9FZZ59mhRtTtLqDc8nV80QpJ8t9quawsl4GbNQqDouaRvKyHmisWmWi0z+6j7v5x5ZqVxwR9oMEmyeaybDiH0OasUKM+pHM5xiI4bgnc+N40ykJROj0atrFBiWVn+lUbWi649554oUo9yT+TYDz3u/sjtnH4WU8cNvMOROkQzllIqWWS0wk9+x8FgiyL9hVLwK/1XoDTzH/X7EWS4RbIC0H4eN7/dyK4HE8isaIkQNzsJEIkAQzf0mSeRtGYD7hoOSeiTx2PrHGIf+FivwnSkvvWX+wkzk/JYKJOQk2yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nt6Hw7DE1yGVTQWE0T0oMMWizFBfsyOlitciCN8QtmU=; b=nrh/kcJvlaDYq9yVcjIURLTTcxuikL43nTrT0Q6k64KkEFQrRS1kJbDxTs5EGosXwb/Gz1GF3bJr9/O4ugsCCpMS4Z3k02ZdOsL7/u9QH3dP0oTwIhX8kJQKLF+t3FHmp2HrEAGdwAzRrGV2+19RZOKcV7KiiWmDEpHubEUpEIRgbn+Fq4jvIpDoHz7wxXp5gQ7ngOfoxA9oH9Lmg75YgQYRdPqczOFZuEiiEEpbUMevmlaVXnqceeFp9tcJcmimjCEx18A2FHoZM8+EP2urI5mEkxYdqfH6lailOEzSncUp8pYIleiEKxO61IAHZZMmcwcxIawBJfzRAZllkownIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , CC: , , Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AQHWZXpAYzBRFTPdWk2PQZUrWhbqXAAxTF+AAHUFTIACvTCesAAduZCAAAG4RsCpHKOrAA== Date: Sat, 15 Aug 2020 06:01:29 +0000 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [178.199.12.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a308be3-cfef-4661-6857-08d840e0a73e x-ms-traffictypediagnostic: ZR0P278MB0028: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DAN970WY4KWNWS1vMF6bpPbJ8qGuK+kBQidGWrSRQYT/zJ09LogjXirbjMp8dVp/zcT5iVi9Hl5MKJtG/OYxnaM8Qvm7dKQRfxr+0/M5axnX/7/8Juv4rRMOZJ4JyZg78j4jPapDaErZvxdBfKQPgzVA96nH1DPy3iMSDDKyUpOZiZXifqBt094Q00W15eY474vvUnu6YoNhX+dWW9gIdCl/+kUuuQrr0KWPI2NOMHRHD6njmIiwQmkUPGE38VCNtu/cihft5ar/Kk/Bhk7hBfPdeHn/u1co67/Ddc2ADg5WW554trvklHFGDKtZa9BROLMSBLkQo6XrSRHowv8cCY2u/k/cKf6PG/ynmooZ6ASidgBgEMX1hgiunco5P3MFFJuqlIFQ6WyH1Bb4MdHlJg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(136003)(39860400002)(376002)(366004)(30864003)(4326008)(52536014)(33656002)(478600001)(83380400001)(186003)(9686003)(6506007)(53546011)(10290500003)(8676002)(55016002)(7696005)(166002)(19627235002)(66574015)(66446008)(64756008)(66476007)(66556008)(26005)(316002)(10300500001)(86362001)(66946007)(76116006)(2906002)(110136005)(5660300002)(54906003)(71200400001)(8936002)(966005)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YRP3adxC2Dp8F1svmEqMM8nUFib4C4YfpLXdCedpnSKtoFaLBPlG2BORrBwpBRqe0BuZPEBk/6DkHecSVPdD8nKMS9N5/XWmpGTXs4gw70FCJOlGLpFq9idQfWgHqbHSUJiRFh3bKsSFlCHZRzDEcJC2BhkMqRd5QmtAhJ8QG1rNtVNA8z1howHu39uTOeJhORBl+LBqVeVchCD++ieCalidM2MiUkvoFWWcb+Km9XU8RbkE6QiI19VCIsFVJmgafDOjDQ8jJ08bd+YAr9pM9/0qRjsajghx6GL/BG9IIlA05B51se7DAvcJKuntInxsHda0rSqYk+DPi7VdhGpl3AQCtYNNx5doCxlMpnX6NUE3rg9AFRg6ZikSu4m+8AsV0NXjGeI6HNwzL7kaVtSK6QmrBuQ7pOGuN2CdwKzOKRp3wkJiZKgL0Ohy8358SvV8FoJQyOa1bjeyvfqxCe4uuPQv+12dnSAQuDtkBfZrG2o+Q9sesj50VpBsWXd3yDlpzCcS2L1EJTxU15qQqWP8R85YOQQZmakFb4ie3FDbQxY0b4giz1dKv0hjhUacY8clDHwOaCxTS5UiX9d2n+/QPae9WDIP6CeiLrZREdnN0feTt2Qcq8P0wfBDn7eI8tyHM3IxVcdQ5yaA/d/box5PoQ== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3a308be3-cfef-4661-6857-08d840e0a73e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2020 06:01:29.4218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PfMRXJDWOl1Pc1lFdKoAWqtcoTSE4fdJPg+AYWTNcU/cOXx/rhEuhiNFMleMJqZpRQczBb19mpoPozfbRFfR1RJEoVk8k5BSHeKwV6e61Zs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0028 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 06:02:26 -0000 ------=_Part_3003079_1519164914.1597471334092 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB012599E0B7C0A68BDE83623B89410ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB012599E0B7C0A68BDE83623B89410ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, * This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. * What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? It is important to distinguish between intend and result. If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets = with the label distribution protocol which needs to be removed or not. IE46= enables that by looking at the result of the forwarded traffic and not at = the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section= -3, describes the context. * What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decision= s, the node can change the forwarding by pushing additional labels. With IP= FIX SrSidType we are able to cover this dimension in IPFIX. Enabling to ana= lyze the result of this decision. The example with " Adjacency SID or a LAN= Adjacency SID" is not very useful because the difference of the two is the= topology among the adjacency. If you compare " Adjacency SID with Prefix S= ID", that makes much more sense. Since it describes that a particular adjac= ency is chosen to forward the packet instead of a prefix. If IE 89, Forward= ingStatus is drop, we understand that result of that decision lead to the d= rop and this enables to narrow down forwarding issues in segment routing ne= tworks more efficiently and quickly. ? am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a bette= r understanding where your fear is coming from. I would appreciate if you c= ould differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= . Best wishes Thomas From: Ketan Talaulikar (ketant) Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF ; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters = and is more important is that it is a Prefix SID. Hardly any deployments wo= uld be running multiple protocols and learning the same prefix from differe= nt IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available= therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not p= ossible to different between Prefix and Node and Anycast SID. Many of these= types are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update.. Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_ZRAP278MB012599E0B7C0A68BDE83623B89410ZRAP278MB0125CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan,

 

  • This helps = identification of specific SR-MPLS segment types as well as differentiating= them from LDP, RSVP-TE, etc.

 =

To be precise, th= e existing MPLS Label Type identifier differentiates from LDP, RSVP-TE. Not= the new SrSidType IPFIX IE being proposed.

 

  • What value = is provided for IPFIX analysis if the SR Prefix SID was being signalled via= OSPF or ISIS?

 

It is important t= o distinguish between intend and result.

 

If you migrate fr= om one label distribution protocol to another, a network operator want's to= understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or = not. IE46 enables that by looking at the result of the forwarded traffic an= d not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context.

 

  • What value = is provided for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency= SID?

 =

Quote from RFC840= 2. "Segment Routing (SR) leverages the source routing paradigm". = Means that not the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels= . With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabli= ng to analyze the result of this decision. The example with " Adjacenc= y SID or a LAN Adjacency SID" is not very useful because the difference of the two is the topology among the ad= jacency. If you compare " Adjacency SID with Prefix SID", that ma= kes much more sense. Since it describes that a particular adjacency is chos= en to forward the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we understand that result of that deci= sion lead to the drop and this enables to narrow down forwarding issues in = segment routing networks more efficiently and quickly.

 =

&Osla= sh;  am asking for WG to weigh the implementation complexities

 =

For the WG and me= , I would be important if you can describe more detailed what you mean with implementa= tion complexities. I would like to have a better understanding where your f= ear is coming from. I would appreciate if you could differentiate between MPLS Label Type identifier, IE46,= from which label protocol the label was coming from and SrSidType which SI= D type was used.

 =

Best wishes<= /o:p>

Thomas=

 =

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hanne= s@gredler.at
Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Hi Thomas,

 

I should have been more clear in my email.

 

The proposal/suggestion is to add the following to the IPFIX MPLS Lab= el type identifier registry:

  • SR Prefix S= ID
  • SR Adjacency SID
  • SR Binding SID<= /li>
  • SR BGP = Peering SID
  • … and so on

 

This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc.

 

And my questions were:

  1. What value = is provided for IPFIX analysis if the SR Prefix SID was being signalled via= OSPF or ISIS?
  2. What value is provided for IPFIX analysis if it was a Adjacency= SID or a LAN Adjacency SID?

 

I am asking for WG to weigh the implementation complexities and overh= eads with the proposed details of SR-MPLS segments in IPFIX against the ben= efit (if any) that they provide for the flow analysis and monitoring.

 

Thanks,

Ketan

 

From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Hi Ketan,

 

Thank you very mu= ch for the review and feedback.

 =

  • What or how= much value be there on determining whether a SR Prefix SID was signalled/p= rogrammed on a node via OSPFv2/OSPFv3/ISIS – what matters and is more important is that it is a Prefix SID. Har= dly any deployments would be running multiple protocols and learning the sa= me prefix from different IGPs.

 

As Jeff already pointed out. Mul= tiple IGP labelling protocols are used  in networks when migrations ar= e ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom wh= en we first discovered this shortcoming in vendor implementations. The key = point here, with these additional IPFIX MPLS Label Type identifiers we enab= le the possibility to verify the label protocol migration without taking the label value into the considera= tion.

 

  • IPFIX may b= e picking this information from a FIB in some implementation where the prot= ocol does not matter and this information is not available therein.

 

I am not sure if you have seen t= he presentation in IETF 108 at OPSAWG and SPRING.

https://www.ietf.org/p= roceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-inform= ation-in-ipfix-00.pdf

 

Slide 2 shows Cisco as example v= endor which implemented IE 46, MPLS Label Type identifier. There is an open= ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.=

 

I do understand y= our point that not all the vendors are capable to implement IE 46. But that= ’s not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementa= tion can refer to the right code point. With RFC 5102 the decision has been= made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends = the IE 46 registry with the Segment Routing label protocol code points so w= hen OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX im= plementation can point to the right code point.

 

  • On some nod= es, the same Prefix SID may be learnt via both BGP and IGP – what wou= ld we use/show?

 =

In this case the = IE 46 shows the label protocol which was used to program the FIB.

 =

  • = For that table proposal, it is very difficult and in some cases not possibl= e to different between Prefix and Node and Anycast SID. Many of these types= are control plane elements and we can be sure more get added.
    • =

 =

I fully agree. As= a network operator its still hard to understand the architecture and const= raints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what mak= e sense. By purpose, all available SID types are listed in the draft. This = with the aim to start the discussion in the working groups what is possible= what makes sense. I would be interested to get your and also Jeff's feedback.

 =

In above mentione= d slides I described how TI-LFA application would benefit of visibility in = the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which lab= el protocol was used to forward a particular packet, but also which SID typ= e to further understand the intend why this label is being pushed.

 =

I hope this makes= all sense. Looking forward for reply.

 

Best wishes

Thomas

 

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
Cc: lsr@ietf.org; SPRING WG <= spring@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

< also copying Spring WG for their review/inputs >

 

Hi Thomas/All,

 

I have reviewed the draft and would like to share a different perspec= tive.

 

What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS – what ma= tters and is more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and= learning the same prefix from different IGPs. IPFIX may be picking this in= formation from a FIB in some implementation where the protocol does not mat= ter and this information is not available therein.

 

On some nodes, the same Prefix SID may be learnt via both BGP and IGP= – what would we use/show?

 

I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding S= ID, SR BGP Peering SID and so on … for the MPLS Label Type.

 

This also takes away the need for the second table that is being prop= osed to a large extent. For that table proposal, it is very difficult and i= n some cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control p= lane elements and we can be sure more get added. Is there really much value= in differentiation between say an Adjacency SID and LAN Adjacency SID?

 

Could we evaluate the implementation overhead and complexity of this = level of categorization/information in IPFIX against their value in flow an= alysis to perhaps consider a middle ground?

 

Thanks,

Ketan

 

From: Lsr <lsr-bounces@iet= f.org> On Behalf Of Thomas.Graf= @swisscom.com
Sent: 31 July 2020 20:52
To: hannes@gredler.at
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Hi Hannes,

 

Thanks a lot for = the feedback. Yes, makes completely sense. Will take it for the next update= ..

 =

Best Wishes<= /o:p>

Thomas=

 

 

From: Hannes Gredler <hannes@= gredler.at>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

Thomas,

 

I have one comment/suggestion to Paragraph 4 (IANA C= onsiderations).

 

Please add also a code point for BGP Prefix-SID - it= ’s quite popular in DC deployments.

 

thanks,

 

/hannes

 

On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

 

Dear lsr,

 

I presented the following draft=

 

Export of MPLS Segment Routing = Label Type Information in IP Flow Information Export (IPFIX)

 

at the spring working group at = IETF 108 yesterday

 

and today at OPSAWG where I cal= l for adoption.

 

This draft adds additional segm= ent routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 an= d OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

 

I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link state routing protocols and mpls data plane.

 

I am looking forward to your fe= edback and input.

 

Best Wishes

Thomas Graf

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

 

--_000_ZRAP278MB012599E0B7C0A68BDE83623B89410ZRAP278MB0125CHEP_-- ------=_Part_3003079_1519164914.1597471334092 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE1MDYwMjE0WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCAXN4EZ a8Q+Y2WdC/W33oblv8d9CJ5w/t6paoBX30c+hzB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAFnUH8Jzw0yXAMjk5XQ4n1jRbbVlv05RdEnJsqbdDHi7bkljQ3Ql0rMT4 P5UV64seYGhXrVX9A1bRk5EP5S7f9RJI1SQk/U6P28F2GRBOJlBrdt7lm+KR0ElAMylFh9MmLn2X LG02vOBsVr5QV8AWLb5zRbrT6YHlmYzpNLH07nuEziDuSO0rnM/0IqfvCw+8LaGmmNTRh/It/qBp VBF3gzeWlMhvySadtWuT+qiAb7/57zonrGeRdSsKGzC6jUGl/ZopA9RW7FWFErJnJTr8VnvdKyMG +jlZm2MR64znzrZDY10DomcCGCMHj4jRtK6jurC7itKjvUR9LABrePx7SAAAAAAAAA== ------=_Part_3003079_1519164914.1597471334092-- From nobody Fri Aug 14 23:24:34 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259733A0814; Fri, 14 Aug 2020 23:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LUu0pykQ_cqy; Fri, 14 Aug 2020 23:24:30 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 40FD93A080E; Fri, 14 Aug 2020 23:24:30 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id k1so2472173vkb.7; Fri, 14 Aug 2020 23:24:30 -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=HuHj6rwoLzSnctFWj0TvD201cAvpCB4AYha7xM1/6RU=; b=N65izRa+LgD4x2O/WPmBvmW0Qog6CzmGPPDFBFgzOZeZ1ElfKVbjqdp/25qosMw8Tl MwAKIibdzawU7WbPwscplfLIj5517HFVguVpxSwq/uMN+zz5BgfZ1s034pBuAWK/DeWs GfzVnsXM6+Cv8SGwFU7K2G9BEW58gYMhA6VC+EZb7/Q+IxhxS5w2UhOdhl5+7KjX+WtI Wr4nulusE45LUYYBDd10TygBCRN0iijlFVjOaDezqfRvpi70spb5nGOhpYi2VdQ8z1dX 0SjN4rZgBofF9ig2d/jR1QI8m5rJXmn7ZJAnPgKJftoiWMZYx18tUZLfmEI9CNNF18BN mbNA== 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=HuHj6rwoLzSnctFWj0TvD201cAvpCB4AYha7xM1/6RU=; b=NT9m2IdNHbDQxcSJPi6qJDgoarYr4OZpsaH3fDff3FepI7Au8zDRI9fxAx5O0cJclH MT34j3dcTDmxyTgKF4ocXoFhCDuxnejqOlm5iGn8d41CY+1aZNFqL38vlU+7HA5X28NE ARSilfJv2adA5+ME+VTxjZIN/Kc1vj9D5Va2v34yRiyWdavcBM0Vq79N/OTlDW0ODlG+ OBkwZ+wbGIu6CDKowErQXiRpokfMnp/xVcxzN9G/C8EW2H12b/sMe3VGpR8AFWArUeGi SkM8BMWvBgaOKqThHE9C13NcdInGLjTGKOIGOqebqWcAt2ppeijvorVGE1MrJrmmMaGJ MbHQ== X-Gm-Message-State: AOAM530zDkoiWIomRfH6aUiwr9BvK5+h3yXBghlmRqwV6E5hK8504MuU Kqgl2OLR+inkRWCrdpM/dgSITii5ARocFMdamaw= X-Google-Smtp-Source: ABdhPJxIgthK3gQJJ+Q2MHEytgjtGsG6urH5qmUYrfrtpK3zn9IDwTlrBU0SyKrIDOR/Attk0Oe7AuMfwX2Daq0jC6w= X-Received: by 2002:a1f:5fcf:: with SMTP id t198mr3420258vkb.32.1597472669216; Fri, 14 Aug 2020 23:24:29 -0700 (PDT) MIME-Version: 1.0 References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: From: Gyan Mishra Date: Sat, 15 Aug 2020 02:24:18 -0400 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: "bruno.decraene@orange.com" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fcbd4d05ace496f7" Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 06:24:32 -0000 --000000000000fcbd4d05ace496f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support WG adoption adoption of this draft. For operators moving towards SR technology, RSVP FRR is widely deployed by operators, so SR node protection is a critical feature for operators. >From the thread started by Joel Halpern I think path protection is as well critical to operators. With regards to SR FRR node protection, how does TI-LFA FRR work in conjunction with SR FRR node protection for the same PLR junction to the merge point bypass loop. Is the concept of context table a requirement for node FRR as it will consume more resources. In the bypass loop if their is only one next next hop path Neighbor or a few would a context table be necessary. For the node protection this does seem similar conceptually to RSVP node protection with the additional label to signal lsp to the merge point. Kind Regards Gyan On Fri, Aug 14, 2020 at 8:25 AM Ketan Talaulikar (ketant) wrote: > > > > > > > > > > > > > > > > > Hi All, > > > > > > I believe this topic is relevant and something for the WG to adopt and > work on. > > > > > > I have some concerns though on it=E2=80=99s applicability and more specif= ically > it=E2=80=99s implications on existing deployments/use-cases. I=E2=80=99ve= share the same on > the thread started by Joel on this specific aspect [1]. Some discussion a= nd > clarity on this > > would help before adoption. > > > > > > One other bit, for the example in Sec 2.3, perhaps some text is required > to clarify that this applies only for segments signalled via IGPs and if > the 9054 was a BSID or BGP-EPE SID then this approach would not work. May= I > suggest to add > > a section 2.4 to capture these aspects (it would be some what on the line= s > of Sec 3.4 but not related to the context table solution). > > > > > > The document is well-written and detailed. It does a very good job of > describing the node protection scenarios and options. > > > > > > Thanks, > > > Ketan > > > > > > [1] > > https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/ > > > > > > > > > > *From:* spring > > *On Behalf Of *bruno.decraene@orange.com > > > > > *Sent:* 30 July 2020 17:55 > > > *To:* spring@ietf.org > > > *Cc:* draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org > > > *Subject:* [spring] WG adoption call for > draft-hegde-spring-node-protection-for-sr-te-paths > > > > > > > > > > Hi SPRING WG, > > > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have > asked for WG adoption. > > > > > > Please indicate your support, comments, or objection, for adopting this > draft as a working group item by August 20th 2020. (*) > > > > > > Could those who are willing to work on this document, please notify the > list. That gives us an indication of the energy level in the working grou= p > to work on this. > > > > > > Thanks, > > > Regards, > > > Bruno, Jim, Joel > > > > > > [1] > > > https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-= paths-07 > > > (*) 3 weeks to account for the IETF meeting week and the august/summer > period. > > > > > > _________________________________________________________________________= ________________________________________________ > > > > > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > > > Thank you. > > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000fcbd4d05ace496f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support WG adoption adoption of this dra= ft.

For operators moving= towards SR technology, RSVP FRR is widely deployed by operators, so SR nod= e protection is a critical feature for operators.
From the thread started by Joel Halpern I think p= ath protection is as well critical to operators.
With regards to SR FRR node protection, =C2=A0how = does TI-LFA FRR work in conjunction with SR FRR node protection for the =C2= =A0same PLR junction to the merge point bypass loop.=C2=A0

Is the concept of context table a requir= ement for node FRR as it will consume more resources.=C2=A0 In the bypass l= oop if their is only one next next hop path Neighbor or a few would a conte= xt table be necessary.=C2=A0 For the node protection this does seem similar= conceptually to RSVP node protection with the additional label to signal l= sp =C2=A0to the merge point. =C2=A0

Kind Regards=C2=A0

Gyan

On Fri, Aug 14, 2020 at 8:25 AM Ketan Talaulikar (ketant) &= lt;ketant=3D40cisco.com@dmarc= .ietf.org> wrote:















Hi All,

=

=C2=A0



I believe this topic is relevant and something for the WG to ado= pt and work on.



=C2= =A0



I have some concerns though on= it=E2=80=99s applicability and more specifically it=E2=80=99s implications= on existing deployments/use-cases. I=E2=80=99ve share the same on the thre= ad started by Joel on this specific aspect [1]. Some discussion and clarity= on this

would help before adoption.



=C2=A0



On= e other bit, for the example in Sec 2.3, perhaps some text is required to c= larify that this applies only for segments signalled via IGPs and if the 90= 54 was a BSID or BGP-EPE SID then this approach would not work. May I sugge= st to add

a section 2.4 to capture these aspects (it would be some = what on the lines of Sec 3.4 but not related to the context table solution)= .



=C2=A0

<= br>

The document is well-written and detailed. It= does a very good job of describing the node protection scenarios and optio= ns.



=C2=A0

Thanks,



Ketan



=C2=A0



[1]

https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp= _WAiClFwpOmM/



= =C2=A0







From:<= /b> spring <spring-bounces@ietf.org>

On Behalf O= f bruno.= decraene@orange.com




Sent: 30 July 2020 17:55


To: spring@ietf.org


Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.= org


Subject: [spring] WG adoption call for draft-hegd= e-spring-node-protection-for-sr-te-paths







=C2=A0


Hi SPRING WG,



=C2= =A0



Au= thors of draft-hegde-spring-node-protection-for-sr-te-paths=C2=A0 [1] have = asked for WG adoption.



=C2=A0



Please indicate your support, comments, or = objection, for adopting this draft as a working group item by August 20th 2= 020. (*)



=C2=A0



Could those who are willing to work on this document, pl= ease notify the list. That gives us an indication of the energy level in th= e working group to work on this.



=C2=A0



=

Thanks,

Regards,=



Bruno, Jim, = Joel



=C2=A0



[1]

https://tools.i= etf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07



(*)= 3 weeks to account for the IETF meeting week and the august/summer period.=



=C2=A0



______________________=
___________________________________________________________________________=
________________________


=C2=A0


Ce message et ses pieces jointes peuvent conteni=
r des informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans a=
utorisation. Si vous avez recu ce message par erreur, veuillez le signaler<=
u style=3D"font-family:monospace">


a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'=
;alteration,


Orange decline toute respon=
sabilite si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

=C2=A0


This m=
essage and its attachments may contain confidential or privileged informati=
on that may be protected by law;


they sh=
ould not be distributed, used or copied without 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 mess=
ages that have been modified, changed or falsified.


=

Thank you.






<= br>
_______________________________________________

spring mailin= g list

spring@i= etf.org

https://www.ietf.org/mailman/listinfo= /spring

--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 50= 2-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD


--000000000000fcbd4d05ace496f7-- From nobody Sat Aug 15 11:33:03 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1553A0B35; Sat, 15 Aug 2020 11:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Vbooh3dQpsPu; Sat, 15 Aug 2020 11:33:00 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 963603A0B32; Sat, 15 Aug 2020 11:33:00 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id u15so3599667uau.10; Sat, 15 Aug 2020 11:33:00 -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=YuQAmKeZhhIGcWwvX7RfYyfJ2OBYHkOaMo8xBbZYCyk=; b=FLlgQk4vBiSOBTdm8G5mPIdzgOpO8GWR8SBoLmiqmXfE58m3LpcI1CKInfV7GRIpBo SxqJigeTxYnl7u7va1bICbo9uRdi553gDSQhxk4A0LBXG085053NHWd2Go3xmLbNOYSG chC6T0Oy5ypt/YV9yHjkij8M+7Dg4q5NTKGeucfv7KlPdmTFrSWd4MLwscb2EfLJNs+c pbed8rGAjBwOrN53RH9FU1a2CnhKjvTHoBzBow4S9trc2OxzRgQZVe94ttzxA6VQiM8T HVzvSG7EWnWZY6BWo18Z0rKwQYSgchgMuvK8trHsbJTj34Lt596Osz9VrOUu0QMu8gyS TnIA== 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=YuQAmKeZhhIGcWwvX7RfYyfJ2OBYHkOaMo8xBbZYCyk=; b=FyB9qP9kQ/0e5XUuisDoX40h7JSndKT+OUjXfL8IVKEE98RP5sJWUsdYmAY5VF44ew lw4vhNib7v18qMv51tvl+DIxqs77tLAJSXnR7T4GB6BxJn+TJafXK0IAyg6v0OXPZ1vT 3d1e0woG72gqwZ2quMCo+cLGLrM8SFoZ2AuMtUV19ldcDyn/ZW7RBKmSK7XU9F6Tom6a 6IcAne5FoiWdqs0CuX8ehqnlFedAqqbdzFyLIK1sFCvQgB8InSXkbYyg2IAYJaPb9oyd r1reWKSjqdOZqNb8G62SV06jQ0Ux8vLScGgAlym1DQUuL4pkiYGSt1GOcVcg3ORwFAwi Foug== X-Gm-Message-State: AOAM531zVxhgLOutmvlXI3MUgwv8xuN2yV68oDAkRdVmqJhZBL4s9UHA kO6ixsd8Co15GSF253RV07ZvSr+WOSl0t3uTfvg= X-Google-Smtp-Source: ABdhPJzzZ4bX0JhGW/NnzAwMNo4FAPNNq0MikAWcbRMDRCbWqXyPz3FFqMXJEzYhe44+aNLtJq/3ra0B5oaeVqxh1/M= X-Received: by 2002:ab0:c3:: with SMTP id 61mr4339945uaj.106.1597516379583; Sat, 15 Aug 2020 11:32:59 -0700 (PDT) MIME-Version: 1.0 References: <544EDC5B-EA7D-40F1-A6B2-DCA486FDF41F@cisco.com> In-Reply-To: <544EDC5B-EA7D-40F1-A6B2-DCA486FDF41F@cisco.com> From: Gyan Mishra Date: Sat, 15 Aug 2020 14:32:48 -0400 Message-ID: To: "Richard Vallee (rvallee)" Cc: James Guichard , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000053fb8605aceec423" Archived-At: Subject: Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 18:33:02 -0000 --00000000000053fb8605aceec423 Content-Type: text/plain; charset="UTF-8" I support WG adoption. Thanks Gyan On Mon, Jul 27, 2020 at 7:51 AM Richard Vallee (rvallee) wrote: > > > > > > > > > > > > > > > > > Hello WG, > > > > > > I support the WG adoption of this important work for SRv6. > > > > > > Thanks > > > Richard > > > > > > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > > > *Date: *Monday, July 13, 2020 at 5:52 PM > > > *To: *"spring@ietf.org" > > > *Cc: *"spring-chairs@ietf.org" > > > *Subject: *[spring] WG Adoption Call for draft-raza-spring-srv6-yang > > > > > > > > > > > > Dear WG: > > > > > > This email begins a 2 week WG adoption call for > > https://datatracker.ietf.org/doc/draft-raza-spring-srv6-yang/ ending > Monday 27th July 2020. > > > > > > > Please speak up if you support or oppose adopting this document into the > WG. Please also provide comments/reasons for that support (or lack > thereof). Silence will not be considered consent. > > > > > > Thanks! > > > > > > Jim, Joel & Bruno > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000053fb8605aceec423 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support WG adoption.

Thanks=C2=A0

Gyan

On Mon, Jul 27, 2020 at 7:51 AM Richard Valle= e (rvallee) <rvallee=3D40c= isco.com@dmarc.ietf.org> wrote:
















Hel= lo=C2=A0WG,



=C2=A0



I support the=C2=A0WG=C2=A0adoption=C2= =A0of this important work=C2=A0for=C2=A0SRv6.


<= br>

=C2=A0<= /span>



Thanks=



Richard



=C2=A0





From: spring <spring-bounces@ietf.org> on behalf of Jam= es Guichard <james.n.guichard@futurewei.com>


Date: Mon= day, July 13, 2020 at 5:52 PM


To: "spring@ietf.org" <spring@ietf.org>

Cc: "spring-chairs@ietf.org" <spring-chairs@ietf.org>


= Subject: [spring] WG Adoption Call for draft-raza-spring-srv6-yang







=C2=A0





Dea= r WG:



=C2=A0<= /p>

This email begins a 2 week WG adoption ca= ll for

https://datatracker.ietf.org/doc/draft-raza= -spring-srv6-yang/ ending Monday 27th July 2020.

<= /u>



=C2=A0


Please speak up if you support or oppose adopting = this document into the WG. Please also provide comments/reasons for that su= pport (or lack thereof). Silence will not be considered consent.<= /u>



=C2=A0



Thanks!



= =C2=A0



Jim, Joel & Brun= o



=C2=A0

<= br>

=C2=A0



=C2=A0



=C2=A0<= /u>









_________________= ______________________________

spring mailing list

spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring

--
<= div>

Gyan Mishra

=

Network Solutions A<= /i>rchitect=C2=A0=

M 301 502-1347
13101 Columbia Pi= ke=C2=A0
Silver Spring, MD


--00000000000053fb8605aceec423-- From nobody Sat Aug 15 12:26:23 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0513A0B5A; Sat, 15 Aug 2020 12:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4TBIuyi3nfHF; Sat, 15 Aug 2020 12:26:11 -0700 (PDT) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 32A0F3A0B58; Sat, 15 Aug 2020 12:26:11 -0700 (PDT) Received: by mail-vk1-xa2d.google.com with SMTP id i20so2712769vkk.2; Sat, 15 Aug 2020 12:26:11 -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=joSETKepABZ9fbWzPkBOowkUt549ITrXSTCenTnatKE=; b=MObwGR79Zmm6RU2YqBkw9YWvVjDcW3Hf3gugu+aNe+RDpkaptCSV3HZzofpKVQejXD tpwsxahw60R93/S+L/PV393IjyKzfv1O2uq5moY9A57P5abpK5s2XMJLvvMoxohfM46v qObUUwS6gNDOfEbsyILL5NDoN0blR6Azjmau5UG2SUexZ+ASAOfzyBXqwUfCtT8ufB/G vVCRllu/w2JZIbocQmnzenfXE3X4u2ZPaq0jfOKukrPrKn7ROT4rXj0KhcVIrBfPy5Q0 P1lYZH+d6EpV5tQK2/j2tdEmfhYIS4m4ZgyBogAGpH2zuJjO2oGqH31YqWflYVWyMV9F QMkw== 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=joSETKepABZ9fbWzPkBOowkUt549ITrXSTCenTnatKE=; b=s57q0O5dWycxncSouFivDXP7PsSAV/BjChUBalpBSVhnNxKWkAWXBLoWnUTmucVl4y pVpR3I+E6xXBtWRlq7A9r2rl2YnNFQN6T43lPG9+eNSEe5FgPsYPlKfIxJboHH9O9b4B dl6/Qyw/iEKY9Ak+uXY9u6WBqhOK/iuaR5Sp6qUkZXNXMQt/1IEpy7l7i0fZrGg+6+QG HSzVcHL86WebbumHCnA7yOz1BzA0YRIaKAw8BJuDbU3n50jRGABrUp9IbFj+vs2oaL4c 6Et3dJ7Q5VZKIX2JMg4JFApdauOMvVmNgJwuyVPxAQxZf/FglKp1dGWcRaXJAfUSeqmT g5CA== X-Gm-Message-State: AOAM530m6n6UWbeX+5IwbkCO0KvoBx0+CioRynjaDfyT4uek8+D97AvA 6ccGUO4zSNqlQOUcG9rDiuRkZHw3PzrX3/u5r7i6f3/6EsJxMg== X-Google-Smtp-Source: ABdhPJwkUoap0Scv5KgOIiLa3bNGwBP2Ad0rKPrCpqwVUO2Zgb4aAPTlh+DXCtrecOSIE6p/5CEU/M6VAmWu2Mue2x8= X-Received: by 2002:a1f:5fcf:: with SMTP id t198mr4579695vkb.32.1597519570013; Sat, 15 Aug 2020 12:26:10 -0700 (PDT) MIME-Version: 1.0 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> In-Reply-To: <696872714.3003081.1597471334092@ss002889> From: Gyan Mishra Date: Sat, 15 Aug 2020 15:25:59 -0400 Message-ID: To: Thomas.Graf@swisscom.com Cc: hannes@gredler.at, ketant@cisco.com, lsr@ietf.org, opsawg@ietf.org, spring@ietf.org Content-Type: multipart/alternative; boundary="0000000000007e1a4505acef82bb" Archived-At: Subject: Re: [spring] [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 19:26:14 -0000 --0000000000007e1a4505acef82bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas Responses in-line On Sat, Aug 15, 2020 at 2:02 AM wrote: > > > > > > > > > > > > > > > Hi Ketan, - This helps identification of specific SR-MPLS segment types as well as differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. - What value is provided for IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS? It is important to distinguish between intend and result. If you migrate from one label distribution protocol to another, a network operator want's to understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or not. IE46 enables that by looking at the result of the forwarded traffic and not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context. Gyan> IPFIX has been traditionally been used for flow analysis and to that end all that was required is support of the data plane encapsulation. With your proposed SR support idea you are really transforming the IPFIX to be used for not just flow monitoring at that level solely, but now also to analyze and troubleshoot data plane forwarding. That is a considerable departure I think from what IPFIX was intended. I am not sure we want to add that layer of complexity into IPFIX. > > > > > > > > - What value is provided for IPFIX analysis if it was a Adjacency SID > or a LAN Adjacency SID? > > > > > > > Quote from RFC8402. "Segment Routing (SR) leverages the source routing > paradigm". Means that not the routing protocol does all the forwarding > > decisions, the node can change the forwarding by pushing additional > labels.. With IPFIX SrSidType we are able to cover this dimension in IPFI= X. > Enabling to analyze the result of this decision. The example with " > Adjacency SID or a LAN Adjacency SID" is not > > very useful because the difference of the two is the topology among the > adjacency. If you compare " Adjacency SID with Prefix SID", that makes mu= ch > more sense. Since it describes that a particular adjacency is chosen to > forward the packet instead of a prefix. > > If IE 89, ForwardingStatus is drop, we understand that result of that > decision lead to the drop and this enables to narrow down forwarding issu= es > in segment routing networks more efficiently and quickly. > > > > > > =C3=98 > > am asking for WG to weigh the implementation complexities > > > > > > For the WG and me, I would be important if you can describe more detailed > what you mean with > > implementation complexities. I would like to have a better understanding > where your fear is coming from. I would appreciate if you could > differentiate between > > MPLS Label Type identifier, IE46, from which label protocol the label was > coming from and SrSidType which SID type was used. > > > > > > > Best wishes > > > Thomas > > > > > > > > > > *From:* Ketan Talaulikar (ketant) > > > > > *Sent:* Saturday, August 15, 2020 7:09 AM > > > *To:* Graf Thomas, INI-NET-DCF ; > hannes@gredler.at > > > *Cc:* lsr@ietf.org; spring@ietf.org; opsawg@ietf.org > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Thomas, > > > > > > I should have been more clear in my email. > > > > > > The proposal/suggestion is to add the following to the IPFIX MPLS Label > type identifier registry: > > > > > > - SR Prefix SID > - SR Adjacency SID > - SR Binding SID > - SR BGP Peering SID > - =E2=80=A6 and so on > > > > > > > This helps identification of specific SR-MPLS segment types as well as > differentiating them from LDP, RSVP-TE, etc. > > > > > > And my questions were: > > > > > > 1. What value is provided for IPFIX analysis if the SR Prefix SID was > being signalled via OSPF or ISIS? > > 2. What value is provided for IPFIX analysis if it was a Adjacency SID > or a LAN Adjacency SID? > > > > > > > I am asking for WG to weigh the implementation complexities and overheads > with the proposed details of SR-MPLS segments in IPFIX against the benefi= t > (if any) that they provide for the > > flow analysis and monitoring. > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* > > Thomas.Graf@swisscom.com > > > > > *Sent:* 15 August 2020 09:40 > > > *To:* Ketan Talaulikar (ketant) ; > > hannes@gredler.at > > > *Cc:* lsr@ietf.org; > > spring@ietf.org; opsawg@ietf.org > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Ketan, > > > > > > Thank you very much for the review and feedback. > > > > > > > > > - What or how much value be there on determining whether a SR Prefix > SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS > > =E2=80=93 what matters and is more important is that it is a Prefix SI= D. > Hardly any deployments would be running multiple protocols and learnin= g the > same prefix from different IGPs. > > > > > > > > As Jeff already pointed out. Multiple IGP labelling protocols are used i= n > networks when migrations are ongoing. Usually in a life cycle. Migrating > from > > LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom > when we first discovered this shortcoming in vendor implementations. The > key point here, with these additional IPFIX MPLS Label Type identifiers w= e > enable the possibility to verify the > > label protocol migration without taking the label value into the > consideration. > > > > > > > > > - IPFIX may be picking this information from a FIB in some > implementation where the protocol does not matter and this information > > is not available therein. > > > > > > > I am not sure if you have seen the presentation in IETF 108 at OPSAWG and > SPRING. > > > > https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-m= pls-sr-label-type-information-in-ipfix-00.pdf > > > > > > > Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label > Type identifier. There is an open ddts where vendor feasibility has been > clarified. > > Ping me off the list when you like to have more details. > > > > > > I do understand your point that not all the vendors are capable to > implement IE 46. But that=E2=80=99s not the point about the IPFIX IE regi= stry. > > The IE registry enables that an IPFIX implementation can refer to the > right code point. With RFC 5102 the decision has been made that MPLS Labe= l > Type identifier make sense > > and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends > the IE 46 registry with the Segment Routing label protocol code points so > when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX > implementation can point to the right > > code point. > > > > > > > > > - On some nodes, the same Prefix SID may be learnt via both BGP and > IGP =E2=80=93 what would we use/show? > > > > > > > In this case the IE 46 shows the label protocol which was used to program > the FIB. > > > > > > > > > > - > > For that table proposal, it is very difficult and in some cases not > possible to different between Prefix and Node and Anycast SID. Many of > these types are control plane elements and we can > > be sure more get added. > > > > > > > I fully agree. As a network operator its still hard to understand the > architecture and constraints within a router. When monitoring capabilitie= s > > are discussed at IETF, this is the usual topic. What is possible, what > make sense. By purpose, all available SID types are listed in the draft. > This with the aim to start the discussion in the working groups what is > possible what makes sense. I would be interested > > to get your and also Jeff's feedback. > > > > > > In above mentioned slides I described how TI-LFA application would benefi= t > of visibility in the FIB by showing where Adj-SID was used. This > > should be a simple example why it make sense not only to look at which > label protocol was used to forward a particular packet, but also which SI= D > type to further understand the intend why this label is being pushed. > > > > > > > I hope this makes all sense. Looking forward for reply. > > > > > > Best wishes > > > Thomas > > > > > > > > > > *From:* Ketan Talaulikar (ketant) > > > > > *Sent:* Friday, August 14, 2020 7:35 PM > > > *To:* Graf Thomas, INI-NET-DCF ; > > hannes@gredler.at > > > *Cc:* lsr@ietf.org; SPRING WG > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > < also copying Spring WG for their review/inputs > > > > > > > Hi Thomas/All, > > > > > > I have reviewed the draft and would like to share a different perspective= . > > > > > > What or how much value be there on determining whether a SR Prefix SID wa= s > signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matt= ers and is > more important is that it is a > > Prefix SID. Hardly any deployments would be running multiple protocols an= d > learning the same prefix from different IGPs. IPFIX may be picking this > information from a FIB in some implementation where the protocol does not > matter and this information is not > > available therein. > > > > > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 > what would we use/show? > > > > > > I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, > SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type. > > > > > > This also takes away the need for the second table that is being proposed > to a large extent. For that table proposal, it is very difficult and in > some cases not possible to different > > between Prefix and Node and Anycast SID. Many of these types are control > plane elements and we can be sure more get added. Is there really much > value in differentiation between say an Adjacency SID and LAN Adjacency S= ID? > > > > > > Could we evaluate the implementation overhead and complexity of this leve= l > of categorization/information in IPFIX against their value in flow analys= is > to perhaps consider a middle ground? > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* Lsr > > *On Behalf Of *Thomas.Graf@swisscom.com > > > *Sent:* 31 July 2020 20:52 > > > *To:* hannes@gredler.at > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Hannes, > > > > > > Thanks a lot for the feedback. Yes, makes completely sense. Will take it > for the next update... > > > > > > Best Wishes > > > Thomas > > > > > > > > > > > > > > > > > *From:* Hannes Gredler > > > > > *Sent:* Wednesday, July 29, 2020 9:31 AM > > > *To:* Graf Thomas, INI-NET-DCF > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Thomas, > > > > > > > > > > > > I have one comment/suggestion to Paragraph 4 (IANA Considerations). > > > > > > > > > > > > > > Please add also a code point for BGP Prefix-SID - it=E2=80=99s quite popu= lar in DC > deployments. > > > > > > > https://tools..ietf.org/html/rfc8669 > > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > /hannes > > > > > > > > > > > > > > > > On 28.07.2020, at 10:11, > > Thomas.Graf@swisscom.com wrote: > > > > > > > > > > > > Dear lsr, > > > > > > > > > > > > > > I presented the following draft > > > > > > > > > > > > > > Export of MPLS Segment Routing Label Type Information in IP Flow > Information Export (IPFIX) > > > > > > > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 > > > > > > > > > > > > > > > at the spring working group at IETF 108 yesterday > > > > > > > > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-inf= ormation-export-ipfix-00.pdf > > > > > > > > > > > > > > > and today at OPSAWG where I call for adoption. > > > > > > > > > > > > > > This draft adds additional segment routing code points for in the IANA > IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID type= s > to gain > > further insights into the MPLS-SR forwarding-plane. > > > > > > > > > > > > > > I have been asked to not only gather feedback from spring and opsawg but > also from lsr and mpls working groups since these code points are related > to link > > state routing protocols and mpls data plane. > > > > > > > > > > > > > > I am looking forward to your feedback and input. > > > > > > > > > > > > > > Best Wishes > > > > > > > Thomas Graf > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000007e1a4505acef82bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Thomas=C2=A0

Responses in-line=C2=A0

On Sat, Aug 15, 2020 at 2:02 AM <Thomas.Graf@swisscom.com> wrote:














<= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS",sans-se= rif;color:#44546a">Hi Ketan,



=C2=A0





  • <= span lang=3D"EN-IN">This helps identification of specific SR-MPLS segment t= ypes as well as differentiating them from LDP, RSVP-TE, etc.<= /span>


=C2=A0



To be precise, the existing MPLS Label Type = identifier differentiates from LDP, RSVP-TE. Not the new SrSidType IPFIX IE= being proposed.


=C2=A0



  • What value is provided for IPFIX analy= sis if the SR Prefix SID was being signalled via OSPF or ISIS?



=C2=A0



It is important to distinguish between intend and = result.



=C2=A0



If you migrate from one label distribution= protocol to another, a network operator want's to understand if the da= ta plane is still forwarding

packets with the label distribution pr= otocol which needs to be removed or not. IE46 enables that by looking at th= e result of the forwarded traffic and not at the intend. RFC 8661 section 3= ,

https://tools.ietf.org/html/rfc8661#section= -3,

describes the cont= ext.


Gyan> IPFIX has been traditionally been used for flow ana= lysis and to that end all that was required is support of the data plane en= capsulation.=C2=A0 With your proposed SR support idea you are really transf= orming the IPFIX to be used for not just flow monitoring at that level sole= ly, but now also to analyze and troubleshoot data plane forwarding.=C2=A0 T= hat is a considerable departure I think from what IPFIX was intended.=C2=A0= =C2=A0

I am not sure we = want to add that layer of complexity into IPFIX.

=C2=A0=




  • What value is provided= for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?


=C2=A0



Quote from RFC8402. "Segment Rou= ting (SR) leverages the source routing paradigm". Means that not the r= outing protocol does all the forwarding

decisions, the node can cha= nge the forwarding by pushing additional labels.. With IPFIX SrSidType we a= re able to cover this dimension in IPFIX. Enabling to analyze the result of= this decision. The example with " Adjacency SID or a LAN Adjacency SI= D" is not

very useful because the difference of the two is the= topology among the adjacency. If you compare " Adjacency SID with Pre= fix SID", that makes much more sense. Since it describes that a partic= ular adjacency is chosen to forward the packet instead of a prefix.

= If IE 89, ForwardingStatus is drop, we understand that result of that deci= sion lead to the drop and this enables to narrow down forwarding issues in = segment routing networks more efficiently and quickly.=



=C2=A0



=C3=98=C2=A0

am asking for WG to weigh the implementati= on complexities



=C2=A0



For the WG and me, I would be important if you can desc= ribe more detailed what you mean with

im= plementation complexities. I would like to have a better understanding wher= e your fear is coming from. I would appreciate if you could differentiate b= etween

MPLS Label Type ide= ntifier, IE46, from which label protocol the label was coming from and SrSi= dType which SID type was used.

=


=C2=A0<= /p>

Best w= ishes



Thomas



=C2=A0

<= br>


=C2=A0


Hi Thomas,



=C2=A0<= /u>



I should = have been more clear in my email.



=C2=A0



=

The proposal/suggestion is to a= dd the following to the IPFIX MPLS Label type identifier registry:





    =
  • SR Prefix SID<= /u>
  • SR Adjace= ncy SID
  • SR Binding SID
  • SR BGP Peering SID
  • =E2=80=A6 and so on


<= u>=C2=A0



This helps identification of specific SR-MPLS segment types as well = as differentiating them from LDP, RSVP-TE, etc.


=C2=A0



And my questions w= ere:





  1. Wh= at value is provided for IPFIX analysis if the SR Prefix SID was being sign= alled via OSPF or ISIS?

  2. What value is provided for IPFIX analysis = if it was a Adjacency SID or a LAN Adjacency SID?
    3. =


=C2=A0



I am askin= g for WG to weigh the implementation complexities and overheads with the pr= oposed details of SR-MPLS segments in IPFIX against the benefit (if any) th= at they provide for the

flow analysis and monitoring.=



=C2= =A0



Th= anks,



Ketan



=C2=A0





=

From:

Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>



Sent: 15 August 2020 09:40


To: Ketan Tal= aulikar (ketant) <= ketant@cisco.com>;

hannes@gredler.at


Cc: lsr@ietf.org;

spring@ietf.org; opsawg@ietf.org


Subjec= t: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type<= /p>





=C2=A0



Hi Ketan,



=C2=A0



Thank you very much for the = review and feedback.



=C2=A0



=


  • What or how much value be there on determining w= hether a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3= /ISIS

    =E2=80=93 what matters and is more important is that it is a = Prefix SID. Hardly any deployments would be running multiple protocols and = learning the same prefix from different IGPs.

    <= /li>


=C2=A0<= u>



As Jeff= already pointed out. Multiple IGP labelling protocols are used =C2=A0in ne= tworks when migrations are ongoing. Usually in a life cycle. Migrating from=

LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swi= sscom when we first discovered this shortcoming in vendor implementations. = The key point here, with these additional IPFIX MPLS Label Type identifiers= we enable the possibility to verify the

label protocol migration w= ithout taking the label value into the consideration.<= /p>

=C2=A0=





  • IPFIX may be picking this inf= ormation from a FIB in some implementation where the protocol does not matt= er and this information

    is not available therein.


=C2= =A0



I a= m not sure if you have seen the presentation in IETF 108 at OPSAWG and SPRI= NG.



https= ://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-= label-type-information-in-ipfix-00.pdf



=

=C2=A0

=

Slide 2 shows Cisco as e= xample vendor which implemented IE 46, MPLS Label Type identifier. There is= an open ddts where vendor feasibility has been clarified.

Ping me = off the list when you like to have more details.


=C2=A0



I do= understand your point that not all the vendors are capable to implement IE= 46. But that=E2=80=99s not the point about the IPFIX IE registry.

<= /span>The IE registry enables that an IPFIX implementat= ion can refer to the right code point. With RFC 5102 the decision has been = made that MPLS Label Type identifier make sense

and can be implemen= ted. draft-tgraf-ipfix-mpls-sr-label-type just extends the IE 46 registry w= ith the Segment Routing label protocol code points so when OSPFv2/OSPFv3/IS= IS SR TLV is used, and IE 46 is supported, the IPFIX implementation can poi= nt to the right

code point.



=C2=A0




  • On some nodes, the same Prefix SID may be learn= t via both BGP and IGP =E2=80=93 what would we use/show?


=C2=A0



In this case the IE 46 shows the label protocol wh= ich was used to program the FIB.



=C2=A0







  • For that table proposal, it is very difficult and in = some cases not possible to different between Prefix and Node and Anycast SI= D. Many of these types are control plane elements and we can

    be sur= e more get added.


    • = =C2=A0



    I fully agree. As a network operator its still hard to under= stand the architecture and constraints within a router. When monitoring cap= abilities

    are discussed at IETF, this is the usual topic. What is p= ossible, what make sense. By purpose, all available SID types are listed in= the draft. This with the aim to start the discussion in the working groups= what is possible what makes sense. I would be interested

    to get yo= ur and also Jeff's feedback.



    =C2=A0



    In = above mentioned slides I described how TI-LFA application would benefit of = visibility in the FIB by showing where Adj-SID was used. This

    shoul= d be a simple example why it make sense not only to look at which label pro= tocol was used to forward a particular packet, but also which SID type to f= urther understand the intend why this label is being pushed.

    =



    =C2=A0



    I hope this makes all sense. Looking forward= for reply.



    =C2=A0



    <= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS",sans-se= rif;color:#44546a">Best wishes



    Thomas



    =C2=A0






    From: Ketan T= alaulikar (ketant) <ketant@cisco.com>




    Sent: Friday, August 1= 4, 2020 7:35 PM


    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom= .com>;

    hannes@gredler.at


    Cc: lsr@ietf.org; SPRING WG <spring@ietf.org>


    Subject= : RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type


    <= br>




    =C2=A0<= /p>

    < also copying Sp= ring WG for their review/inputs >



    =C2=A0


    Hi Thomas/All,<= /span>



    =C2=A0=



    I hav= e reviewed the draft and would like to share a different perspective.



    <= /u>=C2=A0



    What or how much value be there on determining whether a SR Prefix SID = was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what ma= tters and is more important is that it is a

    Prefix SID. Hardly any = deployments would be running multiple protocols and learning the same prefi= x from different IGPs. IPFIX may be picking this information from a FIB in = some implementation where the protocol does not matter and this information= is not

    available therein.



    =C2=A0



    =

    On some nodes, the same Prefix = SID may be learnt via both BGP and IGP =E2=80=93 what would we use/show?=



    <= u>=C2=A0



    I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding = SID, SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type.=



    =C2=A0



    This also takes away the need for the second table that is being propose= d to a large extent. For that table proposal, it is very difficult and in s= ome cases not possible to different

    between Prefix and Node and Any= cast SID. Many of these types are control plane elements and we can be sure= more get added. Is there really much value in differentiation between say = an Adjacency SID and LAN Adjacency SID?



    =C2=A0


    Could we evaluate the impl= ementation overhead and complexity of this level of categorization/informat= ion in IPFIX against their value in flow analysis to perhaps consider a mid= dle ground?



    =C2=A0



    = Thanks,



    Ketan



    =C2=A0






    From: Lsr <lsr-bounces@ietf.org>

    On B= ehalf Of = Thomas.Graf@swisscom.com


    Sent: 31 July 2020 20:52
    =

    To: h= annes@gredler.at


    Cc: lsr@ietf.org


    Subject: Re: [Lsr] dra= ft-tgraf-ipfix-mpls-sr-label-type






    =C2= =A0



    Hi = Hannes,



    =C2=A0



    Thanks a lot for the feedback. Yes, makes co= mpletely sense. Will take it for the next update...

    = =C2=A0



    Best Wishes



    Thomas




    =C2=A0=





    =C2=A0







    <= p class=3D"MsoNormal">From: Hannes Gredler <hannes@gredler.at>




    Sent: Wednesday= , July 29, 2020 9:31 AM


    To: Graf Thomas, INI-NET-DCF <= Thomas.Graf@s= wisscom.com>


    Cc: lsr@ietf.org


    Subject: Re: [Lsr] draf= t-tgraf-ipfix-mpls-sr-label-type




    =


    =C2=A0



    Thomas,





    =C2=A0







    <= p class=3D"MsoNormal">I have one comment/suggestion to Paragraph 4 (IANA Co= nsiderations).







    =C2=A0







    <= p class=3D"MsoNormal">Please add also a code point for BGP Prefix-SID - it= =E2=80=99s quite popular in DC deployments.



    =





=C2=A0







thanks,<= u>







= =C2=A0







/hannes








=C2=A0=



=



On 28.07.2020, at 10:11,

Thomas.Graf= @swisscom.com wrote:





=C2=A0







Dear lsr,






=C2=A0<= /p>





I presented the following draft







=C2=A0







Export of MPLS Segment Routing Label Type Inform= ation in IP Flow Information Export (IPFIX)






<= div>

=C2=A0






at the spring working group at IETF 108 yesterday

=







=C2=A0







and today at OPSAWG where I call for= adoption.







=C2=A0


<= br>




T= his draft adds additional segment routing code points for in the IANA IPFIX= registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to ga= in

further insights into the MPLS-SR forwarding-plane.







=C2=A0





<= br>

I have been asked to not= only gather feedback from spring and opsawg but also from lsr and mpls wor= king groups since these code points are related to link

state routi= ng protocols and mpls data plane.






=C2=A0=







I am looking forward to your feedback and input.







=C2=A0






Best Wishes







Thomas Graf



<= br>

___________________________________________= ____


Lsr mailing list


Lsr@ietf.org

=
https://www.ietf.org/mailman/listinfo/lsr<= /u>









=C2=A0






=




_______________________________________________
OPSAWG mailing list

OPSAWG@ietf.org

https://www.ietf.= org/mailman/listinfo/opsawg



--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD


--0000000000007e1a4505acef82bb-- From nobody Sun Aug 16 00:13:49 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC84B3A0811; Sun, 16 Aug 2020 00:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 rdKmOvBEFwRT; Sun, 16 Aug 2020 00:13:40 -0700 (PDT) Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 57B873A081C; Sun, 16 Aug 2020 00:13:37 -0700 (PDT) Received: by mail.swisscom.com; Sun, 16 Aug 2020 09:13:29 +0200 Message-ID: <1180087721.1311955.1597562009048@ss007564> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_1311953_1608935745.1597562009047" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+G1AjKTN2p171QJ0/dgnZZlDLHugYHTJVd7cbRiHLQifiz4gV4ic5HWNZlPgdt8KkIMdcQMWOKNGnyZEA55+zzZfTlvIlWds2uZuCmDuoCQ32M9fZ4FOfdMBOMC8f2Rpuvcte5498yPVA6dSxQTn6Lz7FY1jc3IvGhbhEJwtyFq2htM3QP5ZUS6yXbneoc1QKUOBFRBwwZJ0spa3l9aT74tKsu/raSSETvIenFUXUH8Dlfcl/E2f0+XZ7nb7sFvnPLK10WNUCXHUSVfc5vZ+PrSj8nYSwtlyfNE1xihez2Be0wENcQobhp70seP+e+oPnjbVVHkoMs/r0fbC0TK7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TGNdvZICv8Pi8s2FX466ZPTwZ2URpsByas5iS/i9hEc=; b=E7vKVQz2abOELe04Cyj6awPsdFc2q6NlOyU/ni9fHiTzYtndObYrSQ30iVpaYjiCHysQRa466MhlAjZFv+X9zHo61htS1emUCA+hYrLfo/gMAu5ZqVeHClCH9UDTaIIelIC9QkihoHJ0DFGJ5hHericGR62G4ljm80Hz4w8fWiVIO2M7Jd3UYrs9iTSpiVtpRUHFwuoHKGqioil0o7xCxelYgllz/vCWkpEN+y5XD1vVsMAI/Wfkm088cemkIo5l/WKfMQGdmYMPtFJno5Zmf7Zf8DiQw/hqHM7qQexZc0JgFl0BhQlr13//B3flMwFrCzs7hX0uX34yQXLn8Uf5Kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: CC: , , , , Thread-Topic: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AQHWZXpAYzBRFTPdWk2PQZUrWhbqXAAxTF+AAHUFTIACvTCesAAduZCAAAG4RsCpHZFNsoAAuuaA Date: Sun, 16 Aug 2020 07:13:25 +0000 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-08-16T07:13:22.6334064Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=f0d47f00-8397-4e91-8795-dd0a29b41697; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [178.199.12.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: effe4aba-170d-41f5-57eb-08d841b3de17 x-ms-traffictypediagnostic: ZRAP278MB0093: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V41KgCW3Zs/cNUc6FHE8OdvR3fsmgV45iWzst/34R5EVWNE6nVeSv1r/3aunoXb6PLF1aEt/v2IkBLlgC/KaCCuviZhV9e4wZg+jidiJ9gyjkfgfYG7J5boncA0B4+moBdyNyONS2wowYXR8k5H5i7BZ0QdJLQBN6UC082jKpUn26n/fgQ3GND63EbJPOmF75WoXjo5xUm85wfa6yMuydokznUO/i2/Bt9VP62V6zoS63Z2VrtvAtGRmq3zHBvEIwBtwMJDN6U9uX++bZI+QQwv9s7WnPFekTFqlBA1kE02uitWm+JGEA0/C0MbfIrx15ahgtP62mdAg+0ohULeVU9LxHZDMxYR6iqFG7TBF5ohUkTVQ9QWmrrzKRFHycjkam3vpUFYpYw9mepxIm0EaXg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(376002)(39850400004)(396003)(346002)(478600001)(54906003)(2906002)(966005)(316002)(5660300002)(6916009)(10300500001)(8676002)(19627235002)(4326008)(52536014)(8936002)(10290500003)(30864003)(86362001)(7696005)(83380400001)(66946007)(55016002)(66476007)(66556008)(64756008)(76116006)(71200400001)(186003)(26005)(66574015)(53546011)(166002)(66446008)(33656002)(9686003)(6506007)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 8NayphawjFxOB6yw8k7r/hvHE6ScqxcOPS0X4loAuIesi477JEbJBh0RnbUH/a8PpShogEoa9joqkyNQAU4bJs/clioFOr5bg83bkD6UgtPHmBKBXB1VJ0Es0tbzNK5SKh+b/jz+VJWqL3sekcVAwQeTxhQVebjODmb6fTkSO0OKWBOYi8AY1Mdyu3h11zb6KRrhc2j0eczwtR158zxFxsVcm2B3MF0+kLwAQh6scA+kEaR+SNhvsKN2ugQrcLjDbrdT/Zf9STvYY3ns8oTJABVAB5W0iPBa6U7GcUrC/mXzcArgCxnHJDj+FO8JeOmeXsDpxAvVuCp+Jqu6jtwl0PXMxG7mGtuotX9Z6PZpPH5Bm20YtB+pCp31OLISZ/QR2aJuLDJeuBWHS54SzrERnyuwBzGpi0m5nF3QhitJ7NpaXHzbYZaOMW3M08mfUO2TVIH10UcBKJutvtDa5pD+ic7sF/NENvoL/sQ/mZ8qdGLSFv5f44UX2e4XG4xSnAurQ/+d0UdWYjLWBpAPC+Ncfg0B6FD+zzINy32joQ8v0mglOTpVL07XCztzhMLMDpGSZQwoKCODa2h60WxxAnbdT63Yo/Mqw70sM9FDB2qB8iw1Tf2M33w9AYDjsFIqQOYHqpyaywomWGeBG0UTuQlFeg== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: effe4aba-170d-41f5-57eb-08d841b3de17 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2020 07:13:25.2942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yYOmKaHl0BWGbAYH8KS4T0Y80ifz5yHF/HVqykKCbkzph81rb1o+c1sq5v31JRL1/z2/sETuM9lH2JCVZsXfSNaC1cLyb5afodWzw042TME= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZRAP278MB0093 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 07:13:44 -0000 ------=_Part_1311953_1608935745.1597562009047 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB01257142287FC55DC8990AFC895E0ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB01257142287FC55DC8990AFC895E0ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gyan, Gyan> IPFIX has been traditionally been used for flow analysis and to that = end all that was required is support of the data plane encapsulation. With= your proposed SR support idea you are really transforming the IPFIX to be = used for not just flow monitoring at that level solely, but now also to ana= lyze and troubleshoot data plane forwarding. That is a considerable depart= ure I think from what IPFIX was intended. I am not sure we want to add tha= t layer of complexity into IPFIX. Thomas> I have seen your feedback to Tarek and was puzzled about your remar= k about data plane encapsulation and IPFIX. I think you have a limited pict= ure for what IPFIX has been intended and being used. I do not want to lectu= re, but it might be useful to go back to the origins of Netflow and IPFIX. = At the beginning, the main reason for was to account traffic for BGP contro= l-plane dimensions. Such as BGP peer AS, src and dst prefix attribute. Thes= e helped to account traffic in shared enviroments. Later also for datacente= rs. These was and is always in conjunction with the encapsulated header met= rics of forwarded traffic and device dimensions such as ingress interface, = egress interface, vrf id and vrf name. In order to have a proper picture ab= out the forwarding plane, and to enable data correlation, key fields from o= ther perspectives (control-plane, forwarding-plane, device) are necessary t= o enable data correlation with other protocols such as BMP and YANG. Thomas> Going back to the initial conversation. Section 7.2 of RFC 5102 https://tools.ietf.org/html/rfc5102#section-7.2 For ensuring extensibility of this information, IANA has created a new registry for MPLS label types and filled it with the initial list from the description Information Element #46, mplsTopLabelType. Thomas> When IPFIX was specified, it has been defined in mind that other MP= LS label protocols will be developed in the future. Which is the case with = RFC 8665, 8666, 8667 and 8669. All adding TLV's to carry segment routing SI= D's. In the presentation I gave, I showed one of many vendors implemented I= E46 and showing the wrong value. Event though the label protocol was IS-IS = SR TLV, the value shown was LDP. This is not acceptable. When new protocols= are developed, we at IETF must ensure that they can be properly monitored.= With IPFIX we have the proper protocol to do that. Even without modificati= ons as section 4 in draft-ali-spring-sr-traffic-accounting mentioned: https= ://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#section-4 Thomas> You have been referring to complexity. One of the key objectives of= SR-MPLS was that it does not much change in the MPLS data plane. You need = to explain on this WG how SR differs from other MPLS label protocols in ter= ms of RIB/FIB. And then from there why an implementation would be difficult= . That's the discussion I am looking forward to. Best wishes Thomas From: Gyan Mishra Sent: Saturday, August 15, 2020 9:26 PM To: Graf Thomas, INI-NET-DCF Cc: hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.org; spr= ing@ietf.org Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas Responses in-line On Sat, Aug 15, 2020 at 2:02 AM > wrote: Hi Ketan, * This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. * What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? It is important to distinguish between intend and result. If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or n= ot. IE46 enables that by looking at the result of the forwarded traffic and= not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context. Gyan> IPFIX has been traditionally been used for flow analysis and to that = end all that was required is support of the data plane encapsulation. With= your proposed SR support idea you are really transforming the IPFIX to be = used for not just flow monitoring at that level solely, but now also to ana= lyze and troubleshoot data plane forwarding. That is a considerable depart= ure I think from what IPFIX was intended. I am not sure we want to add that layer of complexity into IPFIX. * What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels.= . With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabli= ng to analyze the result of this decision. The example with " Adjacency SID= or a LAN Adjacency SID" is not very useful because the difference of the two is the topology among the adj= acency. If you compare " Adjacency SID with Prefix SID", that makes much mo= re sense. Since it describes that a particular adjacency is chosen to forwa= rd the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we understand that result of that decis= ion lead to the drop and this enables to narrow down forwarding issues in s= egment routing networks more efficiently and quickly. > am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a better understanding wh= ere your fear is coming from. I would appreciate if you could differentiate= between MPLS Label Type identifier, IE46, from which label protocol the label was c= oming from and SrSidType which SID type was used. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is more important is that it is a Prefix SID. Hardly any= deployments would be running multiple protocols and learning the same pref= ix from different IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom whe= n we first discovered this shortcoming in vendor implementations. The key p= oint here, with these additional IPFIX MPLS Label Type identifiers we enabl= e the possibility to verify the label protocol migration without taking the label value into the considerat= ion. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementation can refer to the right= code point. With RFC 5102 the decision has been made that MPLS Label Type = identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends t= he IE 46 registry with the Segment Routing label protocol code points so wh= en OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX imp= lementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not possibl= e to different between Prefix and Node and Anycast SID. Many of these types= are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what make= sense. By purpose, all available SID types are listed in the draft. This w= ith the aim to start the discussion in the working groups what is possible = what makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which labe= l protocol was used to forward a particular packet, but also which SID type= to further understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and = learning the same prefix from different IGPs. IPFIX may be picking this inf= ormation from a FIB in some implementation where the protocol does not matt= er and this information is not available therein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control pl= ane elements and we can be sure more get added. Is there really much value = in differentiation between say an Adjacency SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update... Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools..ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_ZRAP278MB01257142287FC55DC8990AFC895E0ZRAP278MB0125CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_ZRAP278MB01257142287FC55DC8990AFC895E0ZRAP278MB0125CHEP_-- ------=_Part_1311953_1608935745.1597562009047 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE2MDcxMzI5WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCB825/o 3g8dFVye1Qsm0cKlBPU6HFwkiqV6XVYMl9ECyjB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAZ6eKa8PTXoUm9hd4QSBdaWsZiVlOIC4mTpZKVgq9Va1miCf4vapqfV8+ OiGP6VckBiJrtHO4p2U1bqkftH3s6scSaQzQtNY5SuV8uWPbLtJPXcQ5ynU8KGF67PnxJTJmCV5e pMTTAEhI8+kyBjG/Zymh76+L121mVqXHXuaXTlXWZ94biR/04FaW5PuCZSaaI12jtIm8+ewxJ5Z/ K2DQIy42U69JchT44aJkrk9J/txl7r/7y4wkYfE0BmRsiijiYreh9Na0RTIQO0oSp22X5VGRRG1i 63zsQhW9vJ5wPNdulliUCYYWrSPsRVQTmnAS6jBZF6RsQ625STrZQPPDjwAAAAAAAA== ------=_Part_1311953_1608935745.1597562009047-- From nobody Sun Aug 16 13:39:55 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0E93A1122; Sun, 16 Aug 2020 13:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OHAXnsihlBKg; Sun, 16 Aug 2020 13:39:44 -0700 (PDT) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 266163A1136; Sun, 16 Aug 2020 13:39:44 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id s81so3106402vkb.3; Sun, 16 Aug 2020 13:39:43 -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=TmWffxdvbvGn862UXdFqTpSrX1LEC1PmlKXYZTuCLtQ=; b=S9+yQ7ABVt/oWGe1rwJ8fWpQKXBToQrp5rnyz+jTXWKkUdzDPzgp/gP7HMct7fAedC 0jEEdfGfS0eaJ+OVH7UEfOzWlgRVZXFgDRKv/ZUCMt3IB5WY2EskF7O79cJPENJkn+f1 wT1Fu+hGOR+TU2nSYluM4JhmO0G+T+CvqbpS3LM3slNQuEVCvF0j2VLrj2zadJ5qM3Vo Z1JoJ0040dXz2fJMJPo7cXd6tnlNk+7mS/p67Wo/8dfMbcLKfhRLFli4Ny2VNOqGlVQA +mjzoQED6h9UrjG2srpnkwDBAT+6ESaWf8+jHiKQUK9u1jnOy18KtvxTsv8K01ZyZwTQ P2qw== 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=TmWffxdvbvGn862UXdFqTpSrX1LEC1PmlKXYZTuCLtQ=; b=oVnsZtGPr9Dp7F4pLde87wHQETe5lm7nOCjCxjAzHIxAcP3IC/N/9eUnPzFX6uZPrw PEeRdqrdR0cMB7NK2v3UvXVmeNGmEOXXVCNqHmemrSBS75eC9qPpVOLAr7VKzl+Phhb6 5PKvNRzzKBA7WovbnCukjSBR1obHYYXLgp/T5alGC1bDCRpAIuoa8vhC1682yg1GKTCD Gqzg6J72cMthq0kjHy/r4uGl+Avi6uB8DYmSlqcN78scOJLNJlf3NJiHp+ZVv1CVwpyn 4NAHKGUPANJPGL37wdJjyve4Jei/nYhV4B7hkLhdu3plE3WSzyfEMzMuQ5JtkYHeKFJK CVuA== X-Gm-Message-State: AOAM533HrX+D5JMsDwEwbky2WQUc/cY32rLF5ua16ey+W41yoX2+4ZFm YEGc37ImfI0iYeH4RZdSWFH+lQyOV/jhE5DVt/Y= X-Google-Smtp-Source: ABdhPJzc6rxhygLhUhwusboMlSdtO4fv9VLrRyPxZblxRDimPnZA6YOOBeTGwnqQ9QYngPVClfupGyP54uLOLyegLxY= X-Received: by 2002:a1f:1a0e:: with SMTP id a14mr6652600vka.87.1597610382778; Sun, 16 Aug 2020 13:39:42 -0700 (PDT) MIME-Version: 1.0 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> <1180087721.1311955.1597562009048@ss007564> In-Reply-To: <1180087721.1311955.1597562009048@ss007564> From: Gyan Mishra Date: Sun, 16 Aug 2020 16:39:31 -0400 Message-ID: To: Thomas.Graf@swisscom.com Cc: hannes@gredler.at, ketant@cisco.com, lsr@ietf.org, opsawg@ietf.org, spring@ietf.org Content-Type: multipart/alternative; boundary="0000000000005ae49e05ad04a7de" Archived-At: Subject: Re: [spring] [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 20:39:50 -0000 --0000000000005ae49e05ad04a7de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas Sorry for any misunderstanding. I am well aware of the origins and history behind IPFIX and Neflow and use with BGP monitoring. I was not aware of IE 46 and how that was being leveraged to support SR IGP extensions sid types. After reviewing your IPFIX slides related to IE 46 registry for mplsTopLabelType and this drafts solution to extend the IE 46 registry with SR and now requiring new IGP codepoints to be allocated. You had given an example in the LDP interworking example or others that with this new IGP codepoint in case of multiple control planes present such as both LDP and SR that with IPFIX and with the new IGP codepoint allocations for each IGP type that you can see the forwarding resulting FIB entry. I can see that as a benefit for monitoring telemetry In-line below addresses complexity of extending IE46 for SR support. On Sun, Aug 16, 2020 at 3:13 AM wrote: > > > > > > > > > > > > > > > > > Hi Gyan, > > > > > > Gyan> IPFIX has been traditionally been used for flow analysis and to tha= t > end all that was required is support of the data plane encapsulation. Wi= th > your proposed SR support idea you are really transforming the IPFIX > > to be used for not just flow monitoring at that level solely, but now als= o > to analyze and troubleshoot data plane forwarding. That is a considerabl= e > departure I think from what IPFIX was intended. I am not sure we want to > add that layer of complexity into > > IPFIX. > > > > > > Thomas> I have seen your feedback to Tarek and was puzzled about your > remark about data plane encapsulation and IPFIX. I think you have a limit= ed > picture for what IPFIX has been intended and being used. I do not want > > to lecture, but it might be useful to go back to the origins of Netflow > and IPFIX. At the beginning, the main reason for was to account traffic f= or > BGP control-plane dimensions. Such as BGP peer AS, src and dst prefix > attribute. These helped to account traffic > > in shared enviroments. Later also for datacenters. These was and is alway= s > in conjunction with the encapsulated header metrics of forwarded traffic > and device dimensions such as ingress interface, egress interface, vrf id > and vrf name. In order to have a proper > > picture about the forwarding plane, and to enable data correlation, key > fields from other perspectives (control-plane, forwarding-plane, device) > are necessary to enable data correlation with other protocols such as BMP > and YANG. > > > > > > > Thomas> Going back to the initial conversation. Section 7.2 of RFC 5102 > > > https://tools.ietf.org/html/rfc5102#section-7.2 > > > > > > For ensuring extensibility of this information, IANA has created a > > > new registry for MPLS label types and filled it with the initial list > > > from the description Information Element #46, mplsTopLabelType. > > > > > > Thomas> When IPFIX was specified, it has been defined in mind that other > MPLS label protocols will be developed in the future. Which is the case > with RFC 8665, 8666, 8667 and 8669. All adding TLV's to carry segment > routing > > SID's. In the presentation I gave, I showed one of many vendors > implemented IE46 and showing the wrong value. Event though the label > protocol was IS-IS SR TLV, the value shown was LDP. This is not acceptabl= e. > When new protocols are developed, we at IETF must > > ensure that they can be properly monitored. With IPFIX we have the proper > protocol to do that. Even without modifications as section 4 in > draft-ali-spring-sr-traffic-accounting mentioned: > > > > > https://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#sec= tion-4 > > > > > > Thomas> You have been referring to complexity. One of the key objectives > of SR-MPLS was that it does not much change in the MPLS data plane. You > need to explain on this WG how SR differs from other MPLS label protocols > > in terms of RIB/FIB. And then from there *why* an implementation would be > difficult. That=E2=80=99s the discussion I am looking forward to. > > > Gyan> SR-MPLS reuses the MPLS data plane so from that perspective is the > same but how it differs is with SR steering and MSD SID depth with SR-TE > especially when strict ERO is defined with adjacency SID the label stack = is > expanded. > With MPLS we are label swapping however with SR you are label stacking. So let=E2=80=99s say you have an SR-TE path instantiated and usi= ng the strict ERO path with adjacency SIDs defined, would just the active label being used in the forwarding plane be the one that IPFIX would be monitoring versus the entire stack of labels. > In theory it appears that the IPFIX machinery is in place with IE 46 to > support SR as what you have proposed in the draft. > As far as vendor compatibility as long as they support IE 46 they should support SR-MPLS. I don=E2=80=99t see any issues now as far as complexities to support as the= we are using existing machinery IPFIX IE 46 to extend for SR support. I think getting feedback from LSR is critical on their thoughts on complexity and caveats with getting the codepoints assigned. What about IPFIX SRv6 support? Comment on Section 2 A typical use case scenario is to monitor MPLS control plane migrations from LDP to IS-IS or OSPF. By looking at the MPLS label value itself, it is not always clear as to which label protocol it belongs, since they could potentially share the same label allocation range. This is the case for IGP-Adjacency SID's and LDP as an example. SR SRGB label range is different then LDP label range. > > > Best wishes > > > Thomas > > > > > > *From:* Gyan Mishra > > > > > *Sent:* Saturday, August 15, 2020 9:26 PM > > > *To:* Graf Thomas, INI-NET-DCF > > > *Cc:* hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.org; > spring@ietf.org > > > *Subject:* Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > > > > > > > > > > Hi Thomas > > > > > > > > > > > > > > Responses in-line > > > > > > > > > > > > > > > > On Sat, Aug 15, 2020 at 2:02 AM wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ketan, > > > > > > > > > > > > > > > > > > > > - > > This helps identification of specific SR-MPLS segment types as well as > differentiating them from LDP, RSVP-TE, etc. > > > > > > > > > > > > > To be precise, the existing MPLS Label Type identifier differentiates fro= m > LDP, RSVP-TE. > > Not the new SrSidType IPFIX IE being proposed. > > > > > > > > > > > > > > > > > > > > - > > What value is provided for IPFIX analysis if the SR Prefix SID was > being signalled via OSPF or ISIS? > > > > > > > > > > > > > It is important to distinguish between intend and result. > > > > > > > > > > > > If you migrate from one label distribution protocol to another, a network > operator > > want's to understand if the data plane is still forwarding > > > > > > packets with the label distribution protocol which needs to be removed or > not. IE46 enables that by looking at the result of the forwarded traffic > and not at the intend. RFC 8661 section 3, > > > > > > https://tools.ietf.org/html/rfc8661#section-3 > > , > > > > > > describes the context. > > > > > > > > > > > > Gyan> IPFIX has been traditionally been used for flow analysis and to tha= t > end all that was required is support of the data plane encapsulation. Wi= th > your proposed SR support idea you are really transforming the IPFIX to be > used for not > > just flow monitoring at that level solely, but now also to analyze and > troubleshoot data plane forwarding. That is a considerable departure I > think from what IPFIX was intended. > > > > > > > > > > > > > > I am not sure we want to add that layer of complexity into IPFIX. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > What value is provided for IPFIX analysis if it was a Adjacency SID or > a LAN Adjacency SID? > > > > > > > > > > > > > Quote from RFC8402. "Segment Routing (SR) leverages the source routing > paradigm". > > Means that not the routing protocol does all the forwarding > > > > > > decisions, the node can change the forwarding by pushing additional > labels.. With IPFIX SrSidType we are able to cover this dimension in IPFI= X. > Enabling to analyze the result of this decision. The example with " > Adjacency SID or a LAN Adjacency SID" is not > > > > > > very useful because the difference of the two is the topology among the > adjacency. If you compare " Adjacency SID with Prefix SID", that makes mu= ch > more sense. Since it describes that a particular adjacency is chosen to > forward the packet instead of a prefix. > > > > > > If IE 89, ForwardingStatus is drop, we understand that result of that > decision lead to the drop and this enables to narrow down forwarding issu= es > in segment routing networks more efficiently and quickly. > > > > > > > > > > > > =C3=98 > > > > > > am asking for WG to weigh the implementation complexities > > > > > > > > > > > > For the WG and me, I would be important if you can describe more detailed > what you mean > > with > > > > > > implementation complexities. I would like to have a better understanding > where your fear is coming from. I would appreciate if you could > differentiate between > > > > > > MPLS Label Type identifier, IE46, from which label protocol the label was > coming from and SrSidType which SID type was used. > > > > > > > > > > > > > > > > > > > > Best wishes > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > *From:* Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > *Sent:* Saturday, August 15, 2020 7:09 AM > > > > > > > > > *To:* Graf Thomas, INI-NET-DCF ; > > hannes@gredler.at > > > > > > > > > *Cc:* lsr@ietf.org; > > spring@ietf.org; opsawg@ietf.org > > > > > > > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > I should have been more clear in my email. > > > > > > > > > > > > The proposal/suggestion is to add the following to the IPFIX MPLS Label > type identifier registry: > > > > > > > > > > > > > > - > > SR Prefix SID > - > > SR Adjacency SID > - > > SR Binding SID > - > > SR BGP Peering SID > - > > =E2=80=A6 and so on > > > > > > > > > > > > > This helps identification of specific SR-MPLS segment types as well as > differentiating them from LDP, RSVP-TE, etc. > > > > > > > > > > > > And my questions were: > > > > > > > > > > > > > > 1. > > What value is provided for IPFIX analysis if the SR Prefix SID was > being signalled via OSPF or ISIS? > 2. > > What value is provided for IPFIX analysis if it was a Adjacency SID or > a LAN Adjacency SID? > > > > > > > > > > > > > I am asking for WG to weigh the implementation complexities and overheads > with the proposed details of SR-MPLS segments in IPFIX against the benefi= t > (if any) > > that they provide for the > > > > > > flow analysis and monitoring. > > > > > > > > > > > > Thanks, > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > *From:* > > > > > > > > Thomas.Graf@swisscom.com > > > > > > > > > > > > > > > *Sent:* 15 August 2020 09:40 > > > > > > > > > *To:* Ketan Talaulikar (ketant) ; > > > > > > hannes@gredler.at > > > > > > > > > *Cc:* lsr@ietf.org; > > > > > > > > spring@ietf.org; opsawg@ietf.org > > > > > > > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > > > > > > > > > > > > > Hi Ketan, > > > > > > > > > > > > Thank you very much for the review and feedback. > > > > > > > > > > > > > > > > > > > > - > > What or how much value be there on determining whether a SR Prefix SID > was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS > > > > > > =E2=80=93 what matters and is more important is that it is a Prefix SI= D. > Hardly any deployments would be running multiple protocols and learnin= g the > same prefix from different IGPs. > > > > > > > > > > > > > As Jeff already pointed out. Multiple IGP labelling protocols are used i= n > networks when migrations > > are ongoing. Usually in a life cycle. Migrating from > > > > > > LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom > when we first discovered this shortcoming in vendor implementations. The > key point here, with these additional IPFIX MPLS Label Type identifiers w= e > enable the possibility to verify the > > > > > > label protocol migration without taking the label value into the > consideration. > > > > > > > > > > > > > > > > > > > > - > > IPFIX may be picking this information from a FIB in some > implementation where the protocol does not matter and this information > > > > > > is not available therein. > > > > > > > > > > > > > I am not sure if you have seen the presentation in IETF 108 at OPSAWG and > SPRING. > > > > > > > https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-m= pls-sr-label-type-information-in-ipfix-00.pdf > > > > > > > > > > > > > Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label > Type identifier. There > > is an open ddts where vendor feasibility has been clarified. > > > > > > Ping me off the list when you like to have more details. > > > > > > > > > > > > I do understand your point that not all the vendors are capable to > implement IE 46. > > But that=E2=80=99s not the point about the IPFIX IE registry. > > > > > > The IE registry enables that an IPFIX implementation can refer to the > right code point. With RFC 5102 the decision has been made that MPLS Labe= l > Type identifier make sense > > > > > > and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends > the IE 46 registry with the Segment Routing label protocol code points so > when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX > implementation can point to the right > > > > > > code point. > > > > > > > > > > > > > > > > > > > > - > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP > =E2=80=93 what would we use/show? > > > > > > > > > > > > > In this case the IE 46 shows the label protocol which was used to program > the FIB. > > > > > > > > > > > > > > > > > > > > - > > > > > > > > For that table proposal, it is very difficult and in some cases not > possible to different between Prefix and Node and Anycast SID. Many of > these types are control plane elements and we can > > > > > > be sure more get added. > > > > > > > > > > > > > I fully agree. As a network operator its still hard to understand the > architecture > > and constraints within a router. When monitoring capabilities > > > > > > are discussed at IETF, this is the usual topic. What is possible, what > make sense. By purpose, all available SID types are listed in the draft. > This with the aim to start the discussion in the working groups what is > possible what makes sense. I would be interested > > > > > > to get your and also Jeff's feedback. > > > > > > > > > > > > In above mentioned slides I described how TI-LFA application would benefi= t > of visibility > > in the FIB by showing where Adj-SID was used. This > > > > > > should be a simple example why it make sense not only to look at which > label protocol was used to forward a particular packet, but also which SI= D > type to further understand the intend why this label is being pushed. > > > > > > > > > > > > I hope this makes all sense. Looking forward for reply. > > > > > > > > > > > > Best wishes > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > *From:* Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > *Sent:* Friday, August 14, 2020 7:35 PM > > > > > > > > > *To:* Graf Thomas, INI-NET-DCF ; > > > > > > hannes@gredler.at > > > > > > > > > *Cc:* lsr@ietf.org; SPRING WG > > > > > > > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > > > > > > > > > > > > > < also copying Spring WG for their review/inputs > > > > > > > > > > > > > Hi Thomas/All, > > > > > > > > > > > > I have reviewed the draft and would like to share a different perspective= . > > > > > > > > > > > > What or how much value be there on determining whether a SR Prefix SID wa= s > signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matt= ers and is > more important > > is that it is a > > > > > > Prefix SID. Hardly any deployments would be running multiple protocols an= d > learning the same prefix from different IGPs. IPFIX may be picking this > information from a FIB in some implementation where the protocol does not > matter and this information is not > > > > > > available therein. > > > > > > > > > > > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 > what would we use/show? > > > > > > > > > > > > I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, > SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type. > > > > > > > > > > > > This also takes away the need for the second table that is being proposed > to a large extent. For that table proposal, it is very difficult and in > some cases not > > possible to different > > > > > > between Prefix and Node and Anycast SID. Many of these types are control > plane elements and we can be sure more get added. Is there really much > value in differentiation between say an Adjacency SID and LAN Adjacency S= ID? > > > > > > > > > > > > Could we evaluate the implementation overhead and complexity of this leve= l > of categorization/information in IPFIX against their value in flow analys= is > to perhaps > > consider a middle ground? > > > > > > > > > > > > Thanks, > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > *From:* Lsr > > > > > > *On Behalf Of *Thomas.Graf@swisscom.com > > > > > > > > > *Sent:* 31 July 2020 20:52 > > > > > > > > > *To:* hannes@gredler.at > > > > > > > > > *Cc:* lsr@ietf.org > > > > > > > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > Thanks a lot for the feedback. Yes, makes completely sense. Will take it > for the > > next update... > > > > > > > > > > > > Best Wishes > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *From:* Hannes Gredler > > > > > > > > > > > > > > > *Sent:* Wednesday, July 29, 2020 9:31 AM > > > > > > > > > *To:* Graf Thomas, INI-NET-DCF > > > > > > > > > *Cc:* lsr@ietf.org > > > > > > > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > > > > > > > > > > > > > Thomas, > > > > > > > > > > > > > > > > > > > > > > > > > > > I have one comment/suggestion to Paragraph 4 (IANA Considerations). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please add also a code point for BGP Prefix-SID - it=E2=80=99s quite popu= lar in DC > deployments. > > > > > > > > > > > > > > > > > > > > > > > > https://tools..ietf.org/html/rfc8669 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /hannes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 28.07.2020, at 10:11, > > > > > > > > Thomas.Graf@swisscom.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Dear lsr, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I presented the following draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Export of MPLS Segment Routing Label Type Information in IP Flow > Information Export (IPFIX) > > > > > > > > > > > > > > > > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > at the spring working group at IETF 108 yesterday > > > > > > > > > > > > > > > > > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-inf= ormation-export-ipfix-00.pdf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and today at OPSAWG where I call for adoption. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This draft adds additional segment routing code points for in the IANA > IPFIX registry for IS-IS, > > OPSFv2 and OPSF v3 and segment routing SID types to gain > > > > > > further insights into the MPLS-SR forwarding-plane. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been asked to not only gather feedback from spring and opsawg but > also from lsr and mpls > > working groups since these code points are related to link > > > > > > state routing protocols and mpls data plane. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am looking forward to your feedback and input. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Wishes > > > > > > > > > > > > > > > > Thomas Graf > > > > > > > > > > > _______________________________________________ > > > > > > > > > Lsr mailing list > > > > > > > > > Lsr@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > OPSAWG mailing list > > > > > > OPSAWG@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > *Gyan Mishra* > > > *Network Solutions Architect * > > > > > > > > > *M 301 502-134713101 Columbia Pike > *Silver > Spring, MD > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000005ae49e05ad04a7de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas=C2=A0

Hi Gyan,

 

Gyan> IPFIX has been traditi= onally been used for flow analysis and to that end all that was required is= support of the data plane encapsulation.  With your proposed SR suppo= rt idea you are really transforming the IPFIX to be used for not just flow monitoring at that level solely, but now also= to analyze and troubleshoot data plane forwarding.  That is a conside= rable departure I think from what IPFIX was intended.  I am not s= ure we want to add that layer of complexity into IPFIX.

 

Thomas> I have seen your fee= dback to Tarek and was puzzled about your remark about data plane encapsula= tion and IPFIX. I think you have a limited picture for what IPFIX has been = intended and being used. I do not want to lecture, but it might be useful to go back to the origins of Netflow an= d IPFIX. At the beginning, the main reason for was to account traffic for B= GP control-plane dimensions. Such as BGP peer AS, src and dst prefix attrib= ute. These helped to account traffic in shared enviroments. Later also for datacenters. These was and is always= in conjunction with the encapsulated header metrics of forwarded traffic a= nd device dimensions such as ingress interface, egress interface, vrf id an= d vrf name. In order to have a proper picture about the forwarding plane, and to enable data correlation, key fi= elds from other perspectives (control-plane, forwarding-plane, device) are = necessary to enable data correlation with other protocols such as BMP and Y= ANG.

 

Thomas> Going back to the in= itial conversation. Section 7.2 of RFC 5102

https://tools.ietf.org/html/rfc5102#section-7.= 2

 

   For ensuring extensibility of = this information, IANA has created a

   new registry for MPLS label ty= pes and filled it with the initial list

   from the description Informati= on Element #46, mplsTopLabelType.

 

Thomas> When IPFIX was speci= fied, it has been defined in mind that other MPLS label protocols will be d= eveloped in the future. Which is the case with RFC 8665, 8666, 8667 and 866= 9. All adding TLV's to carry segment routing SID's. In the presentation I gave, I showed one of many vendors implemente= d IE46 and showing the wrong value. Event though the label protocol was IS-= IS SR TLV, the value shown was LDP. This is not acceptable. When new protoc= ols are developed, we at IETF must ensure that they can be properly monitored. With IPFIX we have the proper = protocol to do that. Even without modifications as section 4 in draft-ali-s= pring-sr-traffic-accounting mentioned: https://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#secti= on-4

 

Thomas> You have been referr= ing to complexity. One of the key objectives of SR-MPLS was that it does no= t much change in the MPLS data plane. You need to explain on this WG how SR= differs from other MPLS label protocols in terms of RIB/FIB. And then from there why an implementation woul= d be difficult. That’s the discussion I am looking forward to.

 

Best wishes

Thomas

 =

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Saturday, August 15, 2020 9:26 PM
To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
Cc: hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.o= rg; spring@ietf.org
Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

 

Hi Thomas 

 

Responses in-line 

 

On Sat, Aug 15, 2020 at 2:02 AM <Thomas.Graf@swisscom.com&= gt; wrote:












 

 

Hi Ketan,

 

 

 

 

  • This helps identification of specific SR-MPLS segment = types as well as differentiating them from LDP, RSVP-TE, etc.

 

 

 

To be precise, the existing MPL= S Label Type identifier differentiates from LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed.

 

 

 

 

  • What value is provided for IPFIX analysis if the SR Pr= efix SID was being signalled via OSPF or ISIS?

 

 

 

It is important to distinguish = between intend and result.

 

 

 

If you migrate from one label d= istribution protocol to another, a network operator want's to understand if the data plane is still forwarding

packets with the label distribution protocol which needs to be removed or n= ot. IE46 enables that by looking at the result of the forwarded traffic and= not at the intend. RFC 8661 section 3,

https://tools.ietf.org/html/rfc8661#section-3,

describes the context.

 

Gyan> IPFIX has been traditionally been used for = flow analysis and to that end all that was required is support of the data = plane encapsulation.  With your proposed SR support idea you are reall= y transforming the IPFIX to be used for not just flow monitoring at that level solely, but now also to analyze and tro= ubleshoot data plane forwarding.  That is a considerable departure I t= hink from what IPFIX was intended.  

 

I am not sure we want to add that layer of complexit= y into IPFIX.

 

 

 

 

  • What value is provided for IPFIX analysis if it was a = Adjacency SID or a LAN Adjacency SID?

 

 

 

Quote from RFC8402. "Segme= nt Routing (SR) leverages the source routing paradigm". Means that not the routing protocol does all the forwarding

decisions, the node can change the forwarding by pushing additional labels.= . With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabli= ng to analyze the result of this decision. The example with " Adjacenc= y SID or a LAN Adjacency SID" is not

very useful because the difference of the two is the topology among the adj= acency. If you compare " Adjacency SID with Prefix SID", that mak= es much more sense. Since it describes that a particular adjacency is chose= n to forward the packet instead of a prefix.

If IE 89, ForwardingStatus is drop, we understand that result of that decis= ion lead to the drop and this enables to narrow down forwarding issues in s= egment routing networks more efficiently and quickly.

 

 

 

Ø 

am asking for WG to weigh the implementation co= mplexities

 

 

 

For the WG and me, I would be importa= nt if you can describe more detailed what you mean with

implementation complexities. I would like to ha= ve a better understanding where your fear is coming from. I would appreciat= e if you could differentiate between

MPLS Label Type identifier, IE46,= from which label protocol the label was coming from and SrSidType which SI= D type was used.

 

 

 

Best wishes

 

Thomas

 

 

 

 

 

From: Keta= n Talaulikar (ketant) <ketant@cisco.com>




Sent: Saturday, August 15, 2020 7:09 AM


To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at


Cc: lsr@ietf.org; spring@ietf.org; o= psawg@ietf.org


Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type<= /o:p>

 

 

 

 

 

Hi Thomas,

 

 

 

I should have been more clear in my email.

 

 

 

The proposal/suggestion is to add the followi= ng to the IPFIX MPLS Label type identifier registry:

 

 

  • SR Prefix SID
  • SR Adjacency SID
  • SR Binding SID
  • SR BGP Peering SID
  • … and so on

 

 

 

This helps identification of specific SR-MPLS= segment types as well as differentiating them from LDP, RSVP-TE, etc.

 

 

 

And my questions were:

 

 

  1. What value is provided for IPFIX analysis if the SR Pr= efix SID was being signalled via OSPF or ISIS?
  2. What value is provided for IPFIX analysis if it was a = Adjacency SID or a LAN Adjacency SID?

 

 

 

I am asking for WG to weigh the implementatio= n complexities and overheads with the proposed details of SR-MPLS segments = in IPFIX against the benefit (if any) that they provide for the

flow analysis and monitoring.

 

 

 

Thanks,

 

Ketan

 

 

 

 

 

From:

Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>




Sent: 15 August 2020 09:40


To: Ketan Talaulikar (ketant) <ketant@cisco.com>;

hannes@gredler.at


Cc: lsr@ietf.org;

spring@ietf.org; o= psawg@ietf.org


Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type<= /o:p>

 

 

 

 

 

Hi Ketan,

 

 

 

Thank you very much for the rev= iew and feedback.

 

 

 

 

  • What or how much value be there on determining whether= a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS<= br>
    – what matters and is more important is that it is a Prefix SID. Hard= ly any deployments would be running multiple protocols and learning the sam= e prefix from different IGPs.

 

 

 

As Jeff already pointed out. Multiple IGP labe= lling protocols are used  in networks when migrations are ongoing. Usually in a life cycle. Migrating from

LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom whe= n we first discovered this shortcoming in vendor implementations. The key p= oint here, with these additional IPFIX MPLS Label Type identifiers we enabl= e the possibility to verify the

label protocol migration without taking the label value into the considerat= ion.

 

 

 

 

  • IPFIX may be picking this information from a FIB in so= me implementation where the protocol does not matter and this information
    is not available therein.

 

 

 

I am not sure if you have seen the presentatio= n in IETF 108 at OPSAWG and SPRING.

 

https://www.ietf.org/proceedings/108/slides/slides-= 108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf

 

 

 

Slide 2 shows Cisco as example vendor which im= plemented IE 46, MPLS Label Type identifier. There is an open ddts where vendor feasibility has been clarified.

Ping me off the list when you like to have more details.<= /p>

 

 

 

I do understand your point that= not all the vendors are capable to implement IE 46. But that’s not the point about the IPFIX IE registry.

The IE registry enables that an IPFIX implementa= tion can refer to the right code point. With RFC 5102 the decision has been= made that MPLS Label Type identifier make sense

and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends t= he IE 46 registry with the Segment Routing label protocol code points so wh= en OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX imp= lementation can point to the right

code point.

 

 

 

 

  • On some nodes, the same Prefix SID may be learnt via b= oth BGP and IGP – what would we use/show?

 

 

 

In this case the IE 46 shows the labe= l protocol which was used to program the FIB.

 

 

 

 



  • For that table proposal, it= is very difficult and in some cases not possible to different between Pref= ix and Node and Anycast SID. Many of these types are control plane elements= and we can

    be sure more get added.

 

 

 

I fully agree. As a network ope= rator its still hard to understand the architecture and constraints within a router. When monitoring capabilities

are discussed at IETF, this is the usual topic. What is possible, what make= sense. By purpose, all available SID types are listed in the draft. This w= ith the aim to start the discussion in the working groups what is possible = what makes sense. I would be interested

to get your and also Jeff's feedback.

 

 

 

In above mentioned slides I described= how TI-LFA application would benefit of visibility in the FIB by showing where Adj-SID was used. This

should be a simple example why it make sense not only to look at which labe= l protocol was used to forward a particular packet, but also which SID type= to further understand the intend why this label is being pushed.

 

 

 

I hope this makes all sense. Lo= oking forward for reply.

 

 

 

Best wishes

 

Thomas

 

 

 

 

 

From: Ketan Talaulikar (ketant) <ketant@cisco.com>




Sent: Friday, August 14, 2020 7:35 PM


To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;

hannes@gredler.at


Cc: lsr@ietf.org; SPRING WG <spri= ng@ietf.org>


Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

 

 

 

 

 

< also copying Spring WG for their review/= inputs >

 

 

 

Hi Thomas/All,

 

 

 

I have reviewed the draft and would like to s= hare a different perspective.

 

 

 

What or how much value be there on determinin= g whether a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSP= Fv3/ISIS – what matters and is more important is that it is a

Prefix SID. Hardly any deployments would be running multiple protocols and = learning the same prefix from different IGPs. IPFIX may be picking this inf= ormation from a FIB in some implementation where the protocol does not matt= er and this information is not

available therein.

 

 

 

On some nodes, the same Prefix SID may be lea= rnt via both BGP and IGP – what would we use/show?<= /p>

 

 

 

I would recommend using SR Prefix SID, SR Adj= acency SID, SR Binding SID, SR BGP Peering SID and so on … for the MP= LS Label Type.

 

 

 

This also takes away the need for the second = table that is being proposed to a large extent. For that table proposal, it= is very difficult and in some cases not possible to different

between Prefix and Node and Anycast SID. Many of these types are control pl= ane elements and we can be sure more get added. Is there really much value = in differentiation between say an Adjacency SID and LAN Adjacency SID?

 

 

 

Could we evaluate the implementation overhead= and complexity of this level of categorization/information in IPFIX agains= t their value in flow analysis to perhaps consider a middle ground?

 

 

 

Thanks,

 

Ketan

 

 

 

 

 

 

Hi Hannes,

 

 

 

Thanks a lot for the feedback. = Yes, makes completely sense. Will take it for the next update...

 

 

 

Best Wishes

 

Thomas

 

 

 

 

 

 

 

 

 

 

Thomas,

 

 

 

 

 

 

I have one comment/suggestion to Paragraph 4 (IANA Considerations)= .

 

 

 

 

 

 

 

Please add also a code point for BGP Prefix-SID - it’s quite= popular in DC deployments.

 

 

 

 

 

 

 

 

thanks,

 

 

 

 

 

 

 

/hannes

 

 

 

 

 

 

 

 

On 28.07.2020, at 10:11,

Thomas.Graf@swisscom.com wrote:

 

 

 

 

 

 

Dear lsr,

 

 

 

 

 

 

 

I presented the following draft

 

 

 

 

 

 

 

Export of MPLS Segment Routing Label Type Inf= ormation in IP Flow Information Export (IPFIX)

 

 

 

 

 

 

 

 

at the spring working group at IETF 108 yeste= rday

 

 

 

 

 

 

 

 

and today at OPSAWG where I call for adoption= .

 

 

 

 

 

 

 

This draft adds additional segment routing co= de points for in the IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain

further insights into the MPLS-SR forwarding-plane.

 

 

 

 

 

 

 

I have been asked to not only gather feedback= from spring and opsawg but also from lsr and mpls working groups since these code points are related to link

state routing protocols and mpls data plane.

 

 

 

 

 

 

 

I am looking forward to your feedback and inp= ut.

 

 

 

 

 

 

 

Best Wishes

 

 

 

Thomas Graf

 

 

_______________________________________________


Lsr mailing list


Ls= r@ietf.org


https://www.ietf.org/mailman/listinfo/lsr

 

 

 

 

 

 

 

 





_______________________________________________

OPSAWG mailing list

OPSAWG@ietf.org
https://w= ww.ietf.org/mailman/listinfo/opsawg

 

--

Gyan = Mishra

Network = Solutions Architect 

M 301 50= 2-1347
13101 Columbia Pike 
Silver Spring, MD<= /p>

 


Sorry for any misunderstanding.=C2=A0 I am well aware = of the origins and history behind IPFIX and Neflow and use with BGP monitor= ing. =C2=A0

I was not aw= are of IE 46 and how that was being leveraged to support SR IGP extensions = sid types.

After =C2=A0r= eviewing your IPFIX slides related to IE 46 registry for mplsTopLabelType a= nd this drafts solution to extend the IE 46 registry with SR and now requir= ing new IGP codepoints to be allocated. =C2=A0

<= /div>
You had given an example in the LDP interworking exa= mple or others that with this new IGP codepoint in case of multiple control= planes present such as both LDP and SR that with IPFIX and with the new IG= P codepoint allocations for each IGP type that you can see the forwarding r= esulting FIB entry.=C2=A0 I can see that as a benefit for monitoring teleme= try=C2=A0

In-line = =C2=A0below addresses complexity of extending IE46 for SR support.
On Sun, A= ug 16, 2020 at 3:13 AM <Thom= as.Graf@swisscom.com> wrote:



<= br>











Hi Gyan,



=C2=A0



Gyan&= gt; IPFIX has been traditionally been used for flow analysis and to that en= d all that was required is support of the data plane encapsulation.=C2=A0 W= ith your proposed SR support idea you are really transforming the IPFIX
=
to be used for not just flow monitoring at that level solely, but now = also to analyze and troubleshoot data plane forwarding.=C2=A0 That is a con= siderable departure I think from what IPFIX was intended.=C2=A0=C2=A0I am n= ot sure we want to add that layer of complexity into

IPFIX.<= u>



=C2=A0



Thomas> I have seen your feedback to Tarek and was puzzled about your = remark about data plane encapsulation and IPFIX. I think you have a limited= picture for what IPFIX has been intended and being used. I do not want
=
to lecture, but it might be useful to go back to the origins of Netflo= w and IPFIX. At the beginning, the main reason for was to account traffic f= or BGP control-plane dimensions. Such as BGP peer AS, src and dst prefix at= tribute. These helped to account traffic

in shared enviroments. Lat= er also for datacenters. These was and is always in conjunction with the en= capsulated header metrics of forwarded traffic and device dimensions such a= s ingress interface, egress interface, vrf id and vrf name. In order to hav= e a proper

picture about the forwarding plane, and to enable data c= orrelation, key fields from other perspectives (control-plane, forwarding-p= lane, device) are necessary to enable data correlation with other protocols= such as BMP and YANG.



=C2=A0



Thomas> Going back to the initia= l conversation. Section 7.2 of RFC 5102



https://tools.ietf.org/html/rfc= 5102#section-7.2



=C2=A0



=C2=A0=C2=A0 For ensuring extensibility of this information= , IANA has created a



=C2=A0=C2=A0 new registry for MPLS label types and= filled it with the initial list

<= br>

=C2=A0=C2=A0 from the description Info= rmation Element #46, mplsTopLabelType.



=C2=A0



Thomas>= When IPFIX was specified, it has been defined in mind that other MPLS labe= l protocols will be developed in the future. Which is the case with RFC 866= 5, 8666, 8667 and 8669. All adding TLV's to carry segment routing
SID's. In the presentation I gave, I showed one of many vendors impl= emented IE46 and showing the wrong value. Event though the label protocol w= as IS-IS SR TLV, the value shown was LDP. This is not acceptable. When new = protocols are developed, we at IETF must

ensure that they can be pr= operly monitored. With IPFIX we have the proper protocol to do that. Even w= ithout modifications as section 4 in draft-ali-spring-sr-traffic-accounting= mentioned:



https://tools= .ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#section-4



= =C2=A0



Thomas> You have been referring to complexity. One of the key objec= tives of SR-MPLS was that it does not much change in the MPLS data plane. Y= ou need to explain on this WG how SR differs from other MPLS label protocol= s

in terms of RIB/FIB. And then from there why an implementa= tion would be difficult. That=E2=80=99s the discussion I am looking forward= to.



Gyan> SR-MPLS reuses the MPLS data plane so from that =C2= =A0perspective is the same but how it differs is with SR steering and MSD S= ID depth with SR-TE especially when strict ERO is defined with adjacency SI= D the label stack is expanded. =C2=A0


=C2=A0 =C2=A0 With MPLS we are = label swapping however with SR you are label stacking.=C2=A0 So let=E2=80= =99s say you have an SR-TE path instantiated and using the strict ERO path = with adjacency SIDs defined, =C2=A0would just the active label being used i= n the forwarding plane be the one that IPFIX would be monitoring versus the= entire stack of labels.

In theory it appears that the IPFIX machinery is in place with IE 46 to= support SR as what you have proposed in the draft. =C2=A0

=

=C2= =A0 =C2=A0 As far as vendor compatibility as long as they =C2=A0 =C2=A0 =C2= =A0 =C2=A0 support IE 46 they should support SR-MPLS.

I don=E2=80=99t see any issues now as far as = complexities to support as the we are using existing machinery IPFIX IE 46 = to extend for SR support. =C2=A0

I think getting feedback from LSR is critical on their thoughts o= n complexity and caveats with getting the codepoints assigned.

What about IPFIX =C2=A0SRv6 support?=

Comment on Section 2

   A=
 typical use case scenario is to monitor MPLS control plane
   migration=
s from LDP to IS-IS or OSPF.  By looking at the MPLS label
   value itse=
lf, it is not always clear as to which label protocol it
   belongs, sin=
ce they could potentially share the same label allocation
   range.  Thi=
s is the case for IGP-Adjacency SID's and LDP as an
   example.
SR SRGB label range is different then LDP label rang=
e.
=C2=A0 =C2=A0 =C2=A0=C2=A0

=

Best wishes=



Thomas



= =C2=A0=



From: Gyan Mishra <hayabusagsm@gmail.com>



<= br>Sent: Saturday, August 15, 2020 9:26 PM


To: Gra= f Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>


Cc: hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.org; spring@ietf.org


Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type



=C2=A0

<= br>




=C2=A0









Hi Thomas=C2=A0







=C2=A0






Responses in-line=C2=A0





=C2=A0










On Sat= , Aug 15, 2020 at 2:02 AM <Thomas.Graf@swisscom.com> wrote:

<= br>







<= br>






=





























=C2=A0









=C2=A0


Hi Ketan,



=C2=A0



=C2=A0



=C2=A0





<= /u>=C2=A0







  • This helps identification of specific SR-MP= LS segment types as well as differentiating them from LDP, RSVP-TE, etc.


=C2=A0



=C2=A0



=C2=A0


To be = precise, the existing MPLS Label Type identifier differentiates from LDP, R= SVP-TE.

Not the new SrSidType IPFIX IE being proposed.



= =C2=A0



= =C2=A0



=C2=A0





= =C2=A0







  • What value is pro= vided for IPFIX analysis if the SR Prefix SID was being signalled via OSPF = or ISIS?


=C2=A0



=C2=A0



=C2=A0



It is importan= t to distinguish between intend and result.


=C2=A0

=C2=A0<= u>



=C2=A0



If you migrate from one label distribution protocol to anoth= er, a network operator

want's to understand if the data plane i= s still forwarding





packets with the label distributi= on protocol which needs to be removed or not. IE46 enables that by looking = at the result of the forwarded traffic and not at the intend. RFC 8661 sect= ion 3,





https://tools.ietf.org/html/rfc8661#section-3,





d= escribes the context.



=C2=A0









<= p class=3D"MsoNormal">Gyan> IPFIX has been traditionally been used for f= low analysis and to that end all that was required is support of the data p= lane encapsulation.=C2=A0 With your proposed SR support idea you are really= transforming the IPFIX to be used for not

just flow monitoring at = that level solely, but now also to analyze and troubleshoot data plane forw= arding.=C2=A0 That is a considerable departure I think from what IPFIX was = intended.=C2=A0=C2=A0







<= p class=3D"MsoNormal">=C2=A0






I am not sure we want to add that layer of com= plexity into IPFIX.


















=C2=A0



=C2=A0



=C2=A0





=C2=A0







    What value is provided f= or IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?<= u>


=C2=A0



=C2=A0



=C2=A0


<= br>

Quote fro= m RFC8402. "Segment Routing (SR) leverages the source routing paradigm= ".

Means that not the routing protocol does all the forwarding=





decisions, the node can change the forwarding by pu= shing additional labels.. With IPFIX SrSidType we are able to cover this di= mension in IPFIX. Enabling to analyze the result of this decision. The exam= ple with " Adjacency SID or a LAN Adjacency SID" is not




very useful because the difference of the two is the topology= among the adjacency. If you compare " Adjacency SID with Prefix SID&q= uot;, that makes much more sense. Since it describes that a particular adja= cency is chosen to forward the packet instead of a prefix.



<= br>
If IE 89, ForwardingStatus is drop, we understand that result of tha= t decision lead to the drop and this enables to narrow down forwarding issu= es in segment routing networks more efficiently and quickly.<= u>



=C2=A0



=C2=A0



=C2=A0



=C3=98=C2=A0




am asking for WG to weigh the impleme= ntation complexities



=C2=A0



=C2=A0



= =C2=A0



For the WG and me, I would be imp= ortant if you can describe more detailed what you mean

with

=



implementation complexities. I = would like to have a better understanding where your fear is coming from. I= would appreciate if you could differentiate between




MPLS Label Type identifier,= IE46, from which label protocol the label was coming from and SrSidType wh= ich SID type was used.





=





=C2=A0



=C2=A0



=C2=A0


=

Best wis= hes



=C2=A0



Thomas



=C2=A0


=C2=A0=



=C2=A0




=C2=A0

=C2=A0<= u>



=C2=A0



Hi T= homas,



=C2=A0



=C2=A0



=C2=A0



I should have been more clear in my ema= il.



=C2=A0



=C2=A0



=C2=A0



The proposal/suggestion is to add the follow= ing to the IPFIX MPLS Label type identifier registry:<= /p>

=C2= =A0





=C2=A0



<= ul type=3D"disc">



  • SR Prefix SID


  • <= span lang=3D"EN-IN">SR Adjacency SID


  • SR Binding SID=


  • SR BGP Peering SI= D


  • =E2=80=A6 and so on


    • =C2=A0



    =C2=A0


    =C2=A0



    This helps identi= fication of specific SR-MPLS segment types as well as differentiating them = from LDP, RSVP-TE, etc.



    =C2=A0



    =C2=A0



    =

    =C2=A0

    And my questions were:=



    =C2=A0





    =C2=A0=







    1. What value is = provided for IPFIX analysis if the SR Prefix SID was being signalled via OS= PF or ISIS?


    2. What value is provided for IPFIX analysis if it was a Adjace= ncy SID or a LAN Adjacency SID?


    =C2=A0


    =

    =C2=A0=



    =C2= =A0



    I am aski= ng for WG to weigh the implementation complexities and overheads with the p= roposed details of SR-MPLS segments in IPFIX against the benefit (if any)
    that they provide for the





    flow analysis and m= onitoring.



    =C2=A0



    = =C2=A0



    =C2=A0



    Thanks,


    <= br>

    =C2=A0=



    Ketan=



    <= /u>=C2=A0



    =C2= =A0



    =C2=A0





    =C2=A0





    =C2=A0



    From:






    Thomas.Graf@swisscom.com     <Thomas.Graf@swisscom.com>



    <= br>









    Sent: 15 August 2020 09:4= 0








    To: Ketan Talaulikar (ketant) &= lt;ketant@cisco.com>;





    hannes@gredler.at








    Cc:= lsr@ietf.org;





    =

    spring@ietf.org; opsawg@ietf.org








    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

    <= br>

    =C2=A0=





    =C2=A0





    =C2=A0



    =C2=A0



    =C2=A0


    =

    Hi Ketan,=



    <= /u>=C2=A0



    =C2=A0



    =C2=A0



    Thank you very much for the review and= feedback.



    =C2=A0



    = =C2=A0


    =

    =C2=A0





    =C2=A0






    • =
      What or how much value be there on determining whe= ther a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3/I= SIS





      =E2=80=93 what matters and is more important is = that it is a Prefix SID. Hardly any deployments would be running multiple p= rotocols and learning the same prefix from different IGPs.      =


    <= u>=C2=A0



    = =C2=A0



    =C2=A0



    As Jeff already pointed out. Multiple IGP labelling pr= otocols are used =C2=A0in networks when migrations

    are ongoing. Usu= ally in a life cycle. Migrating from





    LDP to OSPFv2/O= SPFv3/ISIS SR TLV. This is/was also the case at Swisscom when we first disc= overed this shortcoming in vendor implementations. The key point here, with= these additional IPFIX MPLS Label Type identifiers we enable the possibili= ty to verify the





    label protocol migration without ta= king the label value into the consideration.


    =C2=A0<= /p>

    =C2=A0=



    <= /u>=C2=A0





    =C2=A0






    • IPFIX may be picking this information from a FIB in some impleme= ntation where the protocol does not matter and this information


      =


      is not available therein.

    =C2=A0

    =C2=A0<= u>



    =C2=A0



    = I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING.



    =C2=A0



    https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-= export-of-mpls-sr-label-type-information-in-ipfix-00.pdf<= u>



    =C2=A0



    =C2= =A0



    =C2=A0



    Slide 2 shows Cisco as example vendor which implemented I= E 46, MPLS Label Type identifier. There

    is an open ddts where vendo= r feasibility has been clarified.





    Ping me off the li= st when you like to have more details.



    =C2=A0


    =C2=A0



    =C2=A0



    I do understand your point that not all the vendors are capab= le to implement IE 46.

    But that=E2=80=99s not the point about the I= PFIX IE registry.





    Th= e IE registry enables that an IPFIX implementation can refer to the right c= ode point. With RFC 5102 the decision has been made that MPLS Label Type id= entifier make sense





    and can be implemented. draft-tg= raf-ipfix-mpls-sr-label-type just extends the IE 46 registry with the Segme= nt Routing label protocol code points so when OSPFv2/OSPFv3/ISIS SR TLV is = used, and IE 46 is supported, the IPFIX implementation can point to the rig= ht





    code point.



    =C2=A0


    =

    =C2=A0=



    =C2= =A0





    =C2=A0



    <= ul type=3D"disc">



  • On some nodes, the same Prefix SID may be learnt via both BGP and IGP = =E2=80=93 what would we use/show?


    • =C2=A0


    =C2=A0=



    =C2=A0



    In this case the= IE 46 shows the label protocol which was used to program the FIB.



    =C2=A0



    =C2=A0



    =C2=A0





    =C2=A0












      For that table pro= posal, it is very difficult and in some cases not possible to different bet= ween Prefix and Node and Anycast SID. Many of these types are control plane= elements and we can





      be sure more get added.      <= u>


    =C2=A0



    =C2=A0



    =C2=A0


    <= br>

    I fully a= gree. As a network operator its still hard to understand the architecture
    and constraints within a router. When monitoring capabilities




    are discussed at IETF, this is the usual topic. What is po= ssible, what make sense. By purpose, all available SID types are listed in = the draft. This with the aim to start the discussion in the working groups = what is possible what makes sense. I would be interested




    to get your and also Jeff's feedback.


    =

    =C2=A0



    =C2=A0



    =C2=A0



    In above = mentioned slides I described how TI-LFA application would benefit of visibi= lity

    in the FIB by showing where Adj-SID was used. This


    =


    should be a simple example why it make sense not only to look a= t which label protocol was used to forward a particular packet, but also wh= ich SID type to further understand the intend why this label is being pushe= d.



    =C2=A0



    =C2=A0



    =C2=A0


    I hope = this makes all sense. Looking forward for reply.


    =C2=A0<= /u>



    =C2=A0



    =C2=A0



    Best wishes



    =C2=A0



    Thomas



    <= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">=C2=A0

    =

    =C2=A0



    = =C2=A0





    =C2=A0





    =C2=A0



    From: Ke= tan Talaulikar (ketant) <ketant@cisco.com>










    =



    Sent: Friday, August 14, 2020 7:35 PM







    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;





    hannes@gredler.at








    Cc:= lsr@ietf.org; SP= RING WG <spring@iet= f.org>








    Subject: RE: [Lsr] = draft-tgraf-ipfix-mpls-sr-label-type



    =C2=A0





    =C2=A0=





    =C2=A0



    =C2=A0<= /u>



    <= u>=C2=A0



    = < also copying Spring WG for their review/inputs >



    = =C2=A0



    =C2=A0=



    =C2=A0



    Hi Thomas/All,



    =C2=A0



    =C2=A0



    =

    =C2=A0

    I have reviewed the dr= aft and would like to share a different perspective.

    =C2=A0=



    =C2=A0



    =C2=A0



    What or how much value be there on determining whether a SR Prefix SID= was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what m= atters and is more important

    is that it is a




    Prefix SID. Hardly any deployments would be running multiple protocols and= learning the same prefix from different IGPs. IPFIX may be picking this in= formation from a FIB in some implementation where the protocol does not mat= ter and this information is not





    available therein.



    =C2=A0



    =C2=A0



    =C2=A0



    On some nodes, the same Prefix SID may be learn= t via both BGP and IGP =E2=80=93 what would we use/show?



    = =C2=A0



    =C2=A0=



    =C2=A0



    I would recommend using SR Prefix SID, SR Adjacency SID, SR Bind= ing SID, SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type.



    =C2=A0



    =C2=A0



    =C2=A0



    This also takes away the need for the second table= that is being proposed to a large extent. For that table proposal, it is v= ery difficult and in some cases not

    possible to different




    between Prefix and Node and Anycast SID. Many of these types = are control plane elements and we can be sure more get added. Is there real= ly much value in differentiation between say an Adjacency SID and LAN Adjac= ency SID?



    =C2=A0



    <= span lang=3D"EN-IN">=C2=A0



    =C2=A0



    Could we evaluate the implementation o= verhead and complexity of this level of categorization/information in IPFIX= against their value in flow analysis to perhaps

    consider a middle = ground?



    =C2=A0



    =C2=A0



    =C2=A0



    Thanks,


    =C2=A0

    Ketan



    =C2=A0



    =C2= =A0



    =C2=A0





    =C2=A0





    =C2=A0



    From: Lsr <lsr-bounces@ietf.org<= /a>>





    On Behalf Of     Thomas.Graf@swisscom.com

    <= br>





    Sent: 31 July 2020 20:52



    <= br>



    To: hannes@gredler.at








    Cc:= lsr@ietf.org
    =







    Subject: Re: [Lsr] draft-tgraf-ipfix= -mpls-sr-label-type



    =C2=A0





    =

    =C2=A0



    = =C2=A0



    =C2=A0



    =C2=A0



    Hi Hannes,



    =C2=A0


    =C2=A0



    =C2= =A0



    Thanks a lot for the feedback. Yes, makes completely sense. Will = take it for the

    next update...



    =C2=A0


    =C2=A0<= /span>



    =C2=A0



    Best Wishes



    <= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">=C2=A0

    =

    Thom= as



    =C2=A0





    =C2=A0



    =C2=A0



    =C2=A0


    <= br>


    =C2=A0



    = =C2=A0



    =C2=A0





    =C2=A0





    =C2=A0



    From: Hannes Gr= edler <hannes@gre= dler.at>














    = Sent: Wednesday, July 29, 2020 9:31 AM







    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>







    Cc: lsr@ietf.org








    Subject:= Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

    =C2=A0<= u>





    =C2=A0





    =C2=A0



    =C2=A0



    =C2=A0



    Thomas,



    =C2=A0





    =C2=A0



    =C2=A0



    =C2=A0





    =C2=A0


    =


    =C2=A0



    I have one comment/suggest= ion to Paragraph 4 (IANA Considerations).



    =C2=A0




    = =C2=A0





    =C2=A0



    =C2= =A0



    =C2=A0





    =C2=A0





    <= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">=C2=A0

    =

    Please add also a code point for BGP Prefix-= SID - it=E2=80=99s quite popular in DC deployments.


    =C2=A0<= /p>



    =C2=A0









    =




    =C2=A0




    =C2=A0

    =C2=A0



    =C2=A0




    = =C2=A0





    =C2=A0



    thank= s,



    =C2=A0





    =C2=A0





    =C2=A0

    <= br>

    =C2=A0



    =C2=A0





    =C2=A0=





    =C2=A0



    /hannes<= /u>



    <= u>=C2=A0





    =C2=A0





    =C2=A0


    <= br>


    = =C2=A0



    =C2=A0



    =C2=A0





    =C2=A0





    =C2=A0



    On 28.07.2020, at 10:11,







    Thomas.Graf@swisscom.c= om     wrote:



    =C2=A0





    =C2=A0



    =C2=A0



    =C2=A0





    =C2=A0

    <= br>


    = =C2=A0



    Dear lsr,=



    = =C2=A0





    =C2=A0





    =C2=A0


    <= br>

    =C2=A0



    =C2=A0


    <= br>


    =C2=A0





    =C2=A0



    I presented the following draft


    =

    =C2=A0





    =C2=A0





    =C2=A0



    =C2=A0



    =C2=A0





    =C2= =A0





    =C2=A0



    Export of MPLS Segment Routing Label Type Information in IP Flow= Information Export (IPFIX)



    =C2=A0



    =

    =C2=A0





    =C2=A0




    =C2=A0



    =C2=A0


    =C2=A0





    =C2=A0





    =C2=A0



    at the spring working group at IETF 108 yesterday=



    =C2=A0





    =C2=A0





    =C2=A0





    =C2=A0



    =C2=A0


    =C2=A0



    =C2=A0





    =C2=A0



    and today at OPSAWG where I call for adoption.



    =C2=A0





    =C2=A0





    =C2=A0


    =C2=A0=



    =C2= =A0





    =C2=A0





    =C2=A0



    This draft adds additional segment routin= g code points for in the IANA IPFIX registry for IS-IS,

    OPSFv2 and = OPSF v3 and segment routing SID types to gain





    furthe= r insights into the MPLS-SR forwarding-plane.


    <= br>

    =C2=A0=





    =C2=A0





    =C2=A0



    =C2=A0



    =C2=A0





    =C2= =A0





    =C2=A0



    I have been asked to not only gather feedback from spring and op= sawg but also from lsr and mpls

    working groups since these code poi= nts are related to link





    state routing protocols and = mpls data plane.



    =C2=A0





    =C2=A0




    <= /u>=C2=A0



    =C2= =A0



    =C2=A0





    =C2=A0




    =C2=A0<= /u>



    I am looking forwa= rd to your feedback and input.



    =C2=A0





    =C2= =A0





    =C2=A0



    =C2=A0



    =C2=A0





    =C2=A0

    <= br>


    = =C2=A0



    Best= Wishes



    =C2=A0





    =C2=A0





    =C2=A0=



    Thomas Graf



    =C2=A0





    =C2=A0



    __= _____________________________________________







    Lsr mailing list








    Lsr@ietf.org



    =




    https://www.ietf.org/mailman/listinfo/lsr



    =C2=A0





    =C2=A0




    =C2=A0<= /p>



    =C2=A0



    =C2=A0



    = =C2=A0





    =C2=A0





    =C2=A0








    <= br>







    ________________________________________= _______





    OPSAWG mailing list





    <= a href=3D"mailto:OPSAWG@ietf.org" target=3D"_blank">OPSAWG@ietf.org
    =




    https://www.ietf.org/mailman/listinfo/opsawg=









    =C2=A0





    --








    =


    --
    <= div dir=3D"ltr">


    Gy= an Mishra

    Net= work Solutions A= rchitect=C2=A0

    M 301 502-1347
    = 13101 Columbia Pike=C2=A0
    Silver Spring, MD

    --0000000000005ae49e05ad04a7de-- From nobody Sun Aug 16 20:05:15 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80403A130D; Sun, 16 Aug 2020 20:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UV7mW5UzIsmf; Sun, 16 Aug 2020 20:04:53 -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 415BD3A1307; Sun, 16 Aug 2020 20:04:53 -0700 (PDT) Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 588DC155C2A4CE8A16F7; Mon, 17 Aug 2020 04:04:51 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 17 Aug 2020 04:04:50 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 17 Aug 2020 11:04:48 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Mon, 17 Aug 2020 11:04:48 +0800 From: Tianran Zhou To: "Thomas.Graf@swisscom.com" , "ketant@cisco.com" , "hannes@gredler.at" CC: "lsr@ietf.org" , "spring@ietf.org" , "opsawg@ietf.org" Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AdZktQw6HSkqPcEmSIuqXgxatw/WKwAgiNeAAHUFS4ACxLlpAAAWMMWAAAIMOYAAAdX7gABuUZPw Date: Mon, 17 Aug 2020 03:04:47 +0000 Message-ID: <36c5b46bbdf541119fd2a70a9c6aa59e@huawei.com> References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> In-Reply-To: <696872714.3003081.1597471334092@ss002889> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: multipart/alternative; boundary="_000_36c5b46bbdf541119fd2a70a9c6aa59ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 03:04:57 -0000 --_000_36c5b46bbdf541119fd2a70a9c6aa59ehuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, I think questions from both Ketan and Gyan on the IE usage are very importa= nt. The value should be described clearly in the draft. So that people now = how to implement and use them. Here your replay to Ketan on the mplsTopLabelType is clear to me. You want = to account the traffic with different IGP distribution, to see if your netw= ork runs correct. The SrSidType seems more complex. "Since it describes that a particular adjacency is chosen to forward the pa= cket instead of a prefix. If IE 89, ForwardingStatus is drop, we understand= that result of that decision lead to the drop and this enables to narrow d= own forwarding issues in segment routing networks more efficiently and quic= kly." Could you please make this use case more clear joint with IE89? And this case want to justify the value of Adjacency SID. Is there any othe= r use cases for accounting other sid types? Thanks, Tianran From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Thomas.Graf@swis= scom.com Sent: Saturday, August 15, 2020 2:01 PM To: ketant@cisco.com; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, ? This helps identification of specific SR-MPLS segment types as well as d= ifferentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. ? What value is provided for IPFIX analysis if the SR Prefix SID was being= signalled via OSPF or ISIS? It is important to distinguish between intend and result. If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets = with the label distribution protocol which needs to be removed or not. IE46= enables that by looking at the result of the forwarded traffic and not at = the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section= -3, describes the context. ? What value is provided for IPFIX analysis if it was a Adjacency SID or a= LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decision= s, the node can change the forwarding by pushing additional labels.. With I= PFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to an= alyze the result of this decision. The example with " Adjacency SID or a LA= N Adjacency SID" is not very useful because the difference of the two is th= e topology among the adjacency. If you compare " Adjacency SID with Prefix = SID", that makes much more sense. Since it describes that a particular adja= cency is chosen to forward the packet instead of a prefix. If IE 89, Forwar= dingStatus is drop, we understand that result of that decision lead to the = drop and this enables to narrow down forwarding issues in segment routing n= etworks more efficiently and quickly. ? am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a bette= r understanding where your fear is coming from. I would appreciate if you c= ould differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= . Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: - SR Prefix SID - SR Adjacency SID - SR Binding SID - SR BGP Peering SID - ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1) What value is provided for IPFIX analysis if the SR Prefix SID was = being signalled via OSPF or ISIS? 2) What value is provided for IPFIX analysis if it was a Adjacency SID= or a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. ? What or how much value be there on determining whether a SR Prefix SID w= as signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and= is more important is that it is a Prefix SID. Hardly any deployments would= be running multiple protocols and learning the same prefix from different = IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. ? IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. ? On some nodes, the same Prefix SID may be learnt via both BGP and IGP - = what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. ? For that table proposal, it is very difficult and in some cases not poss= ible to different between Prefix and Node and Anycast SID. Many of these ty= pes are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update... Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools..ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_36c5b46bbdf541119fd2a70a9c6aa59ehuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Thomas,<= /span>

     

    I think questions from= both Ketan and Gyan on the IE usage are very important. The value should b= e described clearly in the draft. So that people now how to implement and u= se them.

    Here your replay to Ke= tan on the mplsTopLabelType is clear to me. You want to account the traffic= with different IGP distribution, to see if your network runs correct.=

    The SrSidType seems mo= re complex.  

    “Since it descri= bes that a particular adjacency is chosen to forward the packet instead of = a prefix. If IE 89, ForwardingStatus is drop, we understand that result of = that decision lead to the drop and this enables to narrow down forwarding issues in segment routing networks more efficien= tly and quickly.”

    Could you please make = this use case more clear joint with IE89?

    And this case want to = justify the value of Adjacency SID. Is there any other use cases for accoun= ting other sid types?

     

    Thanks,

    Tianran

     

    From: OPSAWG [mailto:opsawg-bounces@ietf.org]= On Behalf Of Thomas.Graf@swisscom.com
    Sent: Saturday, August 15, 2020 2:01 PM
    To: ketant@cisco.com; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
    Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    Ø  This helps identification of specific SR-MPLS segment types a= s well as differentiating them from LDP, RSVP-TE, etc.

     

    To be precise, the existing MPLS= Label Type identifier differentiates from LDP, RSVP-TE. Not the new SrSidT= ype IPFIX IE being proposed.

     

    Ø  What value is provided for IPFIX analysis if the SR Prefix SI= D was being signalled via OSPF or ISIS?

     

    It is important to distinguish b= etween intend and result.

     

    If you migrate from one label di= stribution protocol to another, a network operator want's to understand if = the data plane is still forwarding packets with the label distribution protocol which needs to be removed or not. IE46 ena= bles that by looking at the result of the forwarded traffic and not at the = intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context.

     

    Ø  What value is provided for IPFIX analysis if it was a Adjacen= cy SID or a LAN Adjacency SID?

     

    Quote from RFC8402. "Segmen= t Routing (SR) leverages the source routing paradigm". Means that not = the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels.. With IPF= IX SrSidType we are able to cover this dimension in IPFIX. Enabling to anal= yze the result of this decision. The example with " Adjacency SID or a= LAN Adjacency SID" is not very useful because the difference of the two is the topology among the adjacency. If = you compare " Adjacency SID with Prefix SID", that makes much mor= e sense. Since it describes that a particular adjacency is chosen to forwar= d the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we understand that result of that decision lead = to the drop and this enables to narrow down forwarding issues in segment ro= uting networks more efficiently and quickly.

     

    Ø  am asking for WG to weigh the implementation complexities

     

    For the WG and me, I would be im= portant if you can describe more detailed what you mean with implementa= tion complexities. I would like to have a better understanding where your f= ear is coming from. I would appreciate if you could differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= .

     

    Best wishes

    Thomas

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Saturday, August 15, 2020 7:09 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas,

     

    I should have been more clear in my email.

     

    The proposal/suggestion is to add the following to the IPFIX MPLS Lab= el type identifier registry:

    -          SR Prefix SID

    -          SR Adjacency SID

    -          SR Binding SID

    -          SR BGP Peering SID

    -          … and so on

     

    This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc.

     

    And my questions were:

    1)      What value is provided for IPFIX analysis if the SR Prefix SI= D was being signalled via OSPF or ISIS?

    2)      What value is provided for IPFIX analysis if it was a Adjacen= cy SID or a LAN Adjacency SID?

     

    I am asking for WG to weigh the implementation complexities and overh= eads with the proposed details of SR-MPLS segments in IPFIX against the ben= efit (if any) that they provide for the flow analysis and monitoring.

     

    Thanks,

    Ketan

     

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 09:40
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    Thank you very much for the revi= ew and feedback.

     

    Ø  What or how much value be there on determining whether a SR P= refix SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS –= what matters and is more important is that it is a Prefix SID. Hardly any deployments would be running multiple proto= cols and learning the same prefix from different IGPs.

     

    As Jeff already p= ointed out. Multiple IGP labelling protocols are used  in networks whe= n migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swissc= om when we first discovered this shortcoming in vendor implementations. The= key point here, with these additional IPFIX MPLS Label Type identifiers we= enable the possibility to verify the label protocol migration without taking the label value into the consi= deration.

     

    Ø  IPFIX may be picking this information from a FIB in some impl= ementation where the protocol does not matter and this information is not a= vailable therein.

     

    I am not sure if = you have seen the presentation in IETF 108 at OPSAWG and SPRING.=

    https://www.ietf.org/p= roceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-inform= ation-in-ipfix-00.pdf

     

    Slide 2 shows Cis= co as example vendor which implemented IE 46, MPLS Label Type identifier. T= here is an open ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.

     =

    I do understand your point that = not all the vendors are capable to implement IE 46. But that’s not th= e point about the IPFIX IE registry. The IE registry enables that an I= PFIX implementation can refer to the right code point. With RFC 5102 the de= cision has been made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type ju= st extends the IE 46 registry with the Segment Routing label protocol code = points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, t= he IPFIX implementation can point to the right code point.

     

    Ø  On some nodes, the same Prefix SID may be learnt via both BGP= and IGP – what would we use/show?

     =

    In this case the = IE 46 shows the label protocol which was used to program the FIB.

     =

    Ø  For that table proposal, it is very difficult and in some cas= es not possible to different between Prefix and Node and Anycast SID. Many = of these types are control plane elements and we can be sure more get added. 

    I fully agree. As a network oper= ator its still hard to understand the architecture and constraints within a= router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what make sense. By pu= rpose, all available SID types are listed in the draft. This with the aim t= o start the discussion in the working groups what is possible what makes se= nse. I would be interested to get your and also Jeff's feedback.

     

    In above mentioned slides I desc= ribed how TI-LFA application would benefit of visibility in the FIB by show= ing where Adj-SID was used. This should be a simple example why it make sense not only to look at which label protocol was use= d to forward a particular packet, but also which SID type to further unders= tand the intend why this label is being pushed.

     

    I hope this makes all sense. Loo= king forward for reply.

     =

    Best wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020 7:35 PM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; SPRING WG <= spring@ietf.org>
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    < also copying Spring WG for their review/inputs >

     

    Hi Thomas/All,

     

    I have reviewed the draft and would like to share a different perspec= tive.

     

    What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS – what ma= tters and is more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and= learning the same prefix from different IGPs. IPFIX may be picking this in= formation from a FIB in some implementation where the protocol does not mat= ter and this information is not available therein.

     

    On some nodes, the same Prefix SID may be learnt via both BGP and IGP= – what would we use/show?

     

    I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding S= ID, SR BGP Peering SID and so on … for the MPLS Label Type.

     

    This also takes away the need for the second table that is being prop= osed to a large extent. For that table proposal, it is very difficult and i= n some cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control p= lane elements and we can be sure more get added. Is there really much value= in differentiation between say an Adjacency SID and LAN Adjacency SID?

     

    Could we evaluate the implementation overhead and complexity of this = level of categorization/information in IPFIX against their value in flow an= alysis to perhaps consider a middle ground?

     

    Thanks,

    Ketan

     

    From: Lsr <lsr-bounces@ietf.org> On Behalf Of Thomas.Graf= @swisscom.com
    Sent: 31 July 2020 20:52
    To: hannes@gredler.at
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Hannes,

     =

    Thanks a lot for the feedback. Y= es, makes completely sense. Will take it for the next update...<= /span>

     

    Best Wishes

    Thomas

     

     =

    From: Hannes Gredler <hannes@gredler.at>
    Sent: Wednesday, July 29, 2020 9:31 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Thomas,

     

    I have one comment/suggestion t= o Paragraph 4 (IANA Considerations).

     

    Please add also a code point fo= r BGP Prefix-SID - it’s quite popular in DC deployments.

     

    thanks,

     

    /hannes

    =  

    On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

     

    Dear lsr,

     

    I presented the following draft

     <= /span>

    Export of MPLS Segment Routing Label Type Info= rmation in IP Flow Information Export (IPFIX)

     

    at the spring working group at IETF 108 yester= day

     <= /span>

    and today at OPSAWG where I call for adoption.=

     <= /span>

    This draft adds additional segment routing cod= e points for in the IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and s= egment routing SID types to gain further insights into the MPLS-SR forwarding-plane.<= /span>

     <= /span>

    I have been asked to not only gather feedback = from spring and opsawg but also from lsr and mpls working groups since thes= e code points are related to link state routing protocols and mpls data plane.

     <= /span>

    I am looking forward to your feedback and inpu= t.

     <= /span>

    Best Wishes

    Thomas Graf

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

     

    --_000_36c5b46bbdf541119fd2a70a9c6aa59ehuaweicom_-- From nobody Sun Aug 16 22:52:59 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8113A09A0; Sun, 16 Aug 2020 22:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=nFThk2Yw; dkim=pass (1024-bit key) header.d=juniper.net header.b=YDB6wt2M 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 AYwX71lwSNw0; Sun, 16 Aug 2020 22:52:51 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A414E3A09A3; Sun, 16 Aug 2020 22:52:51 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07H5l2L2016997; Sun, 16 Aug 2020 22:52:47 -0700 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 : mime-version; s=PPS1017; bh=eBILp7L+/ETuEoif+4PTxT/SdfzSYu8Ersx9iYey7BU=; b=nFThk2YwzV6P06TEzKHU6wd8tY3YZ+8mg44f/qYGGluXLU+v+qyT3uke8rfvVGFcbJ2P eYZrAbEv8swvjwVTZLBjCGk0Lg1v8XbiMi6YtIeRf7V3/aal4sWyXp45lXM59S7PgkvF vTdbTVPYocZHEZc//+v2A+8CI5R1jdFENl0lxot/eNIpRVXRf4LGJX4ZSMKtowQDPxEK VhooHxh0vDWJM1Wv1cvD2K5rAcGF9bMFGUxKThqtsrh+5NiN4qmJM0FwMdQP3XfEI9aw g2Lph5tRjRlPvWOEOVAHYPqOU6Y1MsF0VeQjrdibah4hWHxIQGMjFGjRfojt1G2D/NRA zQ== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2108.outbound.protection.outlook.com [104.47.70.108]) by mx0b-00273201.pphosted.com with ESMTP id 32xdmhsw1v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Aug 2020 22:52:47 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CwuVQb3bBq1NuaFDxa9xH00eLuhbQtG/zwFLrVg8EHhu9oOUNcbNdeYqZB3NLRbT9jzwEFHPmbYHwpD17XEeCHNm9DFaquScIcp/pMnwaSeKvdFrQgc7Idj9Dnd/HBl7qVVXH7aca7iuBSLaGefU01Hhcm6W2j3aRSqqOMm6dCcMe1XeBpnmdablqbxnJL495tnSMdiTXyr6yo+oRE5FPvSctwWUMmruC4j8IBTWkR/s9sk1ei8Y5E3ganGZsGvplSVPQv21oSIcpFMFshqKmxl5NdpPNKWuWnrf1IeZzey8hSMe3DxtUg4kCJu0RtaryJvxoA9a0YxgFhD/T80NRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eBILp7L+/ETuEoif+4PTxT/SdfzSYu8Ersx9iYey7BU=; b=cyVG1j12QWjL0nuEfaczi1Ac9y+diWYv/TyvSRjNUTP1mOu8xgxn0/BXbDwAoKkreRU7xxQHN1DzEp50UhuosvKcoW8VeAr5HCgUYhlv08iU0e5ggOoYlX5ShuGKL3B8bbrcxuIPtG3igXsYDWnC5yP++t3/2IRDfLfer0egA9qF+ADEzAsyjqWkR0qnx4K2aOsLacWTcIPPM2R2jqCyTMp1hPGywc8PUIJ3onipAgOybKO47SL6N3htn10PjxPM0LIRaM9I3AqTeb00VRbI/SQG568e5pSLaJFrT+BiKoabkgDpXhhMTbwXyHVbYMdJPG/bbAu0XBlMKo9vgUUjxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eBILp7L+/ETuEoif+4PTxT/SdfzSYu8Ersx9iYey7BU=; b=YDB6wt2MVaBbg8uicBVzyVfBH9Laj+8oeS3CbxBUwgTO9NMmcIr5si3bmYmmUitmTrQ7k044j+973Bjmh2s0anqBM6xDNkkd/NQYG3F57NO88TvPSi3QNzqYmlpws5n0BE7eIdlOUaNXLUynpOm5kM1gwRa/vn5ofbSkID2eH1Q= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3301.namprd05.prod.outlook.com (2603:10b6:910:55::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.13; Mon, 17 Aug 2020 05:52:45 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3305.021; Mon, 17 Aug 2020 05:52:45 +0000 From: Shraddha Hegde To: Gyan Mishra , "Ketan Talaulikar (ketant)" CC: "bruno.decraene@orange.com" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths Thread-Index: AdZmaxBja895PvK+QsirQTKFBBYlewLx82dwACZ1mwAAYw1R8A== Date: Mon, 17 Aug 2020 05:52:45 +0000 Message-ID: References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-17T05:52:42Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=a0eb2daa-165e-4012-94cb-297e4c34c1c9; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [116.197.184.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6f014c31-bd30-4d3c-09a6-08d84271c39c x-ms-traffictypediagnostic: CY4PR05MB3301: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nTlcFlmx7QmuAXvtbvm9PNoelQ+ExelD3WhwK80KZ4P+Ae/OFQ0z4JJsdWmVr2lpEuOcGvhaULcKz6q+DwKYklE4xyaghRmscuZNXolGJw1N9eiyZeeABhzSrqUTzDu0B2sTSsT2iGCglx9xJkTD9zNGJrRTUOyQjzARgMZ/4Y+5r8EMNrU+jca+VUKdvSwvPqkFqjuPpSdC+NI2RfE373+khlqy2ChAv1jzs4pFmMQQSqYAjfcEpDSTTYFr5RvVjrH0s2LbwNeLZ++TXT3pmecYQZ3fnHEu9mjbF5v0ZmKJA8hiej1j79DIwWz19EEIr1VqqApv9b+tskhMkGiV3Aqr5VzjjlFNVkCswPGGguA6vJm2TJem0O0THkhyRNILvLSrkvJSx57GDtwl5jmXyw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(76116006)(66946007)(166002)(2906002)(71200400001)(66476007)(186003)(66556008)(83380400001)(66446008)(26005)(64756008)(4326008)(54906003)(52536014)(9326002)(7696005)(33656002)(8936002)(6506007)(478600001)(966005)(55016002)(86362001)(9686003)(316002)(53546011)(110136005)(5660300002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 4PbOy9EabAMINrFejHzJAZNAV+eYXBfImyz/i8MEvPtrRcH6tPBiRS9xquJwrwT08SKaLzb/KG0mfBSlFaIMDU9aJ5ymAmkMicpNRFDfs71DVLg/ICfszI8/mXdK32hZwDbM5noRp6iOUwLlDNEH1+UlifT4yRvhROQUb9CMcE/GnMzWTVMPlOthF3OX1TH8WNfYZSepbv5THfIrWzmCnOAFBEnU2iIMKX7zkZE6CqBNJoxRYGv+jXEstu3qf6GHYTgJyPbjP//9T1RdYyLfBG766+NjWIcxxzf6Z0o84ewZ5ix2d/arZckEjS2+jHpVqz0tihNKMZ1zUi8URga5c6lfU23WVJFiFTquIx5k04vP8UhVs5zseB26dhdgyOJUQpJvKlXwMsmAMaA/PP/XipTYdY4RQbvjzY6hf2PE4oN301OJDLoM1Rkjh3fi2yx9J1RLwNJ12RHd3iW/Y5OiEzPQ4Mliv3MwO3glsGiFgWFjty2OEtc7kGBBMy+WVWvZZZkSXHqa1pNGwstLahenmSC7i+/BKY7NZkftrUKt8FRad1lsG7d+QgSuxlAXi7FSa+aE+8wNMaqROlQekdirrmF/6HpEPwmQSezeFNlXvx6seP1nLnc5xnnJlTRGySOm86l/k3OP4LrgEbkTZWT1DA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR05MB35767668A49B33F84D618644D55F0CY4PR05MB3576namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f014c31-bd30-4d3c-09a6-08d84271c39c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 05:52:45.2266 (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-CrossTenant-userprincipalname: itXWvzTMWVHAcp2UQZ9wiwgH4IyAuzkyiWvGoTIFnS7Zj1Xi2zwhUdQtwBGer9y2fHWFezzOSw7Snbuod+c/pg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3301 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-17_02:2020-08-17, 2020-08-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 impostorscore=0 bulkscore=0 suspectscore=0 adultscore=0 mlxscore=0 spamscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008170046 Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 05:52:57 -0000 --_000_CY4PR05MB35767668A49B33F84D618644D55F0CY4PR05MB3576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gyan, Thank you for the support. Pls see inline or replies Juniper Business Use Only From: Gyan Mishra Sent: Saturday, August 15, 2020 11:54 AM To: Ketan Talaulikar (ketant) Cc: bruno.decraene@orange.com; draft-hegde-spring-node-protection-for-sr-te= -paths@ietf.org; spring@ietf.org Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protecti= on-for-sr-te-paths [External Email. Be cautious of content] I support WG adoption adoption of this draft. For operators moving towards SR technology, RSVP FRR is widely deployed by = operators, so SR node protection is a critical feature for operators. >From the thread started by Joel Halpern I think path protection is as well = critical to operators. With regards to SR FRR node protection, how does TI-LFA FRR work in conjun= ction with SR FRR node protection for the same PLR junction to the merge p= oint bypass loop. SR path consists of a stack of labels. At any node the forwarding= in based on top label. When there is node failure, the PLR of the failure node applies the procedu= res described in drat-hegde-spring-node-protection-for-sr-te-paths When the= top label is adjacency SID or when the top label is a node-sid which is th= e nexthop. If the top label is a node-sid which is multiple hops away TI-LFA protectio= n is applied. Is the concept of context table a requirement for node FRR as it will consu= me more resources. It is not absolutely necessary. Section 5 of the draft explains = a mechanism that does not use context tables. In the bypass loop if their is only one next next hop path Neighbor or a fe= w would a context table be necessary. Context table is generally necessary if the SRGB in the network = is not uniform and if there are locally significant adjacency-sids used in = the network. Since SR uses IGP SIDs and the paths for the labels change bas= ed on cost change etc The concept of next-nexthop is very dynamic. The recommendation is to use n= on context table based solution only when the Whole network has same SRGB and has global adj-sids deployed. For the node protection this does seem similar conceptually to RSVP node pr= otection with the additional label to signal lsp to the merge point. You are right, this draft solves the same problem that RSVP node= -protection solved. Kind Regards Gyan On Fri, Aug 14, 2020 at 8:25 AM Ketan Talaulikar (ketant) > wrote: Hi All, I believe this topic is relevant and something for the WG to adopt and work= on. I have some concerns though on it's applicability and more specifically it'= s implications on existing deployments/use-cases. I've share the same on th= e thread started by Joel on this specific aspect [1]. Some discussion and c= larity on this would help before adoption. One other bit, for the example in Sec 2.3, perhaps some text is required to= clarify that this applies only for segments signalled via IGPs and if the = 9054 was a BSID or BGP-EPE SID then this approach would not work. May I sug= gest to add a section 2.4 to capture these aspects (it would be some what on the lines = of Sec 3.4 but not related to the context table solution). The document is well-written and detailed. It does a very good job of descr= ibing the node protection scenarios and options. Thanks, Ketan [1] https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/ From: spring > On Behalf Of bruno.decraene@orange.com Sent: 30 July 2020 17:55 To: spring@ietf.org Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org Subject: [spring] WG adoption call for draft-hegde-spring-node-protection-f= or-sr-te-paths Hi SPRING WG, Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have ask= ed for WG adoption. Please indicate your support, comments, or objection, for adopting this dra= ft as a working group item by August 20th 2020. (*) Could those who are willing to work on this document, please notify the lis= t. That gives us an indication of the energy level in the working group to = work on this. Thanks, Regards, Bruno, Jim, Joel [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07 (*) 3 weeks to account for the IETF meeting week and the august/summer peri= od. ___________________________________________________________________________= ______________________________________________ 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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_CY4PR05MB35767668A49B33F84D618644D55F0CY4PR05MB3576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Gyan,

     

    Thank you for the support.

    Pls see inline or replies

     

     

    Juniper Business Use Only

    From: Gyan Mishra <hayabusagsm@gmail.com&g= t;
    Sent: Saturday, August 15, 2020 11:54 AM
    To: Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.or= g>
    Cc: bruno.decraene@orange.com; draft-hegde-spring-node-protection-fo= r-sr-te-paths@ietf.org; spring@ietf.org
    Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-p= rotection-for-sr-te-paths

     

    <= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

     

     

    I support WG adoption adoption of this draft.

     

    For operators moving towards SR technology, RSVP FRR= is widely deployed by operators, so SR node protection is a critical featu= re for operators.

     

    From the thread started by Joel Halpern I think path= protection is as well critical to operators.

     

    With regards to SR FRR node protection,  how do= es TI-LFA FRR work in conjunction with SR FRR node protection for the  = ;same PLR junction to the merge point bypass loop. 

    <Shraddha>SR path consists of a stack of label= s. At any node the forwarding in based on top label.

    When there is node failure, the PLR of the failure n= ode applies the procedures described in drat-hegde-spring-node-protection-f= or-sr-te-paths When the top label is adjacency SID or when the top label is= a node-sid which is the nexthop.

    If the top label is a node-sid which is multiple hop= s away TI-LFA protection is applied.

     

    Is the concept of context table a requirement for no= de FRR as it will consume more resources. 

    <shraddha> It is not absolutely necessary. Sec= tion 5 of the draft explains a mechanism that does not use context tables.<= o:p>

     

    In the bypass loop if their is only one next next ho= p path Neighbor or a few would a context table be necessary. 

    <shraddha> Context table is generally necessar= y if the SRGB in the network is not uniform and if there are locally signif= icant adjacency-sids used in the network. Since SR uses IGP SIDs and the pa= ths for the labels change based on cost change etc

    The concept of next-nexthop is very dynamic. The rec= ommendation is to use non context table based solution only when the

    Whole network has same SRGB and  has global adj= -sids deployed.

     

    For the node protection this does seem similar conce= ptually to RSVP node protection with the additional label to signal lsp &nb= sp;to the merge point.  

    <shraddha> You are right, this draft solves th= e same problem that RSVP node-protection solved.

    Kind Regards 

     

    Gyan

     

    On Fri, Aug 14, 2020 at 8:25 AM Ketan Talaulikar (ke= tant) <ketant=3D40cisco.co= m@dmarc.ietf.org> wrote:











    =  

    =  

    Hi All,

    =  

     

    =  

    I believe this topic is relevant and somethin= g for the WG to adopt and work on.

    =  

     

    =  

    I have some concerns though on it’s app= licability and more specifically it’s implications on existing deploy= ments/use-cases. I’ve share the same on the thread started by Joel on this specific aspect [1]. Some discussion and clarity o= n this

    would help before adoption.

    =  

     

    =  

    One other bit, for the example in Sec 2.3, pe= rhaps some text is required to clarify that this applies only for segments = signalled via IGPs and if the 9054 was a BSID or BGP-EPE SID then this approach would not work. May I suggest to = add

    a section 2.4 to capture these aspects (it would be some what on the lines = of Sec 3.4 but not related to the context table solution).

    =  

     

    =  

    The document is well-written and detailed. It= does a very good job of describing the node protection scenarios and optio= ns.

    =  

     

    =  

    Thanks,

    =  

    Ketan

    =  

     

    =  

    [1]

    https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/

    =  

     

    =  




    Sent: 30 July 2020 17:55


    To: spring@ietf= .org


    Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org


    Subject: [spring] WG adoption call for draft-hegde-spring-node-prote= ction-for-sr-te-paths

    =  

    =  

    =  

     

    =  

    Hi SPRING WG,

    =  

     =

    =  

    Authors of draft-hegde-spring-node-protection= -for-sr-te-paths  [1] have asked for WG adoption.

    =  

     =

    =  

    Please indicate your support, comments, or ob= jection, for adopting this draft as a working group item by August 20th 202= 0. (*)

    =  

     =

    =  

    Could those who are willing to work on this d= ocument, please notify the list. That gives us an indication of the energy = level in the working group to work on this.

    =  

     =

    =  

    Thanks,

    =  

    Regards,

    =  

    Bruno, Jim, Joel<= o:p>

    =  

     =

    =  

    [1]

    https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07

    =  

    (*) 3 weeks to account for the IETF meeting w= eek and the august/summer period.

    =  

     =

    =  

    ____________________________________________________=
_____________________________________________________________________

    =  

     =

    =  

    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<=
span lang=3D"EN-IN">

    =  

    a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
span lang=3D"EN-IN">

    =  

    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.

    =  

    =  





    _______________________________________________

    spring mailing list

    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spr= ing

    --

    Gyan = Mishra

    Network = Solutions Architect 

    M 301 50= 2-1347
    13101 Columbia Pike 
    Silver Spring, MD<= /p>

     

    --_000_CY4PR05MB35767668A49B33F84D618644D55F0CY4PR05MB3576namp_-- From nobody Sun Aug 16 23:20:15 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA22B3A09C6; Sun, 16 Aug 2020 23:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wahGnXJjNkzc; Sun, 16 Aug 2020 23:20:10 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 C8E333A09C1; Sun, 16 Aug 2020 23:20:09 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id n25so7695286vsq.6; Sun, 16 Aug 2020 23:20:09 -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=wVroKOjaNN0akokRAPe4GNTHD7g7zpngC1h0LmA2hQU=; b=ZWaMhZaBpxmsxZS5o3rsXjwIR8l2PFlzMOezKXc4iJTshqHwGgyPsRBS+jyPoFs+Kh 0/8EEbmQ8kbKo8ZW2RY7awB1EqTP9qQaKHSMotVe+pyaudVZZwcQHNt10rxPa6p/uqoW nvWUheEPBYdFO6LtxBOWr6prDu6kF4aieGRC2w+o6+jPQoSEh4uIhq5P+L/PnxMzSHBx avqOAHnbOXDOdu0zZJHA2fAi2xuaGytJKUTEAU6YYAPtS0gkMQlXHcA++gcFSrUMPF3b dGDemd/uccyqD7n0XLatqXtCa+A2quiyVHZv0lFuVd7iHsDXGAw9RBdlu3PrxIyvQ51i 6GfQ== 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=wVroKOjaNN0akokRAPe4GNTHD7g7zpngC1h0LmA2hQU=; b=FO4E8OcLQtAohAYbXmtXqzlERdk2ISWLmZrZHVR0GOEZKo7Su6TU8QP/3fJXF4LQHB DiDuFV3E60cBo2+TDVGV/OVffAeXCKwRzl5ZZdPKpSrwzYoNZO9Ey45VrStefZb/tY3S 2Uk6TsdW5toQoNz92t3swzuX9FYaZ+KJ28cO3VwHpENYmQsb3D9rlKlmp2TrC2AjbWws +sqgkf92E+LRbSM0dSP+aIg59PWFxRjEy5EOyF5G77MhqauPKi4lR1bjrfsMbLhsHIZA F4TRRTQS4AyobUGO4wM3HLpWZmxVDCpc3ARCGq4NVG4t8UaP0hWAGWqVjo0uUpQtLWUb yVEQ== X-Gm-Message-State: AOAM533eLCtIU9xmK+MEgPorHLHMilQ/1VpMd+XAEBErTOdxchBU6kuJ m3p99qFsnqaWvBnM0G+VksFvfZtAKO8fGY6+Xmo= X-Google-Smtp-Source: ABdhPJw+guCN417JWEu+zQ62wkTGkkuZXry/PJQIXu6Q5PdUYwglPAfiW4DDDlqIZH331GdGYSpie5WQCbbjQcChIHE= X-Received: by 2002:a67:30d5:: with SMTP id w204mr7204592vsw.219.1597645208452; Sun, 16 Aug 2020 23:20:08 -0700 (PDT) MIME-Version: 1.0 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> <36c5b46bbdf541119fd2a70a9c6aa59e@huawei.com> In-Reply-To: <36c5b46bbdf541119fd2a70a9c6aa59e@huawei.com> From: Gyan Mishra Date: Mon, 17 Aug 2020 02:19:57 -0400 Message-ID: To: Tianran Zhou Cc: "Thomas.Graf@swisscom.com" , "hannes@gredler.at" , "ketant@cisco.com" , "lsr@ietf.org" , "opsawg@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002081ef05ad0cc38b" Archived-At: Subject: Re: [spring] [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 06:20:14 -0000 --0000000000002081ef05ad0cc38b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas Just a thought to build on what Tianran mentioned. It almost seems as if IPFIX taking on the role of BGP-LU / PCE centralized controller function to to create a SR graph of the topology. We already have all the SR topology data in the PCE for path instantiation and steering. Do we also really need the data replicated into IPFIX. The PCE may also be able to do fault isolation and troubleshooting as it has the topology of the entire SR domain. Something to consider. Also gathering flat bits and pieces of information is not the same as what is being fed by BGP-LS into the PCE. So am wondering what value this will provide with the flat construction of the network graph. Gyan On Sun, Aug 16, 2020 at 11:05 PM Tianran Zhou wrote: > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > I think questions from both Ketan and Gyan on the IE usage are very > important. The value should be described clearly in the draft. So that > people now how to implement and use them. > > > Here your replay to Ketan on the mplsTopLabelType is clear to me. You wan= t > to account the traffic with different IGP distribution, to see if your > network runs correct. > > > The SrSidType seems more complex. > > > =E2=80=9CSince it describes that a particular adjacency is chosen to forw= ard the > packet instead of a prefix. If IE 89, ForwardingStatus is drop, we > understand that result of that decision lead to the drop and this enables > > to narrow down forwarding issues in segment routing networks more > efficiently and quickly.=E2=80=9D > > > Could you please make this use case more clear joint with IE89? > > > And this case want to justify the value of Adjacency SID. Is there any > other use cases for accounting other sid types? > > > > > > Thanks, > > > Tianran > > > > > > > > > > *From:* OPSAWG [mailto:opsawg-bounces@ietf.org] > > *On Behalf Of*Thomas.Graf@swisscom.com > > > *Sent:* Saturday, August 15, 2020 2:01 PM > > > *To:* ketant@cisco.com; hannes@gredler.at > > > *Cc:* lsr@ietf.org; spring@ietf.org; opsawg@ietf.org > > > *Subject:* Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Ketan, > > > > > > > > =C3=98 > > This helps identification of specific SR-MPLS segment types as well as > differentiating them from LDP, RSVP-TE, etc. > > > > > > To be precise, the existing MPLS Label Type identifier differentiates fro= m > LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. > > > > > > > > =C3=98 > > What value is provided for IPFIX analysis if the SR Prefix SID was being > signalled via OSPF or ISIS? > > > > > > > It is important to distinguish between intend and result. > > > > > > If you migrate from one label distribution protocol to another, a network > operator want's to understand if the data plane is still forwarding packe= ts > with > > the label distribution protocol which needs to be removed or not. IE46 > enables that by looking at the result of the forwarded traffic and not at > the intend. RFC 8661 section 3, > > https://tools.ietf.org/html/rfc8661#section-3, > > describes the context. > > > > > > > > =C3=98 > > What value is provided for IPFIX analysis if it was a Adjacency SID or a > LAN Adjacency SID? > > > > > > Quote from RFC8402. "Segment Routing (SR) leverages the source routing > paradigm". Means that not the routing protocol does all the forwarding > decisions, > > the node can change the forwarding by pushing additional labels.. With > IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to > analyze the result of this decision. The example with " Adjacency SID or = a > LAN Adjacency SID" is not very useful > > because the difference of the two is the topology among the adjacency. If > you compare " Adjacency SID with Prefix SID", that makes much more sense. > Since it describes that a particular adjacency is chosen to forward the > packet instead of a prefix. If IE 89, > > ForwardingStatus is drop, we understand that result of that decision lead > to the drop and this enables to narrow down forwarding issues in segment > routing networks more efficiently and quickly. > > > > > > =C3=98 > > am asking for WG to weigh the implementation complexities > > > > > > For the WG and me, I would be important if you can describe more detailed > what you mean with > > implementation complexities. I would like to have a better understanding > where your fear is coming from. I would appreciate if you could > differentiate between > > MPLS Label Type identifier, IE46, from which label protocol the label was > coming from and SrSidType which SID type was used.. > > > > > > > Best wishes > > > Thomas > > > > > > > > > > *From:* Ketan Talaulikar (ketant) > > > > > *Sent:* Saturday, August 15, 2020 7:09 AM > > > *To:* Graf Thomas, INI-NET-DCF ; > > hannes@gredler.at > > > *Cc:* lsr@ietf.org; > > spring@ietf.org; opsawg@ietf.org > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Thomas, > > > > > > I should have been more clear in my email. > > > > > > The proposal/suggestion is to add the following to the IPFIX MPLS Label > type identifier registry: > > > > > - > > SR Prefix SID > > > > > - > > SR Adjacency SID > > > > > - > > SR Binding SID > > > > > - > > SR BGP Peering SID > > > > > - > > =E2=80=A6 and so on > > > > > > This helps identification of specific SR-MPLS segment types as well as > differentiating them from LDP, RSVP-TE, etc. > > > > > > And my questions were: > > > > > 1) > > What value is provided for IPFIX analysis if the SR Prefix SID was being > signalled via OSPF or ISIS? > > > > > > 2) > > What value is provided for IPFIX analysis if it was a Adjacency SID or a > LAN Adjacency SID? > > > > > > I am asking for WG to weigh the implementation complexities and overheads > with the proposed details of SR-MPLS segments in IPFIX against the benefi= t > (if any) that they provide for the > > flow analysis and monitoring. > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* Thomas.Graf@swisscom.com > > > > > *Sent:* 15 August 2020 09:40 > > > *To:* Ketan Talaulikar (ketant) ; > > hannes@gredler.at > > > *Cc:* lsr@ietf.org; > > spring@ietf.org; opsawg@ietf.org > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Ketan, > > > > > > Thank you very much for the review and feedback. > > > > > > > > =C3=98 > > What or how much value be there on determining whether a SR Prefix SID wa= s > signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matt= ers and is > more important is that > > it is a Prefix SID. Hardly any deployments would be running multiple > protocols and learning the same prefix from different IGPs. > > > > > > > As Jeff already pointed out. Multiple IGP labelling protocols are used i= n > networks when migrations are ongoing. Usually in a life cycle. Migrating > > from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at > Swisscom when we first discovered this shortcoming in vendor > implementations. The key point here, with these additional IPFIX MPLS Lab= el > Type identifiers we enable the possibility to verify > > the label protocol migration without taking the label value into the > consideration. > > > > > > > > =C3=98 > > IPFIX may be picking this information from a FIB in some implementation > where the protocol does not matter and this information is not available > therein. > > > > > > I am not sure if you have seen the presentation in IETF 108 at OPSAWG and > SPRING. > > > > https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-m= pls-sr-label-type-information-in-ipfix-00.pdf > > > > > > > Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label > Type identifier. There is an open ddts where vendor feasibility has > > been clarified. Ping me off the list when you like to have more details. > > > > > > I do understand your point that not all the vendors are capable to > implement IE 46. But that=E2=80=99s not the point about the IPFIX IE regi= stry. > > The IE registry enables that an IPFIX implementation can refer to the > right code point. With RFC 5102 the decision has been made that MPLS Labe= l > Type identifier > > make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type > just extends the IE 46 registry with the Segment Routing label protocol > code points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is > supported, the IPFIX implementation can point > > to the right code point. > > > > > > > > =C3=98 > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 > what would we use/show? > > > > > > In this case the IE 46 shows the label protocol which was used to program > the FIB. > > > > > > > > > =C3=98 > > For that table proposal, it is very difficult and in some cases not > possible to different between Prefix and Node and Anycast SID. Many of > these types are control plane elements > > and we can be sure more get added. > > > > > > I fully agree. As a network operator its still hard to understand the > architecture and constraints within a router. When monitoring capabilitie= s > are discussed > > at IETF, this is the usual topic. What is possible, what make sense. By > purpose, all available SID types are listed in the draft. This with the a= im > to start the discussion in the working groups what is possible what makes > sense. I would be interested to get > > your and also Jeff's feedback. > > > > > > In above mentioned slides I described how TI-LFA application would benefi= t > of visibility in the FIB by showing where Adj-SID was used. This should b= e > a simple > > example why it make sense not only to look at which label protocol was > used to forward a particular packet, but also which SID type to further > understand the intend why this label is being pushed. > > > > > > > I hope this makes all sense. Looking forward for reply. > > > > > > Best wishes > > > Thomas > > > > > > > > > > *From:* Ketan Talaulikar (ketant) > > > > > *Sent:* Friday, August 14, 2020 7:35 PM > > > *To:* Graf Thomas, INI-NET-DCF ; > > hannes@gredler.at > > > *Cc:* lsr@ietf.org; SPRING WG > > > *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > < also copying Spring WG for their review/inputs > > > > > > > Hi Thomas/All, > > > > > > I have reviewed the draft and would like to share a different perspective= . > > > > > > What or how much value be there on determining whether a SR Prefix SID wa= s > signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matt= ers and is > more important is that it is a > > Prefix SID. Hardly any deployments would be running multiple protocols an= d > learning the same prefix from different IGPs. IPFIX may be picking this > information from a FIB in some implementation where the protocol does not > matter and this information is not > > available therein. > > > > > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP =E2= =80=93 > what would we use/show? > > > > > > I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, > SR BGP Peering SID and so on =E2=80=A6 for the MPLS Label Type. > > > > > > This also takes away the need for the second table that is being proposed > to a large extent. For that table proposal, it is very difficult and in > some cases not possible to different > > between Prefix and Node and Anycast SID. Many of these types are control > plane elements and we can be sure more get added. Is there really much > value in differentiation between say an Adjacency SID and LAN Adjacency S= ID? > > > > > > Could we evaluate the implementation overhead and complexity of this leve= l > of categorization/information in IPFIX against their value in flow analys= is > to perhaps consider a middle ground? > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* Lsr > > *On Behalf Of *Thomas.Graf@swisscom.com > > > *Sent:* 31 July 2020 20:52 > > > *To:* hannes@gredler.at > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Hannes, > > > > > > Thanks a lot for the feedback. Yes, makes completely sense. Will take it > for the next update... > > > > > > Best Wishes > > > Thomas > > > > > > > > > > > > > > > > > *From:* Hannes Gredler > > > > > *Sent:* Wednesday, July 29, 2020 9:31 AM > > > *To:* Graf Thomas, INI-NET-DCF > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Thomas, > > > > > > > > > > > > I have one comment/suggestion to Paragraph 4 (IANA Considerations). > > > > > > > > > > > > > > Please add also a code point for BGP Prefix-SID - it=E2=80=99s quite popu= lar in DC > deployments. > > > > > > > https://tools..ietf.org/html/rfc8669 > > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > /hannes > > > > > > > > > > > > > > > > On 28.07.2020, at 10:11, > > Thomas.Graf@swisscom.com wrote: > > > > > > > > > > > > Dear lsr, > > > > > > > > > > > > > > I presented the following draft > > > > > > > > > > > > > > Export of MPLS Segment Routing Label Type Information in IP Flow > Information Export (IPFIX) > > > > > > > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 > > > > > > > > > > > > > > > at the spring working group at IETF 108 yesterday > > > > > > > > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-inf= ormation-export-ipfix-00.pdf > > > > > > > > > > > > > > > and today at OPSAWG where I call for adoption. > > > > > > > > > > > > > > This draft adds additional segment routing code points for in the IANA > IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID type= s > to gain further insights > > into the MPLS-SR forwarding-plane. > > > > > > > > > > > > > > I have been asked to not only gather feedback from spring and opsawg but > also from lsr and mpls working groups since these code points are related > to link state routing > > protocols and mpls data plane. > > > > > > > > > > > > > > I am looking forward to your feedback and input. > > > > > > > > > > > > > > Best Wishes > > > > > > > Thomas Graf > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002081ef05ad0cc38b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Thomas=C2=A0

    Just a thought to build on what Tianran mentioned.

    It almost seems as if IPFIX= taking on the role of BGP-LU / PCE =C2=A0centralized controller function t= o to create a SR graph of the topology.=C2=A0 We already have all the SR to= pology data in the PCE for path instantiation and steering. =C2=A0

    Do we also really need the data = replicated into IPFIX.
    =C2=A0=C2=A0
    The PCE may also be able to do fault isolation and troubleshooti= ng as it has the topology of the entire SR domain.
    <= br>
    Something to consider.=C2=A0 Also gathering flat= bits and pieces of information is =C2=A0not the same as what is being fed = by BGP-LS into the PCE.=C2=A0 So am wondering what value this will provide = with the flat construction of the network graph.
    Gyan=C2=A0

    On Sun, Aug 16, 2020 at 11:05 PM Ti= anran Zhou <zhoutianran@huawei= .com> wrote:















    Hi Thomas,



    <= span style=3D"color:#1f497d">=C2=A0



    I think questions from both K= etan and Gyan on the IE usage are very important. The value should be descr= ibed clearly in the draft. So that people now how to implement and use them= .



    Here your replay to Ketan on the mplsTopLabelType is clear to m= e. You want to account the traffic with different IGP distribution, to see = if your network runs correct.



    The SrSidType seems more complex. = =C2=A0



    =E2=80=9CSince it describes that a particular adjacency = is chosen to forward the packet instead of a prefix. If IE 89, ForwardingSt= atus is drop, we understand that result of that decision lead to the drop a= nd this enables

    to narrow down forwarding issues in segment routing= networks more efficiently and quickly.=E2=80=9D


    Could you please= make this use case more clear joint with IE89?


    And this case wan= t to justify the value of Adjacency SID. Is there any other use cases for a= ccounting other sid types?



    =C2=A0


    Thanks,=



    Tia= nran



    =C2=A0







    From: OPSAWG [mailto:opsawg-bounces@ietf.org] = On Behalf Of

    Thomas.Graf@swisscom.com


    Sent: Saturday= , August 15, 2020 2:01 PM


    To: ketant@cisco.com; hannes@gredler.at


    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org

    Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type







    = =C2=A0



    Hi Ketan,



    =C2=A0


    =



    =C3=98=C2=A0

    This helps identification of specific SR-MPLS = segment types as well as differentiating them from LDP, RSVP-TE, etc.



    =C2=A0





    =C2=A0





    =C3=98=C2=A0

    What value is provided for IPFIX analysis if the SR Prefix SID was b= eing signalled via OSPF or ISIS?



    =C2=A0


    It is important to disting= uish between intend and result.



    =C2=A0



    If you migrate from one label distr= ibution protocol to another, a network operator want's to understand if= the data plane is still forwarding packets with

    the label distribu= tion protocol which needs to be removed or not. IE46 enables that by lookin= g at the result of the forwarded traffic and not at the intend. RFC 8661 se= ction 3,

    https://tools.ietf.org/html/rfc8661#section-3,<= br>
    describes the context.



    = =C2=A0





    =C3=98=C2=A0=

    What value is prov= ided for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?



    <= u>=C2=A0



    Quote from RFC8402. "Segment Routing (SR) leverages the source r= outing paradigm". Means that not the routing protocol does all the for= warding decisions,

    the node can change the forwarding by pushing ad= ditional labels.. With IPFIX SrSidType we are able to cover this dimension = in IPFIX. Enabling to analyze the result of this decision. The example with= " Adjacency SID or a LAN Adjacency SID" is not very useful
    because the difference of the two is the topology among the adjacency. I= f you compare " Adjacency SID with Prefix SID", that makes much m= ore sense. Since it describes that a particular adjacency is chosen to forw= ard the packet instead of a prefix. If IE 89,

    ForwardingStatus is d= rop, we understand that result of that decision lead to the drop and this e= nables to narrow down forwarding issues in segment routing networks more ef= ficiently and quickly.



    =C2=A0



    =C3= =98=C2=A0

    am asking for WG to weigh the= implementation complexities



    =C2=A0



    For the WG a= nd me, I would be important if you can describe more detailed what you mean= with

    implementation complexities. I wou= ld like to have a better understanding where your fear is coming from. I wo= uld appreciate if you could differentiate between

    MPLS Label Type identifier, IE46, from which label protocol the la= bel was coming from and SrSidType which SID type was used..

    <= u>



    = =C2=A0



    = Best wishes



    Thomas



    <= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS",sans-se= rif;color:#44546a">=C2=A0






    =C2=A0



    Hi Thomas,



    =C2=A0


    I should have been more clear= in my email.



    =C2=A0



    The proposal/suggestion is to add the following to t= he IPFIX MPLS Label type identifier registry:


    <= br>



    -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    SR Prefix SID



    -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    SR Adjacency SID




    -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= br>
    SR Binding SID





    -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0

    SR BGP Pe= ering SID





    -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0

    =E2=80=A6 and so on



    =C2=A0



    This helps identification of specific S= R-MPLS segment types as well as differentiating them from LDP, RSVP-TE, etc= .



    =C2=A0



    And my questions were:





    1)=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0

    What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS?





    2)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    What value is provided for IPFIX analysis if it was a Adjacency= SID or a LAN Adjacency SID?



    =C2=A0



    I am asking for WG to weigh the imple= mentation complexities and overheads with the proposed details of SR-MPLS s= egments in IPFIX against the benefit (if any) that they provide for the
    =
    flow analysis and monitoring.



    =C2=A0



    =

    Thanks,

    Ketan



    =C2=A0







    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>




    <= b>Sent: 15 August 2020 09:40


    To: Ketan Talaulikar (ke= tant) <ketant@cisc= o.com>;

    hannes@gredler.at


    Cc: lsr@ietf.org;

    spring@ietf.org    ; opsawg@ietf.org


    Subject: RE: = [Lsr] draft-tgraf-ipfix-mpls-sr-label-type



    <= br>


    =C2= =A0



    Hi Ketan,



    =C2=A0


    Thank you very much for the rev= iew and feedback.



    =C2=A0





    =C3=98=C2=A0

    What or how much value be there on determining whether a SR Prefix S= ID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what= matters and is more important is that

    it is a Prefix SID. Hardly a= ny deployments would be running multiple protocols and learning the same pr= efix from different IGPs.



    =C2=A0



    =

    As Jeff already p= ointed out. Multiple IGP labelling protocols are used =C2=A0in networks whe= n migrations are ongoing. Usually in a life cycle. Migrating

    from L= DP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom when= we first discovered this shortcoming in vendor implementations. The key po= int here, with these additional IPFIX MPLS Label Type identifiers we enable= the possibility to verify

    the label protocol migration without tak= ing the label value into the consideration.


    =C2=A0



    =C3=98=C2=A0

    <= /span>IPFIX may be picking this information fro= m a FIB in some implementation where the protocol does not matter and this = information is not available therein.



    =C2=A0


    <= br>

    I am not sure = if you have seen the presentation in IETF 108 at OPSAWG and SPRING.<= u>



    https://www.ietf= .org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-= information-in-ipfix-00.pdf



    =C2=A0



    Slide 2 shows Cisco = as example vendor which implemented IE 46, MPLS Label Type identifier. Ther= e is an open ddts where vendor feasibility has

    been clarified. Ping= me off the list when you like to have more details.

    = =C2=A0



    = I do understand your point that not all the vendors are capable to implemen= t IE 46. But that=E2=80=99s not the point about the IPFIX IE registry.
    <= br>    The IE registry enables that a= n IPFIX implementation can refer to the right code point. With RFC 5102 the= decision has been made that MPLS Label Type identifier

    make sense = and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends t= he IE 46 registry with the Segment Routing label protocol code points so wh= en OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX imp= lementation can point

    to the right code point.    =



    =C2=A0




    =C3= =98=C2=A0

    On some nodes, the same Prefi= x SID may be learnt via both BGP and IGP =E2=80=93 what would we use/show?<= u>



    =C2=A0



    In this case the IE 46 shows the label= protocol which was used to program the FIB.



    = =C2=A0





    =C3=98=C2=A0

    For that table proposal, it is very difficult and in some case= s not possible to different between Prefix and Node and Anycast SID. Many o= f these types are control plane elements

    and we can be sure more ge= t added.

    =

    =C2=A0

    =

    I fully agree. As a netw= ork operator its still hard to understand the architecture and constraints = within a router. When monitoring capabilities are discussed

    at IETF= , this is the usual topic. What is possible, what make sense. By purpose, a= ll available SID types are listed in the draft. This with the aim to start = the discussion in the working groups what is possible what makes sense. I w= ould be interested to get

    your and also Jeff's feedback.=



    =C2=A0



    In above mentioned slides I described how TI-LFA application would benefit= of visibility in the FIB by showing where Adj-SID was used. This should be= a simple

    example why it make sense not only to look at which label= protocol was used to forward a particular packet, but also which SID type = to further understand the intend why this label is being pushed.

    =



    =C2=A0



    I hope this makes all sense. Looking forward for reply.<= /span>



    =C2=A0



    Best wishes



    Thomas



    <= u>=C2=A0







    From: Ketan Talaulikar (ketant) <ketant@cisco.com>




    Sent: Friday= , August 14, 2020 7:35 PM


    To: Graf Thomas, INI-NET-DCF &l= t;Thomas.Graf= @swisscom.com>;

    hannes@gredler.at


    Cc: lsr@ietf.org; SPRING WG <spring@ietf.org>

    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type







    =C2=A0



    < also copying Spring WG for their review/inpu= ts >



    =C2=A0



    Hi Thomas/All,



    =C2=A0



    =

    I have reviewed the draft and w= ould like to share a different perspective.


    =C2=A0

    What or how much value= be there on determining whether a SR Prefix SID was signalled/programmed o= n a node via OSPFv2/OSPFv3/ISIS =E2=80=93 what matters and is more importan= t is that it is a

    Prefix SID. Hardly any deployments would be runni= ng multiple protocols and learning the same prefix from different IGPs. IPF= IX may be picking this information from a FIB in some implementation where = the protocol does not matter and this information is not

    available = therein.



    =C2=A0



    On some nodes, the same Prefix SID may be learnt via bot= h BGP and IGP =E2=80=93 what would we use/show?


    =C2=A0



    I would recommend = using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peering SID a= nd so on =E2=80=A6 for the MPLS Label Type.


    =C2=A0

    This also takes away t= he need for the second table that is being proposed to a large extent. For = that table proposal, it is very difficult and in some cases not possible to= different

    between Prefix and Node and Anycast SID. Many of these t= ypes are control plane elements and we can be sure more get added. Is there= really much value in differentiation between say an Adjacency SID and LAN = Adjacency SID?



    =C2=A0



    Could we evaluate the implementation overhead and c= omplexity of this level of categorization/information in IPFIX against thei= r value in flow analysis to perhaps consider a middle ground?=



    =C2= =A0



    Th= anks,



    Ketan



    =C2=A0





    =

    From: Lsr <lsr-bounces@ietf.org>

    O= n Behalf Of Thomas.Graf@swisscom.com


    Sent: 31 July 2020 20:52<= br>

    To: hannes@gredler.at


    Cc: lsr@ietf.org


    Subject: Re: [Lsr] = draft-tgraf-ipfix-mpls-sr-label-type






    =C2=A0=



    Hi Hannes,



    =C2=A0



    Thanks a lot for the feedback. Yes, = makes completely sense. Will take it for the next update...



    =C2=A0



    Best Wis= hes



    Thomas





    =C2=A0



    =


    = =C2=A0







    From: Hannes Gredler <hannes@gredler.at>




    = Sent: Wednesday, July 29, 2020 9:31 AM


    To: Graf Thoma= s, INI-NET-DCF <Thomas.Graf@swisscom.com>


    Cc: lsr@ietf.org


    Subject:= Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type






    <= u>=C2=A0



    Thomas,





    =C2=A0



    <= br>


    I have one = comment/suggestion to Paragraph 4 (IANA Considerations).







    =C2=A0






    Please add also a code point = for BGP Prefix-SID - it=E2=80=99s quite popular in DC deployments.







    <= span lang=3D"DE-CH">https://tools..ietf.org/html/rfc8669



    =




    <= /u>=C2=A0







    thanks,







    = =C2=A0







    /hannes



    <= br>




    =C2=A0






    On 28.07.2020, at 10:11,

    Thomas.Gr= af@swisscom.com     wrote:





    =C2=A0






    Dear lsr,







    =C2=A0







    I presented the following draft







    =C2=A0=







    Export of MPLS Segment Routing Label Type Information in IP Flow= Information Export (IPFIX)









    =C2=A0<= u>







    at the spring working group at IETF 108 yesterday









    = =C2=A0






    and today at OPSAWG where I= call for adoption.






    =C2=A0<= span lang=3D"DE-CH">






    This draft adds additional segment routin= g code points for in the IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 = and segment routing SID types to gain further insights

    into the MPL= S-SR forwarding-plane.

    =





    =C2=A0





    =

    I have been asked to not only gather f= eedback from spring and opsawg but also from lsr and mpls working groups si= nce these code points are related to link state routing

    protocols a= nd mpls data plane.






    =C2=A0<= span lang=3D"DE-CH">






    I am looking forward to your feedback and= input.



    <= br>


    =C2=A0







    Best Wishes=







    = Thomas Graf





    ________________________= _______________________


    Lsr mailing list


    Lsr@ietf.org


    https://www.ietf.org/mailman/listinfo/lsr









    =C2=A0











    ________= _______________________________________

    OPSAWG mailing list

    <= a href=3D"mailto:OPSAWG@ietf.org" target=3D"_blank">OPSAWG@ietf.org
    =
    https://www.ietf.org/mailman/listinfo/opsawg
    =
    --


    Gyan Mish= ra

    Network So= lutions Archi= tect=C2=A0

    M 301 502-1347
    13101 C= olumbia Pike=C2=A0
    Silver Spring, MD


    =
    --0000000000002081ef05ad0cc38b-- From nobody Sun Aug 16 23:44:40 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B10E3A09F4; Sun, 16 Aug 2020 23:44:39 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=udEEgyK/; dkim=pass (1024-bit key) header.d=juniper.net header.b=ID7idDQF 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 ckz9Dn3_JNGL; Sun, 16 Aug 2020 23:44:37 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 047983A09F3; Sun, 16 Aug 2020 23:44:36 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07H6gmKZ027268; Sun, 16 Aug 2020 23:44:35 -0700 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 : mime-version; s=PPS1017; bh=26ZEdpLz3bB/yW5K8VN34ZZJjDBeOCcgiFI7tI4iTYA=; b=udEEgyK/Ret/3+J7VkOG7gvnQoRGfMgh3KlzCuUcVRCXwM3ePf+o6ZbHDGyPwWSl8uWx hKmnEYMmnioV07Tw1lCWk3D42mrki2al+51s3rKaC72nqPdyQ/aF93GhkESfBh8MLTzZ zvsuV5vJ7Rm4im/joDXFB3eoOX1vHQlYn6R+vJrEUkVzvtrCt6xoa9tbkkKe2gKB3TIZ /sC/pM4W0POc+z+somvzvTZp8pSoeORbvl/hVyxbiR/UqUEl3WjaxAE/PmJC6vuy2MBK feL4WqKD8QZ/6oTfeC6bqL6yDQt76Z3zIqjD4zUoYW4EkxP58xHBKqAZDtQ0nBT4eoFe 4w== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47]) by mx0b-00273201.pphosted.com with ESMTP id 32xety9vyx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Aug 2020 23:44:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VQxzxNLoiZf237Up1PiofVwoVQndFQ4OuLiKIryaVX3mMVvRYsBAUjLcfculacR60ooVScX8D+FZyA3aoDUb/tBKyir+UJSVwYpGITuvgQ0cY3Sob6utwOiZHvlpF5wHrZV2/j3RMdpmIsMNuHVd94t22lOfkjCxCJB1USDkta6KJF4EzyzU/93zNcNL4zM6dw4LrSXqXU3Vh5xtSDuZN1tgt2B5ATYfBtJBSPd38vqJzAlj9bFuy9PIwyZ4HcUmFQgu5DG6BuRVW0wpYaTHSbFtwqY+EPkr/usoV4oDU4oC75D+bI8vkGXLiY3he7tnfRJUezWQ1V68gf5AjDCaCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=26ZEdpLz3bB/yW5K8VN34ZZJjDBeOCcgiFI7tI4iTYA=; b=K7Aoiy/TkajmgsI1N6kSfPlaAMwvNKvOvLZZbfXlv/Ipjsgi1YJge+6bkjQWFA9j54QoCtlGXoPxYhR89QpJtcl05RqCEWf44Hb9Va6EaC1t8o0vQUBVIMr2cw5/7q6+lWonam5JYl3Pj21lSgX90nFICllybSSzGC+ci2Qcu9iOnuh2FlOi5SNtxUcPZKnMfdBo7V6ydehGtl0r3/vil1mOgA/DoOwgKLfDGugzqBATtr1Ib+S4+PCYvcdtTEmh+A45SraJbWkJkvFt+qx2qESXnIY5hE3yIVTmQT4C0xR4DXofnIwPQhiB8Od89B9qCHrVI/urnNDtm2b2I2Bbow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=26ZEdpLz3bB/yW5K8VN34ZZJjDBeOCcgiFI7tI4iTYA=; b=ID7idDQFYeeQrd9ppOeTz7yQpr9Fk/ZBWUbxYQ43WfhqDu36+80K5dR71m+OZlSlA0OO4XGDWhKOkZdhdtM9QrALmBDRgVPLH+UJUHeaw4Aa7PZZC8FImPJGdIqMr7Dj5K/1ejYCWBrB74N+LXi7TZgh9vk7qoR0Q84LnEPmVNM= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3304.namprd05.prod.outlook.com (2603:10b6:910:57::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.13; Mon, 17 Aug 2020 06:44:32 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3305.021; Mon, 17 Aug 2020 06:44:32 +0000 From: Shraddha Hegde To: "Ketan Talaulikar (ketant)" , "bruno.decraene@orange.com" , "spring@ietf.org" CC: "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Thread-Topic: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths Thread-Index: AdZmaxBja895PvK+QsirQTKFBBYlewLx82dwAIu3MKA= Date: Mon, 17 Aug 2020 06:44:32 +0000 Message-ID: References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-17T06:44:30Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=e4cc88c8-796d-461f-b79b-e386f11729e2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [116.197.184.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6cb0771e-f4f8-4bff-1dbc-08d84278ffad x-ms-traffictypediagnostic: CY4PR05MB3304: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fkXoEP5WQV87siEnjSdP33GSVeBwkADnGkFbgW0VhCQglpcfe1/5JvNiNtniyXRPRXRdtIEOWnSL38iYuDsMUcVF31FZqt0XU5ooctIQtuWpFa9PHZSZl3t0ICq55G1vyt5Z1cwWIAXNT2JXQD8xWuf6kZ0QICXggx1KQnKxHrqfOsaxVWT6Ausx7As2ynjNlmqidK8ZcvnQXmrXKByUiYpquihbCyC0VU5p0cQXsYegohmFTtS7yXDNtu9z9i+JwGLy1K86MIFrtKLjcuXVk1epI/+spSK8Sydj/Pf+7QD+1UrdoOoNq8JskjlnovNnJnTaFbFWefd78GwtzlPQOpt4N/gam+evfvpTnvrXY22ci0wNjA39apKWNnmZygKc/nTpo6eUt5LUJVtdlne0Nw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39860400002)(376002)(346002)(6506007)(53546011)(66556008)(166002)(55016002)(66446008)(5660300002)(9686003)(7696005)(66476007)(966005)(8676002)(64756008)(8936002)(478600001)(26005)(186003)(83380400001)(2906002)(316002)(4326008)(86362001)(110136005)(33656002)(76116006)(66946007)(52536014)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2jcHUIEJ78bUr5w6xD6FUO7A12+kWcu5INCXt0wt2sCLjB169g6rtc2upUOP1OtezvUhFTGN5QJ5dEa6Aof8K5B4oKkiJ7z3WR0C1ojlDQ5ihoK7SDnUtSVeevPvKQPGW8fKt7dCu91t/3saXGQfEZgXvH+XEOCy2dseSTA6nHcANbBXxruYXt9wj1OKRjgYS0SR7HtiNk6RkaW3bqwl9B4+H1nZsN+WjucIfr/IbdADb1dczgdgptwh7h8tNl9hdf8Rglmoy+sFFC67WrMw/YcKXFNk7Wl1mVI4rv1KLcHVEy1oVxOGKsXTQFeNb8oehFF5TM6bRTa91UfiWB1kUG0J6JO2ZmKcdZ8x8WbYYVSwIYsISLTDmtdgft1FIgpqi/rimLHSmpMyzJNrJ5CgcgaREilAplYOzuMR4c/0hPbYJhkyMUNtECEvIJbmSRrc4tJOisBxuqWQjDfMdbCHb0+X54uF6eXSS+s+GvIJSiZi2R/g6UeljsDVWzNz2IDkDvbS9OTAw85iZLKnrfFzhVMyqyDw0UKarfz3brLekBJiMvWtf9Z2h0W3xJwncRbPiw0p6zvGnBFBoRUmiYddvokRdOKcz/C1ghvmvihQNu1lMkd0SRd+vH3CSMO4jt3aSCW1BI6+bHFDr3Uzgd4eEw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3576B470BB396699F0BADD4AD55F0CY4PR05MB3576namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cb0771e-f4f8-4bff-1dbc-08d84278ffad X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 06:44:32.4730 (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-CrossTenant-userprincipalname: 2QSSD6L7sbryyBWwLynCPyhNbZBypsG4jS0UaB4A60gYHgSlgYjrL0ge5MF32dDqgEuasHE5Ku0c8dubrxnuXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3304 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-17_02:2020-08-17, 2020-08-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 clxscore=1011 bulkscore=0 phishscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 impostorscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008170052 Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 06:44:39 -0000 --_000_CY4PR05MB3576B470BB396699F0BADD4AD55F0CY4PR05MB3576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ketan, Thanks for the review and suggestion. I'll add a section on B-SID and EPE SID in the next revision. Rgds Shraddha Juniper Business Use Only From: Ketan Talaulikar (ketant) Sent: Friday, August 14, 2020 5:55 PM To: bruno.decraene@orange.com; spring@ietf.org Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org Subject: RE: [spring] WG adoption call for draft-hegde-spring-node-protecti= on-for-sr-te-paths [External Email. Be cautious of content] Hi All, I believe this topic is relevant and something for the WG to adopt and work= on. I have some concerns though on it's applicability and more specifically it'= s implications on existing deployments/use-cases. I've share the same on th= e thread started by Joel on this specific aspect [1]. Some discussion and c= larity on this would help before adoption. One other bit, for the example in Sec 2.3, perhaps some text is required to= clarify that this applies only for segments signalled via IGPs and if the = 9054 was a BSID or BGP-EPE SID then this approach would not work. May I sug= gest to add a section 2.4 to capture these aspects (it would be some what o= n the lines of Sec 3.4 but not related to the context table solution). The document is well-written and detailed. It does a very good job of descr= ibing the node protection scenarios and options. Thanks, Ketan [1] https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOm= M/ From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: 30 July 2020 17:55 To: spring@ietf.org Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org Subject: [spring] WG adoption call for draft-hegde-spring-node-protection-f= or-sr-te-paths Hi SPRING WG, Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have ask= ed for WG adoption. Please indicate your support, comments, or objection, for adopting this dra= ft as a working group item by August 20th 2020. (*) Could those who are willing to work on this document, please notify the lis= t. That gives us an indication of the energy level in the working group to = work on this. Thanks, Regards, Bruno, Jim, Joel [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-t= e-paths-07 (*) 3 weeks to account for the IETF meeting week and the august/summer peri= od. ___________________________________________________________________________= ______________________________________________ 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_CY4PR05MB3576B470BB396699F0BADD4AD55F0CY4PR05MB3576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi ketan,

     

    Thanks for the review and suggestion.

     

    I’ll add a section on B-SID and EPE SID in the= next revision.

     

    Rgds

    Shraddha

     

     

    Juniper Business Use Only

    From: Ketan Talaulikar (ketant) <ketant@ci= sco.com>
    Sent: Friday, August 14, 2020 5:55 PM
    To: bruno.decraene@orange.com; spring@ietf.org
    Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org
    Subject: RE: [spring] WG adoption call for draft-hegde-spring-node-p= rotection-for-sr-te-paths

     

    <= span lang=3D"EN-IN" style=3D"font-size:10.5pt;font-family:"Lato",= sans-serif;color:black">[External Email. Be cautious of content]=

     

    Hi All,

     

    I believe this topic is relevan= t and something for the WG to adopt and work on.

     

    I have some concerns though on = it’s applicability and more specifically it’s implications on e= xisting deployments/use-cases. I’ve share the same on the thread star= ted by Joel on this specific aspect [1]. Some discussion and clarity on this would help before adoption.

     

    One other bit, for the example = in Sec 2.3, perhaps some text is required to clarify that this applies only= for segments signalled via IGPs and if the 9054 was a BSID or BGP-EPE SID = then this approach would not work. May I suggest to add a section 2.4 to capture these aspects (it would be some = what on the lines of Sec 3.4 but not related to the context table solution)= .

     

    The document is well-written an= d detailed. It does a very good job of describing the node protection scena= rios and options.

     

    Thanks,

    Ketan

     

    [1] https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/

     

    From:<= /span> spring <spring-bounces@ietf.org> On Behalf Of bruno.decr= aene@orange.com
    Sent: 30 July 2020 17:55
    To: spring@ietf.org
    Cc: draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org
    Subject: [spring] WG adoption call for draft-hegde-spring-node-prote= ction-for-sr-te-paths

     

    Hi SPRING WG,=

     

    Authors of draft-hegde-spring-n= ode-protection-for-sr-te-paths  [1] have asked for WG adoption.

     

    Please indicate your support, c= omments, or objection, for adopting this draft as a working group item by A= ugust 20th 2020. (*)

     

    Could those who are willing to = work on this document, please notify the list. That gives us an indication = of the energy level in the working group to work on this.=

     

    Thanks,

    Regards,

    Bruno, Jim, Joel

     

    [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-pa= ths-07

    (*) 3 weeks to account for the = IETF meeting week and the august/summer period.

     

    ____________________________________________________=
_____________________________________________________________________<=
/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_CY4PR05MB3576B470BB396699F0BADD4AD55F0CY4PR05MB3576namp_-- From nobody Sun Aug 16 23:51:37 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E234B3A0407; Sun, 16 Aug 2020 23:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.487 X-Spam-Level: X-Spam-Status: No, score=-9.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=YpSz+/ir; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hbwS0w40 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 OujYPNKHqEao; Sun, 16 Aug 2020 23:51:28 -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 442363A09E5; Sun, 16 Aug 2020 23:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69360; q=dns/txt; s=iport; t=1597647088; x=1598856688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W3lkOjIPr2LLoTaXQ3xlVXE0kaYknKiJbCjUogN8gz0=; b=YpSz+/irYdCrOmqt3MSEgVw/yqXUmxcbSOnSE+vrokZnQAP+gRBNa33P dosF/c5CBsC/cuon1/hSaAZI1BjHb3eyBYyzDhqIxiUIPwShgoGcIbX8/ pqm4ShhA7hWdwXwzDX+ladrUB+9IGjo7RTFG2ViYCvn0DwzQqQDSUZBBb 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AiFqwQRa0BB6KUwdZ5G5N223/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWRD57E6ulfgO3T9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7JvXyp9jUVH1?= =?us-ascii?q?P0Mg8mbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHCgBxKDpf/4YNJK1fgQmCbS8jBig?= =?us-ascii?q?HcFgvLAqGCoFpA41amGmBQoERA1AFCwEBAQwBARgBCQsCBAEBgW2CXwKCRwI?= =?us-ascii?q?kOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQECAgEBEAgDEBMBASoBAQgDAQ8?= =?us-ascii?q?CAQgRAQMBASEBBgcnCxQDBggCBAENBQgRCYJ/BAKBfk0DLgEOpEoCgTmIYXS?= =?us-ascii?q?BNIMBAQEFgTMBAwICg3MDFYIOAwaBOIJxiiwbgUE/gRABQ4FPfj6COiIBAQE?= =?us-ascii?q?BARaBDAUbHAwYBwkCgxKCLY9WISEDiUmLXZByCoJiiGOFfItigwCJXAWRGYI?= =?us-ascii?q?nkjmBbIhXlHwCBAIEBQIOAQEFgWojDVpwcBU7gmkTPRcCDY18LxeBAgEJgkK?= =?us-ascii?q?FFIVCdAIBAQEyAgYKAQEDCXyPIQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,322,1592870400"; d="scan'208,217";a="527164978" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Aug 2020 06:51:26 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 07H6pQRb003010 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2020 06:51:26 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 Aug 2020 01:51:26 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 Aug 2020 01:51:25 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 17 Aug 2020 01:51:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SyfJ0vSohVtifWjBVRHTXW6OArujhuQ3ZBJ4GQv3UiARnqHlNd+0kTpEf0Fyj+MdrHgYPLoYMI/F3sFU2e5x2sL56fjAwYENY/7kBdL+o3S4+lfiW4OowAqK0tOdsQJ9n1zgtO3h9/C2X9J+h9iij1du5vxYm0GQ7rVrPGu3ETTdg/J1Fj4THOU3rT/GjPpzk3VyIDULg02V2vVKKKrBDodzcmL9VAkWTgunSJtaNRPbJMuj47BUWAxfK2qve+sSIBxdhVlJ6X4BrQenbA1BMnE4A2MMYgJe7sUBRObEV0MH41Sj8LriOl9W5jtVUHgrvnkd1jQKIE3wVNHhF3YcFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ci7yOzmGM2GcrrI/RBgUJvoCU9NFzXWXXBmFrBoihNA=; b=RIRLBTF8vrhgNlHiK2VxCoAqic1KEv5xVnW4NWE++95y+eIWIhZlWyzh58a/gyMpM/irN37QWnu1k5Hf8B9dFP/sX6dRGQ+1iEXyGzAp6pX0e/rFM6BXQI+dNkhAVgzyS15kXcHO9ZVpDe3LGV8ZgFTfxw+NDE5yuRXe/627829K/Uf0pKBhAlOfKSrJ6PF+reWq20L0UQzPoqnfd2PF0pHb1gWfGhPKrSQ/TL2PNWx3tMnlobYWw7j1Y2e24U1le4ZcnEBltfjFCtn1Le6kP6liJ5McL7mMLRSwlKVojI+oVh5MlQ7Gi6w/ixH//6kQU6kI2WTtRNuLgIErgT7pNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ci7yOzmGM2GcrrI/RBgUJvoCU9NFzXWXXBmFrBoihNA=; b=hbwS0w40HG6+MhRxgZvFbG89yQXOPhZFD2XMSWHJ5NBbQ0cDPuPL9N+IDJeE6wV+QIQWX0J1LuHiHxRO2lYUIEYfBeEH6WuPDKQnE1VHuzI3b+Ob9iXwBZ7LuBCwEuSILcfOWraSKOTq6kGNX47vp5+9dbkwUQSxN2EFD/z4SFA= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2271.namprd11.prod.outlook.com (2603:10b6:301:52::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Mon, 17 Aug 2020 06:51:23 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135%8]) with mapi id 15.20.3283.024; Mon, 17 Aug 2020 06:51:23 +0000 From: "Ketan Talaulikar (ketant)" To: "Thomas.Graf@swisscom.com" , "hannes@gredler.at" CC: "lsr@ietf.org" , "spring@ietf.org" , "opsawg@ietf.org" Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AdZktQw6qX35tZ6KQpiaZtLipXAiTwAxTF+AAHUFTIACvTCesAAduZCAAAG4RsAAAinugABlpowA Date: Mon, 17 Aug 2020 06:51:23 +0000 Message-ID: References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> In-Reply-To: <696872714.3003081.1597471334092@ss002889> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: swisscom.com; dkim=none (message not signed) header.d=none;swisscom.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ae68e30-8d5d-48cf-7ef1-08d84279f4da x-ms-traffictypediagnostic: MWHPR1101MB2271: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: am9ayude5lrAraHL+ym9XISscYKSVuli6aP3QEs8+zpL10ktNBPj8/kuqw8RsathvZnxX+0Fi9hJ9QyKly7l2ZTdt3kLdqq1CZRWRm6mLifqmwyqyFxgvlse15ltmogXrO4lDdwYPvQXe70sZBhwv2xyfv7Y/5epV6S0R4rVoZPJb+UOc1uxzg8PKHW0GtEhQj4PthmWHBHOoTraJ/MJwOVtiMioBtgqw3dYKLRkUrFzGiqQAz4rVgABztpgu8UHAYg5XcTxmuclgR2QXbad3j/zIZZ+scy0ncm0kqmYu0j/TzmHqfjxilARTTEJuFODRrKflAkkNqiP2bqlrxk+Sk/qvhESmuHUCyX1bvj27h5J8SNfiheRf4FDznuehZuetB6PRRKzsXZ0NB0rBahRjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(366004)(376002)(136003)(76116006)(66946007)(2906002)(66556008)(110136005)(66446008)(64756008)(66476007)(54906003)(30864003)(83380400001)(8936002)(966005)(186003)(4326008)(8676002)(33656002)(71200400001)(5660300002)(316002)(9326002)(26005)(53546011)(9686003)(66574015)(7696005)(166002)(52536014)(19627235002)(478600001)(86362001)(6506007)(55016002)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wTfHDUe2BGO4qv/+VQUaTqJ94AAV3ihOEWO0zca372iSNmyg5z0HjWwArhsHt6zh+gAz84b0a0zE4Oq/x1EK1/mRg4AofFrOdjhqcKUzRoNqCu1Ren16ro3lKQO5VCWYEcpY4VtS11ZLoG4VIpsM8t1kTPY5XDc5nC0ntv4DdJv57gfSvCpw9eh6bQOlKSRawcjMqLwxpwfKCcyVCMdYacUDNcW8MTS54FlVf17huJBw1eDt3dgadU4DyTgzBfgCEvKNf7EDDiq5w0lblApfpxrrneTQCfHatxIn6O+92PTTSM4eU1y0qeJiaUEaf45ib0NBljtmmoGXFFNK2zgpDsPAAfGj4p4PK/DKGdOZJLZ3UI/Y/64O+8fcbZbYPhd7IC7SJVf+H+wFXsCdsiVKwk6D7zHUuZxqcGTRctfSPTx5YUrm207t/2BdimFsdpomm3gdTz/C3zcbxjRAfM8LUZWBQx6WrkmiB+Y08Z0x1JPja/lZSTx3jXs1F4Npf7u0FnoYwxoBPgui5s+sRvShP06UNeUY1M2cfUVlzBhXBrhUyPBI0vmw4jWyoype49I+GaMkusXz09y8lUrizP14hsEhSULYA67kjHzeCpnbqTovljSHEzX8hvVsPDQ9/EdBIiqC2rUl4zbl2yqsMH2dPg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB457038435188E14B03EBD599C15F0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ae68e30-8d5d-48cf-7ef1-08d84279f4da X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 06:51:23.6653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /lqHmmuE7/RyqCQZDarDsoAYPJLWCkVFLx0DCPbkxmWK1yzUkcNJZHRI8ZGZ/iFxN6mNMar8dWJ0FUN6z1NvwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2271 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 06:51:32 -0000 --_000_MW3PR11MB457038435188E14B03EBD599C15F0MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, Please check inline below. From: Thomas.Graf@swisscom.com Sent: 15 August 2020 11:31 To: Ketan Talaulikar (ketant) ; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, * This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR= Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment ty= pes from RFC8402)? It's a simpler change to an existing element/field that = makes it easier for routers, collectors and analysers? * What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? It is important to distinguish between intend and result. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets = with the label distribution protocol which needs to be removed or not. IE46= enables that by looking at the result of the forwarded traffic and not at = the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section= -3, describes the context. [KT] Sure, so adding the SR Segments to IE46, one can check whether the tra= ffic forwarding is happening using LDP or SR labels at any link in the netw= ork. * What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decision= s, the node can change the forwarding by pushing additional labels. [KT] From the document, I believe we are still talking only about the top o= f the stack label ... With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling= to analyze the result of this decision. The example with " Adjacency SID o= r a LAN Adjacency SID" is not very useful because the difference of the two= is the topology among the adjacency. If you compare " Adjacency SID with P= refix SID", that makes much more sense. Since it describes that a particula= r adjacency is chosen to forward the packet instead of a prefix. If IE 89, = ForwardingStatus is drop, we understand that result of that decision lead t= o the drop and this enables to narrow down forwarding issues in segment rou= ting networks more efficiently and quickly. [KT] My point is why do we need to introduce another ElementID and why not = use the existing Type 46 as suggested above? * am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a bette= r understanding where your fear is coming from. I would appreciate if you c= ould differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= . [KT] To be clear, I am not talking from the POV of a specific implementatio= n. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nu= ances into IPFIX since they require all that additional context/information= to be made available at the "layer" (or component) from where IPFIX picks = this info (traditionally from the "FIB"). This added information should hav= e a strong enough justification of benefit - e.g. How does difference betwe= en Adj SID and LAN Adj SID matter? How relevant it is to determine if the = SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount= and sufficient information that is necessary for flow analysis. We need to= note that there may be many more/other sources for "off-box enrichment" of= flow information collected and perhaps not everything needs to be determin= ed and reported by routers. Thanks, Ketan Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters = and is more important is that it is a Prefix SID. Hardly any deployments wo= uld be running multiple protocols and learning the same prefix from differe= nt IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available= therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not p= ossible to different between Prefix and Node and Anycast SID. Many of these= types are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update.. Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_MW3PR11MB457038435188E14B03EBD599C15F0MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Thomas= ,

    &nbs= p;

    Please ch= eck inline below.

    &nbs= p;

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 11:31
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredl= er.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    • This helps identification = of specific SR-MPLS segment types as well as differentiating them from LDP,= RSVP-TE, etc.

     =

    To be precise, th= e existing MPLS Label Type identifier differentiates from LDP, RSVP-TE. Not= the new SrSidType IPFIX IE being proposed.

    [KT= ] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR Pr= efix SID, SR Adjacency SID, SR Binding SID … (basically the segment t= ypes from RFC8402)? It’s a simpler change to an existing element/field that makes it easier for routers, collectors = and analysers?

    &nbs= p;

    • What value is provided for= IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?

    &nbs= p;

    It is important t= o distinguish between intend and result.

    [KT] By giving different = types for OSPF and ISIS, is the intention to troubleshoot routing preferenc= e selection (done based on “admin distance” between protocol se= lection in RIB)?

    &nbs= p;

    If you migrate fr= om one label distribution protocol to another, a network operator want's to= understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or = not. IE46 enables that by looking at the result of the forwarded traffic an= d not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context.

    [KT= ] Sure, so adding the SR Segments to IE46, one can check whether the traffi= c forwarding is happening using LDP or SR labels at any link in the network= .

     

    • What value is provided for= IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?

     =

    Quote from RFC840= 2. "Segment Routing (SR) leverages the source routing paradigm". = Means that not the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels= .

    [KT] From the document, I= believe we are still talking only about the top of the stack label …=

     

    With IPFIX SrSidT= ype we are able to cover this dimension in IPFIX. Enabling to analyze the r= esult of this decision. The example with " Adjacency SID or a LAN Adjacency SID" is not very useful because the difference= of the two is the topology among the adjacency. If you compare " Adja= cency SID with Prefix SID", that makes much more sense. Since it descr= ibes that a particular adjacency is chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we und= erstand that result of that decision lead to the drop and this enables to n= arrow down forwarding issues in segment routing networks more efficiently a= nd quickly.

    [KT] My point is why do w= e need to introduce another ElementID and why not use the existing Type 46 = as suggested above?

     =

    • am asking for W= G to weigh the implementation complexities=

     =

    For the WG and me= , I would be important if you can describe more detailed what you mean with implementation complexiti= es. I would like to have a better understanding where your fear is coming f= rom. I would appreciate if you could differentiate between MPLS Label Type identifier, IE46,= from which label protocol the label was coming from and SrSidType which SI= D type was used.

    [KT] To be clear, I am no= t talking from the POV of a specific implementation. Let me summarize my fe= edback and perspective:

    • Carefully consider the addition of more co= ntrol plane elements and nuances into IPFIX since they require all that add= itional context/information to be made available at the “layer” (or component) from where IPFIX picks= this info (traditionally from the “FIB”). This added informati= on should have a strong enough justification of benefit – e.g. How do= es difference between Adj SID and LAN Adj SID matter?  How relevant it is to determine if the SR signaling protocol is OSPF or ISIS?
    • Try to add/extend existing elements/fields with just the right amoun= t and sufficient information that is necessary for flow analysis. We need t= o note that there may be many more/other sources for “off-box enrichment” = of flow information collected and perhaps not everything needs to be determ= ined and reported by routers.

     

    Thanks,=

    Ketan

     =

    Best wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Saturday, August 15, 2020 7:09 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas= ,

    &nbs= p;

    I should = have been more clear in my email.

    &nbs= p;

    The propo= sal/suggestion is to add the following to the IPFIX MPLS Label type identif= ier registry:

    • SR Prefix SID
    • SR Adjacency SID=
    • SR = Binding SID
    • SR BGP Peering SID
    • … and so on

    &nbs= p;

    This help= s identification of specific SR-MPLS segment types as well as differentiati= ng them from LDP, RSVP-TE, etc.

    &nbs= p;

    And my qu= estions were:

    1. What value is provided for= IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?
    2. Wha= t value is provided for IPFIX analysis if it was a Adjacency SID or a LAN A= djacency SID?

    &nbs= p;

    I am aski= ng for WG to weigh the implementation complexities and overheads with the p= roposed details of SR-MPLS segments in IPFIX against the benefit (if any) t= hat they provide for the flow analysis and monitoring.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 09:40
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    Thank you very mu= ch for the review and feedback.

     =

    • What or how much value be = there on determining whether a SR Prefix SID was signalled/programmed on a = node via OSPFv2/OSPFv3/ISIS – what matters and is more important is that it is a Prefix SID. Hardly any deployments w= ould be running multiple protocols and learning the same prefix from differ= ent IGPs.

    &nbs= p;

    As Jeff already p= ointed out. Multiple IGP labelling protocols are used  in networks whe= n migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swissc= om when we first discovered this shortcoming in vendor implementations. The= key point here, with these additional IPFIX MPLS Label Type identifiers we= enable the possibility to verify the label protocol migration without taking the label value into the consi= deration.

    &nbs= p;

    • IPFIX may be picking this = information from a FIB in some implementation where the protocol does not m= atter and this information is not available therein.

    &nbs= p;

    I am not sure if = you have seen the presentation in IETF 108 at OPSAWG and SPRING.=

    https://www.ietf.org/proceedings/10= 8/slides/slides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfi= x-00.pdf

    &nbs= p;

    Slide 2 shows Cis= co as example vendor which implemented IE 46, MPLS Label Type identifier. T= here is an open ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.

     =

    I do understand y= our point that not all the vendors are capable to implement IE 46. But that= ’s not the point about the IPFIX IE registry. The IE registry enables that an I= PFIX implementation can refer to the right code point. With RFC 5102 the de= cision has been made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type ju= st extends the IE 46 registry with the Segment Routing label protocol code = points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, t= he IPFIX implementation can point to the right code point.

    &nbs= p;

    • On some nodes, the same Pr= efix SID may be learnt via both BGP and IGP – what would we use/show?=

     

    In this case the IE 46 shows the= label protocol which was used to program the FIB.

     

    • For that table = proposal, it is very difficult and in some cases not possible to different = between Prefix and Node and Anycast SID. Many of these types are control pl= ane elements and we can be sure more get added.

     =

    I fully agree. As= a network operator its still hard to understand the architecture and const= raints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what mak= e sense. By purpose, all available SID types are listed in the draft. This = with the aim to start the discussion in the working groups what is possible= what makes sense. I would be interested to get your and also Jeff's feedback.

     =

    In above mentione= d slides I described how TI-LFA application would benefit of visibility in = the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which lab= el protocol was used to forward a particular packet, but also which SID typ= e to further understand the intend why this label is being pushed.

     =

    I hope this makes= all sense. Looking forward for reply.

     =

    Best wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020 7:35 PM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; SPRING WG <= spring@ietf.org>
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    < also= copying Spring WG for their review/inputs >

    &nbs= p;

    Hi Thomas= /All,

    &nbs= p;

    I have re= viewed the draft and would like to share a different perspective.

    &nbs= p;

    What or h= ow much value be there on determining whether a SR Prefix SID was signalled= /programmed on a node via OSPFv2/OSPFv3/ISIS – what matters and is mo= re important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and learning the same = prefix from different IGPs. IPFIX may be picking this information from a FI= B in some implementation where the protocol does not matter and this inform= ation is not available therein.

    &nbs= p;

    On some n= odes, the same Prefix SID may be learnt via both BGP and IGP – what w= ould we use/show?

    &nbs= p;

    I would r= ecommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peer= ing SID and so on … for the MPLS Label Type.

    &nbs= p;

    This also= takes away the need for the second table that is being proposed to a large= extent. For that table proposal, it is very difficult and in some cases no= t possible to different between Prefix and Node and Anycast SID. Many of these types are control plane elements a= nd we can be sure more get added. Is there really much value in differentia= tion between say an Adjacency SID and LAN Adjacency SID?<= /p>

    &nbs= p;

    Could we = evaluate the implementation overhead and complexity of this level of catego= rization/information in IPFIX against their value in flow analysis to perha= ps consider a middle ground?

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Lsr <lsr-bounces@iet= f.org> On Behalf Of Thomas.Graf= @swisscom.com
    Sent: 31 July 2020 20:52
    To: hannes@gredler.at
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Hannes,

     =

    Thanks a lot for = the feedback. Yes, makes completely sense. Will take it for the next update= ..

     =

    Best Wishes<= /o:p>

    Thomas=

     

     =

    From: Hannes Gredler <hannes@= gredler.at>
    Sent: Wednesday, July 29, 2020 9:31 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Thomas,

     

    I have one comment/suggestion t= o Paragraph 4 (IANA Considerations).

     

    Please add also a code point fo= r BGP Prefix-SID - it’s quite popular in DC deployments.

     

    thanks,

     

    /hannes

    =  

    On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

     

    Dear lsr,

     

    I presented the following draft=

     

    Export of MPLS Segment Routing = Label Type Information in IP Flow Information Export (IPFIX)

     

    at the spring working group at = IETF 108 yesterday

     

    and today at OPSAWG where I cal= l for adoption.

     

    This draft adds additional segm= ent routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 an= d OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

     

    I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link state routing protocols and mpls data plane.

     

    I am looking forward to your fe= edback and input.

     

    Best Wishes

    Thomas Graf

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

     

    --_000_MW3PR11MB457038435188E14B03EBD599C15F0MW3PR11MB4570namp_-- From nobody Mon Aug 17 03:45:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356C63A0AA8; Mon, 17 Aug 2020 03:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=GPBz+I/b; dkim=pass (1024-bit key) header.d=juniper.net header.b=DjEPP7+m 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 ZFw2DnSJhKOd; Mon, 17 Aug 2020 03:45:37 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 5E4D43A0A7D; Mon, 17 Aug 2020 03:45:37 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07HAhRZ2026737; Mon, 17 Aug 2020 03:45:28 -0700 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=RppUHsBvSnnxmSlEL/mbnh4tHRBUTnHXyI34dn8O698=; b=GPBz+I/bF+6z5Gj7hLtW9zYyWv23klpla+v4dWw4sE8W2pWBqiw5ZkLxfqBqwIZ2SUaV UljYBZ2bKf4ZNxA+VnW6jbADecorzaDOU6L3t4ksVWJsh7CxFYYu3wPS1GfAvd9OOeF6 n/miC+OlShPiYI1k/cgQ9ltOFjuNgEOl7W4S54Tn1tRPSSiUr9mbZVc7sbRyh06g46d8 Xy9i6gU75WI+JKaxV553se6LlywXU4qTB0JWUOnnP43bHJImNuIbH2ay3IM1hUtTMlCQ zgOaYdFxK6/6NTcN3gPFCpEXm9/TBxwwYcCCew5q9r5OYc9K9L0ohWJQlm2vZFwxg2R3 aA== Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam08lp2047.outbound.protection.outlook.com [104.47.73.47]) by mx0b-00273201.pphosted.com with ESMTP id 32xetya74t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Aug 2020 03:45:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QUpwrA6IvsCzI66zTP4orW/v/mx5pnVEBDfrYzXm8G/Ph6UU0jl36mH3opm2n/A35QR+Lql//mlY0S4UNvxWNcIGQO4fol3syx0WV0bSRFNVOd+z//mEGHmLrEqFrw27aHnKUnWKkdI9u3QfRSxleQi7HEFTprH3xcGxUXMfLseMgcg6IdmEWSYzb/LHS6+OrFZ6n0BqMpch/kAU/1/4qZ7wgus9w9f4qMtj346IAaOCetkRxgLVnicMmTV58rr/ob/LWcU0hJKfaMcwtcg1rGE5/5zX1FSkVinExjElFUwB34MeLEfZh63uEXwliV/FzfjXg644OjhsNj1vF2FGSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RppUHsBvSnnxmSlEL/mbnh4tHRBUTnHXyI34dn8O698=; b=I5eeggO2dsHPfPcBOrvmOF9SoUxxDwkZfZS3x68kOHGm5hEJlsHq4meZZv34iwwCwzbPuAtgmBgHnS/mKuQkTJVT2xm6Ur5C4pFbcWkHGqGpLg2Tz+DfxJNoJr7NUu7Q+l2INeX4jqEj4Zb5THZmKVrDBWjCbLFKcOajdTOAysshU0KWWbZAsxYZd35AuFPnq8gj+yRtVdhrJetj+ZtxmSKGW7d1baHT2iKxf2uKvUX4xFgHWzon6esybV9vxAhCDR0ROhDMBTdelcYgo9Srw8Py9Q0Ld70pUk9EkdD/nqTwQzryDnmMvdccNa+/hQCmZ+VWpDpAOb9h1ZqDNh1D3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RppUHsBvSnnxmSlEL/mbnh4tHRBUTnHXyI34dn8O698=; b=DjEPP7+mJfkS6S75FniumTJlhHa1/OX/UvQy2swo5rl+Lb7SFsWk7EJ08ujuuUYCirrDnITqnVtZKfDuqO3g9FTB4ZtScchJThQC5quTG7m+rgSS97qpx+TBLR/L56+IHah4QJRQniUhXLzC9qdYMUCKlslq+e5zcbu5e6UsNfg= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3430.namprd05.prod.outlook.com (2603:10b6:910:5a::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.16; Mon, 17 Aug 2020 10:45:24 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3305.021; Mon, 17 Aug 2020 10:45:24 +0000 From: Shraddha Hegde To: Huzhibo , IETF Secretariat , "spring-chairs@ietf.org" , "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Thread-Topic: [spring] The SPRING WG has placed draft-hegde-spring-node-protection-for-sr-te-paths in state "Call For Adoption By WG Issued" Thread-Index: AQHWZmzEFwNrV+hVKEmdcwB9Q+fIKak3tUWAgASC/KA= Date: Mon, 17 Aug 2020 10:45:24 +0000 Message-ID: References: <159611203375.23062.15788303421011485933@ietfa.amsl.com> <06CF729DA0D6854E8C1E5121AC3330DFAF749133@dggemm509-mbx.china.huawei.com> In-Reply-To: <06CF729DA0D6854E8C1E5121AC3330DFAF749133@dggemm509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-17T10:45:22Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=525674bf-9e5b-4c05-ac33-a217cc3bfe24; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [122.167.129.47] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c9cb32eb-240d-4204-901b-08d8429aa5cc x-ms-traffictypediagnostic: CY4PR05MB3430: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +RyVWylqKLCWdlu25GWbaSmNdf5yDNUzNUVNxgnv+lv6UH4xeNhuPtFA6EWEE+cOzz0h+yh3S1qB9CAL5ugWFPjVaX8U36KxH+xEQ1FQIshpKD4fGwl70ehDgS1h4I9V432r9LJzsTw00FUMUmRbiDknwCZLAF5C7myk8vG09didGDDMu+qMtQdPNMVoWiV0Vzw6JKO4iGgtc3wLDKgY9xJZQXwiWu7rLA1X+05xI8lYOqlVrG5/lp0R7lJJBR4XSYQoFnDVHlnkj9LeaoBplxNwyiWR3ipGkTFLyNGzgT4Of1qY1JMvD1Bud8Cr8PwzSMrjtpaXa1LKNccV9k5raz8LPBcUExRs6mmP5sUeNDCEf576QFa6Q6ZJyvWm/aXXrGdcy/4cEQm+MSc7Ac0gjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(76116006)(66946007)(71200400001)(66476007)(186003)(64756008)(66446008)(2906002)(66556008)(83380400001)(26005)(52536014)(7696005)(33656002)(8936002)(6506007)(966005)(478600001)(55016002)(86362001)(9686003)(316002)(53546011)(110136005)(5660300002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: GXnhC7BK8HVXmVua0lHISO+aJjZR4C6Ua7l9UnyT9fm9lzTQKb86jboZ1ZyGJhcWsa71Y6piWyKyoGt7kCp+3HkP40YMWz3Bg8vgyKAyg0NwbiSq3/okWm6brNBotxP52i+Emw7m7tP101kOm2bSe9DTgPpCklIpY09z1U/GpiordogE50Mlp71tA/zZoFJSLnfp9ilrCOKL3hNJ5CA4ghEgU8dPNEP8LAN6WNNJVPL7GqIEQeU0hvsRacns00Gqgn5zsj8PyK+RJ0qcSa3M5I9YHb7lINYDXGgJH3kjVxFRPSawo2jVSlFuYDwWWSjRPBZNJAKtmmdOVCi5oTk//SpbjXTejLdrDWGBPMQUd2vDQrU+I9Y//TA6y3AGliec+U12P/AE7xM2a8ruAK6RbOFFTK5CPrxrgSzWUJUKRCLVBUb76L/Z+ywZDqw0B1Isz+skSXGDdvzNLkHtbMBHMOYn/Mq3fr9zN8M855/o0+5ebuxTenr+EW0N27lkwuC/kzTg7tWf1eQ/ooKq0xvtDBArE1P+0cD7pdUqaUZrxWdMXqfF+yFexrzgi9Fi6vd7RSpw9UOoYj1qcL7Wo2ta0x66EIltdsO3G6xSLcE1osxd0cmCdlQJU1TNyS1TskWghs0YmbR3kEXQP9x5R6jL4A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9cb32eb-240d-4204-901b-08d8429aa5cc X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 10:45:24.5349 (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-CrossTenant-userprincipalname: YXPHFDLFDF4w4Gnbu4tGY/InWMx5Xx5Cjhukv1mDSwOdqUDjpnBMr/Vf8AbnvwPIrvXGSQJHPVevFE6QVmfedQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3430 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-17_06:2020-08-17, 2020-08-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 clxscore=1011 bulkscore=0 phishscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 impostorscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008170080 Archived-At: Subject: Re: [spring] The SPRING WG has placed draft-hegde-spring-node-protection-for-sr-te-paths in state "Call For Adoption By WG Issued" X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 10:45:39 -0000 SGkgSHV6aGlibywNCg0KVGhhbmtzIGZvciByZXZpZXcgYW5kIGNvbW1lbnRzLiANCg0KVGhlIHNp emUgb2YgdGhlIGNvbnRleHQgdGFibGUgYW5kIHJlc3VsdGluZyBmb3J3YXJkaW5nIHN0YXRlIGlz IHZlcnkgbXVjaCBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQuDQpUaGVyZSBjb3VsZCBiZSB3YXlz IHRvIG9wdGltaXplIHRoYXQuIFRoaXMgZHJhZnQgaXMgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCBh bmQgdGhlIGdvYWwgaXMgdG8gZGVzY3JpYmUgbWVjaG5pc21zIHRoYXQgdXNlIGNvbnRleHQgdGFi bGVzDQpPciBhbiBvcHRpbWl6ZWQgbWVjaGFuaXNtIHRoYXQgdXNlcyBnbG9iYWwgU1JHQi4gVGhl cmUgY2FuIGJlIG90aGVyIHdheXMgb2YgYWNoaWV2aW5nIHRoZSBzYW1lIGVuZCByZXN1bHQgYW5k IHRoZSBkcmFmdCBkb2VzIG5vdA0KRXhjbHVkZSB0aGVtLiBQbHMgcmVmZXIgdGV4dCBpbiBzZWN0 aW9uIDMgcmVnYXJkaW5nIHRoaXMuDQpIb3BlIHRoYXQgY2xhcmlmaWVzDQoNClJnZHMNClNocmFk ZGhhDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEh1emhpYm8gPGh1emhpYm9AaHVhd2VpLmNvbT4gDQpTZW50OiBGcmlkYXks IEF1Z3VzdCAxNCwgMjAyMCA3OjE1IFBNDQpUbzogSUVURiBTZWNyZXRhcmlhdCA8aWV0Zi1zZWNy ZXRhcmlhdC1yZXBseUBpZXRmLm9yZz47IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7IHNwcmluZ0Bp ZXRmLm9yZzsgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0 aHNAaWV0Zi5vcmcNClN1YmplY3Q6IOetlOWkjTogW3NwcmluZ10gVGhlIFNQUklORyBXRyBoYXMg cGxhY2VkIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhz IGluIHN0YXRlICJDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQiDQoNCltFeHRlcm5hbCBF bWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KDQpIaSAgYWxs77yaDQogICAgSSB0aGlu ayB0aGlzIGRyYWZ0IGlzIGEgdXNlZnVsIHRvcGlj77yMSG93ZXZlciwgSSB0aGluayB0aGVyZSBp cyBzdGlsbCBzcGFjZSBmb3IgaW1wcm92ZW1lbnQgaW4gdGhpcyBzb2x1dGlvbi4gQWNjb3JkaW5n IHRvIHRoZSBzb2x1dGlvbiBpbiB0aGUgZHJhZnQsIHRoZSBzaXplIG9mIHRoZSBjb250ZXh0IHRh YmxlIG9mIGVhY2ggbm9kZSBpcyB0aGUgbnVtYmVyIG9mIG5laWdoYm9ycyAqICh0aGUgbnVtYmVy IG9mIG5ldHdvcmsgbm9kZXMgKyB0aGUgbnVtYmVyIG9mIG5laWdoYm9ycyBvZiBuZWlnaGJvcnMp LiBUaGlzIHdpbGwgY2F1c2Ugc2NhbGFiaWxpdHkgcHJvYmxlbXMuIElmIHRoZSBTUkdCIGRpZmZl cmVuY2UgdmFsdWUgaXMgdXNlZCB0byBjYWxjdWxhdGUgdGhlIG1hcHBpbmcgdmFsdWUgZnJvbSB0 aGUgcmVtb3RlIGxhYmVsIHRvIHRoZSBsb2NhbCBsYWJlbCBkaXJlY3RseSB3aGVuIGZvcndhcmRp bmcsIGl0IGlzIGEgcmVjb21tZW5kZWQgbWV0aG9kLg0KDQpUaGFua3MNCg0KWmhpYm8NCg0KDQot LS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnXSDku6PooaggSUVURiBTZWNyZXRhcmlhdA0K5Y+R6YCB5pe26Ze0OiAy MDIw5bm0N+aciDMw5pelIDIwOjI3DQrmlLbku7bkuro6IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7 IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3It c3ItdGUtcGF0aHNAaWV0Zi5vcmcNCuS4u+mimDogW3NwcmluZ10gVGhlIFNQUklORyBXRyBoYXMg cGxhY2VkIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhz IGluIHN0YXRlICJDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQiDQoNCg0KVGhlIFNQUklO RyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNy LXRlLXBhdGhzDQppbiBzdGF0ZSBDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQgKGVudGVy ZWQgYnkgQnJ1bm8gRGVjcmFlbmUpDQoNClRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQNCmh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy9fXzsh IU5FdDZ5TWFPLWdrIVJ1ZGRCRkFNMDFuMnJhdkExV25sZDhjZzRJZWNXbWF0TTF5Q3k0LUoxVU1B SFRTRWRjWW8tVXhrU1M1WEZmOVckDQoNCkNvbW1lbnQ6DQpDYWxsIGZvciBhZG9wdGlvbjoNCmh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3NwcmluZy9CNmN4NzJLQWVYMWdxRGhWMFNvY1Q1UWxobXcvX187ISFORXQ2eU1hTy1n ayFSdWRkQkZBTTAxbjJyYXZBMVdubGQ4Y2c0SWVjV21hdE0xeUN5NC1KMVVNQUhUU0VkY1lvLVV4 a1NhdVl2RHlGJA0KDQpJUFIgcG9sbDoNCmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9uT1BXaFQtNUlhS1ZhclRH cklHdFJDcjh6YVEvX187ISFORXQ2eU1hTy1nayFSdWRkQkZBTTAxbjJyYXZBMVdubGQ4Y2c0SWVj V21hdE0xeUN5NC1KMVVNQUhUU0VkY1lvLVV4a1NjNUJUNy15JA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3By aW5nQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzshIU5FdDZ5TWFPLWdrIVJ1ZGRCRkFNMDFu MnJhdkExV25sZDhjZzRJZWNXbWF0TTF5Q3k0LUoxVU1BSFRTRWRjWW8tVXhrU1ZtckRVMm0kDQo= From nobody Mon Aug 17 14:03:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ED83A11B6 for ; Mon, 17 Aug 2020 14:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, PDS_BTC_MSGID=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 F00zCo-WsT_u for ; Mon, 17 Aug 2020 14:03:46 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 8A6993A11A9 for ; Mon, 17 Aug 2020 14:03:46 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id m71so8853453pfd.1 for ; Mon, 17 Aug 2020 14:03:46 -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=+8NDZhR8jiw6dAMLWNNqizy0Jj98vCQh7xjWmPy7l48=; b=pqJA7WX8SteIJkKxXhux6JCfd/lUzpzjH7c4r6YKx1qCTxLdaAj5qyXW5f1jL+1F76 iiU8VEYYlhja6HHeeYeb5vRoe4EmcncgkFN0IIZ+/PbpVQ6Cjtlc5GsLQsVgjEdj5ogW z0MGojOls4upBC1UgctPVPZ9jXO++xN9+8aHsvB+7v4rW1gkkSxuomcUXRg9R/7gX0Tw SHQMjIfrZy5o5oGALF6D+JQYGP2lH54pkBGCVY9qMrbaPdEy02nGQznraijrC0WsOVjB GA91ahQ4x7SNFOMypZiNCzfgZZVS6nNGzWHrQeS2xcrUm+OQFJr8YR4UDEdWUF62CNfx 6Nlw== 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=+8NDZhR8jiw6dAMLWNNqizy0Jj98vCQh7xjWmPy7l48=; b=JJKkBGW3ahwpW8p+ydlLZtjm4g4bUlWxVyBQh+GL0LWj77dO+feF7SRmsA/OSL8dZT +RJDa/zXqG/wNS8eVFnFkIThbFu/YJw3Ey+R5JEtMKI0h+4W6rS94WTeZ98RacAxZn35 IqjVXnFxn2loTrNm5H/y/1QWGuOJNaz7DWtS8t5XTi8+YbrkpykLqF2VGG/RtyGWDd7X ePZPLl2LahHYmOCm/7XVRQwFandtxt+/v4zoVbDFD+CGUQmz7lLv6Wo/BxbBR36td6r9 Rc8bSsMnT8pB4zpI5Hbd/jbL4woodV+uEpeZke0nfSWt0vlgKQxq8F+uSqvchOJnX20Z /hCw== X-Gm-Message-State: AOAM531jXkNrigdMCGCAf46TGhn0XnG7mDPkKoSRDPTKodbxYx4OFUB5 lMs9oDt8zsI8o+48HW75bwo= X-Google-Smtp-Source: ABdhPJxKhUob3l8A/+rQQdZY8rh//p53QRufCVZzkUA+G41LMFPCYMaKrbyfKMVY1kVlq0qucA7nxQ== X-Received: by 2002:a63:a53:: with SMTP id z19mr10842143pgk.67.1597698225637; Mon, 17 Aug 2020 14:03:45 -0700 (PDT) Received: from [192.168.1.3] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id n12sm20915660pfo.119.2020.08.17.14.03.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 14:03:44 -0700 (PDT) Date: Mon, 17 Aug 2020 14:03:32 -0700 From: Jeff Tantsura To: Gyan Mishra Cc: Alexander Vainshtein , "=?utf-8?Q?EXT-Andrew.Alston=40liquidtelecom.com?=" , "Joel M. Halpern" , "Ketan Talaulikar (ketant)" , Robert Raszuk , Shraddha Hegde , "=?utf-8?Q?spring=40ietf.org?=" Message-ID: <7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark> In-Reply-To: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> X-Readdle-Message-ID: 7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f3af0ad_1f16e9e8_65d7" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 21:03:55 -0000 --5f3af0ad_1f16e9e8_65d7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Gyan, TI-L=46A computation is local to the PLR and is topology dependent, e.g c= hange in downstream topology could/would influence the choice of MP (PQ) = node. While an implementation could take into consideration some additional met= a-data (e.g. locally provisioned SRLG, usually used to avoid protected an= d protecting ports on the same line card), this is not a standardized met= hod. If a service node must be included in a backup path, there=E2=80=99s a st= ate associated with it as well as distribution of the state involved. Back to my point, removing state and introducing services in the network = (at the very least at the computational logic and head-end level) are mut= ually exclusive, trade-offs are inevitable (You can't eat your cake and h= ave it). Keeping the state limited to: - a logically centralized computational logic (aka PCE) - off path, scale= s horizontally, could use additional business logic for the path computat= ion, example - CPU/memory consumption on a service node - head-end - anchor to primary/backup paths seems like a reasonable set of trade-offs. Cheers, Jeff On Aug 14, 2020, 7:44 PM -0700, Gyan Mishra , wr= ote: > > Catching up on this thread as it is a interesting topic as =46RR 1:N li= nk protection, node protection and path protection is critical to operato= rs. > > There are multiple somewhat orthogonal topics brought up in the discuss= ion. > > Excluding SR S=46C from =E2=80=9Cbypass=E2=80=9D capable node such for = appliances such as firewalls and load balancer.=C2=A0 Makes sense.=C2=A0 = I would not think S=46C would be in a PLR path to merger point but I coul= d be mistaken. > > The goal of SR is eliminating state and so having TE like state is unde= sirable. > > Intent based instantiation of bypass via SR-TE from network feedback at= PLR detection node of a failure and make before break pre computed backu= p paths that can. > > It would make sense that SR-TE binding SID policy would be appropriate = for RSVP like =46RR link node or path protection. > > My thoughts on this topic of SR protection is that don=E2=80=99t we alr= eady have =46RR protection natively without requiring SR-TE BSID or any a= dditional undesirable state maintenance with TI-L=46A. > > Thanks > > Gyan > > > On =46ri, Aug 14, 2020 at 5:47 PM Jeff Tantsura wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PCE computation in this case is trivial too(must traverse node B or= node X) else =46AIL. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Robert, > > > > > > > > > > > > > > > > > > > > > > > > Agreed and apologies, hit send before finishing the email (it is = =46riday) ;-) > > > > > > > > > > > > > > > > > > > > > > > > Path protection in this case make more sense and is much less com= plex, > > > > > > > > > > > > if in the pathA (A->B->C) node B is a service node, it can=E2=80=99= t be bypassed (node protected) if the link between A and B breaks > > > > > > > > > > > > however it could have a backup pathB (A->X->C) where X is the ser= vice node, potentially synchronizing its state with the node B. > > > > > > > > > > > > > > > > > > > > > > > > To my previous email - at expense of more state, we provide path = and service protection, hence the similarity with RSVP-TE trade-offs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , wrote: > > > > > > > > > > > > > > > > > > > > > > > Jeff, > > > > > > > > > > > > > > > > > > > > > > > > > > This is very similar to RSVP-TE > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would rather differ on that statement. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See if you are using SR just for TE you are 100% right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if your SIDs embed additional local SR node processing func= tions this suddenly=C2=A0becomes a completely different game. Let's keep = this in mind in this thread/topic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 11:15 PM Jeff Tantsura wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very similar to RSVP-TE, path vs link/node protecti= on and usually dictated by the business logic, the triggers are obviously= very different, head-end being notified of the failure on a path and swi= tching to the backup path vs reaction to a local failure, so same conside= rations apply: > > > > > > > > > > > > > > > > > > > > > -more state > > > > > > > > > > > > > > > > > > > > > -pre-reserved resources > > > > > > > > > > > > > > > > > > > > > while > > > > > > > > > > > > > > > > > > > > > -predictable > > > > > > > > > > > > > > > > > > > > > -meets SLA (as good as primary) > > > > > > > > > > > > > > > > > > > > > vs > > > > > > > > > > > > > > > > > > > > > -less state > > > > > > > > > > > > > > > > > > > > > -local > > > > > > > > > > > > > > > > > > > > > -best effort / can cause congestions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) = , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We do not have a signalling mechanism in IGPs today to in= dicate a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If the= re was a desire for it, an IGP extension would be required (there is none= in progress A=46AIK). Note that this results in doubling the prefix SID = scale (global labels) in the network. So I would not go about this trivia= lly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it helps to get more inputs and perspectives from= operators on their views for doing a bypass via local protection for seg= ments in an SR Policy. There may be those that prefer end-to-end path pro= tection using a fallback path that is say disjoint with the primary but p= rovides an appropriate SLA/intent=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 23:04 > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determining= applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Looks like we are pretty much in sync here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But let me just observe that I purposely=C2=A0did not men= tion about SR policies as we are not able to signal the intent with the p= ackets itself. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So all we have there is SIDs. BSIDs or prefix SIDs need t= o be flooded with information if policies build with using them are bypas= s eligible or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was actually under the impression that this is already = there and I am just not aware, but looking deeper indeed I do not see thi= s marking neither in ISIS nor OSP=46 for prefix SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there some work in progress to add it to those protoco= ls or have we just documented need=C2=A0for a short LSR draft=C2=A0 =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thx, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketan= t) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check inline below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 21:13 > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determini= ng applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ketan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I completely agree with your note the consequence= s of it are pretty sevre. > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D I understand. We need to be mindful of implica= tions of protection schemes for the SLAs/intent of SR Policies. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Unless we signal which prefix SID is protection eligibl= e and which is not how would other nodes know if they can protect it or n= ot =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D Correct. To be more accurate, we need to consi= der this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR Pol= icies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for local p= rotection for some of those SR Policies. We also have path-protection mec= hanisms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems that today's safe thing is not to apply any no= de protection on SR flows at the PLRs then. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And link protection MUST assure that packets will arriv= e at the neighbor node via some other link regardless of further path tow= ards destination. > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D Yes. We have a mechanism to indicate which adj= -SIDs have protection (that mechanism only provides link protection to ge= t to the neighbor node) so the SR Policy computation is able to indicate = whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its= choice of protected or unprotected adj-SIDs respectively. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is it correct =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thx > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ket= ant) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The service node advertises its own Prefix SID.. The = service function that this service node implements does not require any c= ontext (i.e. all packets arriving at the node are subjected to that servi= ce). Therefore the service node does not need to receive a packet with it= =E2=80=99s own Prefix SID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thus, we cannot assume that when PHP is used, then th= e SID is only associated with a topological instruction. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope that clarifies=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 20:24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) ; J= oel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determi= ning applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan, and all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have stated that, IMHO and =46WIW, both Adj-SIDs an= d Prefix SIDs that are advertised with PHP can=C2=A0 ONLY represent topol= ogical instructions in SR-MPLS - because the advertising node will not re= ceive them and therefore can hardly be expected to associate any service = function with them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is complementary to what you have said. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope this clarifies my position. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What, if anything, did I miss=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: =46riday, August 14, 2020, 16:23 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Alexander Vainshtein; Joel M. Halpern; Shraddha H= egde; EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: RE: =5Bspring=5D Spring protection - determi= ning applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NOTICE: This email was received from an EXTERNAL send= er > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the service does not need any additional context (= e.g. a firewall that just applies locally configured default rules on it)= , then I don=E2=80=99t see why PHP could not be done for a Prefix SID ass= ociated with a service node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, I didn=E2=80=99t follow the point that you were= trying to make about Adj-SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 18:24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) ; J= oel M. Halpern ; Alexander Vainshtein ; Shraddha Hegde ; EXT-Andre= w.Alston=40liquidtelecom.com ; Robert = Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determi= ning applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding the statement =22Prefix SID could be just a= topological instruction or may also be used to steer the flow to a node = which is applying a service function to it=22: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think that in SR-MPLS a Node SID that is advertised= with PHP aciton can be safely considered as =22just a topological instru= ction=22 by the PLR because the originating node will not receive it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The same applies to Adj-SDIs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My 2c. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: spring on behalf = of Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: =46riday, August 14, 2020, 15:00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Joel M. Halpern; Alexander Vainshtein; Shraddha H= egde; EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determi= ning applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to share a different perspective on this= . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46irst, thanks to Joel for bringing up the discussio= n. Clearly we need a well-defined applicability statement for determining= applicability of protection for segment used in an SR Policy. Some of th= is is captured in =5B1=5D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is about local repair at a PLR. By it's very nat= ure, the PLR does not have a notion of how =22strict or not=22 is the SLA= that is being provided by the SR Policy. Awareness of that notion exists= at the SR Policy headend and/or computation-node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have protected and un-protected variants of adjace= ncy SIDs to enable the computation to pick or the other based on the =22s= trictness=22 of the SLA requirement for picking that link. We do not have= such a notion for Prefix SIDs. One can say that we could introduce signa= lling (e.g. a B flag) to indicate whether a Prefix SID can be bypassed or= not. This provides the opportunity for the computation to use one or the= other flavor depending on the nature of the SLA for the SR Policy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a problem and a concern in the assumption that= PLRs can assume that the currently defined variant of Prefix SIDs in R=46= C8402 (and IGP specs) are =22bypass-able=22. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As Joel and others have brought out, the Prefix SID c= ould be just a topological instruction or may also be used to steer the f= low to a node which is applying a service function to it. In order to sup= port a mix of SR Policies of different SLAs (strict and not-strict), we n= eed to enable the choice of SIDs that indicates to the PLR whether they a= re =22bypass-able=22 or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46or the cases, where the SR Policy has a specific S= LA, it is required for nodes to drop the packets meant for the =22active = segment=22 than to bypass it. When this mechanism is used along side SRTE= path monitoring mechanisms, it enables the headend to detect the failure= and fallback to an alternate path using the path protection approach. Th= is is something that is described and in use in deployments today =5B1=5D= .. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5B1=5D https://clicktime.symantec.com/3Y3fWuN=46YCjM= JUiiAiWwUms6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-= ietf-spring-segment-routing-policy-08%23section-9 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5B2=5D https://clicktime.symantec.com/36fCMrgmEewC4a= 4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46draft-ie= tf-spring-segment-routing-policy-08%23section-9.3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: spring On Behalf = Of Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 04 August 2020 20:25 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Alexander Vainshtein ; Shraddha Hegde ; EXT-An= drew.Alston=40liquidtelecom.com ; Robe= rt Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org; Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - determi= ning applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are, as far as I can tell, a number of ways to = address this family of related questions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What struck me, and prompted the starting question, w= as that none of them were spelled out.=C2=A0 I see lots of interesting id= eas / proposals. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some of them are compatible with others.=C2=A0=C2=A0 = Some are not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It would be good if we could reach agreement on how w= e thought it should be handled. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am still not sure that the problem of bypass goin= g thru undesirable > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > links/nodes exists in the case of topological SIDs.= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46= C 4090 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ) has = been successfully deployed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > for many years before SR-MPLS has been introduced. = What=E2=80=99s more, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > signaling of bypass tunnels he PLR usually did not = include any of the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > constraints used for computing of any specific LSP = that the bypass LSP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > would protect =E2=80=93 because in the =46acility P= rotection mode the same > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > bypass LSP would be used to protect multiple LSPs p= assing thru the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > failed link/node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =46rom my POV the only difference between thi= s behavior and that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > introduced by the =E2=80=9Cbypassing=E2=80=9D draft= s in SR is that, in the case of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RSVP-TE, the operator would explicitly indicate, as= part of LSP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > signaling, whether it would or would not use =46RR;= LSPs that would not > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > use =46RR would then drop traffic rather than deliv= ering it the wrong way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Such an option indeed does not exist in SR-TE today= , but would be easy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to provide if so desired IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Did I miss something substantial=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, and lots of thanks in advance, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Office: +972-39266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Email:=C2=A0=C2=A0 Alexander.Vainshtein=40ecitele.c= om > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* spring *On Be= half Of *Shraddha Hegde > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* EXT-Andrew.Alston=40liquidtelecom.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ; Robert Raszuk = > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* spring=40ietf.org; Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - det= ermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a very interesting discussion and thanks to= Joel for starting > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > this discussion. IMO, when there are strict require= ments of avoiding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > certain nodes/links it can be realized=C2=A0 either= by defining a flex-algo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > avoiding those > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nodes and links or by using a stack of unprotected = adj-sids that avoid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > restricted nodes and links. When a stack of adj-sid= s is used to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > realize the path, the head-end based (sB=46D) prote= ction mechanisms can be applied. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If Node-sids/prefix-sid/anycast-sids are used to bu= ild the stack, the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > failure events may cause traffic to go through rest= ricted nodes and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > links. This would happen regardless of whether any = kind of protection > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is in use or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rgds > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shraddha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* spring > > > > > > > > > > > *On Behalf Of *= Andrew Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* spring=40ietf.org ;= Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - det= ermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=5BExternal Email. Be cautious of content=5D* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robert this is actually far more difficult when =E2= =80=93 it can be an entire > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (long) series of nodes that need to be avoided. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It could potentially be made to work but I=E2=80=99= d worry that to do this =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93= 30 negative labels =E2=80=93 and that wouldn=E2=80=99t > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > be viable. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It=E2=80=99s easier to use algorithms and adjacency= sids and other such things > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to calculate paths =E2=80=93 the biggest trick is a= bout the stack depth.=C2=A0 When > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you have this need for node avoidance =E2=80=93 the= need for 10+ label depth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is critical =E2=80=93 unless you wanna be applying = one hell of a lot of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > binding labels along the way which is a nightmare. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But to answer your question, is this a common use c= ase =E2=80=93 it=E2=80=99s a use > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > case that most of the people I discuss this with ce= rtain have =E2=80=93 I cant > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > comment on a global scale, or for anyone else, but = every indication I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > have is that yes =E2=80=93 its something people nee= d, and want > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, 4 August 2020 01:27 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* Andrew Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* Joel M. Halpern > > > > > > > > > > >; spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection - det= ermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is this a common use case ie.=C2=A0 =22but rather =E2= =80=93 which nodes / network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > segments it can never touch or flow through.=22 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If so perhaps its time to define notion of *negativ= e-SID* ie. list in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the packet resources which given=C2=A0packet MUST n= ot ever traverse. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Put in the packet set of nodes or links which the p= acket should never > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > traverse. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That goes in line of recent wave of negative routin= g implementations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (RI=46T) or discussions (LSR) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fa= ct, some very major use cases in any > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us re= volve around the following > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of= certain nodes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of= certain sections of the network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result = in that explicit avoidance being violated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, sha= ll we say significant problems. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not= a case of which nodes the packets flow > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rathe= r =E2=80=93 which nodes / network segments it can never > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0= Effectively, to be used as a technology to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for sp= ecific reasons. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the rea= sons for needing such deep label stacks =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path = programming tends to deepen the stack > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have = to be pretty explicit. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical t= o us that this functionality is there =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situa= tions which could cause traffic to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things expli= citly avoided. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more spec= ific than this, but it is what it is. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *=46rom:* spring > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > *On Behalf Of *Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 20= 20 21:36 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring=40ietf..org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: =5Bspring=5D= Spring protection - determining > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotte= n long enough, reiterating that this is as a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair= .) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP netw= orks. And yes, I have seen IP networks that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. =46= or all sorts of reasons. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely ot= her reasons why one may not want a random > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen T= E path. I think it is important we be clear > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may = be / are violated when we tell people they > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective = rerouting) that is intended to preserve QoS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not ar= guing that this is not a good idea. It is a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am= trying to figure otu what combination of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and c= lear descriptions will lead to everyone > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they e= xpect (which may not be the behavior they > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is th= e best we can do.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert= Raszuk wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talkin= g about IP networks=C2=A0here =3F Or perhaps some hard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real r= esource reservations or detnets =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we = are talking=C2=A0about IP networking I have two > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 observations: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to t= raverse via a specific node (ie. firewall) you > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 better > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulat= ion to that node.. I don't think IP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today s= uch that destination address of the packet is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 ignored. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen an= y IP network where upon topology change (link > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 or node > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you sudden= ly=C2=A0start dropping=C2=A0flows in spite of SPT offering > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms long= er path with 10 ms more jitter =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR mark= eting slides promise to turn IP networks in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new = =3F Worse ... do they mention path quality guarantees, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservatio= ns=C2=A0=3F I hope not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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=A0=C2=A0 > On Mon, Aug 3, 2020= at 8:10 PM Joel M. Halpern > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious f= or TE SIDs, I am not sure the problem is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 restricted > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SID= s. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PC= E has specified the path to meet some complex te > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 Th= e bypass node has no way of knowing what those > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for= some kinds of traffic, it is better to drop the packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it = outside the envelop.=C2=A0 I suspect that the right > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is =22too b= ad=22..=C2=A0 If so, as with the distinction regarding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 service > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should sa= y so, shouldn't we=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM= , Alexander Vainshtein wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and al= l, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in m= ost cases: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear = differentiation between =22topological=22 and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =22service=22 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in S= ID advertisements. E.g.: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node = SIDs IGP Adj-SIDs (identified as such in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP= advertisements) represent topological > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 instructions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for= SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisi= ngly represent =E2=80=9Cservice=E2=80=9D instructions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that r= epresent topological instructions can be bypassed, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments th= at represent service instructions require > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechan= isms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems t= o be aligned with R=46C 8402 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 that says in Section 1: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= In the context of an IGP-based distributed control plane, two > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segme= nts are defined: the IGP-Adjacency segment and the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= IGP-Prefix segment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= In the context of a BGP-based distributed control plane, two > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segme= nts are defined: the BGP peering segment and the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= BGP-Prefix segment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR= -MPLS this differentiation is assumed in Section > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protecti= on for SR-TE Path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft that says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= The node protection mechanism described in the previous > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 sections > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= depends on the assumption that the label immediately below > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the labe= l stack is understood in the IGP domain.=C2=A0 When the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= provider edge routers exchange service labels via BGP or some > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= non-IGP mechanism the bottom label is not understood in the IGP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= domain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= The egress node protection mechanisms described in the draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= =5BR=46C8679 > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 >=5D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to thi= s use case and no additional changes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= will be required for SR based networks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in = which =C2=A0differentiation between =E2=80=9Ctopological=E2=80=9D and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2= =80=9D instructions is broken are indeed problematic. E.g., > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in w= hich a Node SID in the ERO of a SR-TE path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as= a firewall for all packets it receives, i.e., > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall serv= ice without any dedicated service SID > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say tha= t the Node SID of such a node would combine > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instr= uctions thus breaking the differentiation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if = usage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged= . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing= an ability to identify such SIDs in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would = be useful IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-3926= 6302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +972-549266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.= Vainshtein=40ecitele.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > > -----Original Mes= sage----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =46rom: spring > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > On Behalf Of Mach Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, Aug= ust 3, 2020 6:30 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpe= rn > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > >; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: =5Bs= pring=5D Spring protection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a= good point that may not be discussed in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't thin= k there is a =22can be bypassed=22 indication in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertise= ment for now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the informa= tion advertised by routing is neutral, such > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be= bypassed) is more path specific, thus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 normally the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should= be responsible for deciding whether/which SID > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Orig= inal Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46rom: s= pring =5Bmailto:spring-bounces=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =5D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Mon= day, August 3, 2020 7:51 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: sprin= g=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > Subject: = =5Bspring=5D Spring protection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > (WG Chair= hat Off, this is merely a note from a slightly > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participa= nt.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > I have be= en reading the various repair drafts, and the various > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks = programming and service programming draft, and I am > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure ou= t one aspect of the combination. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > How does = a node that is doing some form of bypass (suppose, for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicit= y, it is Node N2 deciding to bypass the next SID for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) = know that it is safe to do so=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > If the pa= th was just for TE, then it is =22safe=22 if the new path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE cr= iteria.=C2=A0 or maybe it is safe if it is even close, as > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not= used for too long. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > But what = if the node were a =46irewall, included to meet legal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was so= me other necessary programmatic transform (wince we are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberat= ely vague about what nodes can do when asked suitably.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > Is there = some =22can be bypassed=22 indication in the routing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertise= ments that I missed=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > Thank you= , > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring ma= iling list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring=40= ietf..org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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 https://clicktime.symantec.= com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46%2=46w= ww.ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 >%2=46= mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing li= st > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0 https://clicktime.symantec.= com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46m= ailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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 > > Notice: This e-ma= il together with any attachments may contain > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ri= bbon Communications Inc. that is confidential > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for t= he sole use of the intended recipient. Any review, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, relia= nce or distribution by others or forwarding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 without > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permissio= n is strictly prohibited. If you are not the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please= notify the sender immediately and then delete all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including= any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing li= st > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ietf.org= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime= .symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf= .org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring mailing list= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring=40ietf.org <= mailto:spring=40ietf.org> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.s= ymantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.o= rg%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.= com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46m= ailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2= =46www.ietf.org%2=46mailman%2=46listi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46= YNE8E=5FR1oiQAtQxgm0x0wxqgu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------= ------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any attachments m= ay contain > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > information of Ribbon Communications Inc. that is c= onfidential and/or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > proprietary for the sole use of the intended recipi= ent. Any review, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > disclosure, reliance or distribution by others or f= orwarding without > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > express permission is strictly prohibited. If you a= re not the intended > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > recipient, please notify the sender immediately and= then delete all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > copies, including any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------= ------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqL= q6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46sp= ring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqL= q6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46sp= ring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any attachments may= contain information of Ribbon Communications Inc. that is confidential a= nd/or proprietary for the sole use of the intended recipient. Any review,= disclosure, reliance or distribution by others or forwarding without exp= ress permission is strictly prohibited. If you are not the intended recip= ient, please notify the sender immediately and then delete all copies, in= cluding any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > spring mailing list > > > > > > spring=40ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > Gyan Mishra > Network Solutions Architect > M 301 502-1347 > 13101 Columbia Pike > Silver Spring, MD > --5f3af0ad_1f16e9e8_65d7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    Gyan,

    TI-L=46A computation is local to the PLR and is topology dependent, e.g c= hange in downstream topology could/would influence the choice of MP (PQ) = node.
    While an implementation could take into consideration some additional met= a-data (e.g. locally provisioned SRLG, usually used to avoid protected an= d protecting ports on the same line card), this is not a standardized met= hod.&=23160;&=23160;
    If a service node must be included in a backup path, there=E2=80=99s a st= ate associated with it as well as distribution of the state involved.&=23= 160;

    Back to my point, removing state and introducing services in the network = (at the very least at the computational logic and head-end level) are mut= ually exclusive, trade-offs are inevitable (You can't eat your cake and h= ave it).
    Keeping the state limited to:
    - a logically centralized computational logic (aka PCE) - off path, scale= s horizontally, could use additional business logic for the path computat= ion, example - CPU/memory consumption on a service node
    - head-end - anchor to primary/backup paths
    seems like a reasonable set of trade-offs.

    Cheers,
    Jeff
    On Aug 14, 2020, 7:44 PM -0700, Gya= n Mishra <hayabusagsm=40gmail.com>, wrote:

    Catching up on this thread as it is a interesting t= opic as =46RR 1:N link protection, node protection and path protection is= critical to operators.

    There are multiple somewhat orthogonal topics broug= ht up in the discussion.

    Excluding SR S=46C from =E2=80=9Cbypass=E2=80=9D ca= pable node such for appliances such as firewalls and load balancer.&=2316= 0; Makes sense.&=23160; I would not think S=46C would be in a PLR path to= merger point but I could be mistaken.

    The goal of SR is eliminating state and so having T= E like state is undesirable.&=23160;

    Intent based instantiation of bypass via SR-TE from= network feedback at PLR detection node of a failure and make before brea= k pre computed backup paths that can. &=23160;&=23160;

    It would make sense that SR-TE binding SID policy w= ould be appropriate for RSVP like =46RR link node or path protection.

    My thoughts on this topic of SR protection is that = don=E2=80=99t we already have =46RR protection natively without requiring= SR-TE BSID or any additional undesirable state maintenance with TI-L=46A= .

    Thanks&=23160;

    Gyan

    On =46ri, Aug 14, 2020 at= 5:47 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:












    PCE computation in this case is trivial too(must tr= averse node B or node X) else =46AIL.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:44 PM -0700, Jef= f Tantsura <jefftant.ietf=40gmail.com>, wrote:






    Robert,





    Agreed and apologies, hit send before finishing the email (it is =46riday= ) ;-)





    Path protection in this case make more sense and is much less complex,&=23= 160;


    if in the pathA (A->B->C) node B is a service node, it can=E2=80=99= t be bypassed (node protected) if the link between A and B breaks&=23160;=


    however it could have a backup pathB (A->X->C) where X is the servi= ce node, potentially synchronizing its state with the node B.





    To my previous email - at expense of more state, we provide path and serv= ice protection, hence the similarity with RSVP-TE trade-offs.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:30 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:




    Jeff,




    > This is very similar to RSVP-TE&=23160;&=23160;





    I would rather differ on that statement.&=23160;





    See if you are using SR just for TE you are 100% right.&=23160;




    But if your SIDs embed additional local SR node processing functions= this suddenly&=23160;becomes a completely different game. Let's keep thi= s in mind in this thread/topic.&=23160;





    Kind regards,


    R.












    On =46ri, Aug 14, 2020 at= 11:15 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:








    This is very similar to RSVP-TE, path vs link/node = protection and usually dictated by the business logic, the triggers are o= bviously very different, head-end being notified of the failure on a path= and switching to the backup path vs reaction to a local failure, so same= considerations apply:&=23160;


    -more state


    -pre-reserved resources


    while&=23160;


    -predictable


    -meets SLA (as good as primary)


    vs


    -less state


    -local


    -best effort / can cause congestions&=23160;







    Cheers,

    Jeff






    On Aug 14, 2020, 10:46 AM -0700, Ke= tan Talaulikar (ketant) <ketant=3D40cisco.com=40dmarc.ietf.org&= gt;, wrote:






    Hi Robert,



    &=23160;



    We do not have a signalling mechanism in= IGPs today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Pr= efix SIDs. If there was a desire for it, an IGP extension would be requir= ed (there is none in progress A=46AIK). Note that this results in doublin= g the prefix SID scale (global labels) in the network. So I would not go = about this trivially.



    &=23160;



    I think it helps to get more inputs and = perspectives from operators on their views for doing a bypass via local p= rotection for segments in an SR Policy. There may be those that prefer en= d-to-end path protection using a fallback path that is say disjoint with = the primary but provides an appropriate SLA/intent=3F



    &=23160;



    Thanks,



    Ketan



    &=23160;





    =46rom: R= obert Raszuk <robert=40raszuk.net>


    Sent: 14 August 2020 23:04


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility





    &=23160;





    Ketan,





    &=23160;







    Looks like we are pretty much in sync here.&=23= 160;







    &=23160;







    But let me just observe that I purposely&=2316= 0;did not mention about SR policies as we are not able to signal the inte= nt with the packets itself.&=23160;







    &=23160;







    So all we have there is SIDs. BSIDs or prefix = SIDs need to be flooded with information if policies build with using the= m are bypass eligible or not.&=23160;







    &=23160;







    I was actually under the impression that this = is already there and I am just not aware, but looking deeper indeed I do = not see this marking neither in ISIS nor OSP=46 for prefix SIDs.&=23160;<= /p>





    &=23160;







    Is there some work in progress to add it to th= ose protocols or have we just documented need&=23160;for a short LSR draf= t&=23160; =3F&=23160;







    &=23160;







    Thx,







    R.







    &=23160;







    &=23160;







    On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:











    Hi Robert,



    &=23160;



    Please check inline below.



    &=23160;





    =46rom: R= obert Raszuk <robert=40raszuk.net>


    Sent: 14 August 2020 21:13


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility





    &=23160;





    Hi Ketan,





    &=23160;







    While I completely agree with your note the co= nsequences of it are pretty sevre.&=23160;



    =5BKT=5D I understand. We need to be min= dful of implications of protection schemes for the SLAs/intent of SR Poli= cies.







    &=23160;







    Unless we signal which prefix SID is protectio= n eligible and which is not how would other nodes know if they can protec= t it or not =3F&=23160;



    =5BKT=5D Correct. To be more accurate, w= e need to consider this more in the context of SLA or =E2=80=9Cintent=E2=80= =9D of SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D= for local protection for some of those SR Policies. We also have path-pr= otection mechanisms.







    &=23160;







    It seems that today's safe thing is not to app= ly any node protection on SR flows at the PLRs then.&=23160;







    &=23160;







    And link protection MUST assure that packets w= ill arrive at the neighbor node via some other link regardless of further= path towards destination.&=23160;



    =5BKT=5D Yes. We have a mechanism to ind= icate which adj-SIDs have protection (that mechanism only provides link p= rotection to get to the neighbor node) so the SR Policy computation is ab= le to indicate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D= or not by its choice of protected or unprotected adj-SIDs respectively.<= /i>



    &=23160;



    Thanks,



    Ketan







    &=23160;







    Is it correct =3F&=23160;







    &=23160;







    Thx







    R







    &=23160;







    On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:











    Hi Sasha,



    &=23160;



    The service node advertises its own Prefix SID= .. The service function that this service node implements does not requir= e any context (i.e. all packets arriving at the node are subjected to tha= t service). Therefore the service node does not need to receive a packet = with it=E2=80=99s own Prefix SID.



    &=23160;



    Thus, we cannot assume that when PHP is used, = then the SID is only associated with a topological instruction.



    &=23160;



    Hope that clarifies=3F



    &=23160;



    Thanks,



    Ketan



    &=23160;







    =46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>


    Sent: 14 August 2020 20:24


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Shraddha Hegde <shraddha=40juniper.ne= t>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.= net>


    Cc: spring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility







    &=23160;



    Ketan, and all,



    I have stated that, IMHO and =46WIW, both Adj-SIDs= and Prefix SIDs that are advertised with PHP can&=23160; ONLY represent = topological instructions in SR-MPLS - because the advertising node will n= ot receive them and therefore can hardly be expected to associate any ser= vice function with them.



    &=23160;



    This is complementary to what you have said.



    &=23160;



    Hope this clarifies my position.



    What, if anything, did I miss=3F



    &=23160;



    Regards,



    Sasha







    &=23160;





    Get Outlook for Android









    &=23160;











    =46rom: Ketan Talaulikar (ketant) <ketant=40cisc= o.com>


    Sent: =46riday, August 14, 2020, 16:23


    To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk


    Cc: sp= ring=40ietf.org


    Subject: RE: =5Bspring=5D Spring protection - determining applicability=





    &=23160;







    NOTICE: This email was received from an EXTERN= AL sender







    &=23160;





    Hi Sasha,



    &=23160;



    If the service does not need any additional co= ntext (e.g. a firewall that just applies locally configured default rules= on it), then I don=E2=80=99t see why PHP could not be done for a Prefix = SID associated with a service node.



    &=23160;



    Also, I didn=E2=80=99t follow the point that y= ou were trying to make about Adj-SIDs.



    &=23160;



    Thanks,



    Ketan



    &=23160;







    =46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>


    Sent: 14 August 2020 18:24


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Alexander Vainshtein <Alexand= er.Vainshtein=40rbbn.com>; Shraddha Hegde <shraddha=40juniper.net<= /a>>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.net= >


    Cc: spring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility







    &=23160;



    Hi all,



    Regarding the statement =22Prefix SID could be jus= t a topological instruction or may also be used to steer the flow to a no= de which is applying a service function to it=22:



    &=23160;



    &=23160;



    I think that in SR-MPLS a Node SID that is adverti= sed with PHP aciton can be safely considered as =22just a topological ins= truction=22 by the PLR because the originating node will not receive it.<= /span>



    The same applies to Adj-SDIs.



    &=23160;



    My 2c.







    &=23160;





    Get Outlook for Android









    &=23160;











    =46rom: spring <spring-bounces=40ietf.org= > on behalf of Ketan Talaulikar (ketant) <ketant=3D= 40cisco.com=40dmarc.ietf.org>


    Sent: =46riday, August 14, 2020, 15:00


    To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk


    Cc: sp= ring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicability=





    &=23160;





    Hi All,





    I would like to share a different perspective on this.





    =46irst, thanks to Joel for bringing up the discussion. Clearly we need a= well-defined applicability statement for determining applicability of pr= otection for segment used in an SR Policy. Some of this is captured in =5B= 1=5D.





    This is about local repair at a PLR. By it's very nature, the PLR does no= t have a notion of how =22strict or not=22 is the SLA that is being provi= ded by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.





    We have protected and un-protected variants of adjacency SIDs to enable t= he computation to pick or the other based on the =22strictness=22 of the = SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag= ) to indicate whether a Prefix SID can be bypassed or not. This provides = the opportunity for the computation to use one or the other flavor depend= ing on the nature of the SLA for the SR Policy.





    I have a problem and a concern in the assumption that PLRs can assume tha= t the currently defined variant of Prefix SIDs in R=46C8402 (and IGP spec= s) are =22bypass-able=22.





    As Joel and others have brought out, the Prefix SID could be just a topol= ogical instruction or may also be used to steer the flow to a node which = is applying a service function to it. In order to support a mix of SR Pol= icies of different SLAs (strict and not-strict), we need to enable the ch= oice of SIDs that indicates to the PLR whether they are =22bypass-able=22= or not.





    =46or the cases, where the SR Policy has a specific SLA, it is required f= or nodes to drop the packets meant for the =22active segment=22 than to b= ypass it. When this mechanism is used along side SRTE path monitoring mec= hanisms, it enables the headend to detect the failure and fallback to an = alternate path using the path protection approach. This is something that= is described and in use in deployments today =5B1=5D..





    Thanks,


    Ketan





    =5B1=5D htt= ps://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2= =46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-pol= icy-08%23section-9


    =5B2=5D htt= ps://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46= %2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-policy= -08%23section-9.3





    -----Original Message-----


    =46rom: spring <spring-bounces=40ietf.org> On Behalf Of Joel M.= Halpern


    Sent: 04 August 2020 20:25


    To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com>= ;; Shraddha Hegde <shraddha=3D40juniper.net=40dmarc.ie= tf.org>; EXT-Andrew.Alston=40liquidtelecom.com <= ;Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40= raszuk.net>


    Cc: spri= ng=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>


    Subject: Re: =5Bspring=5D Spring protection - determining applicability




    There are, as far as I can tell, a number of ways to address this family = of related questions.


    What struck me, and prompted the starting question, was that none of them= were spelled out.&=23160; I see lots of interesting ideas / proposals.

    Some of them are compatible with others.&=23160;&=23160; Some are not.

    It would be good if we could reach agreement on how we thought it should = be handled.





    Thank you,


    Joel





    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:


    > Hi all,


    >


    > I am still not sure that the problem of bypass going thru undesirabl= e


    > links/nodes exists in the case of topological SIDs.


    >


    > A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090


    > <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs= 6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46rfc4090>) = has been successfully deployed


    > for many years before SR-MPLS has been introduced. What=E2=80=99s mo= re,


    > signaling of bypass tunnels he PLR usually did not include any of th= e


    > constraints used for computing of any specific LSP that the bypass L= SP


    > would protect =E2=80=93 because in the =46acility Protection mode th= e same


    > bypass LSP would be used to protect multiple LSPs passing thru the

    > failed link/node.


    >


    >&=23160; =46rom my POV the only difference between this behavior and = that


    > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, = in the case of


    > RSVP-TE, the operator would explicitly indicate, as part of LSP


    > signaling, whether it would or would not use =46RR; LSPs that would = not


    > use =46RR would then drop traffic rather than delivering it the wron= g way.


    >


    > Such an option indeed does not exist in SR-TE today, but would be ea= sy


    > to provide if so desired IMHO.


    >


    > Did I miss something substantial=3F


    >


    > Regards, and lots of thanks in advance,


    >


    > Sasha


    >


    > Office: +972-39266302


    >


    > Cell:&=23160;&=23160;&=23160;&=23160;&=23160; +972-549266302


    >


    > Email:&=23160;&=23160; Alexander.Vainshtein=40ecitele.com


    >


    > *=46rom:* spring <    spring-bounces=40ietf.org> *On Behalf Of = *Shraddha Hegde


    > *Sent:* Tuesday, August 4, 2020 9:41 AM


    > *To:* EXT-Andrew.Alston=40liquidtelecom.com


    > <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk &= lt;rob= ert=40raszuk.net>


    > *Cc:* spring=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>


    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > All,


    >


    > This is a very interesting discussion and thanks to Joel for startin= g


    > this discussion. IMO, when there are strict requirements of avoiding=


    > certain nodes/links it can be realized&=23160; either by defining a = flex-algo


    > avoiding those


    >


    > Nodes and links or by using a stack of unprotected adj-sids that avo= id


    > restricted nodes and links. When a stack of adj-sids is used to


    > realize the path, the head-end based (sB=46D) protection mechanisms = can be applied.


    >


    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, th= e


    > failure events may cause traffic to go through restricted nodes and<= br />

    > links. This would happen regardless of whether any kind of protectio= n


    > is in use or not.


    >


    > Rgds


    >


    > Shraddha


    >


    > Juniper Business Use Only


    >


    > *=46rom:* spring <spring-bounces=40ietf.org
     > = <mailto:spring-bounces=40ietf.org>> *On Behalf Of *Andrew Al= ston


    > *Sent:* Tuesday, August 4, 2020 5:41 AM


    > *To:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net>>


    > *Cc:*     spring=40ietf.org <mailto:spring=40ietf.org>; Joel M. Halpern


    > <jmh=40joelhalpern.com <mailto:jmh=40joelhalpern.com>>

    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > *=5BExternal Email. Be cautious of content=5D*


    >


    > Robert this is actually far more difficult when =E2=80=93 it can be = an entire


    > (long) series of nodes that need to be avoided.


    >


    > It could potentially be made to work but I=E2=80=99d worry that to d= o this =E2=80=93


    > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative la= bels =E2=80=93 and that wouldn=E2=80=99t


    > be viable.


    >


    > It=E2=80=99s easier to use algorithms and adjacency sids and other s= uch things


    > to calculate paths =E2=80=93 the biggest trick is about the stack de= pth.&=23160; When


    > you have this need for node avoidance =E2=80=93 the need for 10+ lab= el depth


    > is critical =E2=80=93 unless you wanna be applying one hell of a lot= of


    > binding labels along the way which is a nightmare.


    >


    > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use


    > case that most of the people I discuss this with certain have =E2=80= =93 I cant


    > comment on a global scale, or for anyone else, but every indication = I


    > have is that yes =E2=80=93 its something people need, and want
    =

    >


    > Andrew


    >


    > *=46rom:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net= >>


    > *Sent:* Tuesday, 4 August 2020 01:27


    > *To:* Andrew Alston <Andrew.Alston=40liquidtelecom.= com
     > <mailto:Andrew.Alston=40liquidtelecom.com>>


    > *Cc:* Joel M. Halpern <    jmh=40joelhalpern.com
     > <= ;mai= lto:jmh=40joelhalpern.com>>; spring=40ietf.org


    > <mailto:spring=40ietf.org>


    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > Is this a common use case ie.&=23160; =22but rather =E2=80=93 which = nodes / network


    > segments it can never touch or flow through.=22


    >


    > If so perhaps its time to define notion of *negative-SID* ie. list i= n


    > the packet resources which given&=23160;packet MUST not ever travers= e.


    >


    > Put in the packet set of nodes or links which the packet should neve= r


    > traverse.


    >


    > That goes in line of recent wave of negative routing implementations=


    > (RI=46T) or discussions (LSR)


    >


    > Best,


    > R.


    >


    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston


    > <Andrew.Alston=40liquidtelecom.com
     > &= lt;mailto:Andrew.Alston=40liquidtelecom.com>> wrote:


    >


    >&=23160;&=23160;&=23160;&=23160; So =E2=80=93


    >


    >&=23160;&=23160;&=23160;&=23160; One of the use cases, in fact, some = very major use cases in any


    >&=23160;&=23160;&=23160;&=23160; spring technology for us revolve aro= und the following


    >


    >&=23160;&=23160;&=23160;&=23160; a.The explicit avoidance of certain = nodes


    >


    >&=23160;&=23160;&=23160;&=23160; b.The explicit avoidance of certain = sections of the network


    >


    >&=23160;&=23160;&=23160;&=23160; Anything that could result in that e= xplicit avoidance being violated


    >&=23160;&=23160;&=23160;&=23160; =E2=80=93 would create, shall we say= significant problems.


    >


    >&=23160;&=23160;&=23160;&=23160; Much of the use case is not a case o= f which nodes the packets flow


    >&=23160;&=23160;&=23160;&=23160; through =E2=80=93 but rather =E2=80=93= which nodes / network segments it can never


    >&=23160;&=23160;&=23160;&=23160; touch or flow through.&=23160; Effec= tively, to be used as a technology to


    >&=23160;&=23160;&=23160;&=23160; avoid certain things for specific re= asons.


    >


    >&=23160;&=23160;&=23160;&=23160; This is also one of the reasons for = needing such deep label stacks =E2=80=93


    >&=23160;&=23160;&=23160;&=23160; this kind of detailed path programmi= ng tends to deepen the stack


    >&=23160;&=23160;&=23160;&=23160; because you sometimes have to be pre= tty explicit.


    >


    >&=23160;&=23160;&=23160;&=23160; It is absolutely critical to us that= this functionality is there =E2=80=93


    >&=23160;&=23160;&=23160;&=23160; and that we can avoid situations whi= ch could cause traffic to


    >&=23160;&=23160;&=23160;&=23160; accidently hit things explicitly avo= ided.


    >


    >&=23160;&=23160;&=23160;&=23160; I wish I could be more specific than= this, but it is what it is.


    >


    >&=23160;&=23160;&=23160;&=23160; Thanks


    >


    >&=23160;&=23160;&=23160;&=23160; Andrew


    >


    >&=23160;&=23160;&=23160;&=23160; *=46rom:* spring <spring-bounc= es=40ietf.org
     >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing-bounces=40ietf.org>> *On Behalf Of *Joel M. Halpern


    >&=23160;&=23160;&=23160;&=23160; *Sent:* Monday, 3 August 2020 21:36<= br />

    >&=23160;&=23160;&=23160;&=23160; *To:* Robert Raszuk <robert=40raszuk.net= <mailto:robert=40raszuk.net>>


    >&=23160;&=23160;&=23160;&=23160; *Cc:* spring=40ietf..org <mailto:spring=40ie= tf.org>


    >&=23160;&=23160;&=23160;&=23160; *Subject:* Re: =5Bspring=5D Spring p= rotection - determining


    > applicability


    >


    >&=23160;&=23160;&=23160;&=23160; (Since the thread has gotten long en= ough, reiterating that this is as a


    >&=23160;&=23160;&=23160;&=23160; participant, not a WG chair.)


    >


    >&=23160;&=23160;&=23160;&=23160; Yes, we are talking IP networks. And= yes, I have seen IP networks that


    >&=23160;&=23160;&=23160;&=23160; choose to drop packets. =46or all so= rts of reasons.


    >&=23160;&=23160;&=23160;&=23160; I think there are likely other reaso= ns why one may not want a random


    >&=23160;&=23160;&=23160;&=23160; path rather than a chosen TE path. I= think it is important we be clear


    >&=23160;&=23160;&=23160;&=23160; about what constraints may be / are = violated when we tell people they


    >&=23160;&=23160;&=23160;&=23160; have this tool (protective rerouting= ) that is intended to preserve QoS.


    >


    >&=23160;&=23160;&=23160;&=23160; Let's be clear. I am not arguing tha= t this is not a good idea. It is a


    >&=23160;&=23160;&=23160;&=23160; good idea. And useful. I am trying t= o figure otu what combination of


    >&=23160;&=23160;&=23160;&=23160; additional mechanisms and clear desc= riptions will lead to everyone


    >&=23160;&=23160;&=23160;&=23160; getting the behavior they expect (wh= ich may not be the behavior they


    >&=23160;&=23160;&=23160;&=23160; desire, but sometimes is the best we= can do.)


    >


    >&=23160;&=23160;&=23160;&=23160; Yours,


    >&=23160;&=23160;&=23160;&=23160; Joel


    >


    >&=23160;&=23160;&=23160;&=23160; On 8/3/2020 2:30 PM, Robert Raszuk w= rote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Joel,


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Are we still talking ab= out IP networks&=23160;here =3F Or perhaps some hard


    >&=23160;&=23160;&=23160;&=23160;&=23160; > slicing with real resou= rce reservations or detnets =3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Because&=23160;if we ar= e talking&=23160;about IP networking I have two


    >&=23160;&=23160;&=23160;&=23160; observations:


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > A) If you need to trave= rse via a specific node (ie. firewall) you


    >&=23160;&=23160;&=23160;&=23160; better


    >&=23160;&=23160;&=23160;&=23160;&=23160; > apply IP encapsulation = to that node.. I don't think IP


    >&=23160;&=23160;&=23160;&=23160; encapsulation&=23160;can


    >&=23160;&=23160;&=23160;&=23160;&=23160; > be hijacked today such = that destination address of the packet is


    >&=23160;&=23160;&=23160;&=23160; ignored.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > B) Have you seen any IP= network where upon topology change (link


    >&=23160;&=23160;&=23160;&=23160; or node


    >&=23160;&=23160;&=23160;&=23160;&=23160; > failure) you suddenly&=23= 160;start dropping&=23160;flows in spite of SPT offering


    >&=23160;&=23160;&=23160;&=23160;&=23160; > perhaps few ms longer p= ath with 10 ms more jitter =3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Or are some SR marketin= g slides promise to turn IP networks in


    >&=23160;&=23160;&=23160;&=23160;&=23160; > something&=23160;new =3F= Worse ... do they mention path quality guarantees,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > resource reservations&=23= 160;=3F I hope not.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Thx,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > R.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > On Mon, Aug 3, 2020 at = 8:10 PM Joel M. Halpern <jmh=40joelhalpern.com
     >&=23160;&=23= 160;&=23160;&=23160; <mailto:jmh=40joelhalpern.com%20%0b>> &= lt;m= ailto:jmh=40joelhalpern.com>> wrote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Well less serious for T= E SIDs, I am not sure the problem is


    >&=23160;&=23160;&=23160;&=23160; restricted


    >&=23160;&=23160;&=23160;&=23160;&=23160; > to just service SIDs.

    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Suppose that the PCE ha= s specified the path to meet some complex te


    >&=23160;&=23160;&=23160;&=23160;&=23160; > objective.&=23160; The = bypass node has no way of knowing what those


    >&=23160;&=23160;&=23160;&=23160;&=23160; > constraints


    >&=23160;&=23160;&=23160;&=23160;&=23160; > were.&=23160; And for s= ome kinds of traffic, it is better to drop the packet


    >&=23160;&=23160;&=23160;&=23160;&=23160; > than to deliver it outs= ide the envelop.&=23160; I suspect that the right


    >&=23160;&=23160;&=23160;&=23160;&=23160; > answer


    >&=23160;&=23160;&=23160;&=23160;&=23160; > to this is =22too bad=22= ..&=23160; If so, as with the distinction regarding


    >&=23160;&=23160;&=23160;&=23160; service


    >&=23160;&=23160;&=23160;&=23160;&=23160; > nodes, we should say so= , shouldn't we=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Yours,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Joel


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > On 8/3/2020 2:36 AM, Al= exander Vainshtein wrote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach, Joel and all= ,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I think that in mo= st cases:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > 1.There is clear d= ifferentiation between =22topological=22 and


    >&=23160;&=23160;&=23160;&=23160; =22service=22


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > instructions in SI= D advertisements. E.g.:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > oIGP Prefix Node S= IDs IGP Adj-SIDs (identified as such in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > corresponding IGP = advertisements) represent topological


    >&=23160;&=23160;&=23160;&=23160; instructions


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > oService SIDs for = SRv6 (see SRv6 BGP-Based Overlay Services


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3CCcy9mY6cMfbk7Qfjhi= A3R6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.ietf.org%2=46doc%2=46html%2=46= draft-ietf-bess-srv6-services-04
     >&=23160;&=23160;&=23160;&=23= 160; <https://clickt= ime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2=3Fu=3Dhttps%3A%2=46%2=46urlde= fense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46= html%2=46draft-ietf-bess-srv6-services-04=5F=5F%3B%21%21NEt6yMaO-gk%21S0Y= usx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24&= gt;>


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > draft) unsurprisin= gly represent =E2=80=9Cservice=E2=80=9D instructions


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > 2.Segments that re= present topological instructions can be bypassed,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > while segments tha= t represent service instructions require


    >&=23160;&=23160;&=23160;&=23160;&=23160; > alternative


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > protection mechani= sms.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > This view seems to= be aligned with R=46C 8402


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2=3Fu=3Dhttps%3A= %2=46%2=46tools.ietf.org%2=46html%2=46rfc8402
     >&=23160;&=231= 60;&=23160;&=23160; <https://clicktime.symantec.com/37PzUK= AD82cjSvmVcGvpkh=466H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46tools.ietf.org%2=46html%2=46rfc8402=5F=5F%3B%21%21NEt6= yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I= 4Ybtm%24>>


    >&=23160;&=23160;&=23160;&=23160; that says in Section 1:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of an IGP-based distributed control plane, two


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the IGP-Adjacency segment and the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; IGP-Prefix segment.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of a BGP-based distributed control plane, two


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the BGP peering segment and the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; BGP-Prefix segment.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > In the case of SR-= MPLS this differentiation is assumed in Section


    >&=23160;&=23160;&=23160;&=23160;&=23160; > 3.4 of


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the Node Protectio= n for SR-TE Path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktim= e.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2=3Fu=3Dhttps%3A%2=46%2=46datatra= cker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protection-for= -sr-te-paths-07%23section-3.4
     >&=23160;&=23160;&=23160;&=231= 60; <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ= 16H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= datatracker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protect= ion-for-sr-te-paths-07%2Asection-3.4=5F=5F%3BIw%21%21NEt6yMaO-gk%21S0Yusx= 9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>= >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > draft that says:

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The node protection mechanism described in the previous


    >&=23160;&=23160;&=23160;&=23160; sections


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; depends on the assumption that the label immediately below


    >&=23160;&=23160;&=23160;&=23160;&=23160; > the top


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > label in the label= stack is understood in the IGP domain.&=23160; When the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; provider edge routers exchange service labels via BGP or some


    >&=23160;&=23160;&=23160;&=23160;&=23160; > other


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; non-IGP mechanism the bottom label is not understood in the IGP


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; domain.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The egress node protection mechanisms described in the draft


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; =5BR=46C8679 <https://clicktime.syma= ntec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.i= etf.org%2=46doc%2=46html%2=46rfc8679
     >&=23160;&=23160;&=2316= 0;&=23160; <https://clicktime.symantec.com/36= dMAjuYTQovo8jHwmm3eJw6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46html%2=46rfc8679=5F=5F= %3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo8MGipXc%24>>=5D


    >&=23160;&=23160;&=23160;&=23160; is


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > applicable to this= use case and no additional changes


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; will be required for SR based networks


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > The scenarios in w= hich &=23160;differentiation between =E2=80=9Ctopological=E2=80=9D and

    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =E2=80=9Cservice=E2= =80=9D instructions is broken are indeed problematic. E.g.,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > consider


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the use case in wh= ich a Node SID in the ERO of a SR-TE path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > identifies a


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > node that acts as = a firewall for all packets it receives, i.e.,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > provides


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the firewall servi= ce without any dedicated service SID


    >&=23160;&=23160;&=23160;&=23160;&=23160; > identifying it.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > One could say that= the Node SID of such a node would combine


    >&=23160;&=23160;&=23160;&=23160;&=23160; > topological


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > and service instru= ctions thus breaking the differentiation


    >&=23160;&=23160;&=23160;&=23160;&=23160; > between the two.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I am not sure if u= sage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented


    >&=23160;&=23160;&=23160;&=23160;&=23160; > or at


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > least discouraged.=


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > If not, providing = an ability to identify such SIDs in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > advertisement


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > mechanisms would b= e useful IMHO.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > My 2c,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Sasha


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Office: +972-39266= 302


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Cell:&=23160;&=231= 60;&=23160;&=23160;&=23160; +972-549266302


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Email: Alex= ander.Vainshtein=40ecitele.com


    >&=23160;&=23160;&=23160;&=23160; <mailto:Alexander.Vainsh= tein=40ecitele.com>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:Ale= xander.Vainshtein=40ecitele.com>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > -----Original Mess= age-----


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =46rom: spring <= ;spring-bounces=40ietf.org
     >&=23160;&=23160;&=23160;&=231= 60; <mailto:spring-bounces=40ietf.org%0b>>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org= >> On Behalf Of Mach Chen


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Sent: Monday, Augu= st 3, 2020 6:30 AM


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > To: Joel M. Halper= n <jmh=40joelhalpern.com
     >&=23160;&=23160;&=23160;&=23160;= <mailto:jmh=40joelhalpern.com%0b>> <mailto:jmh=40joelhalpern.= com>>;


    >&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Subject: Re: =5Bsp= ring=5D Spring protection - determining applicability


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Hi Joel,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I think this is a = good point that may not be discussed in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > past. And


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I also don't think= there is a =22can be bypassed=22 indication in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > routing advertisem= ent for now.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > IMHO, the informat= ion advertised by routing is neutral, such


    >&=23160;&=23160;&=23160;&=23160;&=23160; > information


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > (can or cannot be = bypassed) is more path specific, thus


    >&=23160;&=23160;&=23160;&=23160; normally the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > controller should = be responsible for deciding whether/which SID


    >&=23160;&=23160;&=23160;&=23160;&=23160; > can be


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > bypassed.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Best regards,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > -----= Original Message-----


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46ro= m: spring =5Bmailto:spring-bounces=40ietf.org


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring-bounc= es=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org%0b%3e%20%3cmailto:spring-= bounces=40ietf.org%3e>=5D


    >&=23160;&=23160;&=23160;&=23160; On Behalf Of Joel M.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Halpe= rn


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Sent:= Monday, August 3, 2020 7:51 AM


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > To: <= a href=3D=22mailto:spring=40ietf.org=22 target=3D=22=5Fblank=22>spring=40= ietf.org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
     >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Subje= ct: =5Bspring=5D Spring protection - determining applicability


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > (WG C= hair hat Off, this is merely a note from a slightly


    >&=23160;&=23160;&=23160;&=23160;&=23160; > confused WG


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > parti= cipant.)


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > I hav= e been reading the various repair drafts, and the various


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > netwo= rks programming and service programming draft, and I am


    >&=23160;&=23160;&=23160;&=23160;&=23160; > trying to


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > figur= e out one aspect of the combination.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > How d= oes a node that is doing some form of bypass (suppose, for


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > simpl= icity, it is Node N2 deciding to bypass the next SID for


    >&=23160;&=23160;&=23160;&=23160;&=23160; > a failed


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > node = N3) know that it is safe to do so=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > If th= e path was just for TE, then it is =22safe=22 if the new path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > meets


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > the T= E criteria.&=23160; or maybe it is safe if it is even close, as


    >&=23160;&=23160;&=23160;&=23160;&=23160; > long as


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > it is= not used for too long.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > But w= hat if the node were a =46irewall, included to meet legal


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > requirements=3F

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Or wa= s some other necessary programmatic transform (wince we are


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > delib= erately vague about what nodes can do when asked suitably.)


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Is th= ere some =22can be bypassed=22 indication in the routing


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > adver= tisements that I missed=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Thank= you,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Yours= ,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Joel<= br />

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > sprin= g mailing list


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > spring=40ietf= ..org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
     >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dh= ttps%3A%2


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892X= uXy2H6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A= %2=46clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%= 2A3A%2A2=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0w= xqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3F= u=3Dhttps%3A%252
     >&=23160;&=23160;&=23160;&=23160; <https://clicktime.sym= antec.com/3A5B8H2=46m1rPnaZ3Supjwr6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.= com%2=46v3%2=46=5F=5Fhttps%3A%2=46clicktime.symantec.com%2=46367qhU4KiUkz= W9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%2A252=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0= Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24= >>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46%<= a href=3D=22http://2=46www.ietf.org=22 target=3D=22=5Fblank=22>2=46www.ie= tf.org


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/39NznmYBt= RuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5F= http%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5F= R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <https://clicktime.sym= antec.com/3GWT9fyja=46i3=46cvHDvoodvS6H2=3Fu=3Dhttp%3A%2=46%2=462=46www.i= etf.org
     >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symant= ec.com/39NznmYBtRuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%= 2=46v3%2=46=5F=5Fhttp%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<= /a>>>%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >     spring=40ietf.org <= mailto:s= pring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org> <mailto:s= pring=40ietf.org
     >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing=40ietf.org%0b>> <mailto:spring=40ietf.org>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJt= T6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%= 2A2=46%2A2=46www.ietf.org%2A2=46mailman%2A2=46listinfo%2A2=46spring=5F=5F= %3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo-hR3gAD%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Notice: This e-mai= l together with any attachments may contain


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > information of Rib= bon Communications Inc. that is confidential


    >&=23160;&=23160;&=23160;&=23160;&=23160; > and/or


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > proprietary for th= e sole use of the intended recipient. Any review,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > disclosure, relian= ce or distribution by others or forwarding


    >&=23160;&=23160;&=23160;&=23160; without


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > express permission= is strictly prohibited. If you are not the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > intended


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > recipient, please = notify the sender immediately and then delete all


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > copies, including = any attachments.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dht= tps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https:/= /clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > spring mailing list


    >&=23160;&=23160;&=23160;&=23160;&=23160; > spring=40ietf.org <mailto:spring= =40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A= %2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https:/= /clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >


    >&=23160;&=23160;&=23160;&=23160; =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


    >&=23160;&=23160;&=23160;&=23160; spring mailing list


    >&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;     https://cli= cktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160;


    > <https://clicktime.= symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%
     > 2=46= %2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listi


    > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqgu


    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >


    >


    >


    > --------------------------------------------------------------------= --


    > --


    > Notice: This e-mail together with any attachments may contain


    > information of Ribbon Communications Inc. that is confidential and/o= r


    > proprietary for the sole use of the intended recipient. Any review,<= br />

    > disclosure, reliance or distribution by others or forwarding without=


    > express permission is strictly prohibited. If you are not the intend= ed


    > recipient, please notify the sender immediately and then delete all<= br />

    > copies, including any attachments.


    > --------------------------------------------------------------------= --


    > --





    =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


    spring mailing list


    spring=40= ietf.org


    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring


    =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


    spring mailing list


    spring=40= ietf.org


    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring





    &=23160;





    &=23160;



    <= /span>



    Notice: This e-mail together with any attachments may co= ntain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, di= sclosure, reliance or distribution by others or forwarding without expres= s permission is strictly prohibited. If you are not the intended recipien= t, please notify the sender immediately and then delete all copies, inclu= ding any attachments.



    <= /span>





    &=23160;























    =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


    spring mailing list


    spring=40= ietf.org


    https://www.ietf.org/mailman/listinfo/spring






















    =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

    spring mailing list

    spring=40= ietf.org

    https://www.ietf.org/mailman/listinfo/= spring

    --


    Gyan Mishra<= /p>

    Netw= ork Solutions Architect&=23160;

    M 301 502-1347
    13101 Columbia Pike&=23160;
    Silver Spring, MD


    --5f3af0ad_1f16e9e8_65d7-- From nobody Mon Aug 17 14:25:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0046A3A11F1 for ; Mon, 17 Aug 2020 14:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 puoJ1YSQ32YK for ; Mon, 17 Aug 2020 14:25:33 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 867623A11FE for ; Mon, 17 Aug 2020 14:25:32 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id c10so13559128edk.6 for ; Mon, 17 Aug 2020 14:25:32 -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=/hE6iIyWshXA9oizDxEidZpcDEVM3nSmbLh/wHEsRS4=; b=XhLrZhcLoX7oI8fYIKptbAeC0F3c3Tg5vhAMVVBeQhzjnEueQxlJhsgPOTbWNbyguI nihZPuPd+8fVwvyVQnLCFdKm5cCE3l6yrrh7K8b0VO6/FI0jsUwETKYlAuFHL3Vssmse HgNgE4c0tj5sK3d36c8LAgn+otRqoz43+/IGGjjtWgTD0WRUsw9VcLaKsiDuzpYDYtmm geP4znLwSOK+433b+drjwglQ27Wrskeoz2rNiQRxin6OacvvgJljDwgBqLfX+YiMTd1M DpMiJMn2sNvVxM+IV5dteOotYNjuDVre4byglrJ+/tQxKU5Oupr5NRSAbxQnub0ikFvR 0SlA== 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=/hE6iIyWshXA9oizDxEidZpcDEVM3nSmbLh/wHEsRS4=; b=f7G0/ntEI1dF64ZJh/0ZX2QRY+QKNpum/HHFHq6IgcjjwHtIPQhlDwh6mKRpOkT1YA 6cTMZp7Kht7LLFIRTRu86CW96dWI4tN6QT6nwbq15BGnb2XWezwOrj6mIz1AtkNhoyFC lXsAa4bd2iSNTH2S5a6gz0M5UVHEdhijOfIXr6CYObMnoTC58MSgpeNQTfcWss9FYbPC nOd/0yHDS0vRXYnu3BTq7aSxNcq6gbYAYNMBODtITlTzfGW8gb3+GSe2LO0atPnpPhpT BizlrRTKDcNIClu6jFqZMFp7cHRoRPlDmiwKYSLrSOxTbdMiFotv/XCyiysTOHXEn/Po fqOg== X-Gm-Message-State: AOAM530j8VkhzuYdwz9JmZZ0lvmkmFeEBO64IGo4Evo3VHBhP/Djj4rf TG+Gll8cigA8maNGmyC36oH4705EKXpTcbuJRU+26g== X-Google-Smtp-Source: ABdhPJxN/wKEYrD+V9zVVo9Mm3ETfzNBgtBC0h779oHhjUkdF+J/MZjB3jAxxyAqLT5Gb3J0MjYps6dQ34l4qZZQank= X-Received: by 2002:a05:6402:a5b:: with SMTP id bt27mr17181393edb.120.1597699530588; Mon, 17 Aug 2020 14:25:30 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> <7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark> In-Reply-To: <7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark> From: Robert Raszuk Date: Mon, 17 Aug 2020 23:25:19 +0200 Message-ID: To: Jeff Tantsura Cc: Gyan Mishra , Alexander Vainshtein , "EXT-Andrew.Alston@liquidtelecom.com" , "Joel M. Halpern" , "Ketan Talaulikar (ketant)" , Shraddha Hegde , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000faa5aa05ad196840" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 21:25:40 -0000 --000000000000faa5aa05ad196840 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeff, This is not about more state in the network nor about including mirror service node in the backup path for some flows. The thread is about possession of enough information in PLR to either take the packet and shift it over backup path or just drop it. - - - Btw - path protection is completely orthogonal to the above. Cheers, Robert. On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura wrote: > Gyan, > > TI-LFA computation is local to the PLR and is topology dependent, e.g > change in downstream topology could/would influence the choice of MP (PQ) > node. > While an implementation could take into consideration some additional > meta-data (e.g. locally provisioned SRLG, usually used to avoid protected > and protecting ports on the same line card), this is not a standardized > method. > If a service node must be included in a backup path, there=E2=80=99s a st= ate > associated with it as well as distribution of the state involved. > > Back to my point, removing state and introducing services in the network > (at the very least at the computational logic and head-end level) are > mutually exclusive, trade-offs are inevitable (You can't eat your cake an= d > have it). > Keeping the state limited to: > - a logically centralized computational logic (aka PCE) - off path, scale= s > horizontally, could use additional business logic for the path computatio= n, > example - CPU/memory consumption on a service node > - head-end - anchor to primary/backup paths > seems like a reasonable set of trade-offs. > > Cheers, > Jeff > On Aug 14, 2020, 7:44 PM -0700, Gyan Mishra , > wrote: > > > Catching up on this thread as it is a interesting topic as FRR 1:N link > protection, node protection and path protection is critical to operators. > > There are multiple somewhat orthogonal topics brought up in the discussio= n. > > Excluding SR SFC from =E2=80=9Cbypass=E2=80=9D capable node such for appl= iances such as > firewalls and load balancer. Makes sense. I would not think SFC would b= e > in a PLR path to merger point but I could be mistaken. > > The goal of SR is eliminating state and so having TE like state is > undesirable. > > Intent based instantiation of bypass via SR-TE from network feedback at > PLR detection node of a failure and make before break pre computed backup > paths that can. > > It would make sense that SR-TE binding SID policy would be appropriate fo= r > RSVP like FRR link node or path protection. > > My thoughts on this topic of SR protection is that don=E2=80=99t we alrea= dy have > FRR protection natively without requiring SR-TE BSID or any additional > undesirable state maintenance with TI-LFA. > > Thanks > > Gyan > > On Fri, Aug 14, 2020 at 5:47 PM Jeff Tantsura > wrote: > >> >> >> >> >> >> >> >> >> >> >> >> >> PCE computation in this case is trivial too(must traverse node B or node >> X) else FAIL. >> >> >> >> >> >> >> >> Cheers, >> >> Jeff >> >> >> >> >> >> >> On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura , >> wrote: >> >> >> >> >> >> >> Robert, >> >> >> >> >> >> Agreed and apologies, hit send before finishing the email (it is Friday) >> ;-) >> >> >> >> >> >> Path protection in this case make more sense and is much less complex, >> >> >> if in the pathA (A->B->C) node B is a service node, it can=E2=80=99t be = bypassed >> (node protected) if the link between A and B breaks >> >> >> however it could have a backup pathB (A->X->C) where X is the service >> node, potentially synchronizing its state with the node B. >> >> >> >> >> >> To my previous email - at expense of more state, we provide path and >> service protection, hence the similarity with RSVP-TE trade-offs. >> >> >> >> >> >> >> >> Cheers, >> >> Jeff >> >> >> >> >> >> >> On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , wrote= : >> >> >> >> >> Jeff, >> >> >> >> >> > This is very similar to RSVP-TE >> >> >> >> >> >> I would rather differ on that statement. >> >> >> >> >> >> See if you are using SR just for TE you are 100% right. >> >> >> >> >> >> But if your SIDs embed additional local SR node processing functions thi= s >> suddenly becomes a completely different game. Let's keep this in mind in >> this thread/topic. >> >> >> >> >> >> Kind regards, >> >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura >> wrote: >> >> >> >>> >>> >>> >>> >>> >>> This is very similar to RSVP-TE, path vs link/node protection and >>> usually dictated by the business logic, the triggers are obviously very >>> different, head-end being notified of the failure on a path and switchi= ng >>> to the backup path vs reaction to a local failure, so same consideratio= ns >>> apply: >>> >>> >>> -more state >>> >>> >>> -pre-reserved resources >>> >>> >>> while >>> >>> >>> -predictable >>> >>> >>> -meets SLA (as good as primary) >>> >>> >>> vs >>> >>> >>> -less state >>> >>> >>> -local >>> >>> >>> -best effort / can cause congestions >>> >>> >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> >>> >>> >>> >>> On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) >> 40cisco.com@dmarc.ietf.org>, wrote: >>> >>> >>> >>> >>> >>> >>> Hi Robert, >>> >>> >>> >>> >>> >>> We do not have a signalling mechanism in IGPs today to indicate a >>> =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was = a desire for it, an >>> IGP extension would be required (there is none in progress AFAIK). Note >>> that this results in doubling the prefix SID scale (global labels) in t= he >>> network. So I would not go about this trivially. >>> >>> >>> >>> >>> >>> I think it helps to get more inputs and perspectives from operators on >>> their views for doing a bypass via local protection for segments in an = SR >>> Policy. There may be those that prefer end-to-end path protection using= a >>> fallback path that is say disjoint with the primary but provides an >>> appropriate SLA/intent? >>> >>> >>> >>> >>> >>> Thanks, >>> >>> >>> Ketan >>> >>> >>> >>> >>> >>> >>> >>> *From:* Robert Raszuk >>> >>> >>> *Sent:* 14 August 2020 23:04 >>> >>> >>> *To:* Ketan Talaulikar (ketant) >>> >>> >>> *Cc:* Alexander Vainshtein ; Joel M. >>> Halpern ; Shraddha Hegde ; >>> EXT-Andrew.Alston@liquidtelecom.com ; >>> spring@ietf.org >>> >>> >>> *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Ketan, >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Looks like we are pretty much in sync here. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> But let me just observe that I purposely did not mention about SR >>> policies as we are not able to signal the intent with the packets itsel= f. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded >>> with information if policies build with using them are bypass eligible = or >>> not. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I was actually under the impression that this is already there and I am >>> just not aware, but looking deeper indeed I do not see this marking nei= ther >>> in ISIS nor OSPF for prefix SIDs. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Is there some work in progress to add it to those protocols or have we >>> just documented need for a short LSR draft ? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Thx, >>> >>> >>> >>> >>> >>> >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) < >>> ketant@cisco.com> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Robert, >>> >>> >>> >>> >>> >>> Please check inline below. >>> >>> >>> >>> >>> >>> >>> >>> *From:* Robert Raszuk >>> >>> >>> *Sent:* 14 August 2020 21:13 >>> >>> >>> *To:* Ketan Talaulikar (ketant) >>> >>> >>> *Cc:* Alexander Vainshtein ; Joel M. >>> Halpern ; Shraddha Hegde ; >>> EXT-Andrew.Alston@liquidtelecom.com ; >>> spring@ietf.org >>> >>> >>> *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Ketan, >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> While I completely agree with your note the consequences of it are >>> pretty sevre. >>> >>> >>> *[KT] I understand. We need to be mindful of implications of protection >>> schemes for the SLAs/intent of SR Policies.* >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Unless we signal which prefix SID is protection eligible and which is >>> not how would other nodes know if they can protect it or not ? >>> >>> >>> *[KT] Correct. To be more accurate, we need to consider this more in th= e >>> context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and which seg= ments may be >>> =E2=80=9Cbypass-able=E2=80=9D for local protection for some of those SR= Policies. We also >>> have path-protection mechanisms.* >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> It seems that today's safe thing is not to apply any node protection on >>> SR flows at the PLRs then. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> And link protection MUST assure that packets will arrive at the neighbo= r >>> node via some other link regardless of further path towards destination= . >>> >>> >>> *[KT] Yes. We have a mechanism to indicate which adj-SIDs have >>> protection (that mechanism only provides link protection to get to the >>> neighbor node) so the SR Policy computation is able to indicate whether >>> that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its choic= e of protected or >>> unprotected adj-SIDs respectively.* >>> >>> >>> >>> >>> >>> *Thanks,* >>> >>> >>> *Ketan* >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Is it correct ? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Thx >>> >>> >>> >>> >>> >>> >>> R >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) < >>> ketant@cisco.com> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Sasha, >>> >>> >>> >>> >>> >>> The service node advertises its own Prefix SID.. The service function >>> that this service node implements does not require any context (i.e. al= l >>> packets arriving at the node are subjected to that service). Therefore = the >>> service node does not need to receive a packet with it=E2=80=99s own Pr= efix SID. >>> >>> >>> >>> >>> >>> Thus, we cannot assume that when PHP is used, then the SID is only >>> associated with a topological instruction. >>> >>> >>> >>> >>> >>> Hope that clarifies? >>> >>> >>> >>> >>> >>> Thanks, >>> >>> >>> Ketan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From:* Alexander Vainshtein >>> >>> >>> *Sent:* 14 August 2020 20:24 >>> >>> >>> *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < >>> jmh@joelhalpern.com>; Shraddha Hegde ; >>> EXT-Andrew.Alston@liquidtelecom.com ; >>> Robert Raszuk >>> >>> >>> *Cc:* spring@ietf.org >>> >>> >>> *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Ketan, and all, >>> >>> >>> I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that >>> are advertised with PHP can ONLY represent topological instructions in >>> SR-MPLS - because the advertising node will not receive them and theref= ore >>> can hardly be expected to associate any service function with them. >>> >>> >>> >>> >>> >>> This is complementary to what you have said. >>> >>> >>> >>> >>> >>> Hope this clarifies my position. >>> >>> >>> What, if anything, did I miss? >>> >>> >>> >>> >>> >>> Regards, >>> >>> >>> Sasha >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Get Outlook for Android >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> >>> >>> >>> *From:* Ketan Talaulikar (ketant) >>> >>> >>> *Sent:* Friday, August 14, 2020, 16:23 >>> >>> >>> *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; >>> EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk >>> >>> >>> *Cc:* spring@ietf.org >>> >>> >>> *Subject:* RE: [spring] Spring protection - determining applicability >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> >>> NOTICE: This email was received from an EXTERNAL sender >>> >>> >>> >>> >>> ------------------------------ >>> >>> >>> >>> >>> >>> >>> >>> Hi Sasha, >>> >>> >>> >>> >>> >>> If the service does not need any additional context (e.g. a firewall >>> that just applies locally configured default rules on it), then I don= =E2=80=99t see >>> why PHP could not be done for a Prefix SID associated with a service no= de. >>> >>> >>> >>> >>> >>> Also, I didn=E2=80=99t follow the point that you were trying to make ab= out >>> Adj-SIDs. >>> >>> >>> >>> >>> >>> Thanks, >>> >>> >>> Ketan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From:* Alexander Vainshtein >>> >>> >>> *Sent:* 14 August 2020 18:24 >>> >>> >>> *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < >>> jmh@joelhalpern.com>; Alexander Vainshtein < >>> Alexander.Vainshtein@rbbn.com>; Shraddha Hegde ; >>> EXT-Andrew.Alston@liquidtelecom.com ; >>> Robert Raszuk >>> >>> >>> *Cc:* spring@ietf.org >>> >>> >>> *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi all, >>> >>> >>> Regarding the statement "Prefix SID could be just a topological >>> instruction or may also be used to steer the flow to a node which is >>> applying a service function to it": >>> >>> >>> >>> >>> >>> >>> >>> >>> I think that in SR-MPLS a Node SID that is advertised with PHP aciton >>> can be safely considered as "just a topological instruction" by the PLR >>> because the originating node will not receive it. >>> >>> >>> The same applies to Adj-SDIs. >>> >>> >>> >>> >>> >>> My 2c. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Get Outlook for Android >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> >>> >>> >>> *From:* spring on behalf of Ketan Talaulikar >>> (ketant) >>> >>> >>> *Sent:* Friday, August 14, 2020, 15:00 >>> >>> >>> *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; >>> EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk >>> >>> >>> *Cc:* spring@ietf.org >>> >>> >>> *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi All, >>> >>> >>> >>> >>> >>> I would like to share a different perspective on this. >>> >>> >>> >>> >>> >>> First, thanks to Joel for bringing up the discussion. Clearly we need a >>> well-defined applicability statement for determining applicability of >>> protection for segment used in an SR Policy. Some of this is captured i= n >>> [1]. >>> >>> >>> >>> >>> >>> This is about local repair at a PLR. By it's very nature, the PLR does >>> not have a notion of how "strict or not" is the SLA that is being provi= ded >>> by the SR Policy. Awareness of that notion exists at the SR Policy head= end >>> and/or computation-node. >>> >>> >>> >>> >>> >>> We have protected and un-protected variants of adjacency SIDs to enable >>> the computation to pick or the other based on the "strictness" of the S= LA >>> requirement for picking that link. We do not have such a notion for Pre= fix >>> SIDs. One can say that we could introduce signalling (e.g. a B flag) to >>> indicate whether a Prefix SID can be bypassed or not. This provides the >>> opportunity for the computation to use one or the other flavor dependin= g on >>> the nature of the SLA for the SR Policy. >>> >>> >>> >>> >>> >>> I have a problem and a concern in the assumption that PLRs can assume >>> that the currently defined variant of Prefix SIDs in RFC8402 (and IGP >>> specs) are "bypass-able". >>> >>> >>> >>> >>> >>> As Joel and others have brought out, the Prefix SID could be just a >>> topological instruction or may also be used to steer the flow to a node >>> which is applying a service function to it. In order to support a mix o= f SR >>> Policies of different SLAs (strict and not-strict), we need to enable t= he >>> choice of SIDs that indicates to the PLR whether they are "bypass-able"= or >>> not. >>> >>> >>> >>> >>> >>> For the cases, where the SR Policy has a specific SLA, it is required >>> for nodes to drop the packets meant for the "active segment" than to by= pass >>> it. When this mechanism is used along side SRTE path monitoring mechani= sms, >>> it enables the headend to detect the failure and fallback to an alterna= te >>> path using the path protection approach. This is something that is >>> described and in use in deployments today [1].. >>> >>> >>> >>> >>> >>> Thanks, >>> >>> >>> Ketan >>> >>> >>> >>> >>> >>> [1] >>> https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9 >>> >>> >>> [2] >>> https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9.3 >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> >>> From: spring On Behalf Of Joel M. Halpern >>> >>> >>> Sent: 04 August 2020 20:25 >>> >>> >>> To: Alexander Vainshtein ; Shraddha >>> Hegde ; >>> EXT-Andrew.Alston@liquidtelecom.com ; >>> Robert Raszuk >>> >>> >>> Cc: spring@ietf.org; Joel M. Halpern >>> >>> >>> Subject: Re: [spring] Spring protection - determining applicability >>> >>> >>> >>> >>> >>> There are, as far as I can tell, a number of ways to address this famil= y >>> of related questions. >>> >>> >>> What struck me, and prompted the starting question, was that none of >>> them were spelled out. I see lots of interesting ideas / proposals. >>> >>> >>> Some of them are compatible with others. Some are not. >>> >>> >>> It would be good if we could reach agreement on how we thought it shoul= d >>> be handled. >>> >>> >>> >>> >>> >>> Thank you, >>> >>> >>> Joel >>> >>> >>> >>> >>> >>> On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: >>> >>> >>> > Hi all, >>> >>> >>> > >>> >>> >>> > I am still not sure that the problem of bypass going thru undesirable >>> >>> >>> > links/nodes exists in the case of topological SIDs. >>> >>> >>> > >>> >>> >>> > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 >>> >>> >>> > < >>> https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2= F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) >>> has been successfully deployed >>> >>> >>> > for many years before SR-MPLS has been introduced. What=E2=80=99s mor= e, >>> >>> >>> > signaling of bypass tunnels he PLR usually did not include any of the >>> >>> >>> > constraints used for computing of any specific LSP that the bypass LS= P >>> >>> >>> > would protect =E2=80=93 because in the Facility Protection mode the s= ame >>> >>> >>> > bypass LSP would be used to protect multiple LSPs passing thru the >>> >>> >>> > failed link/node. >>> >>> >>> > >>> >>> >>> > From my POV the only difference between this behavior and that >>> >>> >>> > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, i= n the case of >>> >>> >>> > RSVP-TE, the operator would explicitly indicate, as part of LSP >>> >>> >>> > signaling, whether it would or would not use FRR; LSPs that would not >>> >>> >>> > use FRR would then drop traffic rather than delivering it the wrong >>> way. >>> >>> >>> > >>> >>> >>> > Such an option indeed does not exist in SR-TE today, but would be eas= y >>> >>> >>> > to provide if so desired IMHO. >>> >>> >>> > >>> >>> >>> > Did I miss something substantial? >>> >>> >>> > >>> >>> >>> > Regards, and lots of thanks in advance, >>> >>> >>> > >>> >>> >>> > Sasha >>> >>> >>> > >>> >>> >>> > Office: +972-39266302 >>> >>> >>> > >>> >>> >>> > Cell: +972-549266302 >>> >>> >>> > >>> >>> >>> > Email: Alexander.Vainshtein@ecitele.com >>> >>> >>> > >>> >>> >>> > *From:* spring *On Behalf Of *Shraddha Hegd= e >>> >>> >>> > *Sent:* Tuesday, August 4, 2020 9:41 AM >>> >>> >>> > *To:* EXT-Andrew.Alston@liquidtelecom.com >>> >>> >>> > ; Robert Raszuk >>> >>> >>> > *Cc:* spring@ietf.org; Joel M. Halpern >>> >>> >>> > *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> > >>> >>> >>> > All, >>> >>> >>> > >>> >>> >>> > This is a very interesting discussion and thanks to Joel for starting >>> >>> >>> > this discussion. IMO, when there are strict requirements of avoiding >>> >>> >>> > certain nodes/links it can be realized either by defining a flex-alg= o >>> >>> >>> > avoiding those >>> >>> >>> > >>> >>> >>> > Nodes and links or by using a stack of unprotected adj-sids that avoi= d >>> >>> >>> > restricted nodes and links. When a stack of adj-sids is used to >>> >>> >>> > realize the path, the head-end based (sBFD) protection mechanisms can >>> be applied. >>> >>> >>> > >>> >>> >>> > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the >>> >>> >>> > failure events may cause traffic to go through restricted nodes and >>> >>> >>> > links. This would happen regardless of whether any kind of protection >>> >>> >>> > is in use or not. >>> >>> >>> > >>> >>> >>> > Rgds >>> >>> >>> > >>> >>> >>> > Shraddha >>> >>> >>> > >>> >>> >>> > Juniper Business Use Only >>> >>> >>> > >>> >>> >>> > *From:* spring >> > >> >> *On Behalf Of *Andrew Alston >>> >>> >>> > *Sent:* Tuesday, August 4, 2020 5:41 AM >>> >>> >>> > *To:* Robert Raszuk >> >> >>> >>> >>> > *Cc:* spring@ietf.org >; >>> Joel M. Halpern >>> >>> >>> > >>> >> >>> >>> >>> > *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> > >>> >>> >>> > *[External Email. Be cautious of content]* >>> >>> >>> > >>> >>> >>> > Robert this is actually far more difficult when =E2=80=93 it can be a= n entire >>> >>> >>> > (long) series of nodes that need to be avoided. >>> >>> >>> > >>> >>> >>> > It could potentially be made to work but I=E2=80=99d worry that to do= this =E2=80=93 >>> >>> >>> > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative lab= els =E2=80=93 and that wouldn=E2=80=99t >>> >>> >>> > be viable. >>> >>> >>> > >>> >>> >>> > It=E2=80=99s easier to use algorithms and adjacency sids and other su= ch things >>> >>> >>> > to calculate paths =E2=80=93 the biggest trick is about the stack dep= th. When >>> >>> >>> > you have this need for node avoidance =E2=80=93 the need for 10+ labe= l depth >>> >>> >>> > is critical =E2=80=93 unless you wanna be applying one hell of a lot = of >>> >>> >>> > binding labels along the way which is a nightmare. >>> >>> >>> > >>> >>> >>> > But to answer your question, is this a common use case =E2=80=93 it= =E2=80=99s a use >>> >>> >>> > case that most of the people I discuss this with certain have =E2=80= =93 I cant >>> >>> >>> > comment on a global scale, or for anyone else, but every indication I >>> >>> >>> > have is that yes =E2=80=93 its something people need, and want >>> >>> >>> > >>> >>> >>> > Andrew >>> >>> >>> > >>> >>> >>> > *From:* Robert Raszuk >> >> >>> >>> >>> > *Sent:* Tuesday, 4 August 2020 01:27 >>> >>> >>> > *To:* Andrew Alston >> > < >>> mailto:Andrew.Alston@liquidtelecom.com >>> >> >>> >>> >>> > *Cc:* Joel M. Halpern >> > >> >>; spring@ietf.org >>> >>> >>> > > >>> >>> >>> > *Subject:* Re: [spring] Spring protection - determining applicability >>> >>> >>> > >>> >>> >>> > Is this a common use case ie. "but rather =E2=80=93 which nodes / ne= twork >>> >>> >>> > segments it can never touch or flow through." >>> >>> >>> > >>> >>> >>> > If so perhaps its time to define notion of *negative-SID* ie. list in >>> >>> >>> > the packet resources which given packet MUST not ever traverse. >>> >>> >>> > >>> >>> >>> > Put in the packet set of nodes or links which the packet should never >>> >>> >>> > traverse. >>> >>> >>> > >>> >>> >>> > That goes in line of recent wave of negative routing implementations >>> >>> >>> > (RIFT) or discussions (LSR) >>> >>> >>> > >>> >>> >>> > Best, >>> >>> >>> > R. >>> >>> >>> > >>> >>> >>> > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston >>> >>> >>> > >> > < >>> mailto:Andrew.Alston@liquidtelecom.com >> >>> wrote: >>> >>> >>> > >>> >>> >>> > So =E2=80=93 >>> >>> >>> > >>> >>> >>> > One of the use cases, in fact, some very major use cases in any >>> >>> >>> > spring technology for us revolve around the following >>> >>> >>> > >>> >>> >>> > a.The explicit avoidance of certain nodes >>> >>> >>> > >>> >>> >>> > b.The explicit avoidance of certain sections of the network >>> >>> >>> > >>> >>> >>> > Anything that could result in that explicit avoidance being >>> violated >>> >>> >>> > =E2=80=93 would create, shall we say significant problems. >>> >>> >>> > >>> >>> >>> > Much of the use case is not a case of which nodes the packets flo= w >>> >>> >>> > through =E2=80=93 but rather =E2=80=93 which nodes / network segm= ents it can never >>> >>> >>> > touch or flow through. Effectively, to be used as a technology t= o >>> >>> >>> > avoid certain things for specific reasons. >>> >>> >>> > >>> >>> >>> > This is also one of the reasons for needing such deep label stack= s >>> =E2=80=93 >>> >>> >>> > this kind of detailed path programming tends to deepen the stack >>> >>> >>> > because you sometimes have to be pretty explicit. >>> >>> >>> > >>> >>> >>> > It is absolutely critical to us that this functionality is there = =E2=80=93 >>> >>> >>> > and that we can avoid situations which could cause traffic to >>> >>> >>> > accidently hit things explicitly avoided. >>> >>> >>> > >>> >>> >>> > I wish I could be more specific than this, but it is what it is. >>> >>> >>> > >>> >>> >>> > Thanks >>> >>> >>> > >>> >>> >>> > Andrew >>> >>> >>> > >>> >>> >>> > *From:* spring >> > >> >> *On Behalf Of *Joel M. Halpern >>> >>> >>> > *Sent:* Monday, 3 August 2020 21:36 >>> >>> >>> > *To:* Robert Raszuk >> >> >>> >>> >>> > *Cc:* spring@ietf..org > >>> >>> >>> > *Subject:* Re: [spring] Spring protection - determining >>> >>> >>> > applicability >>> >>> >>> > >>> >>> >>> > (Since the thread has gotten long enough, reiterating that this i= s >>> as a >>> >>> >>> > participant, not a WG chair.) >>> >>> >>> > >>> >>> >>> > Yes, we are talking IP networks. And yes, I have seen IP networks >>> that >>> >>> >>> > choose to drop packets. For all sorts of reasons. >>> >>> >>> > I think there are likely other reasons why one may not want a >>> random >>> >>> >>> > path rather than a chosen TE path. I think it is important we be >>> clear >>> >>> >>> > about what constraints may be / are violated when we tell people >>> they >>> >>> >>> > have this tool (protective rerouting) that is intended to preserv= e >>> QoS. >>> >>> >>> > >>> >>> >>> > Let's be clear. I am not arguing that this is not a good idea. It >>> is a >>> >>> >>> > good idea. And useful. I am trying to figure otu what combination >>> of >>> >>> >>> > additional mechanisms and clear descriptions will lead to everyon= e >>> >>> >>> > getting the behavior they expect (which may not be the behavior >>> they >>> >>> >>> > desire, but sometimes is the best we can do.) >>> >>> >>> > >>> >>> >>> > Yours, >>> >>> >>> > Joel >>> >>> >>> > >>> >>> >>> > On 8/3/2020 2:30 PM, Robert Raszuk wrote: >>> >>> >>> > > Joel, >>> >>> >>> > > >>> >>> >>> > > Are we still talking about IP networks here ? Or perhaps some >>> hard >>> >>> >>> > > slicing with real resource reservations or detnets ? >>> >>> >>> > > >>> >>> >>> > > Because if we are talking about IP networking I have two >>> >>> >>> > observations: >>> >>> >>> > > >>> >>> >>> > > A) If you need to traverse via a specific node (ie. firewall) >>> you >>> >>> >>> > better >>> >>> >>> > > apply IP encapsulation to that node.. I don't think IP >>> >>> >>> > encapsulation can >>> >>> >>> > > be hijacked today such that destination address of the packet = is >>> >>> >>> > ignored. >>> >>> >>> > > >>> >>> >>> > > B) Have you seen any IP network where upon topology change (li= nk >>> >>> >>> > or node >>> >>> >>> > > failure) you suddenly start dropping flows in spite of SPT >>> offering >>> >>> >>> > > perhaps few ms longer path with 10 ms more jitter ? >>> >>> >>> > > >>> >>> >>> > > Or are some SR marketing slides promise to turn IP networks in >>> >>> >>> > > something new ? Worse ... do they mention path quality >>> guarantees, >>> >>> >>> > > resource reservations ? I hope not. >>> >>> >>> > > >>> >>> >>> > > Thx, >>> >>> >>> > > R. >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > >>> >>> >>> > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern < >>> jmh@joelhalpern.com >>> > >> >> >> >> wrote: >>> >>> >>> > > >>> >>> >>> > > Well less serious for TE SIDs, I am not sure the problem is >>> >>> >>> > restricted >>> >>> >>> > > to just service SIDs. >>> >>> >>> > > >>> >>> >>> > > Suppose that the PCE has specified the path to meet some >>> complex te >>> >>> >>> > > objective. The bypass node has no way of knowing what those >>> >>> >>> > > constraints >>> >>> >>> > > were. And for some kinds of traffic, it is better to drop the >>> packet >>> >>> >>> > > than to deliver it outside the envelop. I suspect that the >>> right >>> >>> >>> > > answer >>> >>> >>> > > to this is "too bad".. If so, as with the distinction regardi= ng >>> >>> >>> > service >>> >>> >>> > > nodes, we should say so, shouldn't we? >>> >>> >>> > > >>> >>> >>> > > Yours, >>> >>> >>> > > Joel >>> >>> >>> > > >>> >>> >>> > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: >>> >>> >>> > > > Mach, Joel and all, >>> >>> >>> > > > >>> >>> >>> > > > I think that in most cases: >>> >>> >>> > > > >>> >>> >>> > > > 1.There is clear differentiation between "topological" and >>> >>> >>> > "service" >>> >>> >>> > > > instructions in SID advertisements. E.g.: >>> >>> >>> > > > >>> >>> >>> > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in th= e >>> >>> >>> > > > corresponding IGP advertisements) represent topological >>> >>> >>> > instructions >>> >>> >>> > > > >>> >>> >>> > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > < >>> https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%= 2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04 >>> >>> >>> > < >>> https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2= Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1o= iQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24 >>> >> >>> >>> >>> > > >>> >>> >>> > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D in= structions >>> >>> >>> > > > >>> >>> >>> > > > 2.Segments that represent topological instructions can be >>> bypassed, >>> >>> >>> > > > while segments that represent service instructions require >>> >>> >>> > > alternative >>> >>> >>> > > > protection mechanisms. >>> >>> >>> > > > >>> >>> >>> > > > This view seems to be aligned with RFC 8402 >>> >>> >>> > > > < >>> https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >>> >>> >>> > < >>> https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3= B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDu= iDo0I4Ybtm%24 >>> >> >>> >>> >>> > that says in Section 1: >>> >>> >>> > > > >>> >>> >>> > > > In the context of an IGP-based distributed control plane= , >>> two >>> >>> >>> > > > >>> >>> >>> > > > topological segments are defined: the IGP-Adjacency segment >>> and the >>> >>> >>> > > > >>> >>> >>> > > > IGP-Prefix segment. >>> >>> >>> > > > >>> >>> >>> > > > In the context of a BGP-based distributed control plane, >>> two >>> >>> >>> > > > >>> >>> >>> > > > topological segments are defined: the BGP peering segment an= d >>> the >>> >>> >>> > > > >>> >>> >>> > > > BGP-Prefix segment. >>> >>> >>> > > > >>> >>> >>> > > > In the case of SR-MPLS this differentiation is assumed in >>> Section >>> >>> >>> > > 3.4 of >>> >>> >>> > > > the Node Protection for SR-TE Path >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > < >>> https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%= 2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection= -for-sr-te-paths-07%23section-3.4 >>> >>> >>> > < >>> https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2= Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw= %21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDui= Do9wO-Ssn%24 >>> >> >>> >>> >>> > > >>> >>> >>> > > > draft that says: >>> >>> >>> > > > >>> >>> >>> > > > The node protection mechanism described in the previous >>> >>> >>> > sections >>> >>> >>> > > > >>> >>> >>> > > > depends on the assumption that the label immediately bel= ow >>> >>> >>> > > the top >>> >>> >>> > > > >>> >>> >>> > > > label in the label stack is understood in the IGP domain. >>> When the >>> >>> >>> > > > >>> >>> >>> > > > provider edge routers exchange service labels via BGP or >>> some >>> >>> >>> > > other >>> >>> >>> > > > >>> >>> >>> > > > non-IGP mechanism the bottom label is not understood in >>> the IGP >>> >>> >>> > > > >>> >>> >>> > > > domain. >>> >>> >>> > > > >>> >>> >>> > > > The egress node protection mechanisms described in the >>> draft >>> >>> >>> > > > >>> >>> >>> > > > [RFC8679 < >>> https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%= 2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679 >>> >>> >>> > < >>> https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2= Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vp= RHOGt8AkTRDuiDo8MGipXc%24 >>> >>] >>> >>> >>> > is >>> >>> >>> > > > applicable to this use case and no additional changes >>> >>> >>> > > > >>> >>> >>> > > > will be required for SR based networks >>> >>> >>> > > > >>> >>> >>> > > > The scenarios in which differentiation between =E2=80=9Ctop= ological=E2=80=9D >>> and >>> >>> >>> > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed = problematic. E.g., >>> >>> >>> > > consider >>> >>> >>> > > > the use case in which a Node SID in the ERO of a SR-TE path >>> >>> >>> > > identifies a >>> >>> >>> > > > node that acts as a firewall for all packets it receives, >>> i.e., >>> >>> >>> > > provides >>> >>> >>> > > > the firewall service without any dedicated service SID >>> >>> >>> > > identifying it. >>> >>> >>> > > > One could say that the Node SID of such a node would combine >>> >>> >>> > > topological >>> >>> >>> > > > and service instructions thus breaking the differentiation >>> >>> >>> > > between the two. >>> >>> >>> > > > >>> >>> >>> > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SI= Ds could be >>> prevented >>> >>> >>> > > or at >>> >>> >>> > > > least discouraged. >>> >>> >>> > > > >>> >>> >>> > > > If not, providing an ability to identify such SIDs in the >>> >>> >>> > > advertisement >>> >>> >>> > > > mechanisms would be useful IMHO. >>> >>> >>> > > > >>> >>> >>> > > > My 2c, >>> >>> >>> > > > >>> >>> >>> > > > Sasha >>> >>> >>> > > > >>> >>> >>> > > > Office: +972-39266302 >>> >>> >>> > > > >>> >>> >>> > > > Cell: +972-549266302 >>> >>> >>> > > > >>> >>> >>> > > > Email: Alexander.Vainshtein@ecitele.com >>> >>> >>> > >> > >>> >>> >>> > > >> > >>> >>> >>> > > > >>> >>> >>> > > > -----Original Message----- >>> >>> >>> > > > From: spring >> > >> >> >>> >>> >>> > >> On >>> Behalf Of Mach Chen >>> >>> >>> > > > Sent: Monday, August 3, 2020 6:30 AM >>> >>> >>> > > > To: Joel M. Halpern >> > >> >> >> >>; >>> >>> >>> > spring@ietf.org > < >>> mailto:spring@ietf.org > >>> >>> >>> > > > Subject: Re: [spring] Spring protection - determining >>> applicability >>> >>> >>> > > > >>> >>> >>> > > > Hi Joel, >>> >>> >>> > > > >>> >>> >>> > > > I think this is a good point that may not be discussed in th= e >>> >>> >>> > > past. And >>> >>> >>> > > > I also don't think there is a "can be bypassed" indication i= n >>> the >>> >>> >>> > > > routing advertisement for now. >>> >>> >>> > > > >>> >>> >>> > > > IMHO, the information advertised by routing is neutral, such >>> >>> >>> > > information >>> >>> >>> > > > (can or cannot be bypassed) is more path specific, thus >>> >>> >>> > normally the >>> >>> >>> > > > controller should be responsible for deciding whether/which >>> SID >>> >>> >>> > > can be >>> >>> >>> > > > bypassed. >>> >>> >>> > > > >>> >>> >>> > > > Best regards, >>> >>> >>> > > > >>> >>> >>> > > > Mach >>> >>> >>> > > > >>> >>> >>> > > > > -----Original Message----- >>> >>> >>> > > > >>> >>> >>> > > > > From: spring [mailto:spring-bounces@ietf.org >>> >>> >>> > > > >>> >>> >>> > < >>> mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.or= g%3e >>> >= ] >>> >>> >>> > On Behalf Of Joel M. >>> >>> >>> > > > >>> >>> >>> > > > > Halpern >>> >>> >>> > > > >>> >>> >>> > > > > Sent: Monday, August 3, 2020 7:51 AM >>> >>> >>> > > > >>> >>> >>> > > > > To: spring@ietf.org >> > >>> >>> >>> > > >>> >>> >>> > > >> > < >>> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org >>> >>> >>> >>> >>> > > > >>> >>> >>> > > > > Subject: [spring] Spring protection - determining >>> applicability >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > (WG Chair hat Off, this is merely a note from a slightly >>> >>> >>> > > confused WG >>> >>> >>> > > > >>> >>> >>> > > > > participant.) >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > I have been reading the various repair drafts, and the >>> various >>> >>> >>> > > > >>> >>> >>> > > > > networks programming and service programming draft, and I >>> am >>> >>> >>> > > trying to >>> >>> >>> > > > >>> >>> >>> > > > > figure out one aspect of the combination. >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > How does a node that is doing some form of bypass >>> (suppose, for >>> >>> >>> > > > >>> >>> >>> > > > > simplicity, it is Node N2 deciding to bypass the next SID >>> for >>> >>> >>> > > a failed >>> >>> >>> > > > >>> >>> >>> > > > > node N3) know that it is safe to do so? >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > If the path was just for TE, then it is "safe" if the new >>> path >>> >>> >>> > > meets >>> >>> >>> > > > >>> >>> >>> > > > > the TE criteria. or maybe it is safe if it is even close= , >>> as >>> >>> >>> > > long as >>> >>> >>> > > > >>> >>> >>> > > > > it is not used for too long. >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > But what if the node were a Firewall, included to meet >>> legal >>> >>> >>> > > > requirements? >>> >>> >>> > > > >>> >>> >>> > > > > Or was some other necessary programmatic transform (wince >>> we are >>> >>> >>> > > > >>> >>> >>> > > > > deliberately vague about what nodes can do when asked >>> suitably.) >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > Is there some "can be bypassed" indication in the routing >>> >>> >>> > > > >>> >>> >>> > > > > advertisements that I missed? >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > Thank you, >>> >>> >>> > > > >>> >>> >>> > > > > Yours, >>> >>> >>> > > > >>> >>> >>> > > > > Joel >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > > > _______________________________________________ >>> >>> >>> > > > >>> >>> >>> > > > > spring mailing list >>> >>> >>> > > > >>> >>> >>> > > > > spring@ietf..org >> > >>> >>> >>> > > >>> >>> >>> > > >> > < >>> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org >>> >>> >>> >>> >>> > > > >>> >>> >>> > > > > >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > >>> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%= 2 >>> >>> >>> >>> > < >>> https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiU= kzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYN= E8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24 >>> >>> > >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > < >>> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%= 252 >>> >>> >>> > < >>> https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2= F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUk= zW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FY= NE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24 >>> >> >>> >>> >>> > > > >>> >>> >>> > > > > F%2Fwww.ietf.org >>> >>> >>> > < >>> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk= %21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 >>> >>> > >>> >>> >>> > > < >>> https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2= F%2F2Fwww.ietf.org >>> >>> >>> > < >>> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk= %21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 >>> >>%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> > > > >>> >>> >>> > > > _______________________________________________ >>> >>> >>> > > > >>> >>> >>> > > > spring mailing list >>> >>> >>> > > > >>> >>> >>> > > > spring@ietf.org > >>> >>> >>> > > >> > >> >> >> >>> >>> >>> > > > >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > >>> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> > < >>> https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiU= kzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flis= tinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0= x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24 >>> >>> > >>> >>> >>> > > > >>> >>> >>> > > > >>> >>> >>> > > > >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > >>> -----------------------------------------------------------------------= - >>> >>> >>> > > > Notice: This e-mail together with any attachments may contai= n >>> >>> >>> > > > information of Ribbon Communications Inc. that is confidenti= al >>> >>> >>> > > and/or >>> >>> >>> > > > proprietary for the sole use of the intended recipient. Any >>> review, >>> >>> >>> > > > disclosure, reliance or distribution by others or forwarding >>> >>> >>> > without >>> >>> >>> > > > express permission is strictly prohibited. If you are not th= e >>> >>> >>> > > intended >>> >>> >>> > > > recipient, please notify the sender immediately and then >>> delete all >>> >>> >>> > > > copies, including any attachments. >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > >>> -----------------------------------------------------------------------= - >>> >>> >>> > > > >>> >>> >>> > > > _______________________________________________ >>> >>> >>> > > > spring mailing list >>> >>> >>> > > > spring@ietf.org > < >>> mailto:spring@ietf.org > >>> >>> >>> > > > >>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> > < >>> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2= Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpR= HOGt8AkTRDuiDo5KlPnbj%24 >>> >>> > >>> >>> >>> > > > >>> >>> >>> > > >>> >>> >>> > > _______________________________________________ >>> >>> >>> > > spring mailing list >>> >>> >>> > > spring@ietf.org > < >>> mailto:spring@ietf.org > >>> >>> >>> > > >>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> > < >>> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2= Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpR= HOGt8AkTRDuiDo5KlPnbj%24 >>> >>> > >>> >>> >>> > > >>> >>> >>> > >>> >>> >>> > _______________________________________________ >>> >>> >>> > spring mailing list >>> >>> >>> > spring@ietf.org > >>> >>> >>> > >>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> > >>> >>> >>> > >> >>> >>> > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org >>> %2Fmailman%2Flisti >>> >>> >>> > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqg= u >>> >>> >>> > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > ---------------------------------------------------------------------= - >>> >>> >>> > -- >>> >>> >>> > Notice: This e-mail together with any attachments may contain >>> >>> >>> > information of Ribbon Communications Inc. that is confidential and/or >>> >>> >>> > proprietary for the sole use of the intended recipient. Any review, >>> >>> >>> > disclosure, reliance or distribution by others or forwarding without >>> >>> >>> > express permission is strictly prohibited. If you are not the intende= d >>> >>> >>> > recipient, please notify the sender immediately and then delete all >>> >>> >>> > copies, including any attachments. >>> >>> >>> > ---------------------------------------------------------------------= - >>> >>> >>> > -- >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> >>> spring mailing list >>> >>> >>> spring@ietf.org >>> >>> >>> >>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> _______________________________________________ >>> >>> >>> spring mailing list >>> >>> >>> spring@ietf.org >>> >>> >>> >>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> >>> Notice: This e-mail together with any attachments may contain >>> information of Ribbon Communications Inc. that is confidential and/or >>> proprietary for the sole use of the intended recipient. Any review, >>> disclosure, reliance or distribution by others or forwarding without >>> express permission is strictly prohibited. If you are not the intended >>> recipient, please notify the sender immediately and then delete all cop= ies, >>> including any attachments. >>> >>> >>> >>> >>> ------------------------------ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> >>> spring mailing list >>> >>> >>> spring@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> spring mailing list >> >> spring@ietf.org >> >> https://www.ietf.org/mailman/listinfo/spring >> >> -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD > > --000000000000faa5aa05ad196840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Jeff,

    This is not about more state i= n the network nor about=C2=A0including mirror service node in the backup pa= th for some flows.=C2=A0

    The thread is about p= ossession of enough information in PLR to either take the packet and shift = it over backup path or just drop it.=C2=A0

    - - -

    Btw - path protection is completely orthogonal to t= he above.=C2=A0

    Cheers,
    Robert.

    <= /div>

    On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
    Gyan,

    TI-LFA computation is local to the PLR and is topology dependent, e.g chang= e in downstream topology could/would influence the choice of MP (PQ) node.<= br> While an implementation could take into consideration some additional meta-= data (e.g. locally provisioned SRLG, usually used to avoid protected and pr= otecting ports on the same line card), this is not a standardized method.= =C2=A0=C2=A0
    If a service node must be included in a backup path, there=E2=80=99s a stat= e associated with it as well as distribution of the state involved.=C2=A0
    Back to my point, removing state and introducing services in the network (a= t the very least at the computational logic and head-end level) are mutuall= y exclusive, trade-offs are inevitable (You can't eat your cake and hav= e it).
    Keeping the state limited to:
    - a logically centralized computational logic (aka PCE) - off path, scales = horizontally, could use additional business logic for the path computation,= example - CPU/memory consumption on a service node
    - head-end - anchor to primary/backup paths
    seems like a reasonable set of trade-offs.

    Cheers,
    Jeff
    On Aug 14, 2020, 7:44 PM -0700, Gyan Mish= ra <hayabusag= sm@gmail.com>, wrote:

    Catching up on this thread as it is a interesting topic a= s FRR 1:N link protection, node protection and path protection is critical = to operators.

    There are multiple somewhat orthogonal topics brought up = in the discussion.

    Excluding SR SFC from =E2=80=9Cbypass=E2=80=9D capable no= de such for appliances such as firewalls and load balancer.=C2=A0 Makes sen= se.=C2=A0 I would not think SFC would be in a PLR path to merger point but = I could be mistaken.

    The goal of SR is eliminating state and so having TE like= state is undesirable.=C2=A0

    Intent based instantiation of bypass via SR-TE from netwo= rk feedback at PLR detection node of a failure and make before break pre co= mputed backup paths that can. =C2=A0=C2=A0

    It would make sense that SR-TE binding SID policy would b= e appropriate for RSVP like FRR link node or path protection.

    My thoughts on this topic of SR protection is that don=E2= =80=99t we already have FRR protection natively without requiring SR-TE BSI= D or any additional undesirable state maintenance with TI-LFA.

    Thanks=C2=A0

    Gyan

    On Fri, Aug 14, 2020 at 5:47 PM Jeff = Tantsura <j= efftant.ietf@gmail.com> wrote:












    PCE computation in this case is trivial too(must traverse= node B or node X) else FAIL.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:44 PM -0700, Jeff Tant= sura <jefft= ant.ietf@gmail.com>, wrote:






    Robert,





    Agreed and apologies, hit send before finishing the email (it is Friday) ;-= )





    Path protection in this case make more sense and is much less complex,=C2= =A0


    if in the pathA (A->B->C) node B is a service node, it can=E2=80=99t = be bypassed (node protected) if the link between A and B breaks=C2=A0


    however it could have a backup pathB (A->X->C) where X is the service= node, potentially synchronizing its state with the node B.





    To my previous email - at expense of more state, we provide path and servic= e protection, hence the similarity with RSVP-TE trade-offs.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:30 PM -0700, Robert Ra= szuk <robert@rasz= uk.net>, wrote:




    Jeff,




    > This is very similar to RSVP-TE=C2=A0=C2=A0





    I would rather differ on that statement.=C2=A0





    See if you are using SR just for TE you are 100% right.=C2=A0





    But if your SIDs embed additional local SR node processing functions t= his suddenly=C2=A0becomes a completely different game. Let's keep this = in mind in this thread/topic.=C2=A0





    Kind regards,


    R.












    On Fri, Aug 14, 2020 at 11:15 PM Jeff= Tantsura <= jefftant.ietf@gmail.com> wrote:








    This is very similar to RSVP-TE, path vs link/node protec= tion and usually dictated by the business logic, the triggers are obviously= very different, head-end being notified of the failure on a path and switc= hing to the backup path vs reaction to a local failure, so same considerati= ons apply:=C2=A0


    -more state


    -pre-reserved resources


    while=C2=A0


    -predictable


    -meets SLA (as good as primary)


    vs


    -less state


    -local


    -best effort / can cause congestions=C2=A0







    Cheers,

    Jeff






    On Aug 14, 2020, 10:46 AM -0700, Ketan Ta= laulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>, wrote:






    Hi Robert,



    =C2=A0



    We do not have a signalling mechanism in IGPs = today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SID= s. If there was a desire for it, an IGP extension would be required (there = is none in progress AFAIK). Note that this results in doubling the prefix S= ID scale (global labels) in the network. So I would not go about this trivi= ally.



    =C2=A0



    I think it helps to get more inputs and perspe= ctives from operators on their views for doing a bypass via local protectio= n for segments in an SR Policy. There may be those that prefer end-to-end p= ath protection using a fallback path that is say disjoint with the primary = but provides an appropriate SLA/intent?



    =C2=A0



    Thanks,



    Ketan



    =C2=A0





    From: Robert Raszuk <robert@raszuk.net>


    Sent: 14 August 2020 23:04


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>





    =C2=A0





    Ketan,





    =C2=A0







    Looks like we are pretty much in sync here.=C2=A0





    =C2=A0







    But let me just observe that I purposely=C2=A0did no= t mention about SR policies as we are not able to signal the intent with th= e packets itself.=C2=A0







    =C2=A0







    So all we have there is SIDs. BSIDs or prefix SIDs n= eed to be flooded with information if policies build with using them are by= pass eligible or not.=C2=A0







    =C2=A0







    I was actually under the impression that this is alr= eady there and I am just not aware, but looking deeper indeed I do not see = this marking neither in ISIS nor OSPF for prefix SIDs.=C2=A0







    =C2=A0







    Is there some work in progress to add it to those pr= otocols or have we just documented need=C2=A0for a short LSR draft=C2=A0 ?= =C2=A0







    =C2=A0







    Thx,







    R.







    =C2=A0







    =C2=A0







    On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:











    Hi Robert,



    =C2=A0



    Please check inline below.



    =C2=A0





    From: Robert Raszuk <robert@raszuk.net>


    Sent: 14 August 2020 21:13


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>





    =C2=A0





    Hi Ketan,





    =C2=A0







    While I completely agree with your note the conseque= nces of it are pretty sevre.=C2=A0



    [KT] I understand. We need to be mindful of im= plications of protection schemes for the SLAs/intent of SR Policies.







    =C2=A0







    Unless we signal which prefix SID is protection elig= ible and which is not how would other nodes know if they can protect it or = not ?=C2=A0



    [KT] Correct. To be more accurate, we need to = consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR = Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for local = protection for some of those SR Policies. We also have path-protection mech= anisms.







    =C2=A0







    It seems that today's safe thing is not to apply= any node protection on SR flows at the PLRs then.=C2=A0







    =C2=A0







    And link protection MUST assure that packets will ar= rive at the neighbor node via some other link regardless of further path to= wards destination.=C2=A0



    [KT] Yes. We have a mechanism to indicate whic= h adj-SIDs have protection (that mechanism only provides link protection to= get to the neighbor node) so the SR Policy computation is able to indicate= whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its = choice of protected or unprotected adj-SIDs respectively.



    =C2=A0



    Thanks,



    Ketan







    =C2=A0







    Is it correct ?=C2=A0







    =C2=A0







    Thx







    R







    =C2=A0







    On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:











    Hi Sasha,



    =C2=A0



    The service node advertises its own Prefix SID.. The= service function that this service node implements does not require any co= ntext (i.e. all packets arriving at the node are subjected to that service)= . Therefore the service node does not need to receive a packet with it=E2= =80=99s own Prefix SID.



    =C2=A0



    Thus, we cannot assume that when PHP is used, then t= he SID is only associated with a topological instruction.



    =C2=A0



    Hope that clarifies?



    =C2=A0



    Thanks,



    Ketan



    =C2=A0







    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>


    Sent: 14 August 2020 20:24


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com &= lt;And= rew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>


    Cc: spring@ietf= .org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>







    =C2=A0



    Ketan, and all,



    I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs= that are advertised with PHP can=C2=A0 ONLY represent topological instruct= ions in SR-MPLS - because the advertising node will not receive them and th= erefore can hardly be expected to associate any service function with them.=



    =C2=A0



    This is complementary to what you have said.



    =C2=A0



    Hope this clarifies my position.



    What, if anything, did I miss?



    =C2=A0



    Regards,



    Sasha







    =C2=A0





    Get Outlook for Android









    =C2=A0











    From: Ketan Talaulikar (ketant) <ketant@cisco.com>


    Sent: Friday, August 14, 2020, 16:23


    To: = Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alston@liqu= idtelecom.com; Robert Raszuk


    Cc: = spring@ietf.org

    Subject: RE: [spring] Spring protection - determining applicability





    =C2=A0







    NOTICE: This email was received from an EXTERNAL sen= der







    =C2=A0





    Hi Sasha,



    =C2=A0



    If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don=E2=80=99t see why PHP could not be done for a Prefix SID associ= ated with a service node.



    =C2=A0



    Also, I didn=E2=80=99t follow the point that you wer= e trying to make about Adj-SIDs.



    =C2=A0



    Thanks,



    Ketan



    =C2=A0







    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>


    Sent: 14 August 2020 18:24


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha@juni= per.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidte= lecom.com>; Robert Raszuk <robert@raszuk.net>


    Cc: spring@ietf= .org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>







    =C2=A0



    Hi all,



    Regarding the statement "Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it":



    =C2=A0



    =C2=A0



    I think that in SR-MPLS a Node SID that is advertised with PHP a= citon can be safely considered as "just a topological instruction"= ; by the PLR because the originating node will not receive it.



    The same applies to Adj-SDIs.



    =C2=A0



    My 2c.







    =C2=A0





    Get O= utlook for Android









    =C2=A0











    From: spring <spring-bounces@ietf.org> on behalf of Ketan Ta= laulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>


    Sent: Friday, August 14, 2020, 15:00


    To: = Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@liqu= idtelecom.com; Robert Raszuk


    Cc: = spring@ietf.org

    Subject: Re: [spring] Spring protection - determining applicability





    =C2=A0





    Hi All,





    I would like to share a different perspective on this.





    First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].





    This is about local repair at a PLR. By it's very nature, the PLR does = not have a notion of how "strict or not" is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Polic= y headend and/or computation-node.





    We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) = to indicate whether a Prefix SID can be bypassed or not. This provides the = opportunity for the computation to use one or the other flavor depending on= the nature of the SLA for the SR Policy.





    I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".





    As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or = not.





    For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alte= rnate path using the path protection approach. This is something that is de= scribed and in use in deployments today [1]..





    Thanks,


    Ketan





    [1] https://clicktime.symantec.com/3Y3= fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-iet= f-spring-segment-routing-policy-08%23section-9


    [2] https://clicktime.symantec.com/3= 6fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-i= etf-spring-segment-routing-policy-08%23section-9.3





    -----Original Message-----


    From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern


    Sent: 04 August 2020 20:25


    To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <= robert@raszuk.net>


    Cc:     spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>


    Subject: Re: [spring] Spring protection - determining applicability





    There are, as far as I can tell, a number of ways to address this family of= related questions.


    What struck me, and prompted the starting question, was that none of them w= ere spelled out.=C2=A0 I see lots of interesting ideas / proposals.


    Some of them are compatible with others.=C2=A0=C2=A0 Some are not.


    It would be good if we could reach agreement on how we thought it should be= handled.





    Thank you,


    Joel





    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:


    > Hi all,


    >


    > I am still not sure that the problem of bypass going thru undesirable<= br>

    > links/nodes exists in the case of topological SIDs.


    >


    > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090


    > <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed


    > for many years before SR-MPLS has been introduced. What=E2=80=99s more= ,


    > signaling of bypass tunnels he PLR usually did not include any of the<= br>

    > constraints used for computing of any specific LSP that the bypass LSP=


    > would protect =E2=80=93 because in the Facility Protection mode the sa= me


    > bypass LSP would be used to protect multiple LSPs passing thru the


    > failed link/node.


    >


    >=C2=A0 From my POV the only difference between this behavior and that

    > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of


    > RSVP-TE, the operator would explicitly indicate, as part of LSP


    > signaling, whether it would or would not use FRR; LSPs that would not<= br>

    > use FRR would then drop traffic rather than delivering it the wrong wa= y.


    >


    > Such an option indeed does not exist in SR-TE today, but would be easy=


    > to provide if so desired IMHO.


    >


    > Did I miss something substantial?


    >


    > Regards, and lots of thanks in advance,


    >


    > Sasha


    >


    > Office: +972-39266302


    >


    > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302


    >


    > Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com


    >


    > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde

    > *Sent:* Tuesday, August 4, 2020 9:41 AM


    > *To:* EXT-Andrew.Alston@liquidtelecom.com


    > <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>


    > *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>


    > *Subject:* Re: [spring] Spring protection - determining applicability<= br>

    >


    > All,


    >


    > This is a very interesting discussion and thanks to Joel for starting<= br>

    > this discussion. IMO, when there are strict requirements of avoiding

    > certain nodes/links it can be realized=C2=A0 either by defining a flex= -algo


    > avoiding those


    >


    > Nodes and links or by using a stack of unprotected adj-sids that avoid=


    > restricted nodes and links. When a stack of adj-sids is used to


    > realize the path, the head-end based (sBFD) protection mechanisms can = be applied.


    >


    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the<= br>

    > failure events may cause traffic to go through restricted nodes and

    > links. This would happen regardless of whether any kind of protection<= br>

    > is in use or not.


    >


    > Rgds


    >


    > Shraddha


    >


    > Juniper Business Use Only


    >


    > *From:* spring <spring-bounces@ietf.org
     > <mailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston


    > *Sent:* Tuesday, August 4, 2020 5:41 AM


    > *To:* Robert Raszuk <    robert@raszuk.net <mailto:robert@raszuk.net>>


    > *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern


    > <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>


    > *Subject:* Re: [spring] Spring protection - determining applicability<= br>

    >


    > *[External Email. Be cautious of content]*


    >


    > Robert this is actually far more difficult when =E2=80=93 it can be an= entire


    > (long) series of nodes that need to be avoided.


    >


    > It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93


    > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t


    > be viable.


    >


    > It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things


    > to calculate paths =E2=80=93 the biggest trick is about the stack dept= h.=C2=A0 When


    > you have this need for node avoidance =E2=80=93 the need for 10+ label= depth


    > is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f


    > binding labels along the way which is a nightmare.


    >


    > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use


    > case that most of the people I discuss this with certain have =E2=80= =93 I cant


    > comment on a global scale, or for anyone else, but every indication I<= br>

    > have is that yes =E2=80=93 its something people need, and want


    >


    > Andrew


    >


    > *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>


    > *Sent:* Tuesday, 4 August 2020 01:27


    > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
     > &= lt;mai= lto:Andrew.Alston@liquidtelecom.com>>


    > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
     > <mailto:jmh@joelhalpern.com>>= ;; spring@ietf.org=


    > <mailto:spring= @ietf.org>


    > *Subject:* Re: [spring] Spring protection - determining applicability<= br>

    >


    > Is this a common use case ie.=C2=A0 "but rather =E2=80=93 which n= odes / network


    > segments it can never touch or flow through."


    >


    > If so perhaps its time to define notion of *negative-SID* ie. list in<= br>

    > the packet resources which given=C2=A0packet MUST not ever traverse.

    >


    > Put in the packet set of nodes or links which the packet should never<= br>

    > traverse.


    >


    > That goes in line of recent wave of negative routing implementations

    > (RIFT) or discussions (LSR)


    >


    > Best,


    > R.


    >


    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston


    > <Andrew.Alston@liquidtelecom.com
     > <mailto:Andrew.Alston@li= quidtelecom.com>> wrote:


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very major= use cases in any


    >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve around the fo= llowing


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain nodes


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain sections o= f the network


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that explicit av= oidance being violated


    >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say significa= nt problems.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case of which no= des the packets flow


    >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 which n= odes / network segments it can never


    >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effectively, to b= e used as a technology to


    >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific reasons.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for needing su= ch deep label stacks =E2=80=93


    >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming tends t= o deepen the stack


    >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pretty explic= it.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this func= tionality is there =E2=80=93


    >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations which could c= ause traffic to


    >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly avoided.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than this, but= it is what it is.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 *From:* spring <spring-bounces@ietf.org
     >= =C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> *On Behalf Of *Jo= el M. Halpern


    >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36


    >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=


    >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring@ietf..org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: [spring] Spring protection - de= termining


    > applicability


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long enough, reit= erating that this is as a


    >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.)


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that


    >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. For all sorts of reaso= ns.


    >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons why one= may not want a random


    >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. I think it = is important we be clear


    >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are violated w= hen we tell people they


    >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerouting) that is = intended to preserve QoS.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing that this= is not a good idea. It is a


    >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying to figure o= tu what combination of


    >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descriptions w= ill lead to everyone


    >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (which may no= t be the behavior they


    >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can do.)<= br>

    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Yours,


    >=C2=A0=C2=A0=C2=A0=C2=A0 Joel


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about IP netwo= rks=C2=A0here ? Or perhaps some hard


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reservat= ions or detnets ?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talking=C2= =A0about IP networking I have two


    >=C2=A0=C2=A0=C2=A0=C2=A0 observations:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via a sp= ecific node (ie. firewall) you


    >=C2=A0=C2=A0=C2=A0=C2=A0 better


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to that node= .. I don't think IP


    >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that destina= tion address of the packet is


    >=C2=A0=C2=A0=C2=A0=C2=A0 ignored.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP network whe= re upon topology change (link


    >=C2=A0=C2=A0=C2=A0=C2=A0 or node


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0start dr= opping=C2=A0flows in spite of SPT offering


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path with 10 = ms more jitter ?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing slides pro= mise to turn IP networks in


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new ? Worse ... do t= hey mention path quality guarantees,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0? I hope= not.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R.


    >=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
     >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.co= m%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SIDs, I am= not sure the problem is


    >=C2=A0=C2=A0=C2=A0=C2=A0 restricted


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has specified = the path to meet some complex te


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass node ha= s no way of knowing what those


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some kinds of t= raffic, it is better to drop the packet


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside the enve= lop.=C2=A0 I suspect that the right


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is "too bad"..=C2= =A0 If so, as with the distinction regarding


    >=C2=A0=C2=A0=C2=A0=C2=A0 service


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn= 9;t we?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most cases:

    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differentiati= on between "topological" and


    >=C2=A0=C2=A0=C2=A0=C2=A0 "service"


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID advertisem= ents. E.g.:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP advertisemen= ts) represent topological


    >=C2=A0=C2=A0=C2=A0=C2=A0 instructions


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services


    >=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 <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
     >=C2=A0= =C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3GC5af2z3JzphZDkPnc= HAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ie= tf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-g= k%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24= >>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent topo= logical instructions can be bypassed,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that represent = service instructions require


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be aligned = with RFC 8402


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3= B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDu= iDo0I4Ybtm%24>>


    >=C2=A0=C2=A0=C2=A0=C2=A0 that says in Section 1:


    >=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 In the cont= ext of an IGP-based distributed control plane, two


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the IGP-Adjacency segment and the


    >=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 IGP-Prefix = segment.


    >=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 In the cont= ext of a BGP-based distributed control plane, two


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the BGP peering segment and the


    >=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 BGP-Prefix = segment.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this di= fferentiation is assumed in Section


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for SR-TE = Path


    >=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 <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
     >=C2=A0=C2=A0= =C2=A0=C2=A0 <https://clicktime.s= ymantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv= 3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-nod= e-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>= ;


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft that says:


    >=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 The node pr= otection mechanism described in the previous


    >=C2=A0=C2=A0=C2=A0=C2=A0 sections


    >=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 depends on = the assumption that the label immediately below


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack is un= derstood in the IGP domain.=C2=A0 When the


    >=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 provider ed= ge routers exchange service labels via BGP or some


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other


    >=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 non-IGP mec= hanism the bottom label is not understood in the IGP


    >=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 domain.


    >=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 The egress = node protection mechanisms described in the draft


    >=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 [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
     >=C2=A0=C2=A0= =C2=A0=C2=A0 <https:= //clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F%2Furlde= fense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__= %3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTR= DuiDo8MGipXc%24>>]


    >=C2=A0=C2=A0=C2=A0=C2=A0 is


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use case an= d no additional changes


    >=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 will be req= uired for SR based networks


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2=A0d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a Node S= ID in the ERO of a SR-TE path


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firewall f= or all packets it receives, i.e.,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service without a= ny dedicated service SID


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the Node SI= D of such a node would combine


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus = breaking the differentiation


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ability t= o identify such SIDs in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMH= O.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein@ecitele= .com


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:Alexander.Vainshtein@ecitele.com>=


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:Alexander.Vainshtein@ecitele.= com>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > -----Original Message-----


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > From: spring <spring-bounces@ietf.org<= br> >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org%0b>>=


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2020 6= :30 AM


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern <jmh@joelhalpern.com >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern= .com>>;


    >=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: [spring] Spring p= rotection - determining applicability


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good point t= hat may not be discussed in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there i= s a "can be bypassed" indication in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now.=


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information advertis= ed by routing is neutral, such


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypassed) is= more path specific, thus


    >=C2=A0=C2=A0=C2=A0=C2=A0 normally the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be responsib= le for deciding whether/which SID


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Messa= ge-----


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > From: spring [mailt= o:spring-bounc= es@ietf.org


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring-bounces@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>]

    >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, Augus= t 3, 2020 7:51 AM


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
     >=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Subject: [spring] S= pring protection - determining applicability


    >=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 > (WG Chair hat Off, = this is merely a note from a slightly


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.)


    >=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 > I have been reading= the various repair drafts, and the various


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programmin= g and service programming draft, and I am


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspe= ct of the combination.


    >=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 > How does a node tha= t is doing some form of bypass (suppose, for


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is N= ode N2 deciding to bypass the next SID for


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know that = it is safe to do so?


    >=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 > If the path was jus= t for TE, then it is "safe" if the new path


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2= =A0 or maybe it is safe if it is even close, as


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used for = too long.


    >=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 > But what if the nod= e were a Firewall, included to meet legal


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other n= ecessary programmatic transform (wince we are


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague = about what nodes can do when asked suitably.)


    >=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 > Is there some "= ;can be bypassed" indication in the routing


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements that= I missed?


    >=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 > Thank you,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel


    >=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=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing list=


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring@ietf..org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
     >=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>


    >=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=A0 https://clicktim= e.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3= Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3= A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A= 2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo6HwPLil%24>


    >=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 <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
     &= gt;=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3A= 5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%= 2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A25= 2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDozoQiAHk%24>>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > F%2Fwww.ietf.org


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.s= ymantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv= 3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQA= tQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
     >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6= H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring


    >=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 > > spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org> <mailto:spring@ietf.org
     >=C2=A0=C2=A0= =C2=A0=C2=A0 <ma= ilto:spring@ietf.org%0b>> <mailto:spring@ietf.org>>


    >=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 https://clicktime.symantec.com/367qhU4KiUkzW9uG= C4eAvP46H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring=


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiR= nfMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sy= mantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.= org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>

    >=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=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0 ----------------------------------------------= --------------------------


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Notice: This e-mail together w= ith any attachments may contain


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Communic= ations Inc. that is confidential


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole use o= f the intended recipient. Any review,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distri= bution by others or forwarding


    >=C2=A0=C2=A0=C2=A0=C2=A0 without


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly= prohibited. If you are not the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify the s= ender immediately and then delete all


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attachme= nts.


    >=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=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symantec.com/= 3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dh= ttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Fli= stinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZ= Hgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >=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 > spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.com/3Q1xs= KGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2= Fspring


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dh= ttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Fli= stinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZ= Hgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >=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 spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMzNJCKyV= PByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring=


    >=C2=A0=C2=A0=C2=A0=C2=A0


    > <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
     > 2F%2Furldefense.com%2Fv3= %2F__https%3A%2Fwww.ie= tf.org%2Fmailman%2Flisti


    > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=


    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >


    >


    >


    > ----------------------------------------------------------------------=


    > --


    > Notice: This e-mail together with any attachments may contain


    > information of Ribbon Communications Inc. that is confidential and/or<= br>

    > proprietary for the sole use of the intended recipient. Any review,

    > disclosure, reliance or distribution by others or forwarding without

    > express permission is strictly prohibited. If you are not the intended=


    > recipient, please notify the sender immediately and then delete all

    > copies, including any attachments.


    > ----------------------------------------------------------------------=


    > --





    _______________________________________________


    spring mailing list


    spring@ietf.org

    h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring


    _______________________________________________


    spring mailing list


    spring@ietf.org

    h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring





    =C2=A0





    =C2=A0







    Notice: This e-mail together with any attachments may contain inform= ation of Ribbon Communications Inc. that is confidential and/or proprietary= for the sole use of the intended recipient. Any review, disclosure, relian= ce or distribution by others or forwarding without express permission is st= rictly prohibited. If you are not the intended recipient, please notify the= sender immediately and then delete all copies, including any attachments.<= /span>









    =C2=A0























    _______________________________________________


    spring mailing list


    spring@ietf.org

    = https://www.ietf.org/mailman/listinfo/spring






















    _______________________________________________

    spring mailing list

    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    --

    Gyan Mishra

    Network Solutions A<= /i>rchitect=C2=A0=

    M 301 502-1347
    13101 Columbia Pike=C2=A0
    Silver Spring, MD


    --000000000000faa5aa05ad196840-- From nobody Mon Aug 17 14:54:50 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8E3A124C for ; Mon, 17 Aug 2020 14:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, PDS_BTC_MSGID=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 m0hkBhry1zvw for ; Mon, 17 Aug 2020 14:54:38 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 6E2BA3A124D for ; Mon, 17 Aug 2020 14:54:38 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id l60so8453336pjb.3 for ; Mon, 17 Aug 2020 14:54:38 -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=kpllSTMh39ieHlJaXIe3OqNxoYSjJgF1OSsgcX/i2Pw=; b=q0vr8JTCaMIy2PM81bXW1BJt0hsPbzWC2EHX7BvnOOUybI6UO/Wkg5dy7yVEn8OzB3 gMAbwzgNtbfMCw6GaikyztQOU+2dbvh5zNezLrPYnHYyDCGw6HrVmlI2+SnwY9WEBDnx tLdMtaIwqMwemBVGSVeNuaccob/l7fd081/9pQb3yiRN+ZYt2HfNNGn0fRYRCDwkd9Vu +ZYJbMnqxV6wVV4E7sKj60QaHRTMzHlVfrvT8//XsfuKJxhayosVEBrOZnqDOrcZJ1rE Oocph9gql1FPtiCxqF75nuz11n7esxxrPLxrb5eQNEXx+LEXokMhYpf+YSWIHeSxRvTG NKxA== 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=kpllSTMh39ieHlJaXIe3OqNxoYSjJgF1OSsgcX/i2Pw=; b=jG1aEVsOSfLsENbZy4IxOk5LOpV6LcwC+9W5Hd8ZZSeQMS9sdVnFOssNFRHY2yufF+ WqHLbNwLZu4aBCGZVEVii0h+yTKLNedD1isMj4dCqkHfI8LdxfsvD9nizMCpvstNcW5r rvYu70Pxnm3ZvmZdNzMRqpXZpdJm8BXfZl7DEjb2DXCIK2fRhdATgSrniI9KoETTT28P D8kPAFkTEmuuBeAXjoxdpO2NlIuaRuhhz/sqtsw+JrkoJQxIom+MZddnVxehBGsMD2Bv rZfhAxkyx/iLGvm2WyX4ZLMN5+ckao+qjQ9Ttw8IFZEXlMTU5Jgi9cw3V9eEzrUzmJ7K K02g== X-Gm-Message-State: AOAM531Xfx1n3h0fuPPQp9Ylw0EdlDZpgfukA2P9GRC2KIyI8nbQA4TL Ee5/t98MW0A4UpbsTNTb1og= X-Google-Smtp-Source: ABdhPJxMUqIMcgPppLcWRM2tNv8+tx4vamFrJ9O/6flAi76TdaqywG5ZtNt86wHziuDqNOZHlQt/zA== X-Received: by 2002:a17:90a:34c4:: with SMTP id m4mr13803670pjf.222.1597701277519; Mon, 17 Aug 2020 14:54:37 -0700 (PDT) Received: from [192.168.1.3] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id f18sm21229161pfj.35.2020.08.17.14.54.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 14:54:36 -0700 (PDT) Date: Mon, 17 Aug 2020 14:54:27 -0700 From: Jeff Tantsura To: Robert Raszuk Cc: Gyan Mishra , Alexander Vainshtein , "=?utf-8?Q?EXT-Andrew.Alston=40liquidtelecom.com?=" , "Joel M. Halpern" , "Ketan Talaulikar (ketant)" , Shraddha Hegde , "=?utf-8?Q?spring=40ietf.org?=" Message-ID: <8940cdc0-9c51-46a4-8ddc-79df170c433f@Spark> In-Reply-To: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> <7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark> X-Readdle-Message-ID: 8940cdc0-9c51-46a4-8ddc-79df170c433f@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f3afc99_66ef438d_65d7" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 21:54:49 -0000 --5f3afc99_66ef438d_65d7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Robert, =22possession of enough information in PLR=E2=80=9D what do you call this= , if not more state, given this information is not present there today=3F= Cheers, Jeff On Aug 17, 2020, 2:25 PM -0700, Robert Raszuk , wrot= e: > Hi Jeff, > > This is not about more state in the network nor about=C2=A0including mi= rror service node in the backup path for some flows. > > The thread is about possession of enough information in PLR to either t= ake the packet and shift it over backup path or just drop it. > > - - - > > Btw - path protection is completely orthogonal to the above. > > Cheers, > Robert. > > > > On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura wrote: > > > Gyan, > > > > > > TI-L=46A computation is local to the PLR and is topology dependent,= e.g change in downstream topology could/would influence the choice of MP= (PQ) node. > > > While an implementation could take into consideration some addition= al meta-data (e.g. locally provisioned SRLG, usually used to avoid protec= ted and protecting ports on the same line card), this is not a standardiz= ed method. > > > If a service node must be included in a backup path, there=E2=80=99= s a state associated with it as well as distribution of the state involve= d. > > > > > > Back to my point, removing state and introducing services in the ne= twork (at the very least at the computational logic and head-end level) a= re mutually exclusive, trade-offs are inevitable (You can't eat your cake= and have it). > > > Keeping the state limited to: > > > - a logically centralized computational logic (aka PCE) - off path,= scales horizontally, could use additional business logic for the path co= mputation, example - CPU/memory consumption on a service node > > > - head-end - anchor to primary/backup paths > > > seems like a reasonable set of trade-offs. > > > > > > Cheers, > > > Jeff > > > On Aug 14, 2020, 7:44 PM -0700, Gyan Mishra , wrote: > > > > > > > > Catching up on this thread as it is a interesting topic as =46RR = 1:N link protection, node protection and path protection is critical to o= perators. > > > > > > > > There are multiple somewhat orthogonal topics brought up in the d= iscussion. > > > > > > > > Excluding SR S=46C from =E2=80=9Cbypass=E2=80=9D capable node suc= h for appliances such as firewalls and load balancer.=C2=A0 Makes sense.=C2= =A0 I would not think S=46C would be in a PLR path to merger point but I = could be mistaken. > > > > > > > > The goal of SR is eliminating state and so having TE like state i= s undesirable. > > > > > > > > Intent based instantiation of bypass via SR-TE from network feedb= ack at PLR detection node of a failure and make before break pre computed= backup paths that can. > > > > > > > > It would make sense that SR-TE binding SID policy would be approp= riate for RSVP like =46RR link node or path protection. > > > > > > > > My thoughts on this topic of SR protection is that don=E2=80=99t = we already have =46RR protection natively without requiring SR-TE BSID or= any additional undesirable state maintenance with TI-L=46A. > > > > > > > > Thanks > > > > > > > > Gyan > > > > > > > > > On =46ri, Aug 14, 2020 at 5:47 PM Jeff Tantsura wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PCE computation in this case is trivial too(must traverse nod= e B or node X) else =46AIL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Agreed and apologies, hit send before finishing the email (= it is =46riday) ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Path protection in this case make more sense and is much le= ss complex, > > > > > > > > > > > > > > > > > > > > > if in the pathA (A->B->C) node B is a service node, it can=E2= =80=99t be bypassed (node protected) if the link between A and B breaks > > > > > > > > > > > > > > > > > > > > > however it could have a backup pathB (A->X->C) where X is t= he service node, potentially synchronizing its state with the node B. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To my previous email - at expense of more state, we provide= path and service protection, hence the similarity with RSVP-TE trade-off= s. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jeff, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very similar to RSVP-TE > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would rather differ on that statement. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See if you are using SR just for TE you are 100% right. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if your SIDs embed additional local SR node processin= g functions this suddenly=C2=A0becomes a completely different game. Let's= keep this in mind in this thread/topic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 11:15 PM Jeff Tantsura wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very similar to RSVP-TE, path vs link/node pr= otection and usually dictated by the business logic, the triggers are obv= iously very different, head-end being notified of the failure on a path a= nd switching to the backup path vs reaction to a local failure, so same c= onsiderations apply: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -more state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -pre-reserved resources > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > while > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -predictable > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -meets SLA (as good as primary) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > vs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -less state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -local > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -best effort / can cause congestions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ke= tant) , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We do not have a signalling mechanism in IGPs today= to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. = If there was a desire for it, an IGP extension would be required (there i= s none in progress A=46AIK). Note that this results in doubling the prefi= x SID scale (global labels) in the network. So I would not go about this = trivially. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it helps to get more inputs and perspective= s from operators on their views for doing a bypass via local protection f= or segments in an SR Policy. There may be those that prefer end-to-end pa= th protection using a fallback path that is say disjoint with the primary= but provides an appropriate SLA/intent=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 23:04 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - deter= mining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Looks like we are pretty much in sync here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But let me just observe that I purposely=C2=A0did n= ot mention about SR policies as we are not able to signal the intent with= the packets itself. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So all we have there is SIDs. BSIDs or prefix SIDs = need to be flooded with information if policies build with using them are= bypass eligible or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was actually under the impression that this is al= ready there and I am just not aware, but looking deeper indeed I do not s= ee this marking neither in ISIS nor OSP=46 for prefix SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there some work in progress to add it to those p= rotocols or have we just documented need=C2=A0for a short LSR draft=C2=A0= =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thx, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar = (ketant) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check inline below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 21:13 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - det= ermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ketan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I completely agree with your note the conse= quences of it are pretty sevre. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D I understand. We need to be mindful of i= mplications of protection schemes for the SLAs/intent of SR Policies. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Unless we signal which prefix SID is protection e= ligible and which is not how would other nodes know if they can protect i= t or not =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D Correct. To be more accurate, we need to= consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of = SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for l= ocal protection for some of those SR Policies. We also have path-protecti= on mechanisms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems that today's safe thing is not to apply = any node protection on SR flows at the PLRs then. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And link protection MUST assure that packets will= arrive at the neighbor node via some other link regardless of further pa= th towards destination. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D Yes. We have a mechanism to indicate whi= ch adj-SIDs have protection (that mechanism only provides link protection= to get to the neighbor node) so the SR Policy computation is able to ind= icate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not = by its choice of protected or unprotected adj-SIDs respectively. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is it correct =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thx > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaulika= r (ketant) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The service node advertises its own Prefix SID.= . The service function that this service node implements does not require= any context (i.e. all packets arriving at the node are subjected to that= service). Therefore the service node does not need to receive a packet w= ith it=E2=80=99s own Prefix SID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thus, we cannot assume that when PHP is used, t= hen the SID is only associated with a topological instruction. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope that clarifies=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 20:24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - d= etermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan, and all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have stated that, IMHO and =46WIW, both Adj-S= IDs and Prefix SIDs that are advertised with PHP can=C2=A0 ONLY represent= topological instructions in SR-MPLS - because the advertising node will = not receive them and therefore can hardly be expected to associate any se= rvice function with them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is complementary to what you have said. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope this clarifies my position. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What, if anything, did I miss=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: =46riday, August 14, 2020, 16:23 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Alexander Vainshtein; Joel M. Halpern; Shra= ddha Hegde; EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: RE: =5Bspring=5D Spring protection - d= etermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NOTICE: This email was received from an EXTERNA= L sender > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the service does not need any additional con= text (e.g. a firewall that just applies locally configured default rules = on it), then I don=E2=80=99t see why PHP could not be done for a Prefix S= ID associated with a service node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, I didn=E2=80=99t follow the point that yo= u were trying to make about Adj-SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 18:24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) ; Joel M. Halpern ; Alexander Vainshtein ; Shraddha Hegde ; EXT= -Andrew.Alston=40liquidtelecom.com ; R= obert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - d= etermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding the statement =22Prefix SID could be = just a topological instruction or may also be used to steer the flow to a= node which is applying a service function to it=22: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think that in SR-MPLS a Node SID that is adve= rtised with PHP aciton can be safely considered as =22just a topological = instruction=22 by the PLR because the originating node will not receive i= t. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The same applies to Adj-SDIs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My 2c. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: spring on b= ehalf of Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: =46riday, August 14, 2020, 15:00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Joel M. Halpern; Alexander Vainshtein; Shra= ddha Hegde; EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - d= etermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to share a different perspective o= n this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46irst, thanks to Joel for bringing up the dis= cussion. Clearly we need a well-defined applicability statement for deter= mining applicability of protection for segment used in an SR Policy. Some= of this is captured in =5B1=5D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is about local repair at a PLR. By it's ve= ry nature, the PLR does not have a notion of how =22strict or not=22 is t= he SLA that is being provided by the SR Policy. Awareness of that notion = exists at the SR Policy headend and/or computation-node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have protected and un-protected variants of = adjacency SIDs to enable the computation to pick or the other based on th= e =22strictness=22 of the SLA requirement for picking that link. We do no= t have such a notion for Prefix SIDs. One can say that we could introduce= signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypas= sed or not. This provides the opportunity for the computation to use one = or the other flavor depending on the nature of the SLA for the SR Policy.= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a problem and a concern in the assumptio= n that PLRs can assume that the currently defined variant of Prefix SIDs = in R=46C8402 (and IGP specs) are =22bypass-able=22. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As Joel and others have brought out, the Prefix= SID could be just a topological instruction or may also be used to steer= the flow to a node which is applying a service function to it. In order = to support a mix of SR Policies of different SLAs (strict and not-strict)= , we need to enable the choice of SIDs that indicates to the PLR whether = they are =22bypass-able=22 or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46or the cases, where the SR Policy has a spec= ific SLA, it is required for nodes to drop the packets meant for the =22a= ctive segment=22 than to bypass it. When this mechanism is used along sid= e SRTE path monitoring mechanisms, it enables the headend to detect the f= ailure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today =5B= 1=5D.. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5B1=5D https://clicktime.symantec.com/3Y3fWuN=46= YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46dr= aft-ietf-spring-segment-routing-policy-08%23section-9 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5B2=5D https://clicktime.symantec.com/36fCMrgm= EewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46dr= aft-ietf-spring-segment-routing-policy-08%23section-9.3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: spring On B= ehalf Of Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 04 August 2020 20:25 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Alexander Vainshtein ; Shraddha Hegde ; EX= T-Andrew.Alston=40liquidtelecom.com ; = Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org; Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection - d= etermining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are, as far as I can tell, a number of wa= ys to address this family of related questions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What struck me, and prompted the starting quest= ion, was that none of them were spelled out.=C2=A0 I see lots of interest= ing ideas / proposals. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some of them are compatible with others.=C2=A0=C2= =A0 Some are not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It would be good if we could reach agreement on= how we thought it should be handled. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote= : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am still not sure that the problem of bypas= s going thru undesirable > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > links/nodes exists in the case of topological= SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A=46AIK, =46acility Protection in RSVP-TE =46= RR (R=46C 4090 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > = ) has been successfully deployed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > for many years before SR-MPLS has been introd= uced. What=E2=80=99s more, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > signaling of bypass tunnels he PLR usually di= d not include any of the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > constraints used for computing of any specifi= c LSP that the bypass LSP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > would protect =E2=80=93 because in the =46aci= lity Protection mode the same > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > bypass LSP would be used to protect multiple = LSPs passing thru the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > failed link/node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =46rom my POV the only difference betwe= en this behavior and that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > introduced by the =E2=80=9Cbypassing=E2=80=9D= drafts in SR is that, in the case of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RSVP-TE, the operator would explicitly indica= te, as part of LSP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > signaling, whether it would or would not use = =46RR; LSPs that would not > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > use =46RR would then drop traffic rather than= delivering it the wrong way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Such an option indeed does not exist in SR-TE= today, but would be easy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to provide if so desired IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Did I miss something substantial=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, and lots of thanks in advance, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Office: +972-39266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-5492= 66302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Email:=C2=A0=C2=A0 Alexander.Vainshtein=40eci= tele.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* spring = *On Behalf Of *Shraddha Hegde > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* EXT-Andrew.Alston=40liquidtelecom.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ; Robert R= aszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* spring=40ietf.org; Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection= - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a very interesting discussion and tha= nks to Joel for starting > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > this discussion. IMO, when there are strict r= equirements of avoiding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > certain nodes/links it can be realized=C2=A0 = either by defining a flex-algo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > avoiding those > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nodes and links or by using a stack of unprot= ected adj-sids that avoid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > restricted nodes and links. When a stack of a= dj-sids is used to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > realize the path, the head-end based (sB=46D)= protection mechanisms can be applied. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If Node-sids/prefix-sid/anycast-sids are used= to build the stack, the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > failure events may cause traffic to go throug= h restricted nodes and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > links. This would happen regardless of whethe= r any kind of protection > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is in use or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rgds > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shraddha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* spring > > > > > > > > > > > > > > *On Behal= f Of *Andrew Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* spring=40ietf.org ; Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection= - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=5BExternal Email. Be cautious of content=5D= * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robert this is actually far more difficult wh= en =E2=80=93 it can be an entire > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (long) series of nodes that need to be avoide= d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It could potentially be made to work but I=E2= =80=99d worry that to do this =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2= =80=93 30 negative labels =E2=80=93 and that wouldn=E2=80=99t > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > be viable. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It=E2=80=99s easier to use algorithms and adj= acency sids and other such things > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to calculate paths =E2=80=93 the biggest tric= k is about the stack depth.=C2=A0 When > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you have this need for node avoidance =E2=80=93= the need for 10+ label depth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is critical =E2=80=93 unless you wanna be app= lying one hell of a lot of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > binding labels along the way which is a night= mare. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But to answer your question, is this a common= use case =E2=80=93 it=E2=80=99s a use > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > case that most of the people I discuss this w= ith certain have =E2=80=93 I cant > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > comment on a global scale, or for anyone else= , but every indication I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > have is that yes =E2=80=93 its something peop= le need, and want > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, 4 August 2020 01:27 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* Andrew Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* Joel M. Halpern > > > > > > > > > > > > > >; spring=40iet= f.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring protection= - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is this a common use case ie.=C2=A0 =22but ra= ther =E2=80=93 which nodes / network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > segments it can never touch or flow through.=22= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If so perhaps its time to define notion of *n= egative-SID* ie. list in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the packet resources which given=C2=A0packet = MUST not ever traverse. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Put in the packet set of nodes or links which= the packet should never > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > traverse. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That goes in line of recent wave of negative = routing implementations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (RI=46T) or discussions (LSR) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > w= rote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases,= in fact, some very major use cases in any > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for= us revolve around the following > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoida= nce of certain nodes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoida= nce of certain sections of the network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could r= esult in that explicit avoidance being violated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would creat= e, shall we say significant problems. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case = is not a case of which nodes the packets flow > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but= rather =E2=80=93 which nodes / network segments it can never > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through= .=C2=A0 Effectively, to be used as a technology to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things = for specific reasons. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of t= he reasons for needing such deep label stacks =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed= path programming tends to deepen the stack > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes= have to be pretty explicit. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely crit= ical to us that this functionality is there =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid= situations which could cause traffic to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things= explicitly avoided. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be mor= e specific than this, but it is what it is. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *=46rom:* spring > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > *On Behalf Of *Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 Aug= ust 2020 21:36 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk <= robert=40raszuk.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring=40ietf..= org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: =5Bspr= ing=5D Spring protection - determining > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has= gotten long enough, reiterating that this is as a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG= chair.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking I= P networks. And yes, I have seen IP networks that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packet= s. =46or all sorts of reasons. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are lik= ely other reasons why one may not want a random > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a ch= osen TE path. I think it is important we be clear > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraint= s may be / are violated when we tell people they > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (prote= ctive rerouting) that is intended to preserve QoS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am = not arguing that this is not a good idea. It is a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful= . I am trying to figure otu what combination of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms= and clear descriptions will lead to everyone > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior = they expect (which may not be the behavior they > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes= is the best we can do.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, = Robert Raszuk wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still = talking about IP networks=C2=A0here =3F Or perhaps some hard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with = real resource reservations or detnets =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0= if we are talking=C2=A0about IP networking I have two > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 observations: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you nee= d to traverse via a specific node (ie. firewall) you > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 better > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP enca= psulation to that node.. I don't think IP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0ca= n > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked t= oday such that destination address of the packet is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 ignored. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you s= een any IP network where upon topology change (link > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 or node > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you = suddenly=C2=A0start dropping=C2=A0flows in spite of SPT offering > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few m= s longer path with 10 ms more jitter =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some S= R marketing slides promise to turn IP networks in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0= new =3F Worse ... do they mention path quality guarantees, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource rese= rvations=C2=A0=3F I hope not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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=A0=C2=A0 > On Mon, Aug 3= , 2020 at 8:10 PM Joel M. Halpern > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less ser= ious for TE SIDs, I am not sure the problem is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 restricted > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just servi= ce SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that = the PCE has specified the path to meet some complex te > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2= =A0 The bypass node has no way of knowing what those > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 A= nd for some kinds of traffic, it is better to drop the packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliv= er it outside the envelop.=C2=A0 I suspect that the right > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is =22= too bad=22..=C2=A0 If so, as with the distinction regarding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 service > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we sho= uld say so, shouldn't we=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2= :36 AM, Alexander Vainshtein wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel = and all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think tha= t in most cases: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is = clear differentiation between =22topological=22 and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =22service=22 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instruction= s in SID advertisements. E.g.: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix= Node SIDs IGP Adj-SIDs (identified as such in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > correspondi= ng IGP advertisements) represent topological > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 instructions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SI= Ds for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft) unsu= rprisingly represent =E2=80=9Cservice=E2=80=9D instructions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments = that represent topological instructions can be bypassed, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segme= nts that represent service instructions require > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection = mechanisms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view s= eems to be aligned with R=46C 8402 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 that says in Section = 1: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 In the context of an IGP-based distributed control plane, two > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological= segments are defined: the IGP-Adjacency segment and the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 IGP-Prefix segment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 In the context of a BGP-based distributed control plane, two > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological= segments are defined: the BGP peering segment and the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 BGP-Prefix segment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case= of SR-MPLS this differentiation is assumed in Section > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Pr= otection for SR-TE Path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft that = says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 The node protection mechanism described in the previous > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 sections > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 depends on the assumption that the label immediately below > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in th= e label stack is understood in the IGP domain.=C2=A0 When the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 provider edge routers exchange service labels via BGP or some > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 non-IGP mechanism the bottom label is not understood in the IGP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 domain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 The egress node protection mechanisms described in the draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 =5BR=46C8679 > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 >=5D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable = to this use case and no additional changes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 will be required for SR based networks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenari= os in which =C2=A0differentiation between =E2=80=9Ctopological=E2=80=9D a= nd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cse= rvice=E2=80=9D instructions is broken are indeed problematic. E.g., > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use cas= e in which a Node SID in the ERO of a SR-TE path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that a= cts as a firewall for all packets it receives, i.e., > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewal= l service without any dedicated service SID > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying i= t. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could s= ay that the Node SID of such a node would combine > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service= instructions thus breaking the differentiation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the t= wo. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not su= re if usage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least disco= uraged. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, pro= viding an ability to identify such SIDs in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms = would be useful IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +97= 2-39266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alex= ander.Vainshtein=40ecitele.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > > -----Origin= al Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =46rom: spr= ing > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > On Behalf Of Mach Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monda= y, August 3, 2020 6:30 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M.= Halpern > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > >; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re= : =5Bspring=5D Spring protection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think thi= s is a good point that may not be discussed in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don'= t think there is a =22can be bypassed=22 indication in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing adv= ertisement for now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the i= nformation advertised by routing is neutral, such > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or can= not be bypassed) is more path specific, thus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 normally the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller = should be responsible for deciding whether/which SID > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regard= s, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > ---= --Original Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46= rom: spring =5Bmailto:spring-bounces=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =5D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Hal= pern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sen= t: Monday, August 3, 2020 7:51 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To:= spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > Sub= ject: =5Bspring=5D Spring protection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > (WG= Chair hat Off, this is merely a note from a slightly > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > par= ticipant.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > I h= ave been reading the various repair drafts, and the various > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > net= works programming and service programming draft, and I am > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > fig= ure out one aspect of the combination. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > How= does a node that is doing some form of bypass (suppose, for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > sim= plicity, it is Node N2 deciding to bypass the next SID for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > nod= e N3) know that it is safe to do so=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > If = the path was just for TE, then it is =22safe=22 if the new path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the= TE criteria.=C2=A0 or maybe it is safe if it is even close, as > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it = is not used for too long. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > But= what if the node were a =46irewall, included to meet legal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirement= s=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or = was some other necessary programmatic transform (wince we are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > del= iberately vague about what nodes can do when asked suitably.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > Is = there some =22can be bypassed=22 indication in the routing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > adv= ertisements that I missed=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > Tha= nk you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > You= rs, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joe= l > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spr= ing mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spr= ing=40ietf..org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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 https://clicktime.sym= antec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > =46= %2=46www.ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 >%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mail= ing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ie= tf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0 https://clicktime.sym= antec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org= %2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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 > > Notice: Thi= s e-mail together with any attachments may contain > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information= of Ribbon Communications Inc. that is confidential > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary= for the sole use of the intended recipient. Any review, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure,= reliance or distribution by others or forwarding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 without > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express per= mission is strictly prohibited. If you are not the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, = please notify the sender immediately and then delete all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, inc= luding any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mail= ing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring=40ie= tf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://cli= cktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring mailin= g list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring=40ietf= .org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://click= time.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.= ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.sym= antec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org= %2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttp= s%3A%2=46www.ietf.org%2=46mailman%2=46listi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0= Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqgu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------= ------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any attachm= ents may contain > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > information of Ribbon Communications Inc. tha= t is confidential and/or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > proprietary for the sole use of the intended = recipient. Any review, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > disclosure, reliance or distribution by other= s or forwarding without > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > express permission is strictly prohibited. If= you are not the intended > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > recipient, please notify the sender immediate= ly and then delete all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > copies, including any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------= ------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyV= PByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%= 2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyV= PByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%= 2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any attachmen= ts may contain information of Ribbon Communications Inc. that is confiden= tial and/or proprietary for the sole use of the intended recipient. Any r= eview, disclosure, reliance or distribution by others or forwarding witho= ut express permission is strictly prohibited. If you are not the intended= recipient, please notify the sender immediately and then delete all copi= es, including any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > -- > > > > > > > > Gyan Mishra > > > > Network Solutions Architect > > > > M 301 502-1347 > > > > 13101 Columbia Pike > > > > Silver Spring, MD > > > > --5f3afc99_66ef438d_65d7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    Hi Robert,

    =22possession of enough information in PLR=E2=80=9D what do you call this= , if not more state, given this information is not present there today=3F=

    Cheers,
    Jeff
    On Aug 17, 2020, 2:25 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:
    Hi Jeff,

    This is not about more state in the network nor about&=23160;includi= ng mirror service node in the backup path for some flows.&=23160;

    The thread is about possession of enough information in PLR to eithe= r take the packet and shift it over backup path or just drop it.&=23160;<= /div>

    - - -

    Btw - path protection is completely orthogonal to the above.&=23160;=

    Cheers,
    Robert.


    On Mon, Aug 17, 2020 at 1= 1:03 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:
    Gyan,

    TI-L=46A computation is local to the PLR and is topology dependent, e.g c= hange in downstream topology could/would influence the choice of MP (PQ) = node.
    While an implementation could take into consideration some additional met= a-data (e.g. locally provisioned SRLG, usually used to avoid protected an= d protecting ports on the same line card), this is not a standardized met= hod.&=23160;&=23160;
    If a service node must be included in a backup path, there=E2=80=99s a st= ate associated with it as well as distribution of the state involved.&=23= 160;

    Back to my point, removing state and introducing services in the network = (at the very least at the computational logic and head-end level) are mut= ually exclusive, trade-offs are inevitable (You can't eat your cake and h= ave it).
    Keeping the state limited to:
    - a logically centralized computational logic (aka PCE) - off path, scale= s horizontally, could use additional business logic for the path computat= ion, example - CPU/memory consumption on a service node
    - head-end - anchor to primary/backup paths
    seems like a reasonable set of trade-offs.

    Cheers,
    Jeff
    On Aug 14, 2020, 7:44 PM -0700, Gya= n Mishra <hayabusagsm=40gmail.com>, wrote:

    Catching up on this thread as it is a interesting t= opic as =46RR 1:N link protection, node protection and path protection is= critical to operators.

    There are multiple somewhat orthogonal topics broug= ht up in the discussion.

    Excluding SR S=46C from =E2=80=9Cbypass=E2=80=9D ca= pable node such for appliances such as firewalls and load balancer.&=2316= 0; Makes sense.&=23160; I would not think S=46C would be in a PLR path to= merger point but I could be mistaken.

    The goal of SR is eliminating state and so having T= E like state is undesirable.&=23160;

    Intent based instantiation of bypass via SR-TE from= network feedback at PLR detection node of a failure and make before brea= k pre computed backup paths that can. &=23160;&=23160;

    It would make sense that SR-TE binding SID policy w= ould be appropriate for RSVP like =46RR link node or path protection.

    My thoughts on this topic of SR protection is that = don=E2=80=99t we already have =46RR protection natively without requiring= SR-TE BSID or any additional undesirable state maintenance with TI-L=46A= .

    Thanks&=23160;

    Gyan

    On =46ri, Aug 14, 2020 at= 5:47 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:












    PCE computation in this case is trivial too(must tr= averse node B or node X) else =46AIL.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:44 PM -0700, Jef= f Tantsura <jefftant.ietf=40gmail.com>, wrote:






    Robert,





    Agreed and apologies, hit send before finishing the email (it is =46riday= ) ;-)





    Path protection in this case make more sense and is much less complex,&=23= 160;


    if in the pathA (A->B->C) node B is a service node, it can=E2=80=99= t be bypassed (node protected) if the link between A and B breaks&=23160;=


    however it could have a backup pathB (A->X->C) where X is the servi= ce node, potentially synchronizing its state with the node B.





    To my previous email - at expense of more state, we provide path and serv= ice protection, hence the similarity with RSVP-TE trade-offs.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:30 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:




    Jeff,




    > This is very similar to RSVP-TE&=23160;&=23160;





    I would rather differ on that statement.&=23160;





    See if you are using SR just for TE you are 100% right.&=23160;




    But if your SIDs embed additional local SR node processing functions= this suddenly&=23160;becomes a completely different game. Let's keep thi= s in mind in this thread/topic.&=23160;





    Kind regards,


    R.












    On =46ri, Aug 14, 2020 at= 11:15 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:








    This is very similar to RSVP-TE, path vs link/node = protection and usually dictated by the business logic, the triggers are o= bviously very different, head-end being notified of the failure on a path= and switching to the backup path vs reaction to a local failure, so same= considerations apply:&=23160;


    -more state


    -pre-reserved resources


    while&=23160;


    -predictable


    -meets SLA (as good as primary)


    vs


    -less state


    -local


    -best effort / can cause congestions&=23160;







    Cheers,

    Jeff






    On Aug 14, 2020, 10:46 AM -0700, Ke= tan Talaulikar (ketant) <ketant=3D40cisco.com=40dmarc.ietf.org&= gt;, wrote:






    Hi Robert,



    &=23160;



    We do not have a signalling mechanism in= IGPs today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Pr= efix SIDs. If there was a desire for it, an IGP extension would be requir= ed (there is none in progress A=46AIK). Note that this results in doublin= g the prefix SID scale (global labels) in the network. So I would not go = about this trivially.



    &=23160;



    I think it helps to get more inputs and = perspectives from operators on their views for doing a bypass via local p= rotection for segments in an SR Policy. There may be those that prefer en= d-to-end path protection using a fallback path that is say disjoint with = the primary but provides an appropriate SLA/intent=3F



    &=23160;



    Thanks,



    Ketan



    &=23160;





    =46rom: R= obert Raszuk <robert=40raszuk.net>


    Sent: 14 August 2020 23:04


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility





    &=23160;





    Ketan,





    &=23160;







    Looks like we are pretty much in sync here.&=23= 160;







    &=23160;







    But let me just observe that I purposely&=2316= 0;did not mention about SR policies as we are not able to signal the inte= nt with the packets itself.&=23160;







    &=23160;







    So all we have there is SIDs. BSIDs or prefix = SIDs need to be flooded with information if policies build with using the= m are bypass eligible or not.&=23160;







    &=23160;







    I was actually under the impression that this = is already there and I am just not aware, but looking deeper indeed I do = not see this marking neither in ISIS nor OSP=46 for prefix SIDs.&=23160;<= /p>





    &=23160;







    Is there some work in progress to add it to th= ose protocols or have we just documented need&=23160;for a short LSR draf= t&=23160; =3F&=23160;







    &=23160;







    Thx,







    R.







    &=23160;







    &=23160;







    On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:











    Hi Robert,



    &=23160;



    Please check inline below.



    &=23160;





    =46rom: R= obert Raszuk <robert=40raszuk.net>


    Sent: 14 August 2020 21:13


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility





    &=23160;





    Hi Ketan,





    &=23160;







    While I completely agree with your note the co= nsequences of it are pretty sevre.&=23160;



    =5BKT=5D I understand. We need to be min= dful of implications of protection schemes for the SLAs/intent of SR Poli= cies.







    &=23160;







    Unless we signal which prefix SID is protectio= n eligible and which is not how would other nodes know if they can protec= t it or not =3F&=23160;



    =5BKT=5D Correct. To be more accurate, w= e need to consider this more in the context of SLA or =E2=80=9Cintent=E2=80= =9D of SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D= for local protection for some of those SR Policies. We also have path-pr= otection mechanisms.







    &=23160;







    It seems that today's safe thing is not to app= ly any node protection on SR flows at the PLRs then.&=23160;







    &=23160;







    And link protection MUST assure that packets w= ill arrive at the neighbor node via some other link regardless of further= path towards destination.&=23160;



    =5BKT=5D Yes. We have a mechanism to ind= icate which adj-SIDs have protection (that mechanism only provides link p= rotection to get to the neighbor node) so the SR Policy computation is ab= le to indicate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D= or not by its choice of protected or unprotected adj-SIDs respectively.<= /i>



    &=23160;



    Thanks,



    Ketan







    &=23160;







    Is it correct =3F&=23160;







    &=23160;







    Thx







    R







    &=23160;







    On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:











    Hi Sasha,



    &=23160;



    The service node advertises its own Prefix SID= .. The service function that this service node implements does not requir= e any context (i.e. all packets arriving at the node are subjected to tha= t service). Therefore the service node does not need to receive a packet = with it=E2=80=99s own Prefix SID.



    &=23160;



    Thus, we cannot assume that when PHP is used, = then the SID is only associated with a topological instruction.



    &=23160;



    Hope that clarifies=3F



    &=23160;



    Thanks,



    Ketan



    &=23160;







    =46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>


    Sent: 14 August 2020 20:24


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Shraddha Hegde <shraddha=40juniper.ne= t>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.= net>


    Cc: spring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility







    &=23160;



    Ketan, and all,



    I have stated that, IMHO and =46WIW, both Adj-SIDs= and Prefix SIDs that are advertised with PHP can&=23160; ONLY represent = topological instructions in SR-MPLS - because the advertising node will n= ot receive them and therefore can hardly be expected to associate any ser= vice function with them.



    &=23160;



    This is complementary to what you have said.



    &=23160;



    Hope this clarifies my position.



    What, if anything, did I miss=3F



    &=23160;



    Regards,



    Sasha







    &=23160;





    Get Outlook for Android









    &=23160;











    =46rom: Ketan Talaulikar (ketant) <ketant=40cisc= o.com>


    Sent: =46riday, August 14, 2020, 16:23


    To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk


    Cc: sp= ring=40ietf.org


    Subject: RE: =5Bspring=5D Spring protection - determining applicability=





    &=23160;







    NOTICE: This email was received from an EXTERN= AL sender







    &=23160;





    Hi Sasha,



    &=23160;



    If the service does not need any additional co= ntext (e.g. a firewall that just applies locally configured default rules= on it), then I don=E2=80=99t see why PHP could not be done for a Prefix = SID associated with a service node.



    &=23160;



    Also, I didn=E2=80=99t follow the point that y= ou were trying to make about Adj-SIDs.



    &=23160;



    Thanks,



    Ketan



    &=23160;







    =46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>


    Sent: 14 August 2020 18:24


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Alexander Vainshtein <Alexand= er.Vainshtein=40rbbn.com>; Shraddha Hegde <shraddha=40juniper.net<= /a>>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.net= >


    Cc: spring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility







    &=23160;



    Hi all,



    Regarding the statement =22Prefix SID could be jus= t a topological instruction or may also be used to steer the flow to a no= de which is applying a service function to it=22:



    &=23160;



    &=23160;



    I think that in SR-MPLS a Node SID that is adverti= sed with PHP aciton can be safely considered as =22just a topological ins= truction=22 by the PLR because the originating node will not receive it.<= /span>



    The same applies to Adj-SDIs.



    &=23160;



    My 2c.







    &=23160;





    Get Outlook for Android









    &=23160;











    =46rom: spring <spring-bounces=40ietf.org= > on behalf of Ketan Talaulikar (ketant) <ketant=3D= 40cisco.com=40dmarc.ietf.org>


    Sent: =46riday, August 14, 2020, 15:00


    To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk


    Cc: sp= ring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicability=





    &=23160;





    Hi All,





    I would like to share a different perspective on this.





    =46irst, thanks to Joel for bringing up the discussion. Clearly we need a= well-defined applicability statement for determining applicability of pr= otection for segment used in an SR Policy. Some of this is captured in =5B= 1=5D.





    This is about local repair at a PLR. By it's very nature, the PLR does no= t have a notion of how =22strict or not=22 is the SLA that is being provi= ded by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.





    We have protected and un-protected variants of adjacency SIDs to enable t= he computation to pick or the other based on the =22strictness=22 of the = SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag= ) to indicate whether a Prefix SID can be bypassed or not. This provides = the opportunity for the computation to use one or the other flavor depend= ing on the nature of the SLA for the SR Policy.





    I have a problem and a concern in the assumption that PLRs can assume tha= t the currently defined variant of Prefix SIDs in R=46C8402 (and IGP spec= s) are =22bypass-able=22.





    As Joel and others have brought out, the Prefix SID could be just a topol= ogical instruction or may also be used to steer the flow to a node which = is applying a service function to it. In order to support a mix of SR Pol= icies of different SLAs (strict and not-strict), we need to enable the ch= oice of SIDs that indicates to the PLR whether they are =22bypass-able=22= or not.





    =46or the cases, where the SR Policy has a specific SLA, it is required f= or nodes to drop the packets meant for the =22active segment=22 than to b= ypass it. When this mechanism is used along side SRTE path monitoring mec= hanisms, it enables the headend to detect the failure and fallback to an = alternate path using the path protection approach. This is something that= is described and in use in deployments today =5B1=5D..





    Thanks,


    Ketan





    =5B1=5D htt= ps://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2= =46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-pol= icy-08%23section-9


    =5B2=5D htt= ps://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46= %2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-policy= -08%23section-9.3





    -----Original Message-----


    =46rom: spring <spring-bounces=40ietf.org> On Behalf Of Joel M.= Halpern


    Sent: 04 August 2020 20:25


    To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com>= ;; Shraddha Hegde <shraddha=3D40juniper.net=40dmarc.ie= tf.org>; EXT-Andrew.Alston=40liquidtelecom.com <= ;Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40= raszuk.net>


    Cc: spri= ng=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>


    Subject: Re: =5Bspring=5D Spring protection - determining applicability




    There are, as far as I can tell, a number of ways to address this family = of related questions.


    What struck me, and prompted the starting question, was that none of them= were spelled out.&=23160; I see lots of interesting ideas / proposals.

    Some of them are compatible with others.&=23160;&=23160; Some are not.

    It would be good if we could reach agreement on how we thought it should = be handled.





    Thank you,


    Joel





    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:


    > Hi all,


    >


    > I am still not sure that the problem of bypass going thru undesirabl= e


    > links/nodes exists in the case of topological SIDs.


    >


    > A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090


    > <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs= 6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46rfc4090>) = has been successfully deployed


    > for many years before SR-MPLS has been introduced. What=E2=80=99s mo= re,


    > signaling of bypass tunnels he PLR usually did not include any of th= e


    > constraints used for computing of any specific LSP that the bypass L= SP


    > would protect =E2=80=93 because in the =46acility Protection mode th= e same


    > bypass LSP would be used to protect multiple LSPs passing thru the

    > failed link/node.


    >


    >&=23160; =46rom my POV the only difference between this behavior and = that


    > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, = in the case of


    > RSVP-TE, the operator would explicitly indicate, as part of LSP


    > signaling, whether it would or would not use =46RR; LSPs that would = not


    > use =46RR would then drop traffic rather than delivering it the wron= g way.


    >


    > Such an option indeed does not exist in SR-TE today, but would be ea= sy


    > to provide if so desired IMHO.


    >


    > Did I miss something substantial=3F


    >


    > Regards, and lots of thanks in advance,


    >


    > Sasha


    >


    > Office: +972-39266302


    >


    > Cell:&=23160;&=23160;&=23160;&=23160;&=23160; +972-549266302


    >


    > Email:&=23160;&=23160; Alexander.Vainshtein=40ecitele.com


    >


    > *=46rom:* spring <    spring-bounces=40ietf.org> *On Behalf Of = *Shraddha Hegde


    > *Sent:* Tuesday, August 4, 2020 9:41 AM


    > *To:* EXT-Andrew.Alston=40liquidtelecom.com


    > <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk &= lt;rob= ert=40raszuk.net>


    > *Cc:* spring=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>


    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > All,


    >


    > This is a very interesting discussion and thanks to Joel for startin= g


    > this discussion. IMO, when there are strict requirements of avoiding=


    > certain nodes/links it can be realized&=23160; either by defining a = flex-algo


    > avoiding those


    >


    > Nodes and links or by using a stack of unprotected adj-sids that avo= id


    > restricted nodes and links. When a stack of adj-sids is used to


    > realize the path, the head-end based (sB=46D) protection mechanisms = can be applied.


    >


    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, th= e


    > failure events may cause traffic to go through restricted nodes and<= br />

    > links. This would happen regardless of whether any kind of protectio= n


    > is in use or not.


    >


    > Rgds


    >


    > Shraddha


    >


    > Juniper Business Use Only


    >


    > *=46rom:* spring <spring-bounces=40ietf.org
     > = <mailto:spring-bounces=40ietf.org>> *On Behalf Of *Andrew Al= ston


    > *Sent:* Tuesday, August 4, 2020 5:41 AM


    > *To:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net>>


    > *Cc:*     spring=40ietf.org <mailto:spring=40ietf.org>; Joel M. Halpern


    > <jmh=40joelhalpern.com <mailto:jmh=40joelhalpern.com>>

    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > *=5BExternal Email. Be cautious of content=5D*


    >


    > Robert this is actually far more difficult when =E2=80=93 it can be = an entire


    > (long) series of nodes that need to be avoided.


    >


    > It could potentially be made to work but I=E2=80=99d worry that to d= o this =E2=80=93


    > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative la= bels =E2=80=93 and that wouldn=E2=80=99t


    > be viable.


    >


    > It=E2=80=99s easier to use algorithms and adjacency sids and other s= uch things


    > to calculate paths =E2=80=93 the biggest trick is about the stack de= pth.&=23160; When


    > you have this need for node avoidance =E2=80=93 the need for 10+ lab= el depth


    > is critical =E2=80=93 unless you wanna be applying one hell of a lot= of


    > binding labels along the way which is a nightmare.


    >


    > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use


    > case that most of the people I discuss this with certain have =E2=80= =93 I cant


    > comment on a global scale, or for anyone else, but every indication = I


    > have is that yes =E2=80=93 its something people need, and want
    =

    >


    > Andrew


    >


    > *=46rom:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net= >>


    > *Sent:* Tuesday, 4 August 2020 01:27


    > *To:* Andrew Alston <Andrew.Alston=40liquidtelecom.= com
     > <mailto:Andrew.Alston=40liquidtelecom.com>>


    > *Cc:* Joel M. Halpern <    jmh=40joelhalpern.com
     > <= ;mai= lto:jmh=40joelhalpern.com>>; spring=40ietf.org


    > <mailto:spring=40ietf.org>


    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > Is this a common use case ie.&=23160; =22but rather =E2=80=93 which = nodes / network


    > segments it can never touch or flow through.=22


    >


    > If so perhaps its time to define notion of *negative-SID* ie. list i= n


    > the packet resources which given&=23160;packet MUST not ever travers= e.


    >


    > Put in the packet set of nodes or links which the packet should neve= r


    > traverse.


    >


    > That goes in line of recent wave of negative routing implementations=


    > (RI=46T) or discussions (LSR)


    >


    > Best,


    > R.


    >


    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston


    > <Andrew.Alston=40liquidtelecom.com
     > &= lt;mailto:Andrew.Alston=40liquidtelecom.com>> wrote:


    >


    >&=23160;&=23160;&=23160;&=23160; So =E2=80=93


    >


    >&=23160;&=23160;&=23160;&=23160; One of the use cases, in fact, some = very major use cases in any


    >&=23160;&=23160;&=23160;&=23160; spring technology for us revolve aro= und the following


    >


    >&=23160;&=23160;&=23160;&=23160; a.The explicit avoidance of certain = nodes


    >


    >&=23160;&=23160;&=23160;&=23160; b.The explicit avoidance of certain = sections of the network


    >


    >&=23160;&=23160;&=23160;&=23160; Anything that could result in that e= xplicit avoidance being violated


    >&=23160;&=23160;&=23160;&=23160; =E2=80=93 would create, shall we say= significant problems.


    >


    >&=23160;&=23160;&=23160;&=23160; Much of the use case is not a case o= f which nodes the packets flow


    >&=23160;&=23160;&=23160;&=23160; through =E2=80=93 but rather =E2=80=93= which nodes / network segments it can never


    >&=23160;&=23160;&=23160;&=23160; touch or flow through.&=23160; Effec= tively, to be used as a technology to


    >&=23160;&=23160;&=23160;&=23160; avoid certain things for specific re= asons.


    >


    >&=23160;&=23160;&=23160;&=23160; This is also one of the reasons for = needing such deep label stacks =E2=80=93


    >&=23160;&=23160;&=23160;&=23160; this kind of detailed path programmi= ng tends to deepen the stack


    >&=23160;&=23160;&=23160;&=23160; because you sometimes have to be pre= tty explicit.


    >


    >&=23160;&=23160;&=23160;&=23160; It is absolutely critical to us that= this functionality is there =E2=80=93


    >&=23160;&=23160;&=23160;&=23160; and that we can avoid situations whi= ch could cause traffic to


    >&=23160;&=23160;&=23160;&=23160; accidently hit things explicitly avo= ided.


    >


    >&=23160;&=23160;&=23160;&=23160; I wish I could be more specific than= this, but it is what it is.


    >


    >&=23160;&=23160;&=23160;&=23160; Thanks


    >


    >&=23160;&=23160;&=23160;&=23160; Andrew


    >


    >&=23160;&=23160;&=23160;&=23160; *=46rom:* spring <spring-bounc= es=40ietf.org
     >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing-bounces=40ietf.org>> *On Behalf Of *Joel M. Halpern


    >&=23160;&=23160;&=23160;&=23160; *Sent:* Monday, 3 August 2020 21:36<= br />

    >&=23160;&=23160;&=23160;&=23160; *To:* Robert Raszuk <robert=40raszuk.net= <mailto:robert=40raszuk.net>>


    >&=23160;&=23160;&=23160;&=23160; *Cc:* spring=40ietf..org <mailto:spring=40ie= tf.org>


    >&=23160;&=23160;&=23160;&=23160; *Subject:* Re: =5Bspring=5D Spring p= rotection - determining


    > applicability


    >


    >&=23160;&=23160;&=23160;&=23160; (Since the thread has gotten long en= ough, reiterating that this is as a


    >&=23160;&=23160;&=23160;&=23160; participant, not a WG chair.)


    >


    >&=23160;&=23160;&=23160;&=23160; Yes, we are talking IP networks. And= yes, I have seen IP networks that


    >&=23160;&=23160;&=23160;&=23160; choose to drop packets. =46or all so= rts of reasons.


    >&=23160;&=23160;&=23160;&=23160; I think there are likely other reaso= ns why one may not want a random


    >&=23160;&=23160;&=23160;&=23160; path rather than a chosen TE path. I= think it is important we be clear


    >&=23160;&=23160;&=23160;&=23160; about what constraints may be / are = violated when we tell people they


    >&=23160;&=23160;&=23160;&=23160; have this tool (protective rerouting= ) that is intended to preserve QoS.


    >


    >&=23160;&=23160;&=23160;&=23160; Let's be clear. I am not arguing tha= t this is not a good idea. It is a


    >&=23160;&=23160;&=23160;&=23160; good idea. And useful. I am trying t= o figure otu what combination of


    >&=23160;&=23160;&=23160;&=23160; additional mechanisms and clear desc= riptions will lead to everyone


    >&=23160;&=23160;&=23160;&=23160; getting the behavior they expect (wh= ich may not be the behavior they


    >&=23160;&=23160;&=23160;&=23160; desire, but sometimes is the best we= can do.)


    >


    >&=23160;&=23160;&=23160;&=23160; Yours,


    >&=23160;&=23160;&=23160;&=23160; Joel


    >


    >&=23160;&=23160;&=23160;&=23160; On 8/3/2020 2:30 PM, Robert Raszuk w= rote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Joel,


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Are we still talking ab= out IP networks&=23160;here =3F Or perhaps some hard


    >&=23160;&=23160;&=23160;&=23160;&=23160; > slicing with real resou= rce reservations or detnets =3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Because&=23160;if we ar= e talking&=23160;about IP networking I have two


    >&=23160;&=23160;&=23160;&=23160; observations:


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > A) If you need to trave= rse via a specific node (ie. firewall) you


    >&=23160;&=23160;&=23160;&=23160; better


    >&=23160;&=23160;&=23160;&=23160;&=23160; > apply IP encapsulation = to that node.. I don't think IP


    >&=23160;&=23160;&=23160;&=23160; encapsulation&=23160;can


    >&=23160;&=23160;&=23160;&=23160;&=23160; > be hijacked today such = that destination address of the packet is


    >&=23160;&=23160;&=23160;&=23160; ignored.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > B) Have you seen any IP= network where upon topology change (link


    >&=23160;&=23160;&=23160;&=23160; or node


    >&=23160;&=23160;&=23160;&=23160;&=23160; > failure) you suddenly&=23= 160;start dropping&=23160;flows in spite of SPT offering


    >&=23160;&=23160;&=23160;&=23160;&=23160; > perhaps few ms longer p= ath with 10 ms more jitter =3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Or are some SR marketin= g slides promise to turn IP networks in


    >&=23160;&=23160;&=23160;&=23160;&=23160; > something&=23160;new =3F= Worse ... do they mention path quality guarantees,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > resource reservations&=23= 160;=3F I hope not.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Thx,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > R.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > On Mon, Aug 3, 2020 at = 8:10 PM Joel M. Halpern <jmh=40joelhalpern.com
     >&=23160;&=23= 160;&=23160;&=23160; <mailto:jmh=40joelhalpern.com%20%0b>> &= lt;m= ailto:jmh=40joelhalpern.com>> wrote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Well less serious for T= E SIDs, I am not sure the problem is


    >&=23160;&=23160;&=23160;&=23160; restricted


    >&=23160;&=23160;&=23160;&=23160;&=23160; > to just service SIDs.

    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Suppose that the PCE ha= s specified the path to meet some complex te


    >&=23160;&=23160;&=23160;&=23160;&=23160; > objective.&=23160; The = bypass node has no way of knowing what those


    >&=23160;&=23160;&=23160;&=23160;&=23160; > constraints


    >&=23160;&=23160;&=23160;&=23160;&=23160; > were.&=23160; And for s= ome kinds of traffic, it is better to drop the packet


    >&=23160;&=23160;&=23160;&=23160;&=23160; > than to deliver it outs= ide the envelop.&=23160; I suspect that the right


    >&=23160;&=23160;&=23160;&=23160;&=23160; > answer


    >&=23160;&=23160;&=23160;&=23160;&=23160; > to this is =22too bad=22= ..&=23160; If so, as with the distinction regarding


    >&=23160;&=23160;&=23160;&=23160; service


    >&=23160;&=23160;&=23160;&=23160;&=23160; > nodes, we should say so= , shouldn't we=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Yours,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Joel


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > On 8/3/2020 2:36 AM, Al= exander Vainshtein wrote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach, Joel and all= ,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I think that in mo= st cases:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > 1.There is clear d= ifferentiation between =22topological=22 and


    >&=23160;&=23160;&=23160;&=23160; =22service=22


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > instructions in SI= D advertisements. E.g.:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > oIGP Prefix Node S= IDs IGP Adj-SIDs (identified as such in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > corresponding IGP = advertisements) represent topological


    >&=23160;&=23160;&=23160;&=23160; instructions


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > oService SIDs for = SRv6 (see SRv6 BGP-Based Overlay Services


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3CCcy9mY6cMfbk7Qfjhi= A3R6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.ietf.org%2=46doc%2=46html%2=46= draft-ietf-bess-srv6-services-04
     >&=23160;&=23160;&=23160;&=23= 160; <https://clickt= ime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2=3Fu=3Dhttps%3A%2=46%2=46urlde= fense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46= html%2=46draft-ietf-bess-srv6-services-04=5F=5F%3B%21%21NEt6yMaO-gk%21S0Y= usx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24&= gt;>


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > draft) unsurprisin= gly represent =E2=80=9Cservice=E2=80=9D instructions


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > 2.Segments that re= present topological instructions can be bypassed,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > while segments tha= t represent service instructions require


    >&=23160;&=23160;&=23160;&=23160;&=23160; > alternative


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > protection mechani= sms.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > This view seems to= be aligned with R=46C 8402


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2=3Fu=3Dhttps%3A= %2=46%2=46tools.ietf.org%2=46html%2=46rfc8402
     >&=23160;&=231= 60;&=23160;&=23160; <https://clicktime.symantec.com/37PzUK= AD82cjSvmVcGvpkh=466H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46tools.ietf.org%2=46html%2=46rfc8402=5F=5F%3B%21%21NEt6= yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I= 4Ybtm%24>>


    >&=23160;&=23160;&=23160;&=23160; that says in Section 1:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of an IGP-based distributed control plane, two


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the IGP-Adjacency segment and the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; IGP-Prefix segment.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of a BGP-based distributed control plane, two


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the BGP peering segment and the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; BGP-Prefix segment.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > In the case of SR-= MPLS this differentiation is assumed in Section


    >&=23160;&=23160;&=23160;&=23160;&=23160; > 3.4 of


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the Node Protectio= n for SR-TE Path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktim= e.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2=3Fu=3Dhttps%3A%2=46%2=46datatra= cker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protection-for= -sr-te-paths-07%23section-3.4
     >&=23160;&=23160;&=23160;&=231= 60; <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ= 16H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= datatracker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protect= ion-for-sr-te-paths-07%2Asection-3.4=5F=5F%3BIw%21%21NEt6yMaO-gk%21S0Yusx= 9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>= >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > draft that says:

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The node protection mechanism described in the previous


    >&=23160;&=23160;&=23160;&=23160; sections


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; depends on the assumption that the label immediately below


    >&=23160;&=23160;&=23160;&=23160;&=23160; > the top


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > label in the label= stack is understood in the IGP domain.&=23160; When the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; provider edge routers exchange service labels via BGP or some


    >&=23160;&=23160;&=23160;&=23160;&=23160; > other


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; non-IGP mechanism the bottom label is not understood in the IGP


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; domain.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The egress node protection mechanisms described in the draft


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; =5BR=46C8679 <https://clicktime.syma= ntec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.i= etf.org%2=46doc%2=46html%2=46rfc8679
     >&=23160;&=23160;&=2316= 0;&=23160; <https://clicktime.symantec.com/36= dMAjuYTQovo8jHwmm3eJw6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46html%2=46rfc8679=5F=5F= %3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo8MGipXc%24>>=5D


    >&=23160;&=23160;&=23160;&=23160; is


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > applicable to this= use case and no additional changes


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; will be required for SR based networks


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > The scenarios in w= hich &=23160;differentiation between =E2=80=9Ctopological=E2=80=9D and

    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =E2=80=9Cservice=E2= =80=9D instructions is broken are indeed problematic. E.g.,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > consider


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the use case in wh= ich a Node SID in the ERO of a SR-TE path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > identifies a


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > node that acts as = a firewall for all packets it receives, i.e.,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > provides


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the firewall servi= ce without any dedicated service SID


    >&=23160;&=23160;&=23160;&=23160;&=23160; > identifying it.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > One could say that= the Node SID of such a node would combine


    >&=23160;&=23160;&=23160;&=23160;&=23160; > topological


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > and service instru= ctions thus breaking the differentiation


    >&=23160;&=23160;&=23160;&=23160;&=23160; > between the two.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I am not sure if u= sage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented


    >&=23160;&=23160;&=23160;&=23160;&=23160; > or at


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > least discouraged.=


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > If not, providing = an ability to identify such SIDs in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > advertisement


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > mechanisms would b= e useful IMHO.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > My 2c,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Sasha


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Office: +972-39266= 302


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Cell:&=23160;&=231= 60;&=23160;&=23160;&=23160; +972-549266302


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Email: Alex= ander.Vainshtein=40ecitele.com


    >&=23160;&=23160;&=23160;&=23160; <mailto:Alexander.Vainsh= tein=40ecitele.com>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:Ale= xander.Vainshtein=40ecitele.com>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > -----Original Mess= age-----


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =46rom: spring <= ;spring-bounces=40ietf.org
     >&=23160;&=23160;&=23160;&=231= 60; <mailto:spring-bounces=40ietf.org%0b>>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org= >> On Behalf Of Mach Chen


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Sent: Monday, Augu= st 3, 2020 6:30 AM


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > To: Joel M. Halper= n <jmh=40joelhalpern.com
     >&=23160;&=23160;&=23160;&=23160;= <mailto:jmh=40joelhalpern.com%0b>> <mailto:jmh=40joelhalpern.= com>>;


    >&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Subject: Re: =5Bsp= ring=5D Spring protection - determining applicability


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Hi Joel,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I think this is a = good point that may not be discussed in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > past. And


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I also don't think= there is a =22can be bypassed=22 indication in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > routing advertisem= ent for now.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > IMHO, the informat= ion advertised by routing is neutral, such


    >&=23160;&=23160;&=23160;&=23160;&=23160; > information


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > (can or cannot be = bypassed) is more path specific, thus


    >&=23160;&=23160;&=23160;&=23160; normally the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > controller should = be responsible for deciding whether/which SID


    >&=23160;&=23160;&=23160;&=23160;&=23160; > can be


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > bypassed.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Best regards,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > -----= Original Message-----


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46ro= m: spring =5Bmailto:spring-bounces=40ietf.org


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring-bounc= es=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org%0b%3e%20%3cmailto:spring-= bounces=40ietf.org%3e>=5D


    >&=23160;&=23160;&=23160;&=23160; On Behalf Of Joel M.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Halpe= rn


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Sent:= Monday, August 3, 2020 7:51 AM


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > To: <= a href=3D=22mailto:spring=40ietf.org=22 target=3D=22=5Fblank=22>spring=40= ietf.org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
     >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Subje= ct: =5Bspring=5D Spring protection - determining applicability


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > (WG C= hair hat Off, this is merely a note from a slightly


    >&=23160;&=23160;&=23160;&=23160;&=23160; > confused WG


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > parti= cipant.)


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > I hav= e been reading the various repair drafts, and the various


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > netwo= rks programming and service programming draft, and I am


    >&=23160;&=23160;&=23160;&=23160;&=23160; > trying to


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > figur= e out one aspect of the combination.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > How d= oes a node that is doing some form of bypass (suppose, for


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > simpl= icity, it is Node N2 deciding to bypass the next SID for


    >&=23160;&=23160;&=23160;&=23160;&=23160; > a failed


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > node = N3) know that it is safe to do so=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > If th= e path was just for TE, then it is =22safe=22 if the new path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > meets


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > the T= E criteria.&=23160; or maybe it is safe if it is even close, as


    >&=23160;&=23160;&=23160;&=23160;&=23160; > long as


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > it is= not used for too long.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > But w= hat if the node were a =46irewall, included to meet legal


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > requirements=3F

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Or wa= s some other necessary programmatic transform (wince we are


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > delib= erately vague about what nodes can do when asked suitably.)


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Is th= ere some =22can be bypassed=22 indication in the routing


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > adver= tisements that I missed=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Thank= you,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Yours= ,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Joel<= br />

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > sprin= g mailing list


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > spring=40ietf= ..org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
     >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dh= ttps%3A%2


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892X= uXy2H6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A= %2=46clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%= 2A3A%2A2=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0w= xqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3F= u=3Dhttps%3A%252
     >&=23160;&=23160;&=23160;&=23160; <https://clicktime.sym= antec.com/3A5B8H2=46m1rPnaZ3Supjwr6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.= com%2=46v3%2=46=5F=5Fhttps%3A%2=46clicktime.symantec.com%2=46367qhU4KiUkz= W9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%2A252=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0= Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24= >>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46%<= a href=3D=22http://2=46www.ietf.org=22 target=3D=22=5Fblank=22>2=46www.ie= tf.org


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/39NznmYBt= RuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5F= http%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5F= R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <https://clicktime.sym= antec.com/3GWT9fyja=46i3=46cvHDvoodvS6H2=3Fu=3Dhttp%3A%2=46%2=462=46www.i= etf.org
     >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symant= ec.com/39NznmYBtRuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%= 2=46v3%2=46=5F=5Fhttp%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<= /a>>>%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >     spring=40ietf.org <= mailto:s= pring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org> <mailto:s= pring=40ietf.org
     >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing=40ietf.org%0b>> <mailto:spring=40ietf.org>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJt= T6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%= 2A2=46%2A2=46www.ietf.org%2A2=46mailman%2A2=46listinfo%2A2=46spring=5F=5F= %3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo-hR3gAD%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Notice: This e-mai= l together with any attachments may contain


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > information of Rib= bon Communications Inc. that is confidential


    >&=23160;&=23160;&=23160;&=23160;&=23160; > and/or


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > proprietary for th= e sole use of the intended recipient. Any review,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > disclosure, relian= ce or distribution by others or forwarding


    >&=23160;&=23160;&=23160;&=23160; without


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > express permission= is strictly prohibited. If you are not the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > intended


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > recipient, please = notify the sender immediately and then delete all


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > copies, including = any attachments.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dht= tps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https:/= /clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > spring mailing list


    >&=23160;&=23160;&=23160;&=23160;&=23160; > spring=40ietf.org <mailto:spring= =40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A= %2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https:/= /clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >


    >&=23160;&=23160;&=23160;&=23160; =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


    >&=23160;&=23160;&=23160;&=23160; spring mailing list


    >&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;     https://cli= cktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160;


    > <https://clicktime.= symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%
     > 2=46= %2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listi


    > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqgu


    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >


    >


    >


    > --------------------------------------------------------------------= --


    > --


    > Notice: This e-mail together with any attachments may contain


    > information of Ribbon Communications Inc. that is confidential and/o= r


    > proprietary for the sole use of the intended recipient. Any review,<= br />

    > disclosure, reliance or distribution by others or forwarding without=


    > express permission is strictly prohibited. If you are not the intend= ed


    > recipient, please notify the sender immediately and then delete all<= br />

    > copies, including any attachments.


    > --------------------------------------------------------------------= --


    > --





    =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


    spring mailing list


    spring=40= ietf.org


    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring


    =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


    spring mailing list


    spring=40= ietf.org


    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring





    &=23160;





    &=23160;



    <= /span>



    Notice: This e-mail together with any attachments may co= ntain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, di= sclosure, reliance or distribution by others or forwarding without expres= s permission is strictly prohibited. If you are not the intended recipien= t, please notify the sender immediately and then delete all copies, inclu= ding any attachments.



    <= /span>





    &=23160;























    =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


    spring mailing list


    spring=40= ietf.org


    https://www.ietf.org/mailman/listinfo/spring






















    =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

    spring mailing list

    spring=40= ietf.org

    https://www.ietf.org/mailman/listinfo/= spring

    --


    Gyan Mishra<= /p>

    Netw= ork Solutions Architect&=23160;

    M 301 502-1347
    13101 Columbia Pike&=23160;
    Silver Spring, MD


    --5f3afc99_66ef438d_65d7-- From nobody Mon Aug 17 15:15:37 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2E43A12A6 for ; Mon, 17 Aug 2020 15:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 eYzkXX9Zp7em for ; Mon, 17 Aug 2020 15:15:29 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575563A12AF for ; Mon, 17 Aug 2020 15:15:28 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id t15so13613077edq.13 for ; Mon, 17 Aug 2020 15:15:28 -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=+8jNDseXFemisY9RXJhDWiBYUq0bEGjkyWjSuya3Sg4=; b=cQYk3yf1M74mnXS05snRVVQFrwtkw/GmLC8SmWAdWhjOPclX0Ao1F76EDITMBh2bN9 4E7XOoo7Lt45FtlC9S6PCIaUhYfzSQofp6x2n0/T1YTQE8xCY5XvIlDiPk5cCNfaAbpX vTQSGX/Dm1MvF816XMKEHgZKgS/kcdLKmE6wlZxNc/+pW4HN/T5Nx3sIquSEuSfs1pBm m9U4JgEIuCWkDAT1u0Z32/qmeSPfRjgwW7nKwcvPntwCray6fWY4E6ykNWZTw91UMBRN i58nrYRSzZGxiqUIwcqleVzQ5ZmLru8nC+ScdSd8RxSZxOqcZIz2MH63iRzLRYMlYHp/ mOgA== 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=+8jNDseXFemisY9RXJhDWiBYUq0bEGjkyWjSuya3Sg4=; b=idiq8norzK2eam/tc3ZnttIyh/KStm/oL1XfzMMJSnzW6cgyqRSxdokUSOHzhQjgae nW9JpHfQpi6av8AiqI/Ij3FFiDTOJUZK3+o7x98D/spZHDh+g/DOer5AY+TDNuEcoskw EvUqo5ZgMDkPqYlw4chYe5JH6QYmV+bXkJrTxojY1EcM2NXtKqaCGB45KvuSNr+k0Xj7 lQ1zAmBCMRRL8m7lSomciCMJHNAZDyS6QvPs1L3Y2BrMPJtZ0o6ATw18wWOPXSC350ri 3FJ42rvSaMpl7X2wfqT3EnSE1Ic0dpUWl4DmnhjDnY99fM+dPlWRdfBmhef7c286E4ni J3uw== X-Gm-Message-State: AOAM532JPbH0FTifYS8EzeCE4LjLTrieB02zSRGBOffCJt+vmUTzvPzi qKBVXaSdwL7HALHZaiE4n6w+HzyKVx4NuvOdmsHiYQ== X-Google-Smtp-Source: ABdhPJwL4h22iVp2QNcvJjs5nttiSl7WGNEqkb5nEDXy0wGjh8Ih8l0YuuNrtjME/BQwf9UUYeP41oTpFcVmYzqZa4M= X-Received: by 2002:aa7:c70b:: with SMTP id i11mr16721115edq.272.1597702525998; Mon, 17 Aug 2020 15:15:25 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> <7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark> <8940cdc0-9c51-46a4-8ddc-79df170c433f@Spark> In-Reply-To: <8940cdc0-9c51-46a4-8ddc-79df170c433f@Spark> From: Robert Raszuk Date: Tue, 18 Aug 2020 00:15:14 +0200 Message-ID: To: Jeff Tantsura Cc: Gyan Mishra , Alexander Vainshtein , "EXT-Andrew.Alston@liquidtelecom.com" , "Joel M. Halpern" , "Ketan Talaulikar (ketant)" , Shraddha Hegde , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000850c5a05ad1a1baf" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 22:15:35 -0000 --000000000000850c5a05ad1a1baf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeff, If one would allocate SIDs in a smart way they can include algorithmically encoded information if packets are FRR eligible. No increase in IGP flooding. No duplication of SID space. Just local behaviour. For SRv6 - trivial. For SR-MPLS, also pretty simple provided one would be keen on using MPLS forwarding paradigm for some time :) Hint: think even/odd (1 bit in the SID) - well known in a domain - and used correctly by your vendor. Best, R. On Mon, Aug 17, 2020 at 11:54 PM Jeff Tantsura wrote: > Hi Robert, > > "possession of enough information in PLR=E2=80=9D what do you call this, = if not > more state, given this information is not present there today? > > Cheers, > Jeff > On Aug 17, 2020, 2:25 PM -0700, Robert Raszuk , wrote: > > Hi Jeff, > > This is not about more state in the network nor about including mirror > service node in the backup path for some flows. > > The thread is about possession of enough information in PLR to either tak= e > the packet and shift it over backup path or just drop it. > > - - - > > Btw - path protection is completely orthogonal to the above. > > Cheers, > Robert. > > > On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura > wrote: > >> Gyan, >> >> TI-LFA computation is local to the PLR and is topology dependent, e.g >> change in downstream topology could/would influence the choice of MP (PQ= ) >> node. >> While an implementation could take into consideration some additional >> meta-data (e.g. locally provisioned SRLG, usually used to avoid protecte= d >> and protecting ports on the same line card), this is not a standardized >> method. >> If a service node must be included in a backup path, there=E2=80=99s a s= tate >> associated with it as well as distribution of the state involved. >> >> Back to my point, removing state and introducing services in the network >> (at the very least at the computational logic and head-end level) are >> mutually exclusive, trade-offs are inevitable (You can't eat your cake a= nd >> have it). >> Keeping the state limited to: >> - a logically centralized computational logic (aka PCE) - off path, >> scales horizontally, could use additional business logic for the path >> computation, example - CPU/memory consumption on a service node >> - head-end - anchor to primary/backup paths >> seems like a reasonable set of trade-offs. >> >> Cheers, >> Jeff >> On Aug 14, 2020, 7:44 PM -0700, Gyan Mishra , >> wrote: >> >> >> Catching up on this thread as it is a interesting topic as FRR 1:N link >> protection, node protection and path protection is critical to operators= . >> >> There are multiple somewhat orthogonal topics brought up in the >> discussion. >> >> Excluding SR SFC from =E2=80=9Cbypass=E2=80=9D capable node such for app= liances such as >> firewalls and load balancer. Makes sense. I would not think SFC would = be >> in a PLR path to merger point but I could be mistaken. >> >> The goal of SR is eliminating state and so having TE like state is >> undesirable. >> >> Intent based instantiation of bypass via SR-TE from network feedback at >> PLR detection node of a failure and make before break pre computed backu= p >> paths that can. >> >> It would make sense that SR-TE binding SID policy would be appropriate >> for RSVP like FRR link node or path protection. >> >> My thoughts on this topic of SR protection is that don=E2=80=99t we alre= ady have >> FRR protection natively without requiring SR-TE BSID or any additional >> undesirable state maintenance with TI-LFA. >> >> Thanks >> >> Gyan >> >> On Fri, Aug 14, 2020 at 5:47 PM Jeff Tantsura >> wrote: >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> PCE computation in this case is trivial too(must traverse node B or nod= e >>> X) else FAIL. >>> >>> >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> >>> >>> >>> >>> On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura = , >>> wrote: >>> >>> >>> >>> >>> >>> >>> Robert, >>> >>> >>> >>> >>> >>> Agreed and apologies, hit send before finishing the email (it is Friday= ) >>> ;-) >>> >>> >>> >>> >>> >>> Path protection in this case make more sense and is much less complex, >>> >>> >>> if in the pathA (A->B->C) node B is a service node, it can=E2=80=99t be= bypassed >>> (node protected) if the link between A and B breaks >>> >>> >>> however it could have a backup pathB (A->X->C) where X is the service >>> node, potentially synchronizing its state with the node B. >>> >>> >>> >>> >>> >>> To my previous email - at expense of more state, we provide path and >>> service protection, hence the similarity with RSVP-TE trade-offs. >>> >>> >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> >>> >>> >>> >>> On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , >>> wrote: >>> >>> >>> >>> >>> Jeff, >>> >>> >>> >>> >>> > This is very similar to RSVP-TE >>> >>> >>> >>> >>> >>> I would rather differ on that statement. >>> >>> >>> >>> >>> >>> See if you are using SR just for TE you are 100% right. >>> >>> >>> >>> >>> >>> But if your SIDs embed additional local SR node processing functions >>> this suddenly becomes a completely different game. Let's keep this in m= ind >>> in this thread/topic. >>> >>> >>> >>> >>> >>> Kind regards, >>> >>> >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Aug 14, 2020 at 11:15 PM Jeff Tantsura >>> wrote: >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> This is very similar to RSVP-TE, path vs link/node protection and >>>> usually dictated by the business logic, the triggers are obviously ver= y >>>> different, head-end being notified of the failure on a path and switch= ing >>>> to the backup path vs reaction to a local failure, so same considerati= ons >>>> apply: >>>> >>>> >>>> -more state >>>> >>>> >>>> -pre-reserved resources >>>> >>>> >>>> while >>>> >>>> >>>> -predictable >>>> >>>> >>>> -meets SLA (as good as primary) >>>> >>>> >>>> vs >>>> >>>> >>>> -less state >>>> >>>> >>>> -local >>>> >>>> >>>> -best effort / can cause congestions >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulikar (ketant) >>> 40cisco.com@dmarc.ietf.org>, wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Robert, >>>> >>>> >>>> >>>> >>>> >>>> We do not have a signalling mechanism in IGPs today to indicate a >>>> =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was= a desire for it, an >>>> IGP extension would be required (there is none in progress AFAIK). Not= e >>>> that this results in doubling the prefix SID scale (global labels) in = the >>>> network. So I would not go about this trivially. >>>> >>>> >>>> >>>> >>>> >>>> I think it helps to get more inputs and perspectives from operators on >>>> their views for doing a bypass via local protection for segments in an= SR >>>> Policy. There may be those that prefer end-to-end path protection usin= g a >>>> fallback path that is say disjoint with the primary but provides an >>>> appropriate SLA/intent? >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Ketan >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* Robert Raszuk >>>> >>>> >>>> *Sent:* 14 August 2020 23:04 >>>> >>>> >>>> *To:* Ketan Talaulikar (ketant) >>>> >>>> >>>> *Cc:* Alexander Vainshtein ; Joel M. >>>> Halpern ; Shraddha Hegde ; >>>> EXT-Andrew.Alston@liquidtelecom.com ; >>>> spring@ietf.org >>>> >>>> >>>> *Subject:* Re: [spring] Spring protection - determining applicability >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Ketan, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Looks like we are pretty much in sync here. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> But let me just observe that I purposely did not mention about SR >>>> policies as we are not able to signal the intent with the packets itse= lf. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded >>>> with information if policies build with using them are bypass eligible= or >>>> not. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I was actually under the impression that this is already there and I a= m >>>> just not aware, but looking deeper indeed I do not see this marking ne= ither >>>> in ISIS nor OSPF for prefix SIDs. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Is there some work in progress to add it to those protocols or have we >>>> just documented need for a short LSR draft ? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thx, >>>> >>>> >>>> >>>> >>>> >>>> >>>> R. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) < >>>> ketant@cisco.com> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Robert, >>>> >>>> >>>> >>>> >>>> >>>> Please check inline below. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* Robert Raszuk >>>> >>>> >>>> *Sent:* 14 August 2020 21:13 >>>> >>>> >>>> *To:* Ketan Talaulikar (ketant) >>>> >>>> >>>> *Cc:* Alexander Vainshtein ; Joel M. >>>> Halpern ; Shraddha Hegde ; >>>> EXT-Andrew.Alston@liquidtelecom.com ; >>>> spring@ietf.org >>>> >>>> >>>> *Subject:* Re: [spring] Spring protection - determining applicability >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Ketan, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> While I completely agree with your note the consequences of it are >>>> pretty sevre. >>>> >>>> >>>> *[KT] I understand. We need to be mindful of implications of protectio= n >>>> schemes for the SLAs/intent of SR Policies.* >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Unless we signal which prefix SID is protection eligible and which is >>>> not how would other nodes know if they can protect it or not ? >>>> >>>> >>>> *[KT] Correct. To be more accurate, we need to consider this more in >>>> the context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and whic= h segments may be >>>> =E2=80=9Cbypass-able=E2=80=9D for local protection for some of those S= R Policies. We also >>>> have path-protection mechanisms.* >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> It seems that today's safe thing is not to apply any node protection o= n >>>> SR flows at the PLRs then. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> And link protection MUST assure that packets will arrive at the >>>> neighbor node via some other link regardless of further path towards >>>> destination. >>>> >>>> >>>> *[KT] Yes. We have a mechanism to indicate which adj-SIDs have >>>> protection (that mechanism only provides link protection to get to the >>>> neighbor node) so the SR Policy computation is able to indicate whethe= r >>>> that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its choi= ce of protected or >>>> unprotected adj-SIDs respectively.* >>>> >>>> >>>> >>>> >>>> >>>> *Thanks,* >>>> >>>> >>>> *Ketan* >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Is it correct ? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thx >>>> >>>> >>>> >>>> >>>> >>>> >>>> R >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) < >>>> ketant@cisco.com> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Sasha, >>>> >>>> >>>> >>>> >>>> >>>> The service node advertises its own Prefix SID.. The service function >>>> that this service node implements does not require any context (i.e. a= ll >>>> packets arriving at the node are subjected to that service). Therefore= the >>>> service node does not need to receive a packet with it=E2=80=99s own P= refix SID. >>>> >>>> >>>> >>>> >>>> >>>> Thus, we cannot assume that when PHP is used, then the SID is only >>>> associated with a topological instruction. >>>> >>>> >>>> >>>> >>>> >>>> Hope that clarifies? >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Ketan >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* Alexander Vainshtein >>>> >>>> >>>> *Sent:* 14 August 2020 20:24 >>>> >>>> >>>> *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < >>>> jmh@joelhalpern.com>; Shraddha Hegde ; >>>> EXT-Andrew.Alston@liquidtelecom.com ; >>>> Robert Raszuk >>>> >>>> >>>> *Cc:* spring@ietf.org >>>> >>>> >>>> *Subject:* Re: [spring] Spring protection - determining applicability >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Ketan, and all, >>>> >>>> >>>> I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that >>>> are advertised with PHP can ONLY represent topological instructions i= n >>>> SR-MPLS - because the advertising node will not receive them and there= fore >>>> can hardly be expected to associate any service function with them. >>>> >>>> >>>> >>>> >>>> >>>> This is complementary to what you have said. >>>> >>>> >>>> >>>> >>>> >>>> Hope this clarifies my position. >>>> >>>> >>>> What, if anything, did I miss? >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> Sasha >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Get Outlook for Android >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> >>>> >>>> *From:* Ketan Talaulikar (ketant) >>>> >>>> >>>> *Sent:* Friday, August 14, 2020, 16:23 >>>> >>>> >>>> *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; >>>> EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk >>>> >>>> >>>> *Cc:* spring@ietf.org >>>> >>>> >>>> *Subject:* RE: [spring] Spring protection - determining applicability >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> NOTICE: This email was received from an EXTERNAL sender >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Sasha, >>>> >>>> >>>> >>>> >>>> >>>> If the service does not need any additional context (e.g. a firewall >>>> that just applies locally configured default rules on it), then I don= =E2=80=99t see >>>> why PHP could not be done for a Prefix SID associated with a service n= ode. >>>> >>>> >>>> >>>> >>>> >>>> Also, I didn=E2=80=99t follow the point that you were trying to make a= bout >>>> Adj-SIDs. >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Ketan >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* Alexander Vainshtein >>>> >>>> >>>> *Sent:* 14 August 2020 18:24 >>>> >>>> >>>> *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < >>>> jmh@joelhalpern.com>; Alexander Vainshtein < >>>> Alexander.Vainshtein@rbbn.com>; Shraddha Hegde ; >>>> EXT-Andrew.Alston@liquidtelecom.com ; >>>> Robert Raszuk >>>> >>>> >>>> *Cc:* spring@ietf.org >>>> >>>> >>>> *Subject:* Re: [spring] Spring protection - determining applicability >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi all, >>>> >>>> >>>> Regarding the statement "Prefix SID could be just a topological >>>> instruction or may also be used to steer the flow to a node which is >>>> applying a service function to it": >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I think that in SR-MPLS a Node SID that is advertised with PHP aciton >>>> can be safely considered as "just a topological instruction" by the PL= R >>>> because the originating node will not receive it. >>>> >>>> >>>> The same applies to Adj-SDIs. >>>> >>>> >>>> >>>> >>>> >>>> My 2c. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Get Outlook for Android >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> >>>> >>>> *From:* spring on behalf of Ketan Talaulikar >>>> (ketant) >>>> >>>> >>>> *Sent:* Friday, August 14, 2020, 15:00 >>>> >>>> >>>> *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; >>>> EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk >>>> >>>> >>>> *Cc:* spring@ietf.org >>>> >>>> >>>> *Subject:* Re: [spring] Spring protection - determining applicability >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi All, >>>> >>>> >>>> >>>> >>>> >>>> I would like to share a different perspective on this. >>>> >>>> >>>> >>>> >>>> >>>> First, thanks to Joel for bringing up the discussion. Clearly we need = a >>>> well-defined applicability statement for determining applicability of >>>> protection for segment used in an SR Policy. Some of this is captured = in >>>> [1]. >>>> >>>> >>>> >>>> >>>> >>>> This is about local repair at a PLR. By it's very nature, the PLR does >>>> not have a notion of how "strict or not" is the SLA that is being prov= ided >>>> by the SR Policy. Awareness of that notion exists at the SR Policy hea= dend >>>> and/or computation-node. >>>> >>>> >>>> >>>> >>>> >>>> We have protected and un-protected variants of adjacency SIDs to enabl= e >>>> the computation to pick or the other based on the "strictness" of the = SLA >>>> requirement for picking that link. We do not have such a notion for Pr= efix >>>> SIDs. One can say that we could introduce signalling (e.g. a B flag) t= o >>>> indicate whether a Prefix SID can be bypassed or not. This provides th= e >>>> opportunity for the computation to use one or the other flavor dependi= ng on >>>> the nature of the SLA for the SR Policy. >>>> >>>> >>>> >>>> >>>> >>>> I have a problem and a concern in the assumption that PLRs can assume >>>> that the currently defined variant of Prefix SIDs in RFC8402 (and IGP >>>> specs) are "bypass-able". >>>> >>>> >>>> >>>> >>>> >>>> As Joel and others have brought out, the Prefix SID could be just a >>>> topological instruction or may also be used to steer the flow to a nod= e >>>> which is applying a service function to it. In order to support a mix = of SR >>>> Policies of different SLAs (strict and not-strict), we need to enable = the >>>> choice of SIDs that indicates to the PLR whether they are "bypass-able= " or >>>> not. >>>> >>>> >>>> >>>> >>>> >>>> For the cases, where the SR Policy has a specific SLA, it is required >>>> for nodes to drop the packets meant for the "active segment" than to b= ypass >>>> it. When this mechanism is used along side SRTE path monitoring mechan= isms, >>>> it enables the headend to detect the failure and fallback to an altern= ate >>>> path using the path protection approach. This is something that is >>>> described and in use in deployments today [1].. >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Ketan >>>> >>>> >>>> >>>> >>>> >>>> [1] >>>> https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A= %2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%2= 3section-9 >>>> >>>> >>>> [2] >>>> https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A= %2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%2= 3section-9.3 >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> >>>> From: spring On Behalf Of Joel M. Halpern >>>> >>>> >>>> Sent: 04 August 2020 20:25 >>>> >>>> >>>> To: Alexander Vainshtein ; Shraddha >>>> Hegde ; >>>> EXT-Andrew.Alston@liquidtelecom.com ; >>>> Robert Raszuk >>>> >>>> >>>> Cc: spring@ietf.org; Joel M. Halpern >>>> >>>> >>>> Subject: Re: [spring] Spring protection - determining applicability >>>> >>>> >>>> >>>> >>>> >>>> There are, as far as I can tell, a number of ways to address this >>>> family of related questions. >>>> >>>> >>>> What struck me, and prompted the starting question, was that none of >>>> them were spelled out. I see lots of interesting ideas / proposals. >>>> >>>> >>>> Some of them are compatible with others. Some are not. >>>> >>>> >>>> It would be good if we could reach agreement on how we thought it >>>> should be handled. >>>> >>>> >>>> >>>> >>>> >>>> Thank you, >>>> >>>> >>>> Joel >>>> >>>> >>>> >>>> >>>> >>>> On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: >>>> >>>> >>>> > Hi all, >>>> >>>> >>>> > >>>> >>>> >>>> > I am still not sure that the problem of bypass going thru undesirabl= e >>>> >>>> >>>> > links/nodes exists in the case of topological SIDs. >>>> >>>> >>>> > >>>> >>>> >>>> > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) >>>> has been successfully deployed >>>> >>>> >>>> > for many years before SR-MPLS has been introduced. What=E2=80=99s mo= re, >>>> >>>> >>>> > signaling of bypass tunnels he PLR usually did not include any of th= e >>>> >>>> >>>> > constraints used for computing of any specific LSP that the bypass L= SP >>>> >>>> >>>> > would protect =E2=80=93 because in the Facility Protection mode the = same >>>> >>>> >>>> > bypass LSP would be used to protect multiple LSPs passing thru the >>>> >>>> >>>> > failed link/node. >>>> >>>> >>>> > >>>> >>>> >>>> > From my POV the only difference between this behavior and that >>>> >>>> >>>> > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, = in the case of >>>> >>>> >>>> > RSVP-TE, the operator would explicitly indicate, as part of LSP >>>> >>>> >>>> > signaling, whether it would or would not use FRR; LSPs that would no= t >>>> >>>> >>>> > use FRR would then drop traffic rather than delivering it the wrong >>>> way. >>>> >>>> >>>> > >>>> >>>> >>>> > Such an option indeed does not exist in SR-TE today, but would be ea= sy >>>> >>>> >>>> > to provide if so desired IMHO. >>>> >>>> >>>> > >>>> >>>> >>>> > Did I miss something substantial? >>>> >>>> >>>> > >>>> >>>> >>>> > Regards, and lots of thanks in advance, >>>> >>>> >>>> > >>>> >>>> >>>> > Sasha >>>> >>>> >>>> > >>>> >>>> >>>> > Office: +972-39266302 >>>> >>>> >>>> > >>>> >>>> >>>> > Cell: +972-549266302 >>>> >>>> >>>> > >>>> >>>> >>>> > Email: Alexander.Vainshtein@ecitele.com >>>> >>>> >>>> > >>>> >>>> >>>> > *From:* spring *On Behalf Of *Shraddha >>>> Hegde >>>> >>>> >>>> > *Sent:* Tuesday, August 4, 2020 9:41 AM >>>> >>>> >>>> > *To:* EXT-Andrew.Alston@liquidtelecom.com >>>> >>>> >>>> > ; Robert Raszuk >>>> >>>> >>>> > *Cc:* spring@ietf.org; Joel M. Halpern >>>> >>>> >>>> > *Subject:* Re: [spring] Spring protection - determining applicabilit= y >>>> >>>> >>>> > >>>> >>>> >>>> > All, >>>> >>>> >>>> > >>>> >>>> >>>> > This is a very interesting discussion and thanks to Joel for startin= g >>>> >>>> >>>> > this discussion. IMO, when there are strict requirements of avoiding >>>> >>>> >>>> > certain nodes/links it can be realized either by defining a flex-al= go >>>> >>>> >>>> > avoiding those >>>> >>>> >>>> > >>>> >>>> >>>> > Nodes and links or by using a stack of unprotected adj-sids that avo= id >>>> >>>> >>>> > restricted nodes and links. When a stack of adj-sids is used to >>>> >>>> >>>> > realize the path, the head-end based (sBFD) protection mechanisms ca= n >>>> be applied. >>>> >>>> >>>> > >>>> >>>> >>>> > If Node-sids/prefix-sid/anycast-sids are used to build the stack, th= e >>>> >>>> >>>> > failure events may cause traffic to go through restricted nodes and >>>> >>>> >>>> > links. This would happen regardless of whether any kind of protectio= n >>>> >>>> >>>> > is in use or not. >>>> >>>> >>>> > >>>> >>>> >>>> > Rgds >>>> >>>> >>>> > >>>> >>>> >>>> > Shraddha >>>> >>>> >>>> > >>>> >>>> >>>> > Juniper Business Use Only >>>> >>>> >>>> > >>>> >>>> >>>> > *From:* spring >>> > >>> >> *On Behalf Of *Andrew Alston >>>> >>>> >>>> > *Sent:* Tuesday, August 4, 2020 5:41 AM >>>> >>>> >>>> > *To:* Robert Raszuk >>> >> >>>> >>>> >>>> > *Cc:* spring@ietf.org >; >>>> Joel M. Halpern >>>> >>>> >>>> > >>> >> >>>> >>>> >>>> > *Subject:* Re: [spring] Spring protection - determining applicabilit= y >>>> >>>> >>>> > >>>> >>>> >>>> > *[External Email. Be cautious of content]* >>>> >>>> >>>> > >>>> >>>> >>>> > Robert this is actually far more difficult when =E2=80=93 it can be = an entire >>>> >>>> >>>> > (long) series of nodes that need to be avoided. >>>> >>>> >>>> > >>>> >>>> >>>> > It could potentially be made to work but I=E2=80=99d worry that to d= o this =E2=80=93 >>>> >>>> >>>> > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative la= bels =E2=80=93 and that wouldn=E2=80=99t >>>> >>>> >>>> > be viable. >>>> >>>> >>>> > >>>> >>>> >>>> > It=E2=80=99s easier to use algorithms and adjacency sids and other s= uch things >>>> >>>> >>>> > to calculate paths =E2=80=93 the biggest trick is about the stack de= pth. When >>>> >>>> >>>> > you have this need for node avoidance =E2=80=93 the need for 10+ lab= el depth >>>> >>>> >>>> > is critical =E2=80=93 unless you wanna be applying one hell of a lot= of >>>> >>>> >>>> > binding labels along the way which is a nightmare. >>>> >>>> >>>> > >>>> >>>> >>>> > But to answer your question, is this a common use case =E2=80=93 it= =E2=80=99s a use >>>> >>>> >>>> > case that most of the people I discuss this with certain have =E2=80= =93 I cant >>>> >>>> >>>> > comment on a global scale, or for anyone else, but every indication = I >>>> >>>> >>>> > have is that yes =E2=80=93 its something people need, and want >>>> >>>> >>>> > >>>> >>>> >>>> > Andrew >>>> >>>> >>>> > >>>> >>>> >>>> > *From:* Robert Raszuk >>> >> >>>> >>>> >>>> > *Sent:* Tuesday, 4 August 2020 01:27 >>>> >>>> >>>> > *To:* Andrew Alston >>> > < >>>> mailto:Andrew.Alston@liquidtelecom.com >>>> >> >>>> >>>> >>>> > *Cc:* Joel M. Halpern >>> > >>> >>; spring@ietf.org >>>> >>>> >>>> > > >>>> >>>> >>>> > *Subject:* Re: [spring] Spring protection - determining applicabilit= y >>>> >>>> >>>> > >>>> >>>> >>>> > Is this a common use case ie. "but rather =E2=80=93 which nodes / n= etwork >>>> >>>> >>>> > segments it can never touch or flow through." >>>> >>>> >>>> > >>>> >>>> >>>> > If so perhaps its time to define notion of *negative-SID* ie. list i= n >>>> >>>> >>>> > the packet resources which given packet MUST not ever traverse. >>>> >>>> >>>> > >>>> >>>> >>>> > Put in the packet set of nodes or links which the packet should neve= r >>>> >>>> >>>> > traverse. >>>> >>>> >>>> > >>>> >>>> >>>> > That goes in line of recent wave of negative routing implementations >>>> >>>> >>>> > (RIFT) or discussions (LSR) >>>> >>>> >>>> > >>>> >>>> >>>> > Best, >>>> >>>> >>>> > R. >>>> >>>> >>>> > >>>> >>>> >>>> > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston >>>> >>>> >>>> > >>> > < >>>> mailto:Andrew.Alston@liquidtelecom.com >>>> >> wrote: >>>> >>>> >>>> > >>>> >>>> >>>> > So =E2=80=93 >>>> >>>> >>>> > >>>> >>>> >>>> > One of the use cases, in fact, some very major use cases in any >>>> >>>> >>>> > spring technology for us revolve around the following >>>> >>>> >>>> > >>>> >>>> >>>> > a.The explicit avoidance of certain nodes >>>> >>>> >>>> > >>>> >>>> >>>> > b.The explicit avoidance of certain sections of the network >>>> >>>> >>>> > >>>> >>>> >>>> > Anything that could result in that explicit avoidance being >>>> violated >>>> >>>> >>>> > =E2=80=93 would create, shall we say significant problems. >>>> >>>> >>>> > >>>> >>>> >>>> > Much of the use case is not a case of which nodes the packets fl= ow >>>> >>>> >>>> > through =E2=80=93 but rather =E2=80=93 which nodes / network seg= ments it can never >>>> >>>> >>>> > touch or flow through. Effectively, to be used as a technology = to >>>> >>>> >>>> > avoid certain things for specific reasons. >>>> >>>> >>>> > >>>> >>>> >>>> > This is also one of the reasons for needing such deep label >>>> stacks =E2=80=93 >>>> >>>> >>>> > this kind of detailed path programming tends to deepen the stack >>>> >>>> >>>> > because you sometimes have to be pretty explicit. >>>> >>>> >>>> > >>>> >>>> >>>> > It is absolutely critical to us that this functionality is there= =E2=80=93 >>>> >>>> >>>> > and that we can avoid situations which could cause traffic to >>>> >>>> >>>> > accidently hit things explicitly avoided. >>>> >>>> >>>> > >>>> >>>> >>>> > I wish I could be more specific than this, but it is what it is. >>>> >>>> >>>> > >>>> >>>> >>>> > Thanks >>>> >>>> >>>> > >>>> >>>> >>>> > Andrew >>>> >>>> >>>> > >>>> >>>> >>>> > *From:* spring >>> > >>> >> *On Behalf Of *Joel M. Halpern >>>> >>>> >>>> > *Sent:* Monday, 3 August 2020 21:36 >>>> >>>> >>>> > *To:* Robert Raszuk >>> >> >>>> >>>> >>>> > *Cc:* spring@ietf..org = > >>>> >>>> >>>> > *Subject:* Re: [spring] Spring protection - determining >>>> >>>> >>>> > applicability >>>> >>>> >>>> > >>>> >>>> >>>> > (Since the thread has gotten long enough, reiterating that this >>>> is as a >>>> >>>> >>>> > participant, not a WG chair.) >>>> >>>> >>>> > >>>> >>>> >>>> > Yes, we are talking IP networks. And yes, I have seen IP network= s >>>> that >>>> >>>> >>>> > choose to drop packets. For all sorts of reasons. >>>> >>>> >>>> > I think there are likely other reasons why one may not want a >>>> random >>>> >>>> >>>> > path rather than a chosen TE path. I think it is important we be >>>> clear >>>> >>>> >>>> > about what constraints may be / are violated when we tell people >>>> they >>>> >>>> >>>> > have this tool (protective rerouting) that is intended to >>>> preserve QoS. >>>> >>>> >>>> > >>>> >>>> >>>> > Let's be clear. I am not arguing that this is not a good idea. I= t >>>> is a >>>> >>>> >>>> > good idea. And useful. I am trying to figure otu what combinatio= n >>>> of >>>> >>>> >>>> > additional mechanisms and clear descriptions will lead to everyo= ne >>>> >>>> >>>> > getting the behavior they expect (which may not be the behavior >>>> they >>>> >>>> >>>> > desire, but sometimes is the best we can do.) >>>> >>>> >>>> > >>>> >>>> >>>> > Yours, >>>> >>>> >>>> > Joel >>>> >>>> >>>> > >>>> >>>> >>>> > On 8/3/2020 2:30 PM, Robert Raszuk wrote: >>>> >>>> >>>> > > Joel, >>>> >>>> >>>> > > >>>> >>>> >>>> > > Are we still talking about IP networks here ? Or perhaps some >>>> hard >>>> >>>> >>>> > > slicing with real resource reservations or detnets ? >>>> >>>> >>>> > > >>>> >>>> >>>> > > Because if we are talking about IP networking I have two >>>> >>>> >>>> > observations: >>>> >>>> >>>> > > >>>> >>>> >>>> > > A) If you need to traverse via a specific node (ie. firewall) >>>> you >>>> >>>> >>>> > better >>>> >>>> >>>> > > apply IP encapsulation to that node.. I don't think IP >>>> >>>> >>>> > encapsulation can >>>> >>>> >>>> > > be hijacked today such that destination address of the packet >>>> is >>>> >>>> >>>> > ignored. >>>> >>>> >>>> > > >>>> >>>> >>>> > > B) Have you seen any IP network where upon topology change >>>> (link >>>> >>>> >>>> > or node >>>> >>>> >>>> > > failure) you suddenly start dropping flows in spite of SPT >>>> offering >>>> >>>> >>>> > > perhaps few ms longer path with 10 ms more jitter ? >>>> >>>> >>>> > > >>>> >>>> >>>> > > Or are some SR marketing slides promise to turn IP networks i= n >>>> >>>> >>>> > > something new ? Worse ... do they mention path quality >>>> guarantees, >>>> >>>> >>>> > > resource reservations ? I hope not. >>>> >>>> >>>> > > >>>> >>>> >>>> > > Thx, >>>> >>>> >>>> > > R. >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern < >>>> jmh@joelhalpern.com >>>> > >>> >> >>> >> wrote: >>>> >>>> >>>> > > >>>> >>>> >>>> > > Well less serious for TE SIDs, I am not sure the problem is >>>> >>>> >>>> > restricted >>>> >>>> >>>> > > to just service SIDs. >>>> >>>> >>>> > > >>>> >>>> >>>> > > Suppose that the PCE has specified the path to meet some >>>> complex te >>>> >>>> >>>> > > objective. The bypass node has no way of knowing what those >>>> >>>> >>>> > > constraints >>>> >>>> >>>> > > were. And for some kinds of traffic, it is better to drop th= e >>>> packet >>>> >>>> >>>> > > than to deliver it outside the envelop. I suspect that the >>>> right >>>> >>>> >>>> > > answer >>>> >>>> >>>> > > to this is "too bad".. If so, as with the distinction >>>> regarding >>>> >>>> >>>> > service >>>> >>>> >>>> > > nodes, we should say so, shouldn't we? >>>> >>>> >>>> > > >>>> >>>> >>>> > > Yours, >>>> >>>> >>>> > > Joel >>>> >>>> >>>> > > >>>> >>>> >>>> > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: >>>> >>>> >>>> > > > Mach, Joel and all, >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > I think that in most cases: >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > 1.There is clear differentiation between "topological" and >>>> >>>> >>>> > "service" >>>> >>>> >>>> > > > instructions in SID advertisements. E.g.: >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in t= he >>>> >>>> >>>> > > > corresponding IGP advertisements) represent topological >>>> >>>> >>>> > instructions >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04 >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%= 2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1= oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24 >>>> >> >>>> >>>> >>>> > > >>>> >>>> >>>> > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D i= nstructions >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > 2.Segments that represent topological instructions can be >>>> bypassed, >>>> >>>> >>>> > > > while segments that represent service instructions require >>>> >>>> >>>> > > alternative >>>> >>>> >>>> > > > protection mechanisms. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > This view seems to be aligned with RFC 8402 >>>> >>>> >>>> > > > < >>>> https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A= %2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%= 3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRD= uiDo0I4Ybtm%24 >>>> >> >>>> >>>> >>>> > that says in Section 1: >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > In the context of an IGP-based distributed control >>>> plane, two >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > topological segments are defined: the IGP-Adjacency segment >>>> and the >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > IGP-Prefix segment. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > In the context of a BGP-based distributed control plane= , >>>> two >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > topological segments are defined: the BGP peering segment >>>> and the >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > BGP-Prefix segment. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > In the case of SR-MPLS this differentiation is assumed in >>>> Section >>>> >>>> >>>> > > 3.4 of >>>> >>>> >>>> > > > the Node Protection for SR-TE Path >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protectio= n-for-sr-te-paths-07%23section-3.4 >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%= 2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BI= w%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDu= iDo9wO-Ssn%24 >>>> >> >>>> >>>> >>>> > > >>>> >>>> >>>> > > > draft that says: >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > The node protection mechanism described in the previous >>>> >>>> >>>> > sections >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > depends on the assumption that the label immediately >>>> below >>>> >>>> >>>> > > the top >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > label in the label stack is understood in the IGP domain. >>>> When the >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > provider edge routers exchange service labels via BGP o= r >>>> some >>>> >>>> >>>> > > other >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > non-IGP mechanism the bottom label is not understood in >>>> the IGP >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > domain. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > The egress node protection mechanisms described in the >>>> draft >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > [RFC8679 < >>>> https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679 >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%= 2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6v= pRHOGt8AkTRDuiDo8MGipXc%24 >>>> >>] >>>> >>>> >>>> > is >>>> >>>> >>>> > > > applicable to this use case and no additional changes >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > will be required for SR based networks >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > The scenarios in which differentiation between >>>> =E2=80=9Ctopological=E2=80=9D and >>>> >>>> >>>> > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed= problematic. >>>> E.g., >>>> >>>> >>>> > > consider >>>> >>>> >>>> > > > the use case in which a Node SID in the ERO of a SR-TE path >>>> >>>> >>>> > > identifies a >>>> >>>> >>>> > > > node that acts as a firewall for all packets it receives, >>>> i.e., >>>> >>>> >>>> > > provides >>>> >>>> >>>> > > > the firewall service without any dedicated service SID >>>> >>>> >>>> > > identifying it. >>>> >>>> >>>> > > > One could say that the Node SID of such a node would combin= e >>>> >>>> >>>> > > topological >>>> >>>> >>>> > > > and service instructions thus breaking the differentiation >>>> >>>> >>>> > > between the two. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D S= IDs could be >>>> prevented >>>> >>>> >>>> > > or at >>>> >>>> >>>> > > > least discouraged. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > If not, providing an ability to identify such SIDs in the >>>> >>>> >>>> > > advertisement >>>> >>>> >>>> > > > mechanisms would be useful IMHO. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > My 2c, >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > Sasha >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > Office: +972-39266302 >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > Cell: +972-549266302 >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > Email: Alexander.Vainshtein@ecitele.com >>>> >>>> >>>> > >>> > >>>> >>>> >>>> > > >>> > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > -----Original Message----- >>>> >>>> >>>> > > > From: spring >>> > >>> >> >>>> >>>> >>>> > >> On >>>> Behalf Of Mach Chen >>>> >>>> >>>> > > > Sent: Monday, August 3, 2020 6:30 AM >>>> >>>> >>>> > > > To: Joel M. Halpern >>> > >>> >> >>> >>; >>>> >>>> >>>> > spring@ietf.org > < >>>> mailto:spring@ietf.org > >>>> >>>> >>>> > > > Subject: Re: [spring] Spring protection - determining >>>> applicability >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > Hi Joel, >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > I think this is a good point that may not be discussed in t= he >>>> >>>> >>>> > > past. And >>>> >>>> >>>> > > > I also don't think there is a "can be bypassed" indication >>>> in the >>>> >>>> >>>> > > > routing advertisement for now. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > IMHO, the information advertised by routing is neutral, suc= h >>>> >>>> >>>> > > information >>>> >>>> >>>> > > > (can or cannot be bypassed) is more path specific, thus >>>> >>>> >>>> > normally the >>>> >>>> >>>> > > > controller should be responsible for deciding whether/which >>>> SID >>>> >>>> >>>> > > can be >>>> >>>> >>>> > > > bypassed. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > Best regards, >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > Mach >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > -----Original Message----- >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > From: spring [mailto:spring-bounces@ietf.org >>>> >>>> >>>> > > > >>>> >>>> >>>> > < >>>> mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.o= rg%3e >>>> >>>> >] >>>> >>>> >>>> > On Behalf Of Joel M. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Halpern >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Sent: Monday, August 3, 2020 7:51 AM >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > To: spring@ietf.org >>> > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>> > < >>>> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org >>>> >>> >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Subject: [spring] Spring protection - determining >>>> applicability >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > (WG Chair hat Off, this is merely a note from a slightly >>>> >>>> >>>> > > confused WG >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > participant.) >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > I have been reading the various repair drafts, and the >>>> various >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > networks programming and service programming draft, and = I >>>> am >>>> >>>> >>>> > > trying to >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > figure out one aspect of the combination. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > How does a node that is doing some form of bypass >>>> (suppose, for >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > simplicity, it is Node N2 deciding to bypass the next SI= D >>>> for >>>> >>>> >>>> > > a failed >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > node N3) know that it is safe to do so? >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > If the path was just for TE, then it is "safe" if the ne= w >>>> path >>>> >>>> >>>> > > meets >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > the TE criteria. or maybe it is safe if it is even >>>> close, as >>>> >>>> >>>> > > long as >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > it is not used for too long. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > But what if the node were a Firewall, included to meet >>>> legal >>>> >>>> >>>> > > > requirements? >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Or was some other necessary programmatic transform (winc= e >>>> we are >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > deliberately vague about what nodes can do when asked >>>> suitably.) >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Is there some "can be bypassed" indication in the routin= g >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > advertisements that I missed? >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Thank you, >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Yours, >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > Joel >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > _______________________________________________ >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > spring mailing list >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > spring@ietf..org < >>>> mailto:spring@ietf.org > >>>> >>>> >>>> > > >>>> >>>> >>>> > > >>> > < >>>> mailto:spring@ietf.org%20%3cmailto:spring@ietf.org >>>> >>> >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > >>>> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A= %2 >>>> >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4Ki= UkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FY= NE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24 >>>> >>>> > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A= %252 >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiU= kzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9F= YNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24 >>>> >> >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > > F%2Fwww.ietf.org >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-g= k%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 >>>> >>>> > >>>> >>>> >>>> > > < >>>> https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%= 2F%2F2Fwww.ietf.org >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-g= k%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 >>>> >>%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > _______________________________________________ >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > spring mailing list >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > spring@ietf.org > >>>> >>>> >>>> > > < >>>> mailto:spring@ietf.org >>>> > >>> >> >> >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > >>>> https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4Ki= UkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Fli= stinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm= 0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24 >>>> >>>> > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > >>>> ----------------------------------------------------------------------= -- >>>> >>>> >>>> > > > Notice: This e-mail together with any attachments may conta= in >>>> >>>> >>>> > > > information of Ribbon Communications Inc. that is >>>> confidential >>>> >>>> >>>> > > and/or >>>> >>>> >>>> > > > proprietary for the sole use of the intended recipient. Any >>>> review, >>>> >>>> >>>> > > > disclosure, reliance or distribution by others or forwardin= g >>>> >>>> >>>> > without >>>> >>>> >>>> > > > express permission is strictly prohibited. If you are not t= he >>>> >>>> >>>> > > intended >>>> >>>> >>>> > > > recipient, please notify the sender immediately and then >>>> delete all >>>> >>>> >>>> > > > copies, including any attachments. >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > >>>> ----------------------------------------------------------------------= -- >>>> >>>> >>>> > > > >>>> >>>> >>>> > > > _______________________________________________ >>>> >>>> >>>> > > > spring mailing list >>>> >>>> >>>> > > > spring@ietf.org > = < >>>> mailto:spring@ietf.org > >>>> >>>> >>>> > > > >>>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%= 2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vp= RHOGt8AkTRDuiDo5KlPnbj%24 >>>> >>>> > >>>> >>>> >>>> > > > >>>> >>>> >>>> > > >>>> >>>> >>>> > > _______________________________________________ >>>> >>>> >>>> > > spring mailing list >>>> >>>> >>>> > > spring@ietf.org > < >>>> mailto:spring@ietf.org > >>>> >>>> >>>> > > >>>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A= %2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%= 2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vp= RHOGt8AkTRDuiDo5KlPnbj%24 >>>> >>>> > >>>> >>>> >>>> > > >>>> >>>> >>>> > >>>> >>>> >>>> > _______________________________________________ >>>> >>>> >>>> > spring mailing list >>>> >>>> >>>> > spring@ietf.org > >>>> >>>> >>>> > >>>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> > >>>> >>>> >>>> > < >>>> https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A= % >>>> >>>> >>>> > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org >>>> %2Fmailman%2Flisti >>>> >>>> >>>> > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxq= gu >>>> >>>> >>>> > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> >>>> >>>> >>>> > >>>> >>>> >>>> > >>>> >>>> >>>> > >>>> >>>> >>>> > --------------------------------------------------------------------= -- >>>> >>>> >>>> > -- >>>> >>>> >>>> > Notice: This e-mail together with any attachments may contain >>>> >>>> >>>> > information of Ribbon Communications Inc. that is confidential and/o= r >>>> >>>> >>>> > proprietary for the sole use of the intended recipient. Any review, >>>> >>>> >>>> > disclosure, reliance or distribution by others or forwarding without >>>> >>>> >>>> > express permission is strictly prohibited. If you are not the intend= ed >>>> >>>> >>>> > recipient, please notify the sender immediately and then delete all >>>> >>>> >>>> > copies, including any attachments. >>>> >>>> >>>> > --------------------------------------------------------------------= -- >>>> >>>> >>>> > -- >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> >>>> spring mailing list >>>> >>>> >>>> spring@ietf.org >>>> >>>> >>>> >>>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> _______________________________________________ >>>> >>>> >>>> spring mailing list >>>> >>>> >>>> spring@ietf.org >>>> >>>> >>>> >>>> https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> Notice: This e-mail together with any attachments may contain >>>> information of Ribbon Communications Inc. that is confidential and/or >>>> proprietary for the sole use of the intended recipient. Any review, >>>> disclosure, reliance or distribution by others or forwarding without >>>> express permission is strictly prohibited. If you are not the intended >>>> recipient, please notify the sender immediately and then delete all co= pies, >>>> including any attachments. >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> >>>> spring mailing list >>>> >>>> >>>> spring@ietf.org >>>> >>>> >>>> https://www.ietf.org/mailman/listinfo/spring >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> spring mailing list >>> >>> spring@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> -- >> >> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD >> >> --000000000000850c5a05ad1a1baf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Jeff,

    If one would allocate SIDs in = a smart way they can include algorithmically encoded information if packets= are FRR eligible. No increase=C2=A0in IGP flooding. No duplication of SID = space. Just local behaviour.

    For SRv6 - trivial. F= or SR-MPLS, also pretty simple provided one would be keen on using MPLS for= warding paradigm for some time :)=C2=A0=C2=A0

    Hint= : think even/odd (1 bit in the SID) - well known in a domain - and used cor= rectly by your vendor.=C2=A0

    Best,
    R.

    On M= on, Aug 17, 2020 at 11:54 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
    Hi Robert,

    "possession of enough information in PLR=E2=80=9D what do you call thi= s, if not more state, given this information is not present there today?

    Cheers,
    Jeff
    On Aug 17, 2020, 2:25 PM -0700, Robert Ra= szuk <robert@rasz= uk.net>, wrote:
    Hi Jeff,

    This is not about more state in the network nor about=C2=A0including m= irror service node in the backup path for some flows.=C2=A0

    The thread is about possession of enough information in PLR to either = take the packet and shift it over backup path or just drop it.=C2=A0

    - - -

    Btw - path protection is completely orthogonal to the above.=C2=A0

    Cheers,
    Robert.


    On Mon, Aug 17, 2020 at 11:03 PM Jeff= Tantsura <= jefftant.ietf@gmail.com> wrote:
    Gyan,

    TI-LFA computation is local to the PLR and is topology dependent, e.g chang= e in downstream topology could/would influence the choice of MP (PQ) node.<= br> While an implementation could take into consideration some additional meta-= data (e.g. locally provisioned SRLG, usually used to avoid protected and pr= otecting ports on the same line card), this is not a standardized method.= =C2=A0=C2=A0
    If a service node must be included in a backup path, there=E2=80=99s a stat= e associated with it as well as distribution of the state involved.=C2=A0
    Back to my point, removing state and introducing services in the network (a= t the very least at the computational logic and head-end level) are mutuall= y exclusive, trade-offs are inevitable (You can't eat your cake and hav= e it).
    Keeping the state limited to:
    - a logically centralized computational logic (aka PCE) - off path, scales = horizontally, could use additional business logic for the path computation,= example - CPU/memory consumption on a service node
    - head-end - anchor to primary/backup paths
    seems like a reasonable set of trade-offs.

    Cheers,
    Jeff
    On Aug 14, 2020, 7:44 PM -0700, Gyan Mish= ra <hayabusag= sm@gmail.com>, wrote:

    Catching up on this thread as it is a interesting topic a= s FRR 1:N link protection, node protection and path protection is critical = to operators.

    There are multiple somewhat orthogonal topics brought up = in the discussion.

    Excluding SR SFC from =E2=80=9Cbypass=E2=80=9D capable no= de such for appliances such as firewalls and load balancer.=C2=A0 Makes sen= se.=C2=A0 I would not think SFC would be in a PLR path to merger point but = I could be mistaken.

    The goal of SR is eliminating state and so having TE like= state is undesirable.=C2=A0

    Intent based instantiation of bypass via SR-TE from netwo= rk feedback at PLR detection node of a failure and make before break pre co= mputed backup paths that can. =C2=A0=C2=A0

    It would make sense that SR-TE binding SID policy would b= e appropriate for RSVP like FRR link node or path protection.

    My thoughts on this topic of SR protection is that don=E2= =80=99t we already have FRR protection natively without requiring SR-TE BSI= D or any additional undesirable state maintenance with TI-LFA.

    Thanks=C2=A0

    Gyan

    On Fri, Aug 14, 2020 at 5:47 PM Jeff = Tantsura <j= efftant.ietf@gmail.com> wrote:












    PCE computation in this case is trivial too(must traverse= node B or node X) else FAIL.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:44 PM -0700, Jeff Tant= sura <jefft= ant.ietf@gmail.com>, wrote:






    Robert,





    Agreed and apologies, hit send before finishing the email (it is Friday) ;-= )





    Path protection in this case make more sense and is much less complex,=C2= =A0


    if in the pathA (A->B->C) node B is a service node, it can=E2=80=99t = be bypassed (node protected) if the link between A and B breaks=C2=A0


    however it could have a backup pathB (A->X->C) where X is the service= node, potentially synchronizing its state with the node B.





    To my previous email - at expense of more state, we provide path and servic= e protection, hence the similarity with RSVP-TE trade-offs.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:30 PM -0700, Robert Ra= szuk <robert@rasz= uk.net>, wrote:




    Jeff,




    > This is very similar to RSVP-TE=C2=A0=C2=A0





    I would rather differ on that statement.=C2=A0





    See if you are using SR just for TE you are 100% right.=C2=A0





    But if your SIDs embed additional local SR node processing functions t= his suddenly=C2=A0becomes a completely different game. Let's keep this = in mind in this thread/topic.=C2=A0





    Kind regards,


    R.












    On Fri, Aug 14, 2020 at 11:15 PM Jeff= Tantsura <= jefftant.ietf@gmail.com> wrote:








    This is very similar to RSVP-TE, path vs link/node protec= tion and usually dictated by the business logic, the triggers are obviously= very different, head-end being notified of the failure on a path and switc= hing to the backup path vs reaction to a local failure, so same considerati= ons apply:=C2=A0


    -more state


    -pre-reserved resources


    while=C2=A0


    -predictable


    -meets SLA (as good as primary)


    vs


    -less state


    -local


    -best effort / can cause congestions=C2=A0







    Cheers,

    Jeff






    On Aug 14, 2020, 10:46 AM -0700, Ketan Ta= laulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>, wrote:






    Hi Robert,



    =C2=A0



    We do not have a signalling mechanism in IGPs = today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SID= s. If there was a desire for it, an IGP extension would be required (there = is none in progress AFAIK). Note that this results in doubling the prefix S= ID scale (global labels) in the network. So I would not go about this trivi= ally.



    =C2=A0



    I think it helps to get more inputs and perspe= ctives from operators on their views for doing a bypass via local protectio= n for segments in an SR Policy. There may be those that prefer end-to-end p= ath protection using a fallback path that is say disjoint with the primary = but provides an appropriate SLA/intent?



    =C2=A0



    Thanks,



    Ketan



    =C2=A0





    From: Robert Raszuk <robert@raszuk.net>


    Sent: 14 August 2020 23:04


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>





    =C2=A0





    Ketan,





    =C2=A0







    Looks like we are pretty much in sync here.=C2=A0





    =C2=A0







    But let me just observe that I purposely=C2=A0did no= t mention about SR policies as we are not able to signal the intent with th= e packets itself.=C2=A0







    =C2=A0







    So all we have there is SIDs. BSIDs or prefix SIDs n= eed to be flooded with information if policies build with using them are by= pass eligible or not.=C2=A0







    =C2=A0







    I was actually under the impression that this is alr= eady there and I am just not aware, but looking deeper indeed I do not see = this marking neither in ISIS nor OSPF for prefix SIDs.=C2=A0







    =C2=A0







    Is there some work in progress to add it to those pr= otocols or have we just documented need=C2=A0for a short LSR draft=C2=A0 ?= =C2=A0







    =C2=A0







    Thx,







    R.







    =C2=A0







    =C2=A0







    On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:











    Hi Robert,



    =C2=A0



    Please check inline below.



    =C2=A0





    From: Robert Raszuk <robert@raszuk.net>


    Sent: 14 August 2020 21:13


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>





    =C2=A0





    Hi Ketan,





    =C2=A0







    While I completely agree with your note the conseque= nces of it are pretty sevre.=C2=A0



    [KT] I understand. We need to be mindful of im= plications of protection schemes for the SLAs/intent of SR Policies.







    =C2=A0







    Unless we signal which prefix SID is protection elig= ible and which is not how would other nodes know if they can protect it or = not ?=C2=A0



    [KT] Correct. To be more accurate, we need to = consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR = Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for local = protection for some of those SR Policies. We also have path-protection mech= anisms.







    =C2=A0







    It seems that today's safe thing is not to apply= any node protection on SR flows at the PLRs then.=C2=A0







    =C2=A0







    And link protection MUST assure that packets will ar= rive at the neighbor node via some other link regardless of further path to= wards destination.=C2=A0



    [KT] Yes. We have a mechanism to indicate whic= h adj-SIDs have protection (that mechanism only provides link protection to= get to the neighbor node) so the SR Policy computation is able to indicate= whether that specific link is =E2=80=9Cbypass-able=E2=80=9D or not by its = choice of protected or unprotected adj-SIDs respectively.



    =C2=A0



    Thanks,



    Ketan







    =C2=A0







    Is it correct ?=C2=A0







    =C2=A0







    Thx







    R







    =C2=A0







    On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:











    Hi Sasha,



    =C2=A0



    The service node advertises its own Prefix SID.. The= service function that this service node implements does not require any co= ntext (i.e. all packets arriving at the node are subjected to that service)= . Therefore the service node does not need to receive a packet with it=E2= =80=99s own Prefix SID.



    =C2=A0



    Thus, we cannot assume that when PHP is used, then t= he SID is only associated with a topological instruction.



    =C2=A0



    Hope that clarifies?



    =C2=A0



    Thanks,



    Ketan



    =C2=A0







    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>


    Sent: 14 August 2020 20:24


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com &= lt;And= rew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>


    Cc: spring@ietf= .org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>







    =C2=A0



    Ketan, and all,



    I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs= that are advertised with PHP can=C2=A0 ONLY represent topological instruct= ions in SR-MPLS - because the advertising node will not receive them and th= erefore can hardly be expected to associate any service function with them.=



    =C2=A0



    This is complementary to what you have said.



    =C2=A0



    Hope this clarifies my position.



    What, if anything, did I miss?



    =C2=A0



    Regards,



    Sasha







    =C2=A0





    Get Outlook for Android









    =C2=A0











    From: Ketan Talaulikar (ketant) <ketant@cisco.com>


    Sent: Friday, August 14, 2020, 16:23


    To: = Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alston@liqu= idtelecom.com; Robert Raszuk


    Cc: = spring@ietf.org

    Subject: RE: [spring] Spring protection - determining applicability





    =C2=A0







    NOTICE: This email was received from an EXTERNAL sen= der







    =C2=A0





    Hi Sasha,



    =C2=A0



    If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don=E2=80=99t see why PHP could not be done for a Prefix SID associ= ated with a service node.



    =C2=A0



    Also, I didn=E2=80=99t follow the point that you wer= e trying to make about Adj-SIDs.



    =C2=A0



    Thanks,



    Ketan



    =C2=A0







    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>


    Sent: 14 August 2020 18:24


    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha@juni= per.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidte= lecom.com>; Robert Raszuk <robert@raszuk.net>


    Cc: spring@ietf= .org


    Subject: Re: [spring] Spring protection - determining applicability<= /span>







    =C2=A0



    Hi all,



    Regarding the statement "Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it":



    =C2=A0



    =C2=A0



    I think that in SR-MPLS a Node SID that is advertised with PHP a= citon can be safely considered as "just a topological instruction"= ; by the PLR because the originating node will not receive it.



    The same applies to Adj-SDIs.



    =C2=A0



    My 2c.







    =C2=A0





    Get O= utlook for Android









    =C2=A0











    From: spring <spring-bounces@ietf.org> on behalf of Ketan Ta= laulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>


    Sent: Friday, August 14, 2020, 15:00


    To: = Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@liqu= idtelecom.com; Robert Raszuk


    Cc: = spring@ietf.org

    Subject: Re: [spring] Spring protection - determining applicability





    =C2=A0





    Hi All,





    I would like to share a different perspective on this.





    First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].





    This is about local repair at a PLR. By it's very nature, the PLR does = not have a notion of how "strict or not" is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Polic= y headend and/or computation-node.





    We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) = to indicate whether a Prefix SID can be bypassed or not. This provides the = opportunity for the computation to use one or the other flavor depending on= the nature of the SLA for the SR Policy.





    I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".





    As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or = not.





    For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alte= rnate path using the path protection approach. This is something that is de= scribed and in use in deployments today [1]..





    Thanks,


    Ketan





    [1] https://clicktime.symantec.com/3Y3= fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-iet= f-spring-segment-routing-policy-08%23section-9


    [2] https://clicktime.symantec.com/3= 6fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-i= etf-spring-segment-routing-policy-08%23section-9.3





    -----Original Message-----


    From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern


    Sent: 04 August 2020 20:25


    To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EXT-Andrew.Alston@liqu= idtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <= robert@raszuk.net>


    Cc:     spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>


    Subject: Re: [spring] Spring protection - determining applicability





    There are, as far as I can tell, a number of ways to address this family of= related questions.


    What struck me, and prompted the starting question, was that none of them w= ere spelled out.=C2=A0 I see lots of interesting ideas / proposals.


    Some of them are compatible with others.=C2=A0=C2=A0 Some are not.


    It would be good if we could reach agreement on how we thought it should be= handled.





    Thank you,


    Joel





    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:


    > Hi all,


    >


    > I am still not sure that the problem of bypass going thru undesirable<= br>

    > links/nodes exists in the case of topological SIDs.


    >


    > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090


    > <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed


    > for many years before SR-MPLS has been introduced. What=E2=80=99s more= ,


    > signaling of bypass tunnels he PLR usually did not include any of the<= br>

    > constraints used for computing of any specific LSP that the bypass LSP=


    > would protect =E2=80=93 because in the Facility Protection mode the sa= me


    > bypass LSP would be used to protect multiple LSPs passing thru the


    > failed link/node.


    >


    >=C2=A0 From my POV the only difference between this behavior and that

    > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of


    > RSVP-TE, the operator would explicitly indicate, as part of LSP


    > signaling, whether it would or would not use FRR; LSPs that would not<= br>

    > use FRR would then drop traffic rather than delivering it the wrong wa= y.


    >


    > Such an option indeed does not exist in SR-TE today, but would be easy=


    > to provide if so desired IMHO.


    >


    > Did I miss something substantial?


    >


    > Regards, and lots of thanks in advance,


    >


    > Sasha


    >


    > Office: +972-39266302


    >


    > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302


    >


    > Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com


    >


    > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde

    > *Sent:* Tuesday, August 4, 2020 9:41 AM


    > *To:* EXT-Andrew.Alston@liquidtelecom.com


    > <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>


    > *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>


    > *Subject:* Re: [spring] Spring protection - determining applicability<= br>

    >


    > All,


    >


    > This is a very interesting discussion and thanks to Joel for starting<= br>

    > this discussion. IMO, when there are strict requirements of avoiding

    > certain nodes/links it can be realized=C2=A0 either by defining a flex= -algo


    > avoiding those


    >


    > Nodes and links or by using a stack of unprotected adj-sids that avoid=


    > restricted nodes and links. When a stack of adj-sids is used to


    > realize the path, the head-end based (sBFD) protection mechanisms can = be applied.


    >


    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the<= br>

    > failure events may cause traffic to go through restricted nodes and

    > links. This would happen regardless of whether any kind of protection<= br>

    > is in use or not.


    >


    > Rgds


    >


    > Shraddha


    >


    > Juniper Business Use Only


    >


    > *From:* spring <spring-bounces@ietf.org
     > <mailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston


    > *Sent:* Tuesday, August 4, 2020 5:41 AM


    > *To:* Robert Raszuk <    robert@raszuk.net <mailto:robert@raszuk.net>>


    > *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern


    > <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>


    > *Subject:* Re: [spring] Spring protection - determining applicability<= br>

    >


    > *[External Email. Be cautious of content]*


    >


    > Robert this is actually far more difficult when =E2=80=93 it can be an= entire


    > (long) series of nodes that need to be avoided.


    >


    > It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93


    > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t


    > be viable.


    >


    > It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things


    > to calculate paths =E2=80=93 the biggest trick is about the stack dept= h.=C2=A0 When


    > you have this need for node avoidance =E2=80=93 the need for 10+ label= depth


    > is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f


    > binding labels along the way which is a nightmare.


    >


    > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use


    > case that most of the people I discuss this with certain have =E2=80= =93 I cant


    > comment on a global scale, or for anyone else, but every indication I<= br>

    > have is that yes =E2=80=93 its something people need, and want


    >


    > Andrew


    >


    > *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>


    > *Sent:* Tuesday, 4 August 2020 01:27


    > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
     > &= lt;mai= lto:Andrew.Alston@liquidtelecom.com>>


    > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
     > <mailto:jmh@joelhalpern.com>>= ;; spring@ietf.org=


    > <mailto:spring= @ietf.org>


    > *Subject:* Re: [spring] Spring protection - determining applicability<= br>

    >


    > Is this a common use case ie.=C2=A0 "but rather =E2=80=93 which n= odes / network


    > segments it can never touch or flow through."


    >


    > If so perhaps its time to define notion of *negative-SID* ie. list in<= br>

    > the packet resources which given=C2=A0packet MUST not ever traverse.

    >


    > Put in the packet set of nodes or links which the packet should never<= br>

    > traverse.


    >


    > That goes in line of recent wave of negative routing implementations

    > (RIFT) or discussions (LSR)


    >


    > Best,


    > R.


    >


    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston


    > <Andrew.Alston@liquidtelecom.com
     > <mailto:Andrew.Alston@li= quidtelecom.com>> wrote:


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very major= use cases in any


    >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve around the fo= llowing


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain nodes


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain sections o= f the network


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that explicit av= oidance being violated


    >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say significa= nt problems.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case of which no= des the packets flow


    >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 which n= odes / network segments it can never


    >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effectively, to b= e used as a technology to


    >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific reasons.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for needing su= ch deep label stacks =E2=80=93


    >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming tends t= o deepen the stack


    >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pretty explic= it.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this func= tionality is there =E2=80=93


    >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations which could c= ause traffic to


    >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly avoided.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than this, but= it is what it is.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 *From:* spring <spring-bounces@ietf.org
     >= =C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> *On Behalf Of *Jo= el M. Halpern


    >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36


    >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=


    >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring@ietf..org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: [spring] Spring protection - de= termining


    > applicability


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long enough, reit= erating that this is as a


    >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.)


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that


    >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. For all sorts of reaso= ns.


    >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons why one= may not want a random


    >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. I think it = is important we be clear


    >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are violated w= hen we tell people they


    >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerouting) that is = intended to preserve QoS.


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing that this= is not a good idea. It is a


    >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying to figure o= tu what combination of


    >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descriptions w= ill lead to everyone


    >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (which may no= t be the behavior they


    >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can do.)<= br>

    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 Yours,


    >=C2=A0=C2=A0=C2=A0=C2=A0 Joel


    >


    >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about IP netwo= rks=C2=A0here ? Or perhaps some hard


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reservat= ions or detnets ?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talking=C2= =A0about IP networking I have two


    >=C2=A0=C2=A0=C2=A0=C2=A0 observations:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via a sp= ecific node (ie. firewall) you


    >=C2=A0=C2=A0=C2=A0=C2=A0 better


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to that node= .. I don't think IP


    >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that destina= tion address of the packet is


    >=C2=A0=C2=A0=C2=A0=C2=A0 ignored.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP network whe= re upon topology change (link


    >=C2=A0=C2=A0=C2=A0=C2=A0 or node


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0start dr= opping=C2=A0flows in spite of SPT offering


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path with 10 = ms more jitter ?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing slides pro= mise to turn IP networks in


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new ? Worse ... do t= hey mention path quality guarantees,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0? I hope= not.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R.


    >=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
     >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.co= m%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SIDs, I am= not sure the problem is


    >=C2=A0=C2=A0=C2=A0=C2=A0 restricted


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has specified = the path to meet some complex te


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass node ha= s no way of knowing what those


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some kinds of t= raffic, it is better to drop the packet


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside the enve= lop.=C2=A0 I suspect that the right


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is "too bad"..=C2= =A0 If so, as with the distinction regarding


    >=C2=A0=C2=A0=C2=A0=C2=A0 service


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn= 9;t we?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most cases:

    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differentiati= on between "topological" and


    >=C2=A0=C2=A0=C2=A0=C2=A0 "service"


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID advertisem= ents. E.g.:


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP advertisemen= ts) represent topological


    >=C2=A0=C2=A0=C2=A0=C2=A0 instructions


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services


    >=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 <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
     >=C2=A0= =C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3GC5af2z3JzphZDkPnc= HAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ie= tf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-g= k%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24= >>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent topo= logical instructions can be bypassed,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that represent = service instructions require


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be aligned = with RFC 8402


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%= 2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3= B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDu= iDo0I4Ybtm%24>>


    >=C2=A0=C2=A0=C2=A0=C2=A0 that says in Section 1:


    >=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 In the cont= ext of an IGP-based distributed control plane, two


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the IGP-Adjacency segment and the


    >=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 IGP-Prefix = segment.


    >=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 In the cont= ext of a BGP-based distributed control plane, two


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the BGP peering segment and the


    >=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 BGP-Prefix = segment.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this di= fferentiation is assumed in Section


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for SR-TE = Path


    >=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 <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
     >=C2=A0=C2=A0= =C2=A0=C2=A0 <https://clicktime.s= ymantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv= 3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-nod= e-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>= ;


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft that says:


    >=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 The node pr= otection mechanism described in the previous


    >=C2=A0=C2=A0=C2=A0=C2=A0 sections


    >=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 depends on = the assumption that the label immediately below


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack is un= derstood in the IGP domain.=C2=A0 When the


    >=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 provider ed= ge routers exchange service labels via BGP or some


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other


    >=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 non-IGP mec= hanism the bottom label is not understood in the IGP


    >=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 domain.


    >=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 The egress = node protection mechanisms described in the draft


    >=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 [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
     >=C2=A0=C2=A0= =C2=A0=C2=A0 <https:= //clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F%2Furlde= fense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__= %3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTR= DuiDo8MGipXc%24>>]


    >=C2=A0=C2=A0=C2=A0=C2=A0 is


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use case an= d no additional changes


    >=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 will be req= uired for SR based networks


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2=A0d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a Node S= ID in the ERO of a SR-TE path


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firewall f= or all packets it receives, i.e.,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service without a= ny dedicated service SID


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the Node SI= D of such a node would combine


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus = breaking the differentiation


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ability t= o identify such SIDs in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMH= O.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein@ecitele= .com


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:Alexander.Vainshtein@ecitele.com>=


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:Alexander.Vainshtein@ecitele.= com>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > -----Original Message-----


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > From: spring <spring-bounces@ietf.org<= br> >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org%0b>>=


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2020 6= :30 AM


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern <jmh@joelhalpern.com >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern= .com>>;


    >=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: [spring] Spring p= rotection - determining applicability


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good point t= hat may not be discussed in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there i= s a "can be bypassed" indication in the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now.=


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information advertis= ed by routing is neutral, such


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypassed) is= more path specific, thus


    >=C2=A0=C2=A0=C2=A0=C2=A0 normally the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be responsib= le for deciding whether/which SID


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Messa= ge-----


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > From: spring [mailt= o:spring-bounc= es@ietf.org


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring-bounces@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>]

    >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M.


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, Augus= t 3, 2020 7:51 AM


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
     >=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Subject: [spring] S= pring protection - determining applicability


    >=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 > (WG Chair hat Off, = this is merely a note from a slightly


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.)


    >=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 > I have been reading= the various repair drafts, and the various


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programmin= g and service programming draft, and I am


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspe= ct of the combination.


    >=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 > How does a node tha= t is doing some form of bypass (suppose, for


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is N= ode N2 deciding to bypass the next SID for


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know that = it is safe to do so?


    >=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 > If the path was jus= t for TE, then it is "safe" if the new path


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2= =A0 or maybe it is safe if it is even close, as


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used for = too long.


    >=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 > But what if the nod= e were a Firewall, included to meet legal


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements?


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other n= ecessary programmatic transform (wince we are


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague = about what nodes can do when asked suitably.)


    >=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 > Is there some "= ;can be bypassed" indication in the routing


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements that= I missed?


    >=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 > Thank you,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel


    >=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=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing list=


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring@ietf..org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
     >=C2=A0=C2=A0=C2=A0=C2=A0 <= mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>


    >=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=A0 https://clicktim= e.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3= Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3= A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A= 2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo6HwPLil%24>


    >=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 <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
     &= gt;=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3A= 5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%= 2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A25= 2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDozoQiAHk%24>>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > F%2Fwww.ietf.org


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.s= ymantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv= 3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQA= tQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
     >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6= H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring


    >=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 > > spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org> <mailto:spring@ietf.org
     >=C2=A0=C2=A0= =C2=A0=C2=A0 <ma= ilto:spring@ietf.org%0b>> <mailto:spring@ietf.org>>


    >=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 https://clicktime.symantec.com/367qhU4KiUkzW9uG= C4eAvP46H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring=


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiR= nfMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sy= mantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.= org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>

    >=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=A0 >


    >=C2=A0=C2=A0=C2=A0=C2=A0 ----------------------------------------------= --------------------------


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Notice: This e-mail together w= ith any attachments may contain


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Communic= ations Inc. that is confidential


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole use o= f the intended recipient. Any review,


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distri= bution by others or forwarding


    >=C2=A0=C2=A0=C2=A0=C2=A0 without


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly= prohibited. If you are not the


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify the s= ender immediately and then delete all


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attachme= nts.


    >=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=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symantec.com/= 3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dh= ttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Fli= stinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZ= Hgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >=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 > spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.com/3Q1xs= KGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2= Fspring


    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dh= ttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Fli= stinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZ= Hgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >=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 spring mailing list


    >=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org>


    >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMzNJCKyV= PByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring=


    >=C2=A0=C2=A0=C2=A0=C2=A0


    > <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
     > 2F%2Furldefense.com%2Fv3= %2F__https%3A%2Fwww.ie= tf.org%2Fmailman%2Flisti


    > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=


    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >


    >


    >


    > ----------------------------------------------------------------------=


    > --


    > Notice: This e-mail together with any attachments may contain


    > information of Ribbon Communications Inc. that is confidential and/or<= br>

    > proprietary for the sole use of the intended recipient. Any review,

    > disclosure, reliance or distribution by others or forwarding without

    > express permission is strictly prohibited. If you are not the intended=


    > recipient, please notify the sender immediately and then delete all

    > copies, including any attachments.


    > ----------------------------------------------------------------------=


    > --





    _______________________________________________


    spring mailing list


    spring@ietf.org

    h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring


    _______________________________________________


    spring mailing list


    spring@ietf.org

    h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring





    =C2=A0





    =C2=A0







    Notice: This e-mail together with any attachments may contain inform= ation of Ribbon Communications Inc. that is confidential and/or proprietary= for the sole use of the intended recipient. Any review, disclosure, relian= ce or distribution by others or forwarding without express permission is st= rictly prohibited. If you are not the intended recipient, please notify the= sender immediately and then delete all copies, including any attachments.<= /span>









    =C2=A0























    _______________________________________________


    spring mailing list


    spring@ietf.org

    = https://www.ietf.org/mailman/listinfo/spring






















    _______________________________________________

    spring mailing list

    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    --

    Gyan Mishra

    Network Solutions A<= /i>rchitect=C2=A0=

    M 301 502-1347
    13101 Columbia Pike=C2=A0
    Silver Spring, MD


    --000000000000850c5a05ad1a1baf-- From nobody Mon Aug 17 16:26:57 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5373A1445; Mon, 17 Aug 2020 16:26:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <159770681519.20276.17922805105597087988@ietfa.amsl.com> Date: Mon, 17 Aug 2020 16:26:55 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-20.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 23:26:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-20.txt Pages : 33 Date : 2020-08-17 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-20 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 17 16:42:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23623A1454 for ; Mon, 17 Aug 2020 16:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, PDS_BTC_MSGID=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 WswkaWayK-C4 for ; Mon, 17 Aug 2020 16:42:43 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 B767A3A1452 for ; Mon, 17 Aug 2020 16:42:43 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id i10so3328987pgk.1 for ; Mon, 17 Aug 2020 16:42:43 -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=ausPE6SffHSt8chmSyL7KL7EIPCpYZNTOYBpGr04qcU=; b=uj5ezgFr1Gs/ZpKCkthiHaNxt5TA4evbhgjLMIGfLQZIueUW9CEHKrr193sH9lXPKv RlFtsJVZ3vpc5LvLiHw9lrqM4Pi2pDFIVxMhZpZcBWXEXc9IUsdnnHBZa/xNqmaNzxKJ YUlPzu9XDJwz7dWwUUoQUbNAGKz5iADw6kIvhfLsKRlnwZtv/YVQUH7HTCDoR/9t0Tct epX/sdjXWdCuwwZuEsJYD8Fk8bNrtx5qE+Q6HducN+1U5gkfcxVzvXv5OLE8zaTrvMqX u2c8AExTi9DJt5OifrNNR3F+cK9DgrmEpHFiPoj7f2UcnJT/ddupOArMqbXwMGaFAIHV zO/w== 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=ausPE6SffHSt8chmSyL7KL7EIPCpYZNTOYBpGr04qcU=; b=eXyvQ1lWqUYYyMby4w27rLtsS68EHFbYKLvLSeVr4SUtY+3NBwKlOZ9qJVs/8qpyVV YX8MBIj4oh9k/h8JWwvlxnqAKr66fIQ8cJsaCEplZcs+7N5DTxSImUbzrk8XNSB98CxU 7A3gFf37GuqJYRDUkuRJxaInBEx93qCMoxgXCnCtMBw2F74EV3r8zGAXMgLQppN77Vpm d1NcYpBS/oqZlqc8lYcMPQfGNiReW/9IIAePl26PA8xFJG4KoAg6/4ouuCRDy+ybJW0z khbAKDYoEWP0bpc1Dfa5upDMD4vaavcoz6e5GihZKVcDjdi5yqal4ti2oLZLRobtHPH/ +S2A== X-Gm-Message-State: AOAM533aNV3CL3YuqnlyZ8NsaXl8n8xGYTC65oqaunKXyPAKt8TM5G0w J+4sTtDbnKdOgtsRqqq1MvA= X-Google-Smtp-Source: ABdhPJy4Pq7IOXA33JITM7d9BXwfIJBhaIpl5738hmMbVgR2zoHt1U8JNgdDXA/MvZyZTXgno6TJIg== X-Received: by 2002:a63:161a:: with SMTP id w26mr5012537pgl.211.1597707762676; Mon, 17 Aug 2020 16:42:42 -0700 (PDT) Received: from [192.168.1.3] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id o16sm23279994pfu.188.2020.08.17.16.42.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 16:42:41 -0700 (PDT) Date: Mon, 17 Aug 2020 16:42:24 -0700 From: Jeff Tantsura To: Robert Raszuk Cc: Gyan Mishra , Alexander Vainshtein , "=?utf-8?Q?EXT-Andrew.Alston=40liquidtelecom.com?=" , "Joel M. Halpern" , "Ketan Talaulikar (ketant)" , Shraddha Hegde , "=?utf-8?Q?spring=40ietf.org?=" Message-ID: In-Reply-To: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> <2c83ce86-4413-43bd-9d40-72ea3b9f4962@Spark> <19edd13c-8729-4534-b5da-c48a63a74aee@Spark> <7a88539d-9420-4abc-8dd6-2ba1401fcd0e@Spark> <8940cdc0-9c51-46a4-8ddc-79df170c433f@Spark> X-Readdle-Message-ID: df2401a0-7a7c-4236-895a-d4e2413c1724@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f3b15eb_431bd7b7_65d7" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 23:42:54 -0000 --5f3b15eb_431bd7b7_65d7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ahh, overloading addressing semantics, odd addresses/labels go left while= even go right, and you want this to be standardized ;-) Cheers, Jeff On Aug 17, 2020, 3:15 PM -0700, Robert Raszuk , wrot= e: > Hi Jeff, > > If one would allocate SIDs in a smart way they can include algorithmica= lly encoded information if packets are =46RR eligible. No increase=C2=A0i= n IGP flooding. No duplication of SID space. Just local behaviour. > > =46or SRv6 - trivial. =46or SR-MPLS, also pretty simple provided one wo= uld be keen on using MPLS forwarding paradigm for some time :) > > Hint: think even/odd (1 bit in the SID) - well known in a domain - and = used correctly by your vendor. > > Best, > R. > > > On Mon, Aug 17, 2020 at 11:54 PM Jeff Tantsura wrote: > > > Hi Robert, > > > > > > =22possession of enough information in PLR=E2=80=9D what do you cal= l this, if not more state, given this information is not present there to= day=3F > > > > > > Cheers, > > > Jeff > > > On Aug 17, 2020, 2:25 PM -0700, Robert Raszuk = , wrote: > > > > Hi Jeff, > > > > > > > > This is not about more state in the network nor about=C2=A0includ= ing mirror service node in the backup path for some flows. > > > > > > > > The thread is about possession of enough information in PLR to ei= ther take the packet and shift it over backup path or just drop it. > > > > > > > > - - - > > > > > > > > Btw - path protection is completely orthogonal to the above. > > > > > > > > Cheers, > > > > Robert. > > > > > > > > > > > > > On Mon, Aug 17, 2020 at 11:03 PM Jeff Tantsura wrote: > > > > > > Gyan, > > > > > > > > > > > > TI-L=46A computation is local to the PLR and is topology depe= ndent, e.g change in downstream topology could/would influence the choice= of MP (PQ) node. > > > > > > While an implementation could take into consideration some ad= ditional meta-data (e.g. locally provisioned SRLG, usually used to avoid = protected and protecting ports on the same line card), this is not a stan= dardized method. > > > > > > If a service node must be included in a backup path, there=E2= =80=99s a state associated with it as well as distribution of the state i= nvolved. > > > > > > > > > > > > Back to my point, removing state and introducing services in = the network (at the very least at the computational logic and head-end le= vel) are mutually exclusive, trade-offs are inevitable (You can't eat you= r cake and have it). > > > > > > Keeping the state limited to: > > > > > > - a logically centralized computational logic (aka PCE) - off= path, scales horizontally, could use additional business logic for the p= ath computation, example - CPU/memory consumption on a service node > > > > > > - head-end - anchor to primary/backup paths > > > > > > seems like a reasonable set of trade-offs. > > > > > > > > > > > > Cheers, > > > > > > Jeff > > > > > > On Aug 14, 2020, 7:44 PM -0700, Gyan Mishra , wrote: > > > > > > > > > > > > > > Catching up on this thread as it is a interesting topic as = =46RR 1:N link protection, node protection and path protection is critica= l to operators. > > > > > > > > > > > > > > There are multiple somewhat orthogonal topics brought up in= the discussion. > > > > > > > > > > > > > > Excluding SR S=46C from =E2=80=9Cbypass=E2=80=9D capable no= de such for appliances such as firewalls and load balancer.=C2=A0 Makes s= ense.=C2=A0 I would not think S=46C would be in a PLR path to merger poin= t but I could be mistaken. > > > > > > > > > > > > > > The goal of SR is eliminating state and so having TE like s= tate is undesirable. > > > > > > > > > > > > > > Intent based instantiation of bypass via SR-TE from network= feedback at PLR detection node of a failure and make before break pre co= mputed backup paths that can. > > > > > > > > > > > > > > It would make sense that SR-TE binding SID policy would be = appropriate for RSVP like =46RR link node or path protection. > > > > > > > > > > > > > > My thoughts on this topic of SR protection is that don=E2=80= =99t we already have =46RR protection natively without requiring SR-TE BS= ID or any additional undesirable state maintenance with TI-L=46A. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Gyan > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 5:47 PM Jeff Tantsura wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PCE computation in this case is trivial too(must traver= se node B or node X) else =46AIL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 2:44 PM -0700, Jeff Tantsura , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Agreed and apologies, hit send before finishing the e= mail (it is =46riday) ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Path protection in this case make more sense and is m= uch less complex, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > if in the pathA (A->B->C) node B is a service node, i= t can=E2=80=99t be bypassed (node protected) if the link between A and B = breaks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > however it could have a backup pathB (A->X->C) where = X is the service node, potentially synchronizing its state with the node = B. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To my previous email - at expense of more state, we p= rovide path and service protection, hence the similarity with RSVP-TE tra= de-offs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 2:30 PM -0700, Robert Raszuk , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jeff, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very similar to RSVP-TE > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would rather differ on that statement. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See if you are using SR just for TE you are 100% ri= ght. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if your SIDs embed additional local SR node pro= cessing functions this suddenly=C2=A0becomes a completely different game.= Let's keep this in mind in this thread/topic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 11:15 PM Jeff Tantsura = wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very similar to RSVP-TE, path vs link/n= ode protection and usually dictated by the business logic, the triggers a= re obviously very different, head-end being notified of the failure on a = path and switching to the backup path vs reaction to a local failure, so = same considerations apply: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -more state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -pre-reserved resources > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > while > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -predictable > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -meets SLA (as good as primary) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > vs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -less state > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -local > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -best effort / can cause congestions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 14, 2020, 10:46 AM -0700, Ketan Talaulik= ar (ketant) , wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We do not have a signalling mechanism in IGPs= today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix = SIDs. If there was a desire for it, an IGP extension would be required (t= here is none in progress A=46AIK). Note that this results in doubling the= prefix SID scale (global labels) in the network. So I would not go about= this trivially. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it helps to get more inputs and persp= ectives from operators on their views for doing a bypass via local protec= tion for segments in an SR Policy. There may be those that prefer end-to-= end path protection using a fallback path that is say disjoint with the p= rimary but provides an appropriate SLA/intent=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 23:04 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection -= determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Looks like we are pretty much in sync here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But let me just observe that I purposely=C2=A0= did not mention about SR policies as we are not able to signal the intent= with the packets itself. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So all we have there is SIDs. BSIDs or prefix= SIDs need to be flooded with information if policies build with using th= em are bypass eligible or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was actually under the impression that this= is already there and I am just not aware, but looking deeper indeed I do= not see this marking neither in ISIS nor OSP=46 for prefix SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there some work in progress to add it to t= hose protocols or have we just documented need=C2=A0for a short LSR draft= =C2=A0 =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thx, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talau= likar (ketant) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Robert, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please check inline below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Robert Raszuk = > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 21:13 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde = ; EXT-Andrew.Alston=40liquidtelecom.com ; spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protection= - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ketan, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I completely agree with your note the= consequences of it are pretty sevre. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D I understand. We need to be mindfu= l of implications of protection schemes for the SLAs/intent of SR Policie= s. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Unless we signal which prefix SID is protec= tion eligible and which is not how would other nodes know if they can pro= tect it or not =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D Correct. To be more accurate, we n= eed to consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D= of SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D f= or local protection for some of those SR Policies. We also have path-prot= ection mechanisms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems that today's safe thing is not to = apply any node protection on SR flows at the PLRs then. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And link protection MUST assure that packet= s will arrive at the neighbor node via some other link regardless of furt= her path towards destination. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5BKT=5D Yes. We have a mechanism to indica= te which adj-SIDs have protection (that mechanism only provides link prot= ection to get to the neighbor node) so the SR Policy computation is able = to indicate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D o= r not by its choice of protected or unprotected adj-SIDs respectively. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is it correct =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thx > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On =46ri, Aug 14, 2020 at 5:32 PM Ketan Tal= aulikar (ketant) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The service node advertises its own Prefi= x SID.. The service function that this service node implements does not r= equire any context (i.e. all packets arriving at the node are subjected t= o that service). Therefore the service node does not need to receive a pa= cket with it=E2=80=99s own Prefix SID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thus, we cannot assume that when PHP is u= sed, then the SID is only associated with a topological instruction. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope that clarifies=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 20:24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protecti= on - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan, and all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have stated that, IMHO and =46WIW, both= Adj-SIDs and Prefix SIDs that are advertised with PHP can=C2=A0 ONLY rep= resent topological instructions in SR-MPLS - because the advertising node= will not receive them and therefore can hardly be expected to associate = any service function with them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is complementary to what you have sa= id. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hope this clarifies my position. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What, if anything, did I miss=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: =46riday, August 14, 2020, 16:23 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Alexander Vainshtein; Joel M. Halpern= ; Shraddha Hegde; EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: RE: =5Bspring=5D Spring protecti= on - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > NOTICE: This email was received from an E= XTERNAL sender > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sasha, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the service does not need any addition= al context (e.g. a firewall that just applies locally configured default = rules on it), then I don=E2=80=99t see why PHP could not be done for a Pr= efix SID associated with a service node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, I didn=E2=80=99t follow the point t= hat you were trying to make about Adj-SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: Alexander Vainshtein > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 14 August 2020 18:24 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Ketan Talaulikar (ketant) ; Joel M. Halpern ; Alexander Vainshtein = ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protecti= on - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding the statement =22Prefix SID cou= ld be just a topological instruction or may also be used to steer the flo= w to a node which is applying a service function to it=22: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think that in SR-MPLS a Node SID that i= s advertised with PHP aciton can be safely considered as =22just a topolo= gical instruction=22 by the PLR because the originating node will not rec= eive it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The same applies to Adj-SDIs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My 2c. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: spring on behalf of Ketan Talaulikar (ketant) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: =46riday, August 14, 2020, 15:00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Joel M. Halpern; Alexander Vainshtein= ; Shraddha Hegde; EXT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protecti= on - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to share a different perspec= tive on this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46irst, thanks to Joel for bringing up t= he discussion. Clearly we need a well-defined applicability statement for= determining applicability of protection for segment used in an SR Policy= . Some of this is captured in =5B1=5D. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is about local repair at a PLR. By i= t's very nature, the PLR does not have a notion of how =22strict or not=22= is the SLA that is being provided by the SR Policy. Awareness of that no= tion exists at the SR Policy headend and/or computation-node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have protected and un-protected varian= ts of adjacency SIDs to enable the computation to pick or the other based= on the =22strictness=22 of the SLA requirement for picking that link. We= do not have such a notion for Prefix SIDs. One can say that we could int= roduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be= bypassed or not. This provides the opportunity for the computation to us= e one or the other flavor depending on the nature of the SLA for the SR P= olicy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a problem and a concern in the ass= umption that PLRs can assume that the currently defined variant of Prefix= SIDs in R=46C8402 (and IGP specs) are =22bypass-able=22. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As Joel and others have brought out, the = Prefix SID could be just a topological instruction or may also be used to= steer the flow to a node which is applying a service function to it. In = order to support a mix of SR Policies of different SLAs (strict and not-s= trict), we need to enable the choice of SIDs that indicates to the PLR wh= ether they are =22bypass-able=22 or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46or the cases, where the SR Policy has = a specific SLA, it is required for nodes to drop the packets meant for th= e =22active segment=22 than to bypass it. When this mechanism is used alo= ng side SRTE path monitoring mechanisms, it enables the headend to detect= the failure and fallback to an alternate path using the path protection = approach. This is something that is described and in use in deployments t= oday =5B1=5D.. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ketan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5B1=5D https://clicktime.symantec.com/3Y= 3fWuN=46YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46htm= l%2=46draft-ietf-spring-segment-routing-policy-08%23section-9 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =5B2=5D https://clicktime.symantec.com/36= fCMrgmEewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%= 2=46draft-ietf-spring-segment-routing-policy-08%23section-9.3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =46rom: spring On Behalf Of Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent: 04 August 2020 20:25 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Alexander Vainshtein ; Shraddha Hegde ; EXT-Andrew.Alston=40liquidtelecom.com ; Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: spring=40ietf.org; Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: =5Bspring=5D Spring protecti= on - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are, as far as I can tell, a number= of ways to address this family of related questions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What struck me, and prompted the starting= question, was that none of them were spelled out.=C2=A0 I see lots of in= teresting ideas / proposals. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some of them are compatible with others.=C2= =A0=C2=A0 Some are not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It would be good if we could reach agreem= ent on how we thought it should be handled. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/4/2020 3:54 AM, Alexander Vainshtein= wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am still not sure that the problem of= bypass going thru undesirable > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > links/nodes exists in the case of topol= ogical SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A=46AIK, =46acility Protection in RSVP-= TE =46RR (R=46C 4090 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ) has been successfully deployed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > for many years before SR-MPLS has been = introduced. What=E2=80=99s more, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > signaling of bypass tunnels he PLR usua= lly did not include any of the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > constraints used for computing of any s= pecific LSP that the bypass LSP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > would protect =E2=80=93 because in the = =46acility Protection mode the same > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > bypass LSP would be used to protect mul= tiple LSPs passing thru the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > failed link/node. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =46rom my POV the only difference= between this behavior and that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > introduced by the =E2=80=9Cbypassing=E2= =80=9D drafts in SR is that, in the case of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RSVP-TE, the operator would explicitly = indicate, as part of LSP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > signaling, whether it would or would no= t use =46RR; LSPs that would not > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > use =46RR would then drop traffic rathe= r than delivering it the wrong way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Such an option indeed does not exist in= SR-TE today, but would be easy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to provide if so desired IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Did I miss something substantial=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, and lots of thanks in advance,= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sasha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Office: +972-39266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +97= 2-549266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Email:=C2=A0=C2=A0 Alexander.Vainshtein= =40ecitele.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* spring *On Behalf Of *Shraddha Hegde > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, August 4, 2020 9:41 AM= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* EXT-Andrew.Alston=40liquidtelecom= .com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ; Ro= bert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* spring=40ietf.org; Joel M. Halper= n > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring prot= ection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a very interesting discussion a= nd thanks to Joel for starting > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > this discussion. IMO, when there are st= rict requirements of avoiding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > certain nodes/links it can be realized=C2= =A0 either by defining a flex-algo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > avoiding those > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nodes and links or by using a stack of = unprotected adj-sids that avoid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > restricted nodes and links. When a stac= k of adj-sids is used to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > realize the path, the head-end based (s= B=46D) protection mechanisms can be applied. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If Node-sids/prefix-sid/anycast-sids ar= e used to build the stack, the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > failure events may cause traffic to go = through restricted nodes and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > links. This would happen regardless of = whether any kind of protection > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is in use or not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rgds > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shraddha > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* spring > > > > > > > > > > > > > > > > > *On= Behalf Of *Andrew Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, August 4, 2020 5:41 AM= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* spring=40ietf.org ; Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring prot= ection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=5BExternal Email. Be cautious of cont= ent=5D* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robert this is actually far more diffic= ult when =E2=80=93 it can be an entire > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (long) series of nodes that need to be = avoided. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It could potentially be made to work bu= t I=E2=80=99d worry that to do this =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you=E2=80=99d have to stack 10 =E2=80=93= 20 =E2=80=93 30 negative labels =E2=80=93 and that wouldn=E2=80=99t > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > be viable. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It=E2=80=99s easier to use algorithms a= nd adjacency sids and other such things > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to calculate paths =E2=80=93 the bigges= t trick is about the stack depth.=C2=A0 When > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > you have this need for node avoidance =E2= =80=93 the need for 10+ label depth > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is critical =E2=80=93 unless you wanna = be applying one hell of a lot of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > binding labels along the way which is a= nightmare. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But to answer your question, is this a = common use case =E2=80=93 it=E2=80=99s a use > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > case that most of the people I discuss = this with certain have =E2=80=93 I cant > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > comment on a global scale, or for anyon= e else, but every indication I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > have is that yes =E2=80=93 its somethin= g people need, and want > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *=46rom:* Robert Raszuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Sent:* Tuesday, 4 August 2020 01:27 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *To:* Andrew Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Cc:* Joel M. Halpern > > > > > > > > > > > > > > > > >; spring= =40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Subject:* Re: =5Bspring=5D Spring prot= ection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is this a common use case ie.=C2=A0 =22= but rather =E2=80=93 which nodes / network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > segments it can never touch or flow thr= ough.=22 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If so perhaps its time to define notion= of *negative-SID* ie. list in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the packet resources which given=C2=A0p= acket MUST not ever traverse. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Put in the packet set of nodes or links= which the packet should never > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > traverse. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That goes in line of recent wave of neg= ative routing implementations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (RI=46T) or discussions (LSR) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew = Alston > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use = cases, in fact, some very major use cases in any > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring technolo= gy for us revolve around the following > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit = avoidance of certain nodes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit = avoidance of certain sections of the network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that c= ould result in that explicit avoidance being violated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would= create, shall we say significant problems. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use= case is not a case of which nodes the packets flow > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93= but rather =E2=80=93 which nodes / network segments it can never > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow t= hrough.=C2=A0 Effectively, to be used as a technology to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain t= hings for specific reasons. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 This is also on= e of the reasons for needing such deep label stacks =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of de= tailed path programming tends to deepen the stack > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 because you som= etimes have to be pretty explicit. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutel= y critical to us that this functionality is there =E2=80=93 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can= avoid situations which could cause traffic to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit = things explicitly avoided. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could = be more specific than this, but it is what it is. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *=46rom:* sprin= g > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > *On Behalf Of *Joel M. Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday,= 3 August 2020 21:36 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Ra= szuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring=40= ietf..org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: = =5Bspring=5D Spring protection - determining > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thre= ad has gotten long enough, reiterating that this is as a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 participant, no= t a WG chair.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are tal= king IP networks. And yes, I have seen IP networks that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop = packets. =46or all sorts of reasons. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 I think there a= re likely other reasons why one may not want a random > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 path rather tha= n a chosen TE path. I think it is important we be clear > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 about what cons= traints may be / are violated when we tell people they > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool = (protective rerouting) that is intended to preserve QoS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear.= I am not arguing that this is not a good idea. It is a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And = useful. I am trying to figure otu what combination of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 additional mech= anisms and clear descriptions will lead to everyone > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 getting the beh= avior they expect (which may not be the behavior they > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but som= etimes is the best we can do.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:3= 0 PM, Robert Raszuk wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we = still talking about IP networks=C2=A0here =3F Or perhaps some hard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing= with real resource reservations or detnets =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because= =C2=A0if we are talking=C2=A0about IP networking I have two > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 observations: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If y= ou need to traverse via a specific node (ie. firewall) you > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 better > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply I= P encapsulation to that node.. I don't think IP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2= =A0can > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hija= cked today such that destination address of the packet is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 ignored. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have= you seen any IP network where upon topology change (link > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 or node > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure= ) you suddenly=C2=A0start dropping=C2=A0flows in spite of SPT offering > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps= few ms longer path with 10 ms more jitter =3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are = some SR marketing slides promise to turn IP networks in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > somethi= ng=C2=A0new =3F Worse ... do they mention path quality guarantees, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resourc= e reservations=C2=A0=3F I hope not. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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=A0=C2=A0 > On Mon,= Aug 3, 2020 at 8:10 PM Joel M. Halpern > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well le= ss serious for TE SIDs, I am not sure the problem is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 restricted > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just= service SIDs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose= that the PCE has specified the path to meet some complex te > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objecti= ve.=C2=A0 The bypass node has no way of knowing what those > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constra= ints > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2= =A0 And for some kinds of traffic, it is better to drop the packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to= deliver it outside the envelop.=C2=A0 I suspect that the right > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this= is =22too bad=22..=C2=A0 If so, as with the distinction regarding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 service > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, = we should say so, shouldn't we=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/= 2020 2:36 AM, Alexander Vainshtein wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach,= Joel and all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I thi= nk that in most cases: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.The= re is clear differentiation between =22topological=22 and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =22service=22 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instr= uctions in SID advertisements. E.g.: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP = Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corre= sponding IGP advertisements) represent topological > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 instructions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oServ= ice SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft= ) unsurprisingly represent =E2=80=9Cservice=E2=80=9D instructions > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Seg= ments that represent topological instructions can be bypassed, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while= segments that represent service instructions require > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alterna= tive > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > prote= ction mechanisms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This = view seems to be aligned with R=46C 8402 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 that says in Se= ction 1: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 In the context of an IGP-based distributed control plane, t= wo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topol= ogical segments are defined: the IGP-Adjacency segment and the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 IGP-Prefix segment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 In the context of a BGP-based distributed control plane, tw= o > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topol= ogical segments are defined: the BGP peering segment and the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 BGP-Prefix segment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In th= e case of SR-MPLS this differentiation is assumed in Section > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the N= ode Protection for SR-TE Path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0=C2=A0 > > draft= that says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 The node protection mechanism described in the previous > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 sections > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 depends on the assumption that the label immediately below > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label= in the label stack is understood in the IGP domain.=C2=A0 When the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 provider edge routers exchange service labels via BGP or so= me > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 non-IGP mechanism the bottom label is not understood in the= IGP > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 domain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 The egress node protection mechanisms described in the draf= t > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 =5BR=46C8679 > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 >=5D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > appli= cable to this use case and no additional changes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 will be required for SR based networks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The s= cenarios in which =C2=A0differentiation between =E2=80=9Ctopological=E2=80= =9D and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80= =9Cservice=E2=80=9D instructions is broken are indeed problematic. E.g., > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > conside= r > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the u= se case in which a Node SID in the ERO of a SR-TE path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identif= ies a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node = that acts as a firewall for all packets it receives, i.e., > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provide= s > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the f= irewall service without any dedicated service SID > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identif= ying it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One c= ould say that the Node SID of such a node would combine > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topolog= ical > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and s= ervice instructions thus breaking the differentiation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between= the two. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am = not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs could be preven= ted > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least= discouraged. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If no= t, providing an ability to identify such SIDs in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > adverti= sement > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mecha= nisms would be useful IMHO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c= , > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Offic= e: +972-39266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email= : Alexander.Vainshtein=40ecitele.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > > -----= Original Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =46ro= m: spring > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > On Behalf Of Mach Chen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent:= Monday, August 3, 2020 6:30 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: J= oel M. Halpern > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 > >; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.o= rg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subje= ct: Re: =5Bspring=5D Spring protection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Jo= el, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I thi= nk this is a good point that may not be discussed in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. A= nd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I als= o don't think there is a =22can be bypassed=22 indication in the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routi= ng advertisement for now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO,= the information advertised by routing is neutral, such > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > informa= tion > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can = or cannot be bypassed) is more path specific, thus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 normally the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > contr= oller should be responsible for deciding whether/which SID > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypas= sed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best = regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > -----Original Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > =46rom: spring =5Bmailto:spring-bounces=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 =5D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Jo= el M. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > Halpern > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > To: spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > Subject: =5Bspring=5D Spring protection - determining applicability > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > (WG Chair hat Off, this is merely a note from a slightly > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confuse= d WG > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > participant.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > I have been reading the various repair drafts, and the various > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > networks programming and service programming draft, and I am > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying = to > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > figure out one aspect of the combination. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > How does a node that is doing some form of bypass (suppose, for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > simplicity, it is Node N2 deciding to bypass the next SID for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a faile= d > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > node N3) know that it is safe to do so=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > If the path was just for TE, then it is =22safe=22 if the new path > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > the TE criteria.=C2=A0 or maybe it is safe if it is even close, as > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > it is not used for too long. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > But what if the node were a =46irewall, included to meet legal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requi= rements=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > Or was some other necessary programmatic transform (wince we are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > deliberately vague about what nodes can do when asked suitably.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > Is there some =22can be bypassed=22 indication in the routing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > advertisements that I missed=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > Yours, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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= > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > spring=40ietf..org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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 https://clickti= me.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0= > =46%2=46www.ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 >%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > sprin= g mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > sprin= g=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=A0=C2=A0=C2=A0 https://clickti= me.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46www.ie= tf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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=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 > > Notic= e: This e-mail together with any attachments may contain > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > infor= mation of Ribbon Communications Inc. that is confidential > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > propr= ietary for the sole use of the intended recipient. Any review, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > discl= osure, reliance or distribution by others or forwarding > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 without > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > expre= ss permission is strictly prohibited. If you are not the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intende= d > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recip= ient, please notify the sender immediately and then delete all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copie= s, including any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > sprin= g mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > sprin= g=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https= ://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%= 2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring = mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring=40= ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https:/= /clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46= www.ietf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=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 =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring mailing = list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 spring=40ietf.o= rg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 https://clickti= me.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ie= tf.org%2=46mailman%2=46listinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2=46%2=46urldefense.com%2=46v3%2=46=5F=5F= https%3A%2=46www.ietf.org%2=46mailman%2=46listi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-g= k%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqgu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------= ------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any a= ttachments may contain > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > information of Ribbon Communications In= c. that is confidential and/or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > proprietary for the sole use of the int= ended recipient. Any review, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > disclosure, reliance or distribution by= others or forwarding without > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > express permission is strictly prohibit= ed. If you are not the intended > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > recipient, please notify the sender imm= ediately and then delete all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > copies, including any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------= ------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMz= NJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46lis= tinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/3Q1xsKGyMz= NJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46lis= tinfo%2=46spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any att= achments may contain information of Ribbon Communications Inc. that is co= nfidential and/or proprietary for the sole use of the intended recipient.= Any review, disclosure, reliance or distribution by others or forwarding= without express permission is strictly prohibited. If you are not the in= tended recipient, please notify the sender immediately and then delete al= l copies, including any attachments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 > > > > > > > > > > > > > > > > > > spring mailing list > > > > > > > > > > > > > > > > > > spring=40ietf.org > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Gyan Mishra > > > > > > > Network Solutions Architect > > > > > > > M 301 502-1347 > > > > > > > 13101 Columbia Pike > > > > > > > Silver Spring, MD > > > > > > > --5f3b15eb_431bd7b7_65d7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
    Ahh, overloading addressing semantics, odd addresse= s/labels go left while even go right, and you want this to be standardize= d ;-)&=23160;

    Cheers,
    Jeff
    On Aug 17, 2020, 3:15 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:
    Hi Jeff,

    If one would allocate SIDs in a smart way they can include algorithm= ically encoded information if packets are =46RR eligible. No increase&=23= 160;in IGP flooding. No duplication of SID space. Just local behaviour.

    =46or SRv6 - trivial. =46or SR-MPLS, also pretty simple provided one= would be keen on using MPLS forwarding paradigm for some time :)&=23160;= &=23160;

    Hint: think even/odd (1 bit in the SID) - well known in a domain - a= nd used correctly by your vendor.&=23160;

    Best,
    R.

    On Mon, Aug 17, 2020 at 1= 1:54 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:
    Hi Robert,

    =22possession of enough information in PLR=E2=80=9D what do you call this= , if not more state, given this information is not present there today=3F=

    Cheers,
    Jeff
    On Aug 17, 2020, 2:25 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:
    Hi Jeff,

    This is not about more state in the network nor about&=23160;includi= ng mirror service node in the backup path for some flows.&=23160;

    The thread is about possession of enough information in PLR to eithe= r take the packet and shift it over backup path or just drop it.&=23160;<= /div>

    - - -

    Btw - path protection is completely orthogonal to the above.&=23160;=

    Cheers,
    Robert.


    On Mon, Aug 17, 2020 at 1= 1:03 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:
    Gyan,

    TI-L=46A computation is local to the PLR and is topology dependent, e.g c= hange in downstream topology could/would influence the choice of MP (PQ) = node.
    While an implementation could take into consideration some additional met= a-data (e.g. locally provisioned SRLG, usually used to avoid protected an= d protecting ports on the same line card), this is not a standardized met= hod.&=23160;&=23160;
    If a service node must be included in a backup path, there=E2=80=99s a st= ate associated with it as well as distribution of the state involved.&=23= 160;

    Back to my point, removing state and introducing services in the network = (at the very least at the computational logic and head-end level) are mut= ually exclusive, trade-offs are inevitable (You can't eat your cake and h= ave it).
    Keeping the state limited to:
    - a logically centralized computational logic (aka PCE) - off path, scale= s horizontally, could use additional business logic for the path computat= ion, example - CPU/memory consumption on a service node
    - head-end - anchor to primary/backup paths
    seems like a reasonable set of trade-offs.

    Cheers,
    Jeff
    On Aug 14, 2020, 7:44 PM -0700, Gya= n Mishra <hayabusagsm=40gmail.com>, wrote:

    Catching up on this thread as it is a interesting t= opic as =46RR 1:N link protection, node protection and path protection is= critical to operators.

    There are multiple somewhat orthogonal topics broug= ht up in the discussion.

    Excluding SR S=46C from =E2=80=9Cbypass=E2=80=9D ca= pable node such for appliances such as firewalls and load balancer.&=2316= 0; Makes sense.&=23160; I would not think S=46C would be in a PLR path to= merger point but I could be mistaken.

    The goal of SR is eliminating state and so having T= E like state is undesirable.&=23160;

    Intent based instantiation of bypass via SR-TE from= network feedback at PLR detection node of a failure and make before brea= k pre computed backup paths that can. &=23160;&=23160;

    It would make sense that SR-TE binding SID policy w= ould be appropriate for RSVP like =46RR link node or path protection.

    My thoughts on this topic of SR protection is that = don=E2=80=99t we already have =46RR protection natively without requiring= SR-TE BSID or any additional undesirable state maintenance with TI-L=46A= .

    Thanks&=23160;

    Gyan

    On =46ri, Aug 14, 2020 at= 5:47 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:












    PCE computation in this case is trivial too(must tr= averse node B or node X) else =46AIL.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:44 PM -0700, Jef= f Tantsura <jefftant.ietf=40gmail.com>, wrote:






    Robert,





    Agreed and apologies, hit send before finishing the email (it is =46riday= ) ;-)





    Path protection in this case make more sense and is much less complex,&=23= 160;


    if in the pathA (A->B->C) node B is a service node, it can=E2=80=99= t be bypassed (node protected) if the link between A and B breaks&=23160;=


    however it could have a backup pathB (A->X->C) where X is the servi= ce node, potentially synchronizing its state with the node B.





    To my previous email - at expense of more state, we provide path and serv= ice protection, hence the similarity with RSVP-TE trade-offs.







    Cheers,

    Jeff






    On Aug 14, 2020, 2:30 PM -0700, Rob= ert Raszuk <robert=40raszuk.net>, wrote:




    Jeff,




    > This is very similar to RSVP-TE&=23160;&=23160;





    I would rather differ on that statement.&=23160;





    See if you are using SR just for TE you are 100% right.&=23160;




    But if your SIDs embed additional local SR node processing functions= this suddenly&=23160;becomes a completely different game. Let's keep thi= s in mind in this thread/topic.&=23160;





    Kind regards,


    R.












    On =46ri, Aug 14, 2020 at= 11:15 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:








    This is very similar to RSVP-TE, path vs link/node = protection and usually dictated by the business logic, the triggers are o= bviously very different, head-end being notified of the failure on a path= and switching to the backup path vs reaction to a local failure, so same= considerations apply:&=23160;


    -more state


    -pre-reserved resources


    while&=23160;


    -predictable


    -meets SLA (as good as primary)


    vs


    -less state


    -local


    -best effort / can cause congestions&=23160;







    Cheers,

    Jeff






    On Aug 14, 2020, 10:46 AM -0700, Ke= tan Talaulikar (ketant) <ketant=3D40cisco.com=40dmarc.ietf.org&= gt;, wrote:






    Hi Robert,



    &=23160;



    We do not have a signalling mechanism in= IGPs today to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Pr= efix SIDs. If there was a desire for it, an IGP extension would be requir= ed (there is none in progress A=46AIK). Note that this results in doublin= g the prefix SID scale (global labels) in the network. So I would not go = about this trivially.



    &=23160;



    I think it helps to get more inputs and = perspectives from operators on their views for doing a bypass via local p= rotection for segments in an SR Policy. There may be those that prefer en= d-to-end path protection using a fallback path that is say disjoint with = the primary but provides an appropriate SLA/intent=3F



    &=23160;



    Thanks,



    Ketan



    &=23160;





    =46rom: R= obert Raszuk <robert=40raszuk.net>


    Sent: 14 August 2020 23:04


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility





    &=23160;





    Ketan,





    &=23160;







    Looks like we are pretty much in sync here.&=23= 160;







    &=23160;







    But let me just observe that I purposely&=2316= 0;did not mention about SR policies as we are not able to signal the inte= nt with the packets itself.&=23160;







    &=23160;







    So all we have there is SIDs. BSIDs or prefix = SIDs need to be flooded with information if policies build with using the= m are bypass eligible or not.&=23160;







    &=23160;







    I was actually under the impression that this = is already there and I am just not aware, but looking deeper indeed I do = not see this marking neither in ISIS nor OSP=46 for prefix SIDs.&=23160;<= /p>





    &=23160;







    Is there some work in progress to add it to th= ose protocols or have we just documented need&=23160;for a short LSR draf= t&=23160; =3F&=23160;







    &=23160;







    Thx,







    R.







    &=23160;







    &=23160;







    On =46ri, Aug 14, 2020 at 6:17 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:











    Hi Robert,



    &=23160;



    Please check inline below.



    &=23160;





    =46rom: R= obert Raszuk <robert=40raszuk.net>


    Sent: 14 August 2020 21:13


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>


    Cc: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com= >; Joel M. Halpern <jmh=40joelhalpern.com>; Shraddha Hegde &l= t;s= hraddha=40juniper.net>; EXT-Andrew.Alston=40liquidtele= com.com <Andrew.Alston=40liquidtelecom.com>; spring=40ietf.= org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility





    &=23160;





    Hi Ketan,





    &=23160;







    While I completely agree with your note the co= nsequences of it are pretty sevre.&=23160;



    =5BKT=5D I understand. We need to be min= dful of implications of protection schemes for the SLAs/intent of SR Poli= cies.







    &=23160;







    Unless we signal which prefix SID is protectio= n eligible and which is not how would other nodes know if they can protec= t it or not =3F&=23160;



    =5BKT=5D Correct. To be more accurate, w= e need to consider this more in the context of SLA or =E2=80=9Cintent=E2=80= =9D of SR Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D= for local protection for some of those SR Policies. We also have path-pr= otection mechanisms.







    &=23160;







    It seems that today's safe thing is not to app= ly any node protection on SR flows at the PLRs then.&=23160;







    &=23160;







    And link protection MUST assure that packets w= ill arrive at the neighbor node via some other link regardless of further= path towards destination.&=23160;



    =5BKT=5D Yes. We have a mechanism to ind= icate which adj-SIDs have protection (that mechanism only provides link p= rotection to get to the neighbor node) so the SR Policy computation is ab= le to indicate whether that specific link is =E2=80=9Cbypass-able=E2=80=9D= or not by its choice of protected or unprotected adj-SIDs respectively.<= /i>



    &=23160;



    Thanks,



    Ketan







    &=23160;







    Is it correct =3F&=23160;







    &=23160;







    Thx







    R







    &=23160;







    On =46ri, Aug 14, 2020 at 5:32 PM Ketan Talaul= ikar (ketant) <ketant=40cisco.com> wrote:











    Hi Sasha,



    &=23160;



    The service node advertises its own Prefix SID= .. The service function that this service node implements does not requir= e any context (i.e. all packets arriving at the node are subjected to tha= t service). Therefore the service node does not need to receive a packet = with it=E2=80=99s own Prefix SID.



    &=23160;



    Thus, we cannot assume that when PHP is used, = then the SID is only associated with a topological instruction.



    &=23160;



    Hope that clarifies=3F



    &=23160;



    Thanks,



    Ketan



    &=23160;







    =46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>


    Sent: 14 August 2020 20:24


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Shraddha Hegde <shraddha=40juniper.ne= t>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.= net>


    Cc: spring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility







    &=23160;



    Ketan, and all,



    I have stated that, IMHO and =46WIW, both Adj-SIDs= and Prefix SIDs that are advertised with PHP can&=23160; ONLY represent = topological instructions in SR-MPLS - because the advertising node will n= ot receive them and therefore can hardly be expected to associate any ser= vice function with them.



    &=23160;



    This is complementary to what you have said.



    &=23160;



    Hope this clarifies my position.



    What, if anything, did I miss=3F



    &=23160;



    Regards,



    Sasha




    =


    &=23160;





    Get Outlook for Android









    &=23160;











    =46rom: Ketan Talaulikar (ketant) <ketant=40cisc= o.com>


    Sent: =46riday, August 14, 2020, 16:23


    To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk


    Cc: sp= ring=40ietf.org


    Subject: RE: =5Bspring=5D Spring protection - determining applicability=





    &=23160;







    NOTICE: This email was received from an EXTERN= AL sender







    &=23160;





    Hi Sasha,



    &=23160;



    If the service does not need any additional co= ntext (e.g. a firewall that just applies locally configured default rules= on it), then I don=E2=80=99t see why PHP could not be done for a Prefix = SID associated with a service node.



    &=23160;



    Also, I didn=E2=80=99t follow the point that y= ou were trying to make about Adj-SIDs.



    &=23160;



    Thanks,



    Ketan



    &=23160;







    =46rom: A= lexander Vainshtein <Alexander.Vainshtein=40rbbn.com>


    Sent: 14 August 2020 18:24


    To: Ketan Talaulikar (ketant) <ketant=40cisco.com>; Joel M. Hal= pern <jmh=40joelhalpern.com>; Alexander Vainshtein <Alexand= er.Vainshtein=40rbbn.com>; Shraddha Hegde <shraddha=40juniper.net<= /a>>; EXT-Andrew.Alston=40liquidtelecom.com <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40raszuk.net= >


    Cc: spring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicab= ility







    &=23160;



    Hi all,



    Regarding the statement =22Prefix SID could be jus= t a topological instruction or may also be used to steer the flow to a no= de which is applying a service function to it=22:



    &=23160;



    &=23160;



    I think that in SR-MPLS a Node SID that is adverti= sed with PHP aciton can be safely considered as =22just a topological ins= truction=22 by the PLR because the originating node will not receive it.<= /span>



    The same applies to Adj-SDIs.



    &=23160;



    My 2c.




    =


    &=23160;





    Get Outlook for Android









    &=23160;











    =46rom: spring <spring-bounces=40ietf.org= > on behalf of Ketan Talaulikar (ketant) <ketant=3D= 40cisco.com=40dmarc.ietf.org>


    Sent: =46riday, August 14, 2020, 15:00


    To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; E= XT-Andrew.Alston=40liquidtelecom.com; Robert Raszuk


    Cc: sp= ring=40ietf.org


    Subject: Re: =5Bspring=5D Spring protection - determining applicability=





    &=23160;





    Hi All,





    I would like to share a different perspective on this.





    =46irst, thanks to Joel for bringing up the discussion. Clearly we need a= well-defined applicability statement for determining applicability of pr= otection for segment used in an SR Policy. Some of this is captured in =5B= 1=5D.





    This is about local repair at a PLR. By it's very nature, the PLR does no= t have a notion of how =22strict or not=22 is the SLA that is being provi= ded by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.





    We have protected and un-protected variants of adjacency SIDs to enable t= he computation to pick or the other based on the =22strictness=22 of the = SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag= ) to indicate whether a Prefix SID can be bypassed or not. This provides = the opportunity for the computation to use one or the other flavor depend= ing on the nature of the SLA for the SR Policy.





    I have a problem and a concern in the assumption that PLRs can assume tha= t the currently defined variant of Prefix SIDs in R=46C8402 (and IGP spec= s) are =22bypass-able=22.





    As Joel and others have brought out, the Prefix SID could be just a topol= ogical instruction or may also be used to steer the flow to a node which = is applying a service function to it. In order to support a mix of SR Pol= icies of different SLAs (strict and not-strict), we need to enable the ch= oice of SIDs that indicates to the PLR whether they are =22bypass-able=22= or not.





    =46or the cases, where the SR Policy has a specific SLA, it is required f= or nodes to drop the packets meant for the =22active segment=22 than to b= ypass it. When this mechanism is used along side SRTE path monitoring mec= hanisms, it enables the headend to detect the failure and fallback to an = alternate path using the path protection approach. This is something that= is described and in use in deployments today =5B1=5D..





    Thanks,


    Ketan





    =5B1=5D htt= ps://clicktime.symantec.com/3Y3fWuN=46YCjMJUiiAiWwUms6H2=3Fu=3Dhttps%3A%2= =46%2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-pol= icy-08%23section-9


    =5B2=5D htt= ps://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2=3Fu=3Dhttps%3A%2=46= %2=46tools.ietf.org%2=46html%2=46draft-ietf-spring-segment-routing-policy= -08%23section-9.3





    -----Original Message-----


    =46rom: spring <spring-bounces=40ietf.org> On Behalf Of Joel M.= Halpern


    Sent: 04 August 2020 20:25


    To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com>= ;; Shraddha Hegde <shraddha=3D40juniper.net=40dmarc.ie= tf.org>; EXT-Andrew.Alston=40liquidtelecom.com <= ;Andrew.Alston=40liquidtelecom.com>; Robert Raszuk <robert=40= raszuk.net>


    Cc: spri= ng=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>


    Subject: Re: =5Bspring=5D Spring protection - determining applicability




    There are, as far as I can tell, a number of ways to address this family = of related questions.


    What struck me, and prompted the starting question, was that none of them= were spelled out.&=23160; I see lots of interesting ideas / proposals.

    Some of them are compatible with others.&=23160;&=23160; Some are not.

    It would be good if we could reach agreement on how we thought it should = be handled.





    Thank you,


    Joel





    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:


    > Hi all,


    >


    > I am still not sure that the problem of bypass going thru undesirabl= e


    > links/nodes exists in the case of topological SIDs.


    >


    > A=46AIK, =46acility Protection in RSVP-TE =46RR (R=46C 4090


    > <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs= 6H2=3Fu=3Dhttps%3A%2=46%2=46tools.ietf.org%2=46html%2=46rfc4090>) = has been successfully deployed


    > for many years before SR-MPLS has been introduced. What=E2=80=99s mo= re,


    > signaling of bypass tunnels he PLR usually did not include any of th= e


    > constraints used for computing of any specific LSP that the bypass L= SP


    > would protect =E2=80=93 because in the =46acility Protection mode th= e same


    > bypass LSP would be used to protect multiple LSPs passing thru the

    > failed link/node.


    >


    >&=23160; =46rom my POV the only difference between this behavior and = that


    > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, = in the case of


    > RSVP-TE, the operator would explicitly indicate, as part of LSP


    > signaling, whether it would or would not use =46RR; LSPs that would = not


    > use =46RR would then drop traffic rather than delivering it the wron= g way.


    >


    > Such an option indeed does not exist in SR-TE today, but would be ea= sy


    > to provide if so desired IMHO.


    >


    > Did I miss something substantial=3F


    >


    > Regards, and lots of thanks in advance,


    >


    > Sasha


    >


    > Office: +972-39266302


    >


    > Cell:&=23160;&=23160;&=23160;&=23160;&=23160; +972-549266302


    >


    > Email:&=23160;&=23160; Alexander.Vainshtein=40ecitele.com


    >


    > *=46rom:* spring <    spring-bounces=40ietf.org> *On Behalf Of = *Shraddha Hegde


    > *Sent:* Tuesday, August 4, 2020 9:41 AM


    > *To:* EXT-Andrew.Alston=40liquidtelecom.com


    > <Andrew.Alston=40liquidtelecom.com>; Robert Raszuk &= lt;rob= ert=40raszuk.net>


    > *Cc:* spring=40ietf.org; Joel M. Halpern <jmh=40joelhalpern.com>


    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > All,


    >


    > This is a very interesting discussion and thanks to Joel for startin= g


    > this discussion. IMO, when there are strict requirements of avoiding=


    > certain nodes/links it can be realized&=23160; either by defining a = flex-algo


    > avoiding those


    >


    > Nodes and links or by using a stack of unprotected adj-sids that avo= id


    > restricted nodes and links. When a stack of adj-sids is used to


    > realize the path, the head-end based (sB=46D) protection mechanisms = can be applied.


    >


    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, th= e


    > failure events may cause traffic to go through restricted nodes and<= br />

    > links. This would happen regardless of whether any kind of protectio= n


    > is in use or not.


    >


    > Rgds


    >


    > Shraddha


    >


    > Juniper Business Use Only


    >


    > *=46rom:* spring <spring-bounces=40ietf.org
     > = <mailto:spring-bounces=40ietf.org>> *On Behalf Of *Andrew Al= ston


    > *Sent:* Tuesday, August 4, 2020 5:41 AM


    > *To:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net>>


    > *Cc:*     spring=40ietf.org <mailto:spring=40ietf.org>; Joel M. Halpern


    > <jmh=40joelhalpern.com <mailto:jmh=40joelhalpern.com>>

    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > *=5BExternal Email. Be cautious of content=5D*


    >


    > Robert this is actually far more difficult when =E2=80=93 it can be = an entire


    > (long) series of nodes that need to be avoided.


    >


    > It could potentially be made to work but I=E2=80=99d worry that to d= o this =E2=80=93


    > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative la= bels =E2=80=93 and that wouldn=E2=80=99t


    > be viable.


    >


    > It=E2=80=99s easier to use algorithms and adjacency sids and other s= uch things


    > to calculate paths =E2=80=93 the biggest trick is about the stack de= pth.&=23160; When


    > you have this need for node avoidance =E2=80=93 the need for 10+ lab= el depth


    > is critical =E2=80=93 unless you wanna be applying one hell of a lot= of


    > binding labels along the way which is a nightmare.


    >


    > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use


    > case that most of the people I discuss this with certain have =E2=80= =93 I cant


    > comment on a global scale, or for anyone else, but every indication = I


    > have is that yes =E2=80=93 its something people need, and want
    =

    >


    > Andrew


    >


    > *=46rom:* Robert Raszuk <robert=40raszuk.net <mailto:robert=40raszuk.net= >>


    > *Sent:* Tuesday, 4 August 2020 01:27


    > *To:* Andrew Alston <Andrew.Alston=40liquidtelecom.= com
     > <mailto:Andrew.Alston=40liquidtelecom.com>>


    > *Cc:* Joel M. Halpern <    jmh=40joelhalpern.com
     > <= ;mai= lto:jmh=40joelhalpern.com>>; spring=40ietf.org


    > <mailto:spring=40ietf.org>


    > *Subject:* Re: =5Bspring=5D Spring protection - determining applicab= ility


    >


    > Is this a common use case ie.&=23160; =22but rather =E2=80=93 which = nodes / network


    > segments it can never touch or flow through.=22


    >


    > If so perhaps its time to define notion of *negative-SID* ie. list i= n


    > the packet resources which given&=23160;packet MUST not ever travers= e.


    >


    > Put in the packet set of nodes or links which the packet should neve= r


    > traverse.


    >


    > That goes in line of recent wave of negative routing implementations=


    > (RI=46T) or discussions (LSR)


    >


    > Best,


    > R.


    >


    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston


    > <Andrew.Alston=40liquidtelecom.com
     > &= lt;mailto:Andrew.Alston=40liquidtelecom.com>> wrote:


    >


    >&=23160;&=23160;&=23160;&=23160; So =E2=80=93


    >


    >&=23160;&=23160;&=23160;&=23160; One of the use cases, in fact, some = very major use cases in any


    >&=23160;&=23160;&=23160;&=23160; spring technology for us revolve aro= und the following


    >


    >&=23160;&=23160;&=23160;&=23160; a.The explicit avoidance of certain = nodes


    >


    >&=23160;&=23160;&=23160;&=23160; b.The explicit avoidance of certain = sections of the network


    >


    >&=23160;&=23160;&=23160;&=23160; Anything that could result in that e= xplicit avoidance being violated


    >&=23160;&=23160;&=23160;&=23160; =E2=80=93 would create, shall we say= significant problems.


    >


    >&=23160;&=23160;&=23160;&=23160; Much of the use case is not a case o= f which nodes the packets flow


    >&=23160;&=23160;&=23160;&=23160; through =E2=80=93 but rather =E2=80=93= which nodes / network segments it can never


    >&=23160;&=23160;&=23160;&=23160; touch or flow through.&=23160; Effec= tively, to be used as a technology to


    >&=23160;&=23160;&=23160;&=23160; avoid certain things for specific re= asons.


    >


    >&=23160;&=23160;&=23160;&=23160; This is also one of the reasons for = needing such deep label stacks =E2=80=93


    >&=23160;&=23160;&=23160;&=23160; this kind of detailed path programmi= ng tends to deepen the stack


    >&=23160;&=23160;&=23160;&=23160; because you sometimes have to be pre= tty explicit.


    >


    >&=23160;&=23160;&=23160;&=23160; It is absolutely critical to us that= this functionality is there =E2=80=93


    >&=23160;&=23160;&=23160;&=23160; and that we can avoid situations whi= ch could cause traffic to


    >&=23160;&=23160;&=23160;&=23160; accidently hit things explicitly avo= ided.


    >


    >&=23160;&=23160;&=23160;&=23160; I wish I could be more specific than= this, but it is what it is.


    >


    >&=23160;&=23160;&=23160;&=23160; Thanks


    >


    >&=23160;&=23160;&=23160;&=23160; Andrew


    >


    >&=23160;&=23160;&=23160;&=23160; *=46rom:* spring <spring-bounc= es=40ietf.org
     >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing-bounces=40ietf.org>> *On Behalf Of *Joel M. Halpern


    >&=23160;&=23160;&=23160;&=23160; *Sent:* Monday, 3 August 2020 21:36<= br />

    >&=23160;&=23160;&=23160;&=23160; *To:* Robert Raszuk <robert=40raszuk.net= <mailto:robert=40raszuk.net>>


    >&=23160;&=23160;&=23160;&=23160; *Cc:* spring=40ietf..org <mailto:spring=40ie= tf.org>


    >&=23160;&=23160;&=23160;&=23160; *Subject:* Re: =5Bspring=5D Spring p= rotection - determining


    > applicability


    >


    >&=23160;&=23160;&=23160;&=23160; (Since the thread has gotten long en= ough, reiterating that this is as a


    >&=23160;&=23160;&=23160;&=23160; participant, not a WG chair.)


    >


    >&=23160;&=23160;&=23160;&=23160; Yes, we are talking IP networks. And= yes, I have seen IP networks that


    >&=23160;&=23160;&=23160;&=23160; choose to drop packets. =46or all so= rts of reasons.


    >&=23160;&=23160;&=23160;&=23160; I think there are likely other reaso= ns why one may not want a random


    >&=23160;&=23160;&=23160;&=23160; path rather than a chosen TE path. I= think it is important we be clear


    >&=23160;&=23160;&=23160;&=23160; about what constraints may be / are = violated when we tell people they


    >&=23160;&=23160;&=23160;&=23160; have this tool (protective rerouting= ) that is intended to preserve QoS.


    >


    >&=23160;&=23160;&=23160;&=23160; Let's be clear. I am not arguing tha= t this is not a good idea. It is a


    >&=23160;&=23160;&=23160;&=23160; good idea. And useful. I am trying t= o figure otu what combination of


    >&=23160;&=23160;&=23160;&=23160; additional mechanisms and clear desc= riptions will lead to everyone


    >&=23160;&=23160;&=23160;&=23160; getting the behavior they expect (wh= ich may not be the behavior they


    >&=23160;&=23160;&=23160;&=23160; desire, but sometimes is the best we= can do.)


    >


    >&=23160;&=23160;&=23160;&=23160; Yours,


    >&=23160;&=23160;&=23160;&=23160; Joel


    >


    >&=23160;&=23160;&=23160;&=23160; On 8/3/2020 2:30 PM, Robert Raszuk w= rote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Joel,


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Are we still talking ab= out IP networks&=23160;here =3F Or perhaps some hard


    >&=23160;&=23160;&=23160;&=23160;&=23160; > slicing with real resou= rce reservations or detnets =3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Because&=23160;if we ar= e talking&=23160;about IP networking I have two


    >&=23160;&=23160;&=23160;&=23160; observations:


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > A) If you need to trave= rse via a specific node (ie. firewall) you


    >&=23160;&=23160;&=23160;&=23160; better


    >&=23160;&=23160;&=23160;&=23160;&=23160; > apply IP encapsulation = to that node.. I don't think IP


    >&=23160;&=23160;&=23160;&=23160; encapsulation&=23160;can


    >&=23160;&=23160;&=23160;&=23160;&=23160; > be hijacked today such = that destination address of the packet is


    >&=23160;&=23160;&=23160;&=23160; ignored.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > B) Have you seen any IP= network where upon topology change (link


    >&=23160;&=23160;&=23160;&=23160; or node


    >&=23160;&=23160;&=23160;&=23160;&=23160; > failure) you suddenly&=23= 160;start dropping&=23160;flows in spite of SPT offering


    >&=23160;&=23160;&=23160;&=23160;&=23160; > perhaps few ms longer p= ath with 10 ms more jitter =3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Or are some SR marketin= g slides promise to turn IP networks in


    >&=23160;&=23160;&=23160;&=23160;&=23160; > something&=23160;new =3F= Worse ... do they mention path quality guarantees,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > resource reservations&=23= 160;=3F I hope not.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Thx,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > R.


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > On Mon, Aug 3, 2020 at = 8:10 PM Joel M. Halpern <jmh=40joelhalpern.com
     >&=23160;&=23= 160;&=23160;&=23160; <mailto:jmh=40joelhalpern.com%20%0b>> &= lt;m= ailto:jmh=40joelhalpern.com>> wrote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Well less serious for T= E SIDs, I am not sure the problem is


    >&=23160;&=23160;&=23160;&=23160; restricted


    >&=23160;&=23160;&=23160;&=23160;&=23160; > to just service SIDs.

    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Suppose that the PCE ha= s specified the path to meet some complex te


    >&=23160;&=23160;&=23160;&=23160;&=23160; > objective.&=23160; The = bypass node has no way of knowing what those


    >&=23160;&=23160;&=23160;&=23160;&=23160; > constraints


    >&=23160;&=23160;&=23160;&=23160;&=23160; > were.&=23160; And for s= ome kinds of traffic, it is better to drop the packet


    >&=23160;&=23160;&=23160;&=23160;&=23160; > than to deliver it outs= ide the envelop.&=23160; I suspect that the right


    >&=23160;&=23160;&=23160;&=23160;&=23160; > answer


    >&=23160;&=23160;&=23160;&=23160;&=23160; > to this is =22too bad=22= ..&=23160; If so, as with the distinction regarding


    >&=23160;&=23160;&=23160;&=23160; service


    >&=23160;&=23160;&=23160;&=23160;&=23160; > nodes, we should say so= , shouldn't we=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Yours,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > Joel


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > On 8/3/2020 2:36 AM, Al= exander Vainshtein wrote:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach, Joel and all= ,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I think that in mo= st cases:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > 1.There is clear d= ifferentiation between =22topological=22 and


    >&=23160;&=23160;&=23160;&=23160; =22service=22


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > instructions in SI= D advertisements. E.g.:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > oIGP Prefix Node S= IDs IGP Adj-SIDs (identified as such in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > corresponding IGP = advertisements) represent topological


    >&=23160;&=23160;&=23160;&=23160; instructions


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > oService SIDs for = SRv6 (see SRv6 BGP-Based Overlay Services


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3CCcy9mY6cMfbk7Qfjhi= A3R6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.ietf.org%2=46doc%2=46html%2=46= draft-ietf-bess-srv6-services-04
     >&=23160;&=23160;&=23160;&=23= 160; <https://clickt= ime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2=3Fu=3Dhttps%3A%2=46%2=46urlde= fense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46= html%2=46draft-ietf-bess-srv6-services-04=5F=5F%3B%21%21NEt6yMaO-gk%21S0Y= usx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24&= gt;>


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > draft) unsurprisin= gly represent =E2=80=9Cservice=E2=80=9D instructions


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > 2.Segments that re= present topological instructions can be bypassed,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > while segments tha= t represent service instructions require


    >&=23160;&=23160;&=23160;&=23160;&=23160; > alternative


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > protection mechani= sms.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > This view seems to= be aligned with R=46C 8402


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2=3Fu=3Dhttps%3A= %2=46%2=46tools.ietf.org%2=46html%2=46rfc8402
     >&=23160;&=231= 60;&=23160;&=23160; <https://clicktime.symantec.com/37PzUK= AD82cjSvmVcGvpkh=466H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46tools.ietf.org%2=46html%2=46rfc8402=5F=5F%3B%21%21NEt6= yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I= 4Ybtm%24>>


    >&=23160;&=23160;&=23160;&=23160; that says in Section 1:


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of an IGP-based distributed control plane, two


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the IGP-Adjacency segment and the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; IGP-Prefix segment.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; In the context of a BGP-based distributed control plane, two


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > topological segmen= ts are defined: the BGP peering segment and the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; BGP-Prefix segment.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > In the case of SR-= MPLS this differentiation is assumed in Section


    >&=23160;&=23160;&=23160;&=23160;&=23160; > 3.4 of


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the Node Protectio= n for SR-TE Path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktim= e.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2=3Fu=3Dhttps%3A%2=46%2=46datatra= cker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protection-for= -sr-te-paths-07%23section-3.4
     >&=23160;&=23160;&=23160;&=231= 60; <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ= 16H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= datatracker.ietf.org%2=46doc%2=46html%2=46draft-hegde-spring-node-protect= ion-for-sr-te-paths-07%2Asection-3.4=5F=5F%3BIw%21%21NEt6yMaO-gk%21S0Yusx= 9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>= >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > draft that says:

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The node protection mechanism described in the previous


    >&=23160;&=23160;&=23160;&=23160; sections


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; depends on the assumption that the label immediately below


    >&=23160;&=23160;&=23160;&=23160;&=23160; > the top


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > label in the label= stack is understood in the IGP domain.&=23160; When the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; provider edge routers exchange service labels via BGP or some


    >&=23160;&=23160;&=23160;&=23160;&=23160; > other


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; non-IGP mechanism the bottom label is not understood in the IGP


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; domain.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; The egress node protection mechanisms described in the draft


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; =5BR=46C8679 <https://clicktime.syma= ntec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2=3Fu=3Dhttps%3A%2=46%2=46datatracker.i= etf.org%2=46doc%2=46html%2=46rfc8679
     >&=23160;&=23160;&=2316= 0;&=23160; <https://clicktime.symantec.com/36= dMAjuYTQovo8jHwmm3eJw6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46= =5F=5Fhttps%3A%2=46datatracker.ietf.org%2=46doc%2=46html%2=46rfc8679=5F=5F= %3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo8MGipXc%24>>=5D


    >&=23160;&=23160;&=23160;&=23160; is


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > applicable to this= use case and no additional changes


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; &=23160;&=23= 160; will be required for SR based networks


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > The scenarios in w= hich &=23160;differentiation between =E2=80=9Ctopological=E2=80=9D and

    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =E2=80=9Cservice=E2= =80=9D instructions is broken are indeed problematic. E.g.,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > consider


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the use case in wh= ich a Node SID in the ERO of a SR-TE path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > identifies a


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > node that acts as = a firewall for all packets it receives, i.e.,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > provides


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > the firewall servi= ce without any dedicated service SID


    >&=23160;&=23160;&=23160;&=23160;&=23160; > identifying it.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > One could say that= the Node SID of such a node would combine


    >&=23160;&=23160;&=23160;&=23160;&=23160; > topological


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > and service instru= ctions thus breaking the differentiation


    >&=23160;&=23160;&=23160;&=23160;&=23160; > between the two.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I am not sure if u= sage of such =E2=80=9Ccombined=E2=80=9D SIDs could be prevented


    >&=23160;&=23160;&=23160;&=23160;&=23160; > or at


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > least discouraged.=


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > If not, providing = an ability to identify such SIDs in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > advertisement


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > mechanisms would b= e useful IMHO.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > My 2c,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Sasha


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Office: +972-39266= 302


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Cell:&=23160;&=231= 60;&=23160;&=23160;&=23160; +972-549266302


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Email: Alex= ander.Vainshtein=40ecitele.com


    >&=23160;&=23160;&=23160;&=23160; <mailto:Alexander.Vainsh= tein=40ecitele.com>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:Ale= xander.Vainshtein=40ecitele.com>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > -----Original Mess= age-----


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =46rom: spring <= ;spring-bounces=40ietf.org
     >&=23160;&=23160;&=23160;&=231= 60; <mailto:spring-bounces=40ietf.org%0b>>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org= >> On Behalf Of Mach Chen


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Sent: Monday, Augu= st 3, 2020 6:30 AM


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > To: Joel M. Halper= n <jmh=40joelhalpern.com
     >&=23160;&=23160;&=23160;&=23160;= <mailto:jmh=40joelhalpern.com%0b>> <mailto:jmh=40joelhalpern.= com>>;


    >&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Subject: Re: =5Bsp= ring=5D Spring protection - determining applicability


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Hi Joel,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I think this is a = good point that may not be discussed in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > past. And


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > I also don't think= there is a =22can be bypassed=22 indication in the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > routing advertisem= ent for now.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > IMHO, the informat= ion advertised by routing is neutral, such


    >&=23160;&=23160;&=23160;&=23160;&=23160; > information


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > (can or cannot be = bypassed) is more path specific, thus


    >&=23160;&=23160;&=23160;&=23160; normally the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > controller should = be responsible for deciding whether/which SID


    >&=23160;&=23160;&=23160;&=23160;&=23160; > can be


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > bypassed.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Best regards,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Mach


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > -----= Original Message-----


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46ro= m: spring =5Bmailto:spring-bounces=40ietf.org


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring-bounc= es=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring-bounces=40ietf.org%0b%3e%20%3cmailto:spring-= bounces=40ietf.org%3e>=5D


    >&=23160;&=23160;&=23160;&=23160; On Behalf Of Joel M.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Halpe= rn


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Sent:= Monday, August 3, 2020 7:51 AM


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > To: <= a href=3D=22mailto:spring=40ietf.org=22 target=3D=22=5Fblank=22>spring=40= ietf.org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
     >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Subje= ct: =5Bspring=5D Spring protection - determining applicability


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > (WG C= hair hat Off, this is merely a note from a slightly


    >&=23160;&=23160;&=23160;&=23160;&=23160; > confused WG


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > parti= cipant.)


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > I hav= e been reading the various repair drafts, and the various


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > netwo= rks programming and service programming draft, and I am


    >&=23160;&=23160;&=23160;&=23160;&=23160; > trying to


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > figur= e out one aspect of the combination.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > How d= oes a node that is doing some form of bypass (suppose, for


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > simpl= icity, it is Node N2 deciding to bypass the next SID for


    >&=23160;&=23160;&=23160;&=23160;&=23160; > a failed


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > node = N3) know that it is safe to do so=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > If th= e path was just for TE, then it is =22safe=22 if the new path


    >&=23160;&=23160;&=23160;&=23160;&=23160; > meets


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > the T= E criteria.&=23160; or maybe it is safe if it is even close, as


    >&=23160;&=23160;&=23160;&=23160;&=23160; > long as


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > it is= not used for too long.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > But w= hat if the node were a =46irewall, included to meet legal


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > requirements=3F

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Or wa= s some other necessary programmatic transform (wince we are


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > delib= erately vague about what nodes can do when asked suitably.)


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Is th= ere some =22can be bypassed=22 indication in the routing


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > adver= tisements that I missed=3F


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Thank= you,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Yours= ,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > Joel<= br />

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > sprin= g mailing list


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > spring=40ietf= ..org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <mailto:spring=40ietf.org <mailto:spring=40ietf.org
     >= ;&=23160;&=23160;&=23160;&=23160; <mailto:spring= =40ietf.org%20%3cmailto:spring=40ietf.org>>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; >
    =

    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dh= ttps%3A%2


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892X= uXy2H6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A= %2=46clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%= 2A3A%2A2=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0w= xqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3F= u=3Dhttps%3A%252
     >&=23160;&=23160;&=23160;&=23160; <https://clicktime.sym= antec.com/3A5B8H2=46m1rPnaZ3Supjwr6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.= com%2=46v3%2=46=5F=5Fhttps%3A%2=46clicktime.symantec.com%2=46367qhU4KiUkz= W9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%2A252=5F=5F%3BJSU%21%21NEt6yMaO-gk%21S0= Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24= >>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >&=23160; > =46%<= a href=3D=22http://2=46www.ietf.org=22 target=3D=22=5Fblank=22>2=46www.ie= tf.org


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/39NznmYBt= RuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5F= http%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5F= R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > <https://clicktime.sym= antec.com/3GWT9fyja=46i3=46cvHDvoodvS6H2=3Fu=3Dhttp%3A%2=46%2=462=46www.i= etf.org
     >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symant= ec.com/39NznmYBtRuHARhGJ5W5dGB6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%= 2=46v3%2=46=5F=5Fhttp%3A%2=462=46www.ietf.org=5F=5F%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24<= /a>>>%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >     spring=40ietf.org <= mailto:s= pring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160; <mailto:spring=40ietf.org> <mailto:s= pring=40ietf.org
     >&=23160;&=23160;&=23160;&=23160; <mailto:spr= ing=40ietf.org%0b>> <mailto:spring=40ietf.org>>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; https://cli= cktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJt= T6H2=3Fu=3Dhttps%3A%2=46%2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46= clicktime.symantec.com%2=46367qhU4KiUkzW9uGC4eAvP46H2%3=46u%3Dhttps%2A3A%= 2A2=46%2A2=46www.ietf.org%2A2=46mailman%2A2=46listinfo%2A2=46spring=5F=5F= %3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo-hR3gAD%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > Notice: This e-mai= l together with any attachments may contain


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > information of Rib= bon Communications Inc. that is confidential


    >&=23160;&=23160;&=23160;&=23160;&=23160; > and/or


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > proprietary for th= e sole use of the intended recipient. Any review,


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > disclosure, relian= ce or distribution by others or forwarding


    >&=23160;&=23160;&=23160;&=23160; without


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > express permission= is strictly prohibited. If you are not the


    >&=23160;&=23160;&=23160;&=23160;&=23160; > intended


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > recipient, please = notify the sender immediately and then delete all


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > copies, including = any attachments.


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160; ------------------------------------= ------------------------------------


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring mailing lis= t


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > spring=40ietf.org <= mailto:s= pring=40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dht= tps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https:/= /clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > >


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >&=23160;&=23160;&=23160;&=23160;&=23160; > =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


    >&=23160;&=23160;&=23160;&=23160;&=23160; > spring mailing list


    >&=23160;&=23160;&=23160;&=23160;&=23160; > spring=40ietf.org <mailto:spring= =40ietf.org> <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;&=23160; > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A= %2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160; <https:/= /clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%2=46%2=46= urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listinfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >&=23160;&=23160;&=23160;&=23160;&=23160; >


    >


    >&=23160;&=23160;&=23160;&=23160; =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


    >&=23160;&=23160;&=23160;&=23160; spring mailing list


    >&=23160;&=23160;&=23160;&=23160; spring=40ietf.org <mailto:spring=40ietf.org>


    >&=23160;&=23160;&=23160;&=23160;     https://cli= cktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46ww= w.ietf.org%2=46mailman%2=46listinfo%2=46spring


    >&=23160;&=23160;&=23160;&=23160;


    > <https://clicktime.= symantec.com/3NrDnSTReXh671G79BVGEq16H2=3Fu=3Dhttps%3A%
     > 2=46= %2=46urldefense.com%2=46v3%2=46=5F=5Fhttps%3A%2=46www.ietf.org%2=46mailman%2=46= listi


    > nfo%2=46spring=5F=5F%3B%21%21NEt6yMaO-gk%21S0Yusx9=46YNE8E=5FR1oiQAt= Qxgm0x0wxqgu


    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>


    >


    >


    >


    > --------------------------------------------------------------------= --


    > --


    > Notice: This e-mail together with any attachments may contain


    > information of Ribbon Communications Inc. that is confidential and/o= r


    > proprietary for the sole use of the intended recipient. Any review,<= br />

    > disclosure, reliance or distribution by others or forwarding without=


    > express permission is strictly prohibited. If you are not the intend= ed


    > recipient, please notify the sender immediately and then delete all<= br />

    > copies, including any attachments.


    > --------------------------------------------------------------------= --


    > --





    =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


    spring mailing list


    spring=40= ietf.org


    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring


    =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


    spring mailing list


    spring=40= ietf.org


    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVP= ByhqLq6H2=3Fu=3Dhttps%3A%2=46%2=46www.ietf.org%2=46mailman%2=46listinfo%2= =46spring





    &=23160;





    &=23160;



    <= /span>



    Notice: This e-mail together with any attachments may co= ntain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, di= sclosure, reliance or distribution by others or forwarding without expres= s permission is strictly prohibited. If you are not the intended recipien= t, please notify the sender immediately and then delete all copies, inclu= ding any attachments.



    <= /span>





    &=23160;























    =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


    spring mailing list


    spring=40= ietf.org


    https://www.ietf.org/mailman/listinfo/spring






















    =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

    spring mailing list

    spring=40= ietf.org

    https://www.ietf.org/mailman/listinfo/= spring

    --


    Gyan Mishra<= /p>

    Netw= ork Solutions Architect&=23160;

    M 301 502-1347
    13101 Columbia Pike&=23160;
    Silver Spring, MD


    --5f3b15eb_431bd7b7_65d7-- From nobody Mon Aug 17 18:11:46 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AC23A157A; Mon, 17 Aug 2020 18:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 oizYGy1zX5pc; Mon, 17 Aug 2020 18:11:43 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253038.outbound.protection.outlook.com [40.92.253.38]) (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 E80333A1577; Mon, 17 Aug 2020 18:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G3OryM8T3noEroOvc+JKNYbpd82mtLIeKuuR9WMx0H07DYS1fXe+7dPVoo6swxc+02SezXTtQqtHkwnWpfCBXIm43mSRdX6sdPc03OKdsHtdk51msleb07+4iYzYRzdnFIup8YEfAvBEZbfEY7ml+0Hp1pHWTNewC9hTF+Tb3NDa7OLHfux6sj9Fzt0w2q9Cg70RGoM5GJDuK7IxpgHykC8V6/1RxGtqaNTsdj5Ln0Btlw1fMUjIGumAyTDlshl4XCUL9LaJyapnWIhHjeaOiiPrP7ug7ycFnT1VRy/fs3FMWBF1uDCQKLkY3oD7rJX32gOcheeJ/T5bMub5rcrVpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AyyzDPflMuq2GsD4r7d2SY78P5Ofe/JeRB5mBgpIB3E=; b=VMh6823y3ofaQTLACv2UOpJMQL22GLl1nwS2De/tUzp2dj5RDlyxKXNlV+pVXzA27IDJYOVtXq7uOKN+5gmv2nCycz8u2OWudOCsEvmfEq3VUYtoc17oh7JeupdiGqr2vPoQGzHt/LawvdlrfZn9p9zcgQPNR6dCoBS2yF7JBqOPzPmvfeo+iaCEMhLcVA/+8l99kZVjFXlKqTdpEjCdGCfFYms737ZZokzNcA7Z+vfqq6DJDkY9tHhvB1ECYyAoTyLGeJI4JpkYqpgyWMOnF0HeDwJWpisIeMx8I5dAxbbLKtbtX7yXXX5967K4U8zKEP7WHiGUJbMQtUKxYDB96w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AyyzDPflMuq2GsD4r7d2SY78P5Ofe/JeRB5mBgpIB3E=; b=nv6XJalM1FSNVK/vL99VS18t8EGFbi5ehKzCWbIpyYniZjwWka1BqpWGt2LIobg6OoAuQu7NWJ2fgMROHDGewBh4ivqea4lbI2u7jIi7H8ui56GMj9QuCV+iP85VEuAvCIdClCTHTG8IiptJK4mIQwrn959e65/bTuDp12F87gcugZfyt6EGJ68V2sLWW4LXwIPr/SR4f1MPa2CXDXiukWTs7n5410sL6PccbGe7U9Cdi3B+thAhhyJN0QzPAByVcBcq7Z0kTDzzJF2BaKRkD46HEaQFiVWd/NlJGIKFX8063aaef/Kcq66EK0iYMl2me+FMIbKxXvBDEjgSK7FH2A== Received: from HK2APC01FT043.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::40) by HK2APC01HT027.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::463) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Tue, 18 Aug 2020 01:11:35 +0000 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com (2a01:111:e400:7ebc::4f) by HK2APC01FT043.mail.protection.outlook.com (2a01:111:e400:7ebc::348) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16 via Frontend Transport; Tue, 18 Aug 2020 01:11:35 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:D618F4242FA4955CF4AF27E3819B29D3E431F3A25A2AFB367D644B6793D96AEA; UpperCasedChecksum:CC4B3D9A5C2AB5CE13CCCA2A5A48FD430A4890B8202171ECE8A86C59824B2B96; SizeAsReceived:8889; Count:49 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::7c95:91ff:e747:fd8]) by HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::7c95:91ff:e747:fd8%5]) with mapi id 15.20.3305.023; Tue, 18 Aug 2020 01:11:35 +0000 Date: Tue, 18 Aug 2020 09:12:09 +0800 From: "li_zhenqiang@hotmail.com" To: "Ketan Talaulikar (ketant)" , "spring@ietf.org" , draft-ietf-spring-segment-routing-policy References: , X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart288175522243_=----" X-ClientProxiedBy: HK2PR02CA0201.apcprd02.prod.outlook.com (2603:1096:201:20::13) To HK0PR03MB4066.apcprd03.prod.outlook.com (2603:1096:203:9d::21) X-Microsoft-Original-Message-ID: <2020081809120872827633@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from cmcc-PC (183.243.251.14) by HK2PR02CA0201.apcprd02.prod.outlook.com (2603:1096:201:20::13) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.3283.15 via Frontend Transport; Tue, 18 Aug 2020 01:11:34 +0000 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] X-Microsoft-Original-Message-ID: <2020081809120872827633@hotmail.com> X-TMN: [QjSqWgWGvFb3IyPSxyb3j0UfiCG4tGUP] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 371e1421-c3b8-4310-e175-08d84313a658 X-MS-TrafficTypeDiagnostic: HK2APC01HT027: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FlAI2V625PeDOrsC/ngNhOMikjIAwPstVmz2CH2QdOdeJqRygpP5eYUa8nOnVMSZxXIfWTaJ2Gn7DSQtznQhlcxnBL5ZnNhIJKZf3CMzuXo7Y9yguYwBTU4u/iwK8ldN2i8kG5S2/xswRNozyYzUbVOOPArHE9BNz7WVk6diBMmtb3JOqfelgRp33evR9AV4g9+TLwlLGR+QoT9TDoQRcio0LgahB6B9xdQGnMTyf1/5NVwTT+IosD8TLzuMArUD X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR03MB4066.apcprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:; DIR:OUT; SFP:1901; X-MS-Exchange-AntiSpam-MessageData: 0DEzLLiSBt3YkKYkMhObHsReuRqSWVj7Dbs01VB23GmR/S1RC7M59PWn3R1XwVnts1EEXOPjvpN0MYVZGE5xu4Y0pJN3EnKWL+UeuLkuEO1SwJg4eWspi3Q5fzA+X52zvsPMW9w+7IOkeX1nzN2LDg== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 371e1421-c3b8-4310-e175-08d84313a658 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2020 01:11:35.2324 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT043.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT027 Archived-At: Subject: Re: [spring] Comments on SR policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 01:11:45 -0000 ------=_001_NextPart288175522243_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gS2V0YW4sDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXNwb25zZS4gDQoNCkZvciBxdWVz dGlvbiBOby4gMSwgSSBjYW4gdW5kZXJzdGFuZCBUeXBlIEUgYW5kIFR5cGUgRyBjYW4gYmUgdXNl ZCB0byBwcmVzZW50IGxheWVyIDIgaW50ZXJmYWNlLiBIb3dlcnZlciwgdGhlIG1ldGhvZCBpbnRy b2R1Y2VkIGluIFJGQyA4NjY4IGlzIGRpZmZlcmVudCwgaW4gd2hpY2ggU0lEIGlzIHVzZWQgdG8g ZGlyZWN0bHkgaW5kaWNhdGUgdGhlIG1lbWJlciBsaW5rIG9mIGEgbGF5ZXIgMiBsaW5rIGJ1bmRs ZS4gV2hlbiB1c2luZyB0aGUgc2VnbWVudCBkZWZpbmVkIGluIFJGQzg2NjgsIHRoZSBoZWFkZW5k IGRvZXNuJ3QgbmVlZCB0byByZXNvbHZlIHRoZSBJUCBhZGRyZXNzIGFuZCB0aGUgaW50ZXJmYWNl IElEIHNwZWNpZmllZCBpbiBUeXBlIEUgb3IgRy4NCg0KU28gSSB0aGluayBpdCBpcyBiZXR0ZXIg dG8gYWRkIG9uZSBtb3JlIHNlZ21lbnQgdHlwZSB0byBjb250YWluIHRoZSBzZWdtZW50IGRlZmlu ZWQgaW4gUkZDODY2OCBmb3IgbGF5ZXIgMiBidW5kbGUgbWVtYmVycy4NCg0KQmVzdCBSZWdhcmRz LA0KWmhlbnFpYW5nIExpDQoNCg0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tDQogDQpGcm9tOiBL ZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpDQpEYXRlOiAyMDIwLTA4LTE0IDE5OjM2DQpUbzogbGlf emhlbnFpYW5nQGhvdG1haWwuY29tOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3kNClN1YmplY3Q6IFJFOiBDb21tZW50cyBvbiBTUiBwb2xp Y3kNCkhpIFpoZW5xaWFuZyBMaSwNCiANClRoYW5rcyBmb3IgeW91IHJldmlldyBhbmQgc2hhcmlu ZyB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KIA0KRnJvbTogbGlf emhlbnFpYW5nQGhvdG1haWwuY29tIDxsaV96aGVucWlhbmdAaG90bWFpbC5jb20+IA0KU2VudDog MDUgQXVndXN0IDIwMjAgMTQ6MDMNClRvOiBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kgPGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91 dGluZy1wb2xpY3lAaWV0Zi5vcmc+DQpTdWJqZWN0OiBDb21tZW50cyBvbiBTUiBwb2xpY3kNCiAN CkRlYXIgYXV0aG9ycyBhbmQgYWxsLA0KIA0KUGxlYXNlIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg Y29tbWVudHMuDQoxLiBEbyB5b3UgdGhpbmsgaXQgaXMgb2sgdG8gYWRkIG9uZSBtb3JlIHNlZ21l bnQgdHlwZSBmb3IgdGhlIHNlZ21lbnQgbGlzdCB0byBpbmNvcnBvcmF0ZSB0aGUgc2VnbWVudCBm b3IgTGF5ZXIgMiBidW5kbGUgbWVtYmVycz8gUGxlYXNlIHJlZmVyIHRvIHJmYzg2NjguDQpbS1Rd IFRoZSBTZWdtZW50IFR5cGUgRSBjb3ZlcnMgTGF5ZXIgMiBCdW5kbGUgTWVtYmVycyA6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5LTA4I3NlY3Rpb24tNA0KIA0KICAgICAgICAgVGhpcyB0eXBlIGNhbiBhbHNvIGJlDQog ICAgICAgICB1c2VkIHRvIGluZGljYXRlIGluZGlyZWN0aW9uIGludG8gYSBsYXllciAyIGludGVy ZmFjZSAoaS5lLg0KICAgICAgICAgd2l0aG91dCBJUCBhZGRyZXNzKSBsaWtlIGEgcmVwcmVzZW50 YXRpb24gb2YgYW4gb3B0aWNhbA0KICAgICAgICAgdHJhbnNwb3J0IHBhdGggb3IgYSBsYXllciAy IEV0aGVybmV0IHBvcnQgb3IgY2lyY3VpdCBhdCB0aGUNCiAgICAgICAgIHNwZWNpZmllZCBub2Rl Lg0KDQogDQoyLiBGb3IgcGVyIGZsb3cgc3RlZXJpbmcgdG8gYSBwb2xpY3ksIHdoeSBkbyB3ZSBs aW1pdCB0aGUgYXJyYXkgaW5kZXggdG8gMCB0byA3PyAgSSB0aGluayB0aGlzIGlzIGltcGxlbWVu dGF0aW9uIHNwZWNpZmljIGFuZCB0aGUgbnVtYmVyIG9mIHBhdGhzIGluIGFuIGFycmF5IGRlcGVu ZHMgb24gdGhlIGFwcGxpY2F0aW9uIHNjZW5hcmlvLiBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgb3Ig bm90IDggcGF0aHMgaXMgZW5vdWdoIGZvciBhbGwgc2NlbmFyaW9zLg0KW0tUXSBUaGUgZHJhZnQg ZG9lcyBub3QgbGltaXQgdGhlIEZvcndhcmRpbmcgQ2xhc3NlcyB0byA4LiBUaGUgdmFsdWUgOCBp cyBtb3JlIG9mIGFuIGV4YW1wbGUgYW5kIGNvbWVzIGZyb20gVHJhZmZpYyBDbGFzcyBbUkZDNTQ2 Ml0gYW5kIHRoZSBJUCBQcmVjZWRlbmNlIHBvcnRpb24gb2YgRFNDUCBbUkZDMjQ3NF0uIFRoZSBz ZWN0aW9uIHN0YXJ0cyB3aXRoIOKAnExldCB1cyBhc3N1bWXigJ0gYW5kIHRoZXJlIGlzIGFsc28g dGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSBzYW1lIHNlY3Rpb246ICAgIFRoZSBhcnJheSBpbmRl eCB2YWx1ZXMgKGUuZy4gMCwgMSBhbmQgMikgYW5kIHRoZSBub3Rpb24gb2YgICBmb3J3YXJkaW5n LWNsYXNzIGFyZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBhbmQgb25seSBtZWFudCB0byAgIGRl c2NyaWJlIHRoZSBkZXNpcmVkIGJlaGF2aW9yLiAgVGhlIHNhbWUgY2FuIGJlIHJlYWxpemVkIGJ5 IG90aGVyICAgbWVjaGFuaXNtcy4gDQogDQozLiBGb3IgcHJvdGVjdGlvbiBpbiBzZWN0aW9uIDku MSwgaXQgaXMgYmV0dGVyIHRvIGFkZCBzb21lIHRleHQgbGlrZSAidGhlIGxvY2FsIHByb3RlY3Rp b24gbWF5IG5vdCBzYXRpc2Z5IHRoZSBTTEEgcmVxdWlyZW1lbnRzIG9yIHRoZSBwYXRoIGNvbnN0 cmFpbnMgZm9yIHRoZSBwb2xpY3kiIHdoZW4gYW4gU1IgUG9saWN5IGlzIGJ1aWx0IG9uIHRoZSBi YXNpcyBvZiBUSS1MRkEgcHJvdGVjdGVkIElHUCBzZWdtZW50cy4NCltLVF0gU3VyZS4gV2UgY2Fu IGFkZCB0aGlzIGNsYXJpZmljYXRpb24gaW4gdGhlIG5leHQgdXBkYXRlLg0KIA0KVGhhbmtzLA0K S2V0YW4NCiANCkJlc3QgUmVnYXJkcywNClpoZW5xaWFuZyBMaQ0KDQoNCmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbQ0K ------=_001_NextPart288175522243_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom:= 0px; margin-left: 0.5em; }p { margin-top: 0px; margin-bottom: 0px; }div.Fo= xDiv20200817150514340284 { }body { font-size: 10.5pt; font-family: =E5=BE= =AE=E8=BD=AF=E9=9B=85=E9=BB=91; color: rgb(0, 0, 0); line-height: 1.5; }=0A= =0A=
    Hello Ketan,

    Thank you for your = response. 

    =0A=

    For qu= estion No. 1, I can understand Type E and Type G can be used to present lay= er 2 interface. Howerver, the method introduced in RFC 8668 is different, i= n which SID is used to directly indicate the member link of a layer 2 link = bundle. When using the segment defined in RFC8668, the headend doesn't need= to resolve the IP address and the interface ID specified in Type E or G.


    So I think i= t is better to add one more segment type to contain the segment defined in = RFC8668 for layer 2 bundle members.


    <= div>Best Regards,
    Zhenqiang Li
    =0A=
    li_zhenqiang@hotmail.com
    =0A=
     
    Date: 2020= -08-14 19:36
    To: = li_zhenqiang@hotmail.com; spring@ietf.org; draft-ietf-spring-seg= ment-routing-policy
    Subject: RE: Comments on SR p= olicy
    =0A= =0A=
    =0A=

    Hi Zhenqiang Li,

    =0A=

     

    =0A=

    Thanks for you review and sharing your comments. Please check inline bel= ow.

    =0A=

     

    =0A=
    =0A=
    =0A=

    From:= li_zhenqiang@hotmail.com <li_zhenqiang@hotmail.com= >=0A=
    =0A= Sent: 05 August 2020 14:03
    =0A= To: spring@ietf.org; draft-ietf-spring-segment-routing-policy <dr= aft-ietf-spring-segment-routing-policy@ietf.org>
    =0A= Subject: Comments on SR policy

    =0A=
    =0A=
    =0A=

     

    =0A=
    =0A=

    Dear authors and all,

    =0A=
    =0A=
    =0A=

     

    =0A=
    =0A=
    =0A=

    Please consider the following comme= nts.

    =0A=
    =0A=
    =0A=

    1. Do you think it is ok to add one= more segment type for the segment list to incorporate the segment for Laye= r 2 bundle members? Please refer to rfc8668.

    =0A=

    [KT] The Segment Type E covers Lay= er 2 Bundle Members :=0A= https://tools.ietf.org/html/draft-ietf-spring-segment-routing= -policy-08#section-4

    =0A=

     

    =0A=

         &nbs= p;   This type can also be

    =0A=

         &nbs= p;   used to indicate indirection into a layer 2 interface (i.e.<= o:p>

    =0A=

         &nbs= p;   without IP address) like a representation of an optical=

    =0A=

         &nbs= p;   transport path or a layer 2 Ethernet port or circuit at the<= o:p>

    =0A=

         &nbs= p;   specified node.


    =0A=

     

    =0A=
    =0A=
    =0A=

    2. For per flow steering to a polic= y, why do we limit the array index to 0 to 7?  I think this is impleme= ntation specific and the number of paths in an array depends on=0A= the application scenario. I am not sure whether or not 8 paths is enough f= or all scenarios.

    =0A= 
    [KT] The draft does not limit the Forwarding Classes=
 to 8. The value 8 is more of an example and comes from Traffic Class [RFC5=
462] and the IP Precedence portion of DSCP [RFC2474]. The section starts wi=
th =E2=80=9CLet us assume=
=E2=80=9D =
and there is also the following text in the same section:=
    =0A= 
     
    =0A= 
       The array index values =
(e.g. 0, 1 and 2) and the notion of
    =0A= 
       forwarding-class are im=
plementation specific and only meant to
    =0A= 
       describe the desired be=
havior.  The same can be realized by other
    =0A= 
       mechanisms.<=
/span>
    =0A= 
     
    =0A=

     

    =0A=
    =0A=
    =0A=

    3. For protection in section 9.1, i= t is better to add some text like "the local protection may not satisf= y the SLA requirements or the path constrains for the policy" when&nbs= p;an=0A= SR Policy is built on the basis of TI-LFA protected IGP segments.

    =0A=

    [KT] Sure. We can add this clarifi= cation in the next update.

    =0A=

     

    =0A=

    Thanks,

    =0A=

    Ketan

    =0A=
    =0A=
    =0A=

     

    =0A=
    =0A=
    =0A=

    Best Regards,

    = =0A=
    =0A=
    =0A=

    Zhenqiang Li

    = =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    =0A= =0A=
    =0A=
    =0A=
    =0A=
    =0A= = ------=_001_NextPart288175522243_=------ From nobody Mon Aug 17 21:29:09 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27E63A1738; Mon, 17 Aug 2020 21:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Fx3FUl7l; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=InPNHHtr 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 SFrCUvrzOaKD; Mon, 17 Aug 2020 21:29:03 -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 6F4CA3A1737; Mon, 17 Aug 2020 21:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29144; q=dns/txt; s=iport; t=1597724943; x=1598934543; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=L3zBSXKxvlmXrxHuqAEJL1I3sCTGqRYu/JOCAlHJKVI=; b=Fx3FUl7lVBGauZAySXva9EzT7ZKI6Yiw0vLeZg0IaTQIy4CDIsNlPWHA eTTPakx14GpP827ZEB9wyTvqNl2uqcWaZDGsDMPr/TK5OsnDQyAWQpHqI p/7vJCQGu48XiLca1r/2I7UvGFryedg7NS4Gf1Iv8tTp7QNji4eXdyIdG A=; IronPort-PHdr: =?us-ascii?q?9a23=3A2Lz6sxY52ri6qFwLpOobiOj/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaZD4Xc9/dNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNF3Vvni77DpUER?= =?us-ascii?q?L6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChBQD+Vztf/4QNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoEjL1EHcFgvLAqELYNGA41cgmuHHY5hgUKBEQNVCwEBAQw?= =?us-ascii?q?BASUIAgQBAYRMAheCNgIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEEEhE?= =?us-ascii?q?KEwEBOA8CAQgRAwEBASEHAwICAjAUCQgCBAESCBqDBYF+TQMuAQ6lVwKBOYh?= =?us-ascii?q?hdoEygwEBAQWFORiCDgMGgTiCcYJSS0OGTBuBQT+BEUOBT34+ghpCAQECAYE?= =?us-ascii?q?iEioVCQ0JgmEzgi2TA4Zhi12QIVEKgmKIY4w/hR+DAIlckR6CJ5BggVqBbIh?= =?us-ascii?q?XgmWNcIFGgmECBAIEBQIOAQEFgWojgVdwFTuCaVAXAg2OHwwXg06FFIVCdDc?= =?us-ascii?q?CBgEJAQEDCXyOE4E0AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,326,1592870400"; d="scan'208,217";a="813324672" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2020 04:29:01 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 07I4T2Ul014245 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2020 04:29:02 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 17 Aug 2020 23:29:01 -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.1497.2; Mon, 17 Aug 2020 23:29:01 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 17 Aug 2020 23:29:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WIhsN4w8Yc02qBR13tOqOAAu3+02WvOtx82y5IB9g9N4L/OYcls6qCd8MXHzZrZhgndWL/EvPVdWwrlnXwBnYxY6TCA1QRc5pcYHY0hTpJ8YhLL1S4k5vKSvP+cuZa7xfdWMbJL8YNXoPMEe8aWrHWH8kgGBnuuh/R2o1v+0XVGYZOmld1uoTW0cCsiFdyfxWUyGvMj+6WgVFOwArY26EAWcopmH1UMHwT8cIQgEbvfQHo6GZnrZ6ZwlGoBbWj4VAEpfQOp8LrPLI7cEE0QdbypT+9R4lozn5gAonufHbP9/w41sr1QWZ2pH1Nc/vDdLIkPWY1irIKQ6NiQq9fU8Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L3zBSXKxvlmXrxHuqAEJL1I3sCTGqRYu/JOCAlHJKVI=; b=Ntn55AETFx9fSiUplePUk/4HbA8o5MElYruzxmvxgNfHeJDMOSMtRecEaIx7TS+LWXKMjkC8eB55136PnCUxUj3tJ/w/7LFtNnNq6kL5EP4FWEj50g9zUmTAKo+VsVdyzplUxRaWsgiukJLwnbmVKwHcErnbxNlTcUeJRAwcNFIAfo8QNDsOr2LQvhMMrb6WaysABzrZAjiz2mUJwYnr+eGikJVWnqNSmavP7CZKCrMRawBhsrtKBfdxpLmepj1MOUR4Lh1ELaI3udXTogegunIKuj99UQA2q1scvLon8jv5ygdoML/nkDfR2wjyIim8Saxaxmsivfs8eO2D+RQjqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L3zBSXKxvlmXrxHuqAEJL1I3sCTGqRYu/JOCAlHJKVI=; b=InPNHHtraOegExeR1AnOdSUxP7b8a0h9gZxEV0gnnmZ4+S9iHLwMwffdhKh33b1jbwVGn4nNO5D5hnG2FPc48f0GF6L4Qe1LuEphdkPeiYXBkyW/wrSW5fM0q5JO5gOwVzwlMy8lcLQIggRmr3sxYAF756lmPfTq9b39nX6uAGw= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1405.namprd11.prod.outlook.com (2603:10b6:300:21::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Tue, 18 Aug 2020 04:29:00 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135%8]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 04:29:00 +0000 From: "Ketan Talaulikar (ketant)" To: "li_zhenqiang@hotmail.com" , "spring@ietf.org" , draft-ietf-spring-segment-routing-policy Thread-Topic: RE: Comments on SR policy Thread-Index: AQHWawMILoFabYib1kW1oP9vIEh+a6k3bvOggAW0IjOAADYggA== Date: Tue, 18 Aug 2020 04:28:59 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13f91f7b-1084-4352-e07f-08d8432f3ac5 x-ms-traffictypediagnostic: MWHPR11MB1405: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ylBi+sxOBhusqowdpP12M2i3Y+4OczeHk6wWTDDBVrocdL9MX8UsluxlRaZjfLUNpbMBoQnRfgY4M5NOnX/HN8NT+e+ZvYEJMtZYVsNKKFbVVoUCfYlotHqjwPlYRS79W794j0rEwJthX4hGepbll9c0B7jRllQxzFzHgYKdgVJMF8gpOkwbZUXnqgtRUJH26jUDhoYvCj+/yXeloQmT8TKjI97AI7rBizihmhXgsGPRDSaKmBSkToY8buZIbrhYXd2cUM/QlRbs+lbCVb30wWOiPFzU4kTkx9ccCz3r0mLtjiozpFWlJJIdyGf2CfhrVhACTd6u9U8kRjP10hOYay5OSY8TJXChzltfSqO5d7E5JW5YJn51P7x9Qlr+C2UClsvE+9iFxTiOe+eWjgSVVQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(396003)(366004)(376002)(136003)(7696005)(6506007)(55016002)(53546011)(966005)(45080400002)(71200400001)(478600001)(52536014)(110136005)(5660300002)(8936002)(26005)(9686003)(186003)(316002)(166002)(83380400001)(2906002)(66946007)(33656002)(86362001)(66556008)(66446008)(66476007)(76116006)(64756008)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: TFWnUgtBbtcpbZZT/YQwJRP0VZpPQ7vdl3LRJZfTeCj+ZvnuWDuxU+I1nE+lsh78AMXUo9pC8LDqrFPrWJr36KoxG0DgDyoNY1FdBkCAp0ARVVj+hOBdj8yd9RNaHFmTzaKTU+02YqfWIdqujyeYH6sQS4kruNjBtaQvXViZislHpZT5SQh+LqcbPH/kxi3KyOusDU1eRZ9xQK5zXU2qJl6wvhr7E3EWru4nvGzUiamKvgctpmw1+KDwt31LvDQOkCawRDhQDNyroZtf/DTsKKuTp9zh418j3b4rziDxiqHF301Yn6RgMOOa2+cZuWsQprMnFRWRciqpGbQT3LDUxUEqUb7JlauOHTG86hyizoy4n7JONqKUIcRdaM8IMV1KcnzT61m0kNuHkAqQ9sfm/LW1qAOxmTHMg4ZIzYbJNf2IBfTt/QunONipY4XA6JiQShReMvtUzPq+TtZoKRzgHPRDbYNOfsWdU+CZjB2Uiz51ch6AVMX0XCu+rEOcp6EN6DEec6mWI3YZWwzY6We0vc5i2zaYO+6h/bE61heyjTBnvtkGp15pOVNaOMhP0QAZONJOD8wxaRCZjUk8ytnNEyrkCenL0DM2PTTXvr6khufWWEfXDSYxNeyyyYaYzpE/V9o4UHMInJ9lW3se5qgQxA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570088488A0E4700A875069C15C0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13f91f7b-1084-4352-e07f-08d8432f3ac5 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 04:29:00.0519 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5+6IOJNYt4S+td5ZrOPKdn/AxrQL4rc0QnVOC7AT/djmzcb6Qp/3wKXwTCGabDenf5/sfpgjKjpWGOWGUvIPXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1405 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [spring] Comments on SR policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 04:29:06 -0000 --_000_MW3PR11MB4570088488A0E4700A875069C15C0MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWmhlbnFpYW5nIExpLA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBs aV96aGVucWlhbmdAaG90bWFpbC5jb20gPGxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT4NClNlbnQ6 IDE4IEF1Z3VzdCAyMDIwIDA2OjQyDQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0 YW50QGNpc2NvLmNvbT47IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLXBvbGljeSA8ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGlj eUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBSRTogQ29tbWVudHMgb24gU1IgcG9saWN5DQoNCkhl bGxvIEtldGFuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UuDQoNCkZvciBxdWVzdGlv biBOby4gMSwgSSBjYW4gdW5kZXJzdGFuZCBUeXBlIEUgYW5kIFR5cGUgRyBjYW4gYmUgdXNlZCB0 byBwcmVzZW50IGxheWVyIDIgaW50ZXJmYWNlLiBIb3dlcnZlciwgdGhlIG1ldGhvZCBpbnRyb2R1 Y2VkIGluIFJGQyA4NjY4IGlzIGRpZmZlcmVudCwgaW4gd2hpY2ggU0lEIGlzIHVzZWQgdG8gZGly ZWN0bHkgaW5kaWNhdGUgdGhlIG1lbWJlciBsaW5rIG9mIGEgbGF5ZXIgMiBsaW5rIGJ1bmRsZS4g V2hlbiB1c2luZyB0aGUgc2VnbWVudCBkZWZpbmVkIGluIFJGQzg2NjgsIHRoZSBoZWFkZW5kIGRv ZXNuJ3QgbmVlZCB0byByZXNvbHZlIHRoZSBJUCBhZGRyZXNzIGFuZCB0aGUgaW50ZXJmYWNlIElE IHNwZWNpZmllZCBpbiBUeXBlIEUgb3IgRy4NCltLVF0gVGhlIFR5cGUgQSBpcyBhdmFpbGFibGUg Zm9yIGFsbCB0eXBlcyBvZiBTUi1NUExTIFNlZ21lbnRzIHRvIGJlIHNwZWNpZmllZCBpbiB0aGUg Zm9ybSBvZiBhIGxhYmVsIChhbmQgaXQgZG9lcyBub3QgcmVxdWlyZSBoZWFkZW5kIHRvIHBlcmZv cm0gYW55IHJlc29sdXRpb24pIOKAkyBzYW1lIGlzIGFsc28gdXNhYmxlIGZvciBMMiBCdW5kbGUg TWVtYmVyIEFkai1TSUQuIFRoZSBUeXBlIEUgb3IgRyBpcyBmb3Igd2hlbiB0aGlzIFNJRCBpcyB0 byBiZSByZXByZXNlbnRlZCBhcyBOb2RlIFNlZ21lbnQgKyBMaW5rIElEIGZvciB0aGUgaGVhZGVu ZCB0byByZXNvbHZlIHRvIHRoZSBMMiBCdW5kbGUgTWVtYmVyIEFkai1TSUQuDQoNClRoYW5rcywN CktldGFuDQoNClNvIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGFkZCBvbmUgbW9yZSBzZWdtZW50 IHR5cGUgdG8gY29udGFpbiB0aGUgc2VnbWVudCBkZWZpbmVkIGluIFJGQzg2NjggZm9yIGxheWVy IDIgYnVuZGxlIG1lbWJlcnMuDQoNCg0KQmVzdCBSZWdhcmRzLA0KWmhlbnFpYW5nIExpDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1h aWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20+DQoNCkZyb206IEtldGFuIFRhbGF1bGlrYXIg KGtldGFudCk8bWFpbHRvOmtldGFudEBjaXNjby5jb20+DQpEYXRlOiAyMDIwLTA4LTE0IDE5OjM2 DQpUbzogbGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1haWx0bzpsaV96aGVucWlhbmdAaG90bWFp bC5jb20+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IGRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3k8bWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3lAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQ29tbWVudHMg b24gU1IgcG9saWN5DQpIaSBaaGVucWlhbmcgTGksDQoNClRoYW5rcyBmb3IgeW91IHJldmlldyBh bmQgc2hhcmluZyB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpG cm9tOiBsaV96aGVucWlhbmdAaG90bWFpbC5jb208bWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWls LmNvbT4gPGxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTxtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1h aWwuY29tPj4NClNlbnQ6IDA1IEF1Z3VzdCAyMDIwIDE0OjAzDQpUbzogc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctcG9saWN5IDxkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5QGlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5QGlldGYu b3JnPj4NClN1YmplY3Q6IENvbW1lbnRzIG9uIFNSIHBvbGljeQ0KDQpEZWFyIGF1dGhvcnMgYW5k IGFsbCwNCg0KUGxlYXNlIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgY29tbWVudHMuDQoxLiBEbyB5 b3UgdGhpbmsgaXQgaXMgb2sgdG8gYWRkIG9uZSBtb3JlIHNlZ21lbnQgdHlwZSBmb3IgdGhlIHNl Z21lbnQgbGlzdCB0byBpbmNvcnBvcmF0ZSB0aGUgc2VnbWVudCBmb3IgTGF5ZXIgMiBidW5kbGUg bWVtYmVycz8gUGxlYXNlIHJlZmVyIHRvIHJmYzg2NjguDQpbS1RdIFRoZSBTZWdtZW50IFR5cGUg RSBjb3ZlcnMgTGF5ZXIgMiBCdW5kbGUgTWVtYmVycyA6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4I3NlY3Rpb24t NA0KDQogICAgICAgICBUaGlzIHR5cGUgY2FuIGFsc28gYmUNCiAgICAgICAgIHVzZWQgdG8gaW5k aWNhdGUgaW5kaXJlY3Rpb24gaW50byBhIGxheWVyIDIgaW50ZXJmYWNlIChpLmUuDQogICAgICAg ICB3aXRob3V0IElQIGFkZHJlc3MpIGxpa2UgYSByZXByZXNlbnRhdGlvbiBvZiBhbiBvcHRpY2Fs DQogICAgICAgICB0cmFuc3BvcnQgcGF0aCBvciBhIGxheWVyIDIgRXRoZXJuZXQgcG9ydCBvciBj aXJjdWl0IGF0IHRoZQ0KICAgICAgICAgc3BlY2lmaWVkIG5vZGUuDQoNCg0KMi4gRm9yIHBlciBm bG93IHN0ZWVyaW5nIHRvIGEgcG9saWN5LCB3aHkgZG8gd2UgbGltaXQgdGhlIGFycmF5IGluZGV4 IHRvIDAgdG8gNz8gIEkgdGhpbmsgdGhpcyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBhbmQg dGhlIG51bWJlciBvZiBwYXRocyBpbiBhbiBhcnJheSBkZXBlbmRzIG9uIHRoZSBhcHBsaWNhdGlv biBzY2VuYXJpby4gSSBhbSBub3Qgc3VyZSB3aGV0aGVyIG9yIG5vdCA4IHBhdGhzIGlzIGVub3Vn aCBmb3IgYWxsIHNjZW5hcmlvcy4NCg0KW0tUXSBUaGUgZHJhZnQgZG9lcyBub3QgbGltaXQgdGhl IEZvcndhcmRpbmcgQ2xhc3NlcyB0byA4LiBUaGUgdmFsdWUgOCBpcyBtb3JlIG9mIGFuIGV4YW1w bGUgYW5kIGNvbWVzIGZyb20gVHJhZmZpYyBDbGFzcyBbUkZDNTQ2Ml0gYW5kIHRoZSBJUCBQcmVj ZWRlbmNlIHBvcnRpb24gb2YgRFNDUCBbUkZDMjQ3NF0uIFRoZSBzZWN0aW9uIHN0YXJ0cyB3aXRo IOKAnExldCB1cyBhc3N1bWXigJ0gYW5kIHRoZXJlIGlzIGFsc28gdGhlIGZvbGxvd2luZyB0ZXh0 IGluIHRoZSBzYW1lIHNlY3Rpb246DQoNCg0KDQogICBUaGUgYXJyYXkgaW5kZXggdmFsdWVzIChl LmcuIDAsIDEgYW5kIDIpIGFuZCB0aGUgbm90aW9uIG9mDQoNCiAgIGZvcndhcmRpbmctY2xhc3Mg YXJlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCBvbmx5IG1lYW50IHRvDQoNCiAgIGRlc2Ny aWJlIHRoZSBkZXNpcmVkIGJlaGF2aW9yLiAgVGhlIHNhbWUgY2FuIGJlIHJlYWxpemVkIGJ5IG90 aGVyDQoNCiAgIG1lY2hhbmlzbXMuDQoNCg0KDQozLiBGb3IgcHJvdGVjdGlvbiBpbiBzZWN0aW9u IDkuMSwgaXQgaXMgYmV0dGVyIHRvIGFkZCBzb21lIHRleHQgbGlrZSAidGhlIGxvY2FsIHByb3Rl Y3Rpb24gbWF5IG5vdCBzYXRpc2Z5IHRoZSBTTEEgcmVxdWlyZW1lbnRzIG9yIHRoZSBwYXRoIGNv bnN0cmFpbnMgZm9yIHRoZSBwb2xpY3kiIHdoZW4gYW4gU1IgUG9saWN5IGlzIGJ1aWx0IG9uIHRo ZSBiYXNpcyBvZiBUSS1MRkEgcHJvdGVjdGVkIElHUCBzZWdtZW50cy4NCltLVF0gU3VyZS4gV2Ug Y2FuIGFkZCB0aGlzIGNsYXJpZmljYXRpb24gaW4gdGhlIG5leHQgdXBkYXRlLg0KDQpUaGFua3Ms DQpLZXRhbg0KDQpCZXN0IFJlZ2FyZHMsDQpaaGVucWlhbmcgTGkNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb208bWFpbHRvOmxpX3poZW5x aWFuZ0Bob3RtYWlsLmNvbT4NCg== --_000_MW3PR11MB4570088488A0E4700A875069C15C0MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Ik1pY3Jvc29mdCBZYUhlaSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaWNyb3NvZnQgWWFI ZWkiO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1JTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBaaGVucWlhbmcgTGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBsZWFz ZSBjaGVjayBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+IGxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbSAmbHQ7bGlfemhl bnFpYW5nQGhvdG1haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEF1Z3VzdCAyMDIw IDA2OjQyPGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDtrZXRh bnRAY2lzY28uY29tJmd0Ozsgc3ByaW5nQGlldGYub3JnOyBkcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5ICZsdDtkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUkU6IENvbW1lbnRz IG9uIFNSIHBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGVsbG8gS2V0 YW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWlj cm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9u c2UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gb3IgcXVlc3Rpb24gTm8uIDEs IEkgY2FuIHVuZGVyc3RhbmQgVHlwZSBFIGFuZCBUeXBlIEcgY2FuIGJlIHVzZWQgdG8gcHJlc2Vu dCBsYXllciAyIGludGVyZmFjZS4gSG93ZXJ2ZXIsIHRoZSBtZXRob2QgaW50cm9kdWNlZCBpbiBS RkMgODY2OCBpcyBkaWZmZXJlbnQsDQogaW4gd2hpY2ggU0lEIGlzIHVzZWQgdG8gZGlyZWN0bHkg aW5kaWNhdGUgdGhlIG1lbWJlciBsaW5rIG9mIGEgbGF5ZXIgMiBsaW5rIGJ1bmRsZS4gV2hlbiB1 c2luZyB0aGUgc2VnbWVudCBkZWZpbmVkIGluIFJGQzg2NjgsIHRoZSBoZWFkZW5kIGRvZXNuJ3Qg bmVlZCB0byByZXNvbHZlIHRoZSBJUCBhZGRyZXNzIGFuZCB0aGUgaW50ZXJmYWNlIElEIHNwZWNp ZmllZCBpbiBUeXBlIEUgb3IgRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT5bS1RdIFRoZSBUeXBlIEEgaXMgYXZhaWxhYmxlIGZvciBhbGwgdHlwZXMg b2YgU1ItTVBMUyBTZWdtZW50cyB0byBiZSBzcGVjaWZpZWQgaW4gdGhlIGZvcm0gb2YgYSBsYWJl bCAoYW5kIGl0IGRvZXMgbm90IHJlcXVpcmUgaGVhZGVuZCB0byBwZXJmb3JtIGFueSByZXNvbHV0 aW9uKSDigJMgc2FtZSBpcyBhbHNvIHVzYWJsZSBmb3IgTDIgQnVuZGxlIE1lbWJlciBBZGotU0lE LiBUaGUgVHlwZSBFIG9yIEcNCiBpcyBmb3Igd2hlbiB0aGlzIFNJRCBpcyB0byBiZSByZXByZXNl bnRlZCBhcyBOb2RlIFNlZ21lbnQgKyBMaW5rIElEIGZvciB0aGUgaGVhZGVuZCB0byByZXNvbHZl IHRvIHRoZSBMMiBCdW5kbGUgTWVtYmVyIEFkai1TSUQuPG86cD48L286cD48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5UaGFua3MsPG86cD48L286cD48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPktldGFuPC9pPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOmxpbWUiPjxicj4NCjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv ZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlNvIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGFkZCBvbmUgbW9yZSBzZWdtZW50IHR5 cGUgdG8gY29udGFpbiB0aGUgc2VnbWVudCBkZWZpbmVkIGluIFJGQzg2NjggZm9yIGxheWVyIDIg YnVuZGxlIG1lbWJlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5CZXN0IFJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlpoZW5xaWFuZyBMaTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjIxMCIgc3R5bGU9Indp ZHRoOjE1Ny41cHQiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiNCNUM0REYiIGFsaWduPSJsZWZ0 Ij4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo3LjVwdDtt YXJnaW4tdG9wOjcuNXB0O21hcmdpbi1yaWdodDo3LjVwdDttYXJnaW4tYm90dG9tOjcuNXB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20iPmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6Ni4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 I0VGRUZFRiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lz Y28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+S2V0YW4NCiBUYWxhdWxpa2FyIChr ZXRhbnQpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5EYXRlOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7MjAyMC0wOC0xNCZuYnNwOzE5OjM2PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VG RUZFRiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VG86PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86bGlfemhlbnFpYW5nQGhv dG1haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+bGlfemhlbnFpYW5nQGhvdG1h aWwuY29tPC9zcGFuPjwvYT47DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6IzA1NjNDMSI+c3ByaW5nQGlldGYub3JnPC9zcGFuPjwvYT47DQo8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeUBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3k8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDtSRTogQ29tbWVudHMgb24gU1IgcG9saWN5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpIFpoZW5xaWFuZyBMaSw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VGhhbmtzIGZvciB5b3UgcmV2aWV3IGFuZCBzaGFyaW5nIHlvdXIgY29t bWVudHMuIFBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOmxp X3poZW5xaWFuZ0Bob3RtYWlsLmNvbSI+bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9hPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbSI+bGlfemhlbnFpYW5nQGhv dG1haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAwNSBBdWd1c3QgMjAyMCAxNDow Mzxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5n QGlldGYub3JnPC9hPjsgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xp Y3lAaWV0Zi5vcmciPmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3lAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBDb21tZW50cyBvbiBTUiBwb2xpY3k8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5EZWFyIGF1dGhvcnMgYW5kIGFs bCw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+UGxlYXNlIGNvbnNpZGVyIHRoZSBmb2xsb3dp bmcgY29tbWVudHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4xLiBEbyB5b3UgdGhpbmsgaXQgaXMgb2sgdG8gYWRkIG9u ZSBtb3JlIHNlZ21lbnQgdHlwZSBmb3IgdGhlIHNlZ21lbnQgbGlzdCB0byBpbmNvcnBvcmF0ZSB0 aGUgc2VnbWVudCBmb3IgTGF5ZXIgMiBidW5kbGUgbWVtYmVycz8gUGxlYXNlIHJlZmVyIHRvJm5i c3A7cmZjODY2OC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPltLVF0gVGhlIFNlZ21lbnQgVHlwZSBFIGNvdmVycyBMYXllciAyIEJ1bmRsZSBNZW1i ZXJzIDoNCjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91 dGluZy1wb2xpY3ktMDgjc2VjdGlvbi00Ij48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy1wb2xpY3ktMDgjc2VjdGlvbi00PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhp cyB0eXBlIGNhbiBhbHNvIGJlPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2Vk IHRvIGluZGljYXRlIGluZGlyZWN0aW9uIGludG8gYSBsYXllciAyIGludGVyZmFjZSAoaS5lLjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aG91dCBJUCBhZGRyZXNzKSBsaWtl IGEgcmVwcmVzZW50YXRpb24gb2YgYW4gb3B0aWNhbDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdHJhbnNwb3J0IHBhdGggb3IgYSBsYXllciAyIEV0aGVybmV0IHBvcnQgb3IgY2ly Y3VpdCBhdCB0aGU8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmllZCBu b2RlLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjIu IEZvciBwZXIgZmxvdyBzdGVlcmluZyB0byBhIHBvbGljeSwgd2h5IGRvIHdlIGxpbWl0IHRoZSBh cnJheSBpbmRleCB0byAwIHRvIDc/ICZuYnNwO0kgdGhpbmsgdGhpcyBpcyBpbXBsZW1lbnRhdGlv biBzcGVjaWZpYyBhbmQgdGhlIG51bWJlciBvZiBwYXRocyBpbiBhbiBhcnJheQ0KIGRlcGVuZHMg b24gdGhlIGFwcGxpY2F0aW9uIHNjZW5hcmlvLiBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgb3Igbm90 IDggcGF0aHMgaXMgZW5vdWdoIGZvciBhbGwgc2NlbmFyaW9zLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5bS1RdIDwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlRoZSBkcmFmdCBkb2VzIG5vdCBsaW1pdCB0aGUgRm9yd2FyZGluZyBDbGFzc2VzIHRvIDguIFRo ZSB2YWx1ZSA4IGlzIG1vcmUgb2YgYW4gZXhhbXBsZSBhbmQgY29tZXMgZnJvbSBUcmFmZmljIENs YXNzIFtSRkM1NDYyXSBhbmQgdGhlIElQIFByZWNlZGVuY2UgcG9ydGlvbiBvZiBEU0NQIFtSRkMy NDc0XS4gVGhlIHNlY3Rpb24gc3RhcnRzIHdpdGgg4oCcPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5MZXQgdXMgYXNzdW1lPC9zcGFuPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKA nSBhbmQgdGhlcmUgaXMgYWxzbyB0aGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIHNhbWUgc2VjdGlv bjo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgYXJyYXkgaW5kZXggdmFs dWVzIChlLmcuIDAsIDEgYW5kIDIpIGFuZCB0aGUgbm90aW9uIG9mPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZvcndh cmRpbmctY2xhc3MgYXJlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCBvbmx5IG1lYW50IHRv PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGRlc2NyaWJlIHRoZSBkZXNpcmVkIGJlaGF2aW9yLiZuYnNwOyBUaGUgc2Ft ZSBjYW4gYmUgcmVhbGl6ZWQgYnkgb3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtcy48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4z LiBGb3IgcHJvdGVjdGlvbiBpbiBzZWN0aW9uIDkuMSwgaXQgaXMgYmV0dGVyIHRvIGFkZCBzb21l IHRleHQgbGlrZSAmcXVvdDt0aGUgbG9jYWwgcHJvdGVjdGlvbiBtYXkgbm90IHNhdGlzZnkgdGhl IFNMQSByZXF1aXJlbWVudHMgb3IgdGhlIHBhdGggY29uc3RyYWlucyBmb3IgdGhlDQogcG9saWN5 JnF1b3Q7IHdoZW4mbmJzcDthbiBTUiBQb2xpY3kgaXMgYnVpbHQgb24gdGhlJm5ic3A7YmFzaXMg b2YgVEktTEZBIHByb3RlY3RlZCBJR1Agc2VnbWVudHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5bS1RdIFN1cmUuIFdlIGNhbiBhZGQgdGhpcyBj bGFyaWZpY2F0aW9uIGluIHRoZSBuZXh0IHVwZGF0ZS48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyw8L3Nw YW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ S2V0YW48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5CZXN0IFJlZ2FyZHMsPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9y OmJsYWNrIj5aaGVucWlhbmcgTGk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjIx MCIgc3R5bGU9IndpZHRoOjE1Ny41cHQiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiNBMEEwQTAi IGFsaWduPSJsZWZ0Ij4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcuNXB0O21hcmdpbi10b3A6Ny41cHQ7bWFyZ2luLXJpZ2h0OjcuNXB0O21h cmdpbi1ib3R0b206Ny41cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWls LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNv bTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW3PR11MB4570088488A0E4700A875069C15C0MW3PR11MB4570namp_-- From nobody Tue Aug 18 05:47:26 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1143A09A4; Tue, 18 Aug 2020 05:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.212, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 SC-qenVDitn7; Tue, 18 Aug 2020 05:47:14 -0700 (PDT) Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (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 7D64F3A09A0; Tue, 18 Aug 2020 05:47:11 -0700 (PDT) Received: by mail.swisscom.com; Tue, 18 Aug 2020 14:47:02 +0200 Message-ID: <1896445127.103900.1597754821823@ss002889> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_103898_1492735026.1597754821823" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ElBxQV/cwvgS7MK4cBI08y31Ot7fY4dzkO/2Nzh860TGCW/9VqMn5zZuXlvZVLe6TBeRvuAfeLc7K6anEoSrzDGOh6tOAvnuxMf24ZaY0hLn5nWOEceXzOj+euLrCPmVzEr1CNiinVB3fLTCicXbpCahQOWgv/vX04soXv+j3Tw0JXtABLuYenXwftkY/EUTU3MO1ccRQq1UYyxx/UhliQ9TS/VvTnmEhCkrmoafFJZfMy5/j492tYjULRECUXwrNAsSWzpfPYhuuvpqA1uQpKuDjljeWZFi+L+arAbPh636Qglge9LNUhr/shfw35bBTDtfsJKFTrkg2d103OrfHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gxgGFbXJq2WWSbOb3B3XLZ8EWZwEbHj1ssu2pTccZuc=; b=Ewlw3dmBqK3u3M2wgvxNYDU1x4KP3pzPs+RSvNB104nhVj8+xGyn/kinwh6BF+TO6YMJR28P3rTKM8rYAYyjBlqVXbCU4rTwfqcRqIxXCCux5YA0DLMfevhJc/kaK014XZVduvX/3WqOHpP328Zv/dXFSvswARSIBSLf8020IU91r6r7Z0dvyVggQhVg4idmRM8IaJlInO69bpUZQ1i+NnelxspnEoa4AS6K3nnVLo03/Q2/I6GH7HkPZSvfwkyCARiQDFhQDir64ZM4feNiXxZTpJx/X9Kxd0WETYFP/tZ87ESGruiNfPakWAFeJx/wxGONi9suvS9wOn0WXpJr1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: CC: , , , , Thread-Topic: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AQHWZXpAYzBRFTPdWk2PQZUrWhbqXAAxTF+AAHUFTIACvTCesAAduZCAAAG4RsCpHZFNsoABpuJFgAKVY7A= Date: Tue, 18 Aug 2020 12:46:57 +0000 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> <1180087721.1311955.1597562009048@ss007564> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-08-18T12:46:55.5169015Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=c55f7e0a-f449-4a31-a443-79a43751c05e; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [138.188.143.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4224ae5c-39e0-432b-7aae-08d84374cafe x-ms-traffictypediagnostic: ZRAP278MB0029: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d13bSZrg/TUGPB4TIXkPKrFcIhQRZz4WlUuP5+EkThYR9b8SIKz0bPEGsFvY0kN0+0SO5rRt6VjXTtYcvcqzKlY40Z6Zc3ya/8lZJKRx9ZwkUaCSGDZV4feQvEEM5zT2E6CXKbom8KLlGqZh6ALsRcm9KePkY5Ku3D3xNp7kuiUvdhTqQT8lNmpQq1h4ZuFcZKQEFdb4uYxDZVdoSqamhV7yjEBPQvGjQ5t4EoUUq6yCLSxMGcf+90jH6wDEovdOtZuBhrLi+ShSozSzmh6tZNzJHxlTZINXPfnBw8ZXpNzmUZ55BngusakQ+6jR4ZlYFj35cG5uRLOQnuYWUg2ktzkNnhqXXW2rYdZHen4zOJienRqxQ41xwIOj4Z8xXk8soT4N3SfoQS/r4adP5Sm24g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(376002)(366004)(346002)(966005)(6916009)(54906003)(71200400001)(2906002)(6506007)(55016002)(66946007)(5660300002)(66574015)(53546011)(9686003)(66476007)(64756008)(478600001)(33656002)(7696005)(83380400001)(52536014)(66446008)(66556008)(76116006)(166002)(19627235002)(8676002)(4326008)(186003)(10300500001)(86362001)(10290500003)(8936002)(30864003)(316002)(26005)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2Iv0djlxyYAaJqlNYRNljxYJtKbvfBgXUmCmMBcGLdLxj9IzyTkkbJFSZk2Yumx9t5XR4PZkZFT3zXVKfInBxWHaCD8VXwgBV7qB6lVk+WxEwkithipxbD77nlEEXVbmc9GBz3a8J+Tw1MbPVpjq1j6i7M7CUX/OEEywBxZfQ64J19ah7lErIM6PSIHcUIRgVc700byzFJKocWOSjjKcMBIr8yDLgErKyhhH9ASHIKTjZfmWBZ3/5bDYWQ4tTkidQ5l1w/72oytDcTFkd8vS5NXbHGmT3lglZ0f7eHvDgYQygyOVg0UTDjOnttLkgv74SKqcVNqUS4OhlG6NcBxjzWpwZW+L4Fkr4PhTS0fbF9pY0eftOh1Kr+4SRbwAJ0oJELGf8+67NgSQWRd9HnvpKgo8wMOYIzLNtOAcxjzVDz09VuBUJla7i5/7LxrD4NvPTZynxWzUy7VGc/otKSLCQBzcm33ztIBPdV7faSFgOp6OCNdewcfutmRn7wgyDGpLls4cexqAHQRidL0mL4GtDKpBPO9y6kYWyQqhYjT6D9o6OI0Ku711LFhDrWhlTUx7wARs/jtRN4Pm1wWZM5mE8ksO3kliODLVXt5MsB8fBMNWe8KvJVaN4gYCa+LQgICOB4mJga19IJhxRHK9xLHLGQ== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4224ae5c-39e0-432b-7aae-08d84374cafe X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 12:46:57.3096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NlTIw9ZheIW3zHtvtJJSTKy8LdkU2V9bvc/jNQJCxcJVRuZM+RjtHVuS8w1GgJkiRRaE1fV2DNKnh4G0LoS8YxqP13Wl92D3gHFku91ncKE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZRAP278MB0029 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 12:47:25 -0000 ------=_Part_103898_1492735026.1597754821823 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB0125BF3D5977184EBB6A929D895C0ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB0125BF3D5977184EBB6A929D895C0ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gyan, Thank you very much. Perfect we are in line. All ack on your comments. * With MPLS we are label swapping however with SR you are label stackin= g. So let's say you have an SR-TE path instantiated and using the strict E= RO path with adjacency SIDs defined, would just the active label being use= d in the forwarding plane be the one that IPFIX would be monitoring versus = the entire stack of labels. Correct. IE46 is only referencing the top label. We do not know these addit= ional dimensions for the other labels in the label stack. Same as all other= IE below, just as reference. 46 mplsTopLabelType 47 mplsTopLabelIPv4Address 70 mplsTopLabelStackSection 91 mplsTopLabelPrefixLength 140 mplsTopLabelIPv6Address 200 mplsTopLabelTTL 203 mplsTopLabelExp * What about IPFIX SRv6 support? Good point. draft-patki-srv6-ipfix-00 (https://tools.ietf.org/html/draft-pa= tki-srv6-ipfix-00) is covering the IPv6 data plane in IPFIX. SrSidType in d= raft-tgraf-ipfix-mpls-sr-label-type relates to MPLS-SR and SRv6, IE46 only = to MPLS-SR. Best Wishes Thomas From: Gyan Mishra Sent: Sunday, August 16, 2020 10:40 PM To: Graf Thomas, INI-NET-DCF Cc: hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.org; spr= ing@ietf.org Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas Sorry for any misunderstanding. I am well aware of the origins and history= behind IPFIX and Neflow and use with BGP monitoring. I was not aware of IE 46 and how that was being leveraged to support SR IGP= extensions sid types. After reviewing your IPFIX slides related to IE 46 registry for mplsTopLab= elType and this drafts solution to extend the IE 46 registry with SR and no= w requiring new IGP codepoints to be allocated. You had given an example in the LDP interworking example or others that wit= h this new IGP codepoint in case of multiple control planes present such as= both LDP and SR that with IPFIX and with the new IGP codepoint allocations= for each IGP type that you can see the forwarding resulting FIB entry. I = can see that as a benefit for monitoring telemetry In-line below addresses complexity of extending IE46 for SR support. On Sun, Aug 16, 2020 at 3:13 AM > wrote: Hi Gyan, Gyan> IPFIX has been traditionally been used for flow analysis and to that = end all that was required is support of the data plane encapsulation. With= your proposed SR support idea you are really transforming the IPFIX to be used for not just flow monitoring at that level solely, but now also = to analyze and troubleshoot data plane forwarding. That is a considerable = departure I think from what IPFIX was intended. I am not sure we want to a= dd that layer of complexity into IPFIX. Thomas> I have seen your feedback to Tarek and was puzzled about your remar= k about data plane encapsulation and IPFIX. I think you have a limited pict= ure for what IPFIX has been intended and being used. I do not want to lecture, but it might be useful to go back to the origins of Netflow and= IPFIX. At the beginning, the main reason for was to account traffic for BG= P control-plane dimensions. Such as BGP peer AS, src and dst prefix attribu= te. These helped to account traffic in shared enviroments. Later also for datacenters. These was and is always = in conjunction with the encapsulated header metrics of forwarded traffic an= d device dimensions such as ingress interface, egress interface, vrf id and= vrf name. In order to have a proper picture about the forwarding plane, and to enable data correlation, key fie= lds from other perspectives (control-plane, forwarding-plane, device) are n= ecessary to enable data correlation with other protocols such as BMP and YA= NG. Thomas> Going back to the initial conversation. Section 7.2 of RFC 5102 https://tools.ietf.org/html/rfc5102#section-7.2 For ensuring extensibility of this information, IANA has created a new registry for MPLS label types and filled it with the initial list from the description Information Element #46, mplsTopLabelType. Thomas> When IPFIX was specified, it has been defined in mind that other MP= LS label protocols will be developed in the future. Which is the case with = RFC 8665, 8666, 8667 and 8669. All adding TLV's to carry segment routing SID's. In the presentation I gave, I showed one of many vendors implemented= IE46 and showing the wrong value. Event though the label protocol was IS-I= S SR TLV, the value shown was LDP. This is not acceptable. When new protoco= ls are developed, we at IETF must ensure that they can be properly monitored. With IPFIX we have the proper p= rotocol to do that. Even without modifications as section 4 in draft-ali-sp= ring-sr-traffic-accounting mentioned: https://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#secti= on-4 Thomas> You have been referring to complexity. One of the key objectives of= SR-MPLS was that it does not much change in the MPLS data plane. You need = to explain on this WG how SR differs from other MPLS label protocols in terms of RIB/FIB. And then from there why an implementation would be dif= ficult. That's the discussion I am looking forward to. Gyan> SR-MPLS reuses the MPLS data plane so from that perspective is the s= ame but how it differs is with SR steering and MSD SID depth with SR-TE esp= ecially when strict ERO is defined with adjacency SID the label stack is ex= panded. With MPLS we are label swapping however with SR you are label stacking.= So let's say you have an SR-TE path instantiated and using the strict ERO= path with adjacency SIDs defined, would just the active label being used = in the forwarding plane be the one that IPFIX would be monitoring versus th= e entire stack of labels. In theory it appears that the IPFIX machinery is in place with IE 46 to sup= port SR as what you have proposed in the draft. As far as vendor compatibility as long as they support IE 46 th= ey should support SR-MPLS. I don't see any issues now as far as complexities to support as the we are = using existing machinery IPFIX IE 46 to extend for SR support. I think getting feedback from LSR is critical on their thoughts on complexi= ty and caveats with getting the codepoints assigned. What about IPFIX SRv6 support? Comment on Section 2 A typical use case scenario is to monitor MPLS control plane migrations from LDP to IS-IS or OSPF. By looking at the MPLS label value itself, it is not always clear as to which label protocol it belongs, since they could potentially share the same label allocation range. This is the case for IGP-Adjacency SID's and LDP as an example. SR SRGB label range is different then LDP label range. Best wishes Thomas From: Gyan Mishra > Sent: Saturday, August 15, 2020 9:26 PM To: Graf Thomas, INI-NET-DCF > Cc: hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.org; spring@ietf.org Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas Responses in-line On Sat, Aug 15, 2020 at 2:02 AM > wrote: Hi Ketan, * This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. * What value is provided for IPFIX analysis if the SR Prefix SID was being si= gnalled via OSPF or ISIS? It is important to distinguish between intend and result. If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or n= ot. IE46 enables that by looking at the result of the forwarded traffic and= not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context. Gyan> IPFIX has been traditionally been used for flow analysis and to that = end all that was required is support of the data plane encapsulation. With= your proposed SR support idea you are really transforming the IPFIX to be = used for not just flow monitoring at that level solely, but now also to analyze and trou= bleshoot data plane forwarding. That is a considerable departure I think f= rom what IPFIX was intended. I am not sure we want to add that layer of complexity into IPFIX. * What value is provided for IPFIX analysis if it was a Adjacency SID or a LA= N Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels.= . With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabli= ng to analyze the result of this decision. The example with " Adjacency SID= or a LAN Adjacency SID" is not very useful because the difference of the two is the topology among the adj= acency. If you compare " Adjacency SID with Prefix SID", that makes much mo= re sense. Since it describes that a particular adjacency is chosen to forwa= rd the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we understand that result of that decis= ion lead to the drop and this enables to narrow down forwarding issues in s= egment routing networks more efficiently and quickly. > am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a better understanding wh= ere your fear is coming from. I would appreciate if you could differentiate= between MPLS Label Type identifier, IE46, from which label protocol the label was c= oming from and SrSidType which SID type was used. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was being si= gnalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID or a LA= N Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is more important is that it is a Prefix SID. Hardly any= deployments would be running multiple protocols and learning the same pref= ix from different IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom whe= n we first discovered this shortcoming in vendor implementations. The key p= oint here, with these additional IPFIX MPLS Label Type identifiers we enabl= e the possibility to verify the label protocol migration without taking the label value into the considerat= ion. * IPFIX may be picking this information from a FIB in some implementation whe= re the protocol does not matter and this information is not available therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementation can refer to the right= code point. With RFC 5102 the decision has been made that MPLS Label Type = identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends t= he IE 46 registry with the Segment Routing label protocol code points so wh= en OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX imp= lementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not possibl= e to different between Prefix and Node and Anycast SID. Many of these types= are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what make= sense. By purpose, all available SID types are listed in the draft. This w= ith the aim to start the discussion in the working groups what is possible = what makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which labe= l protocol was used to forward a particular packet, but also which SID type= to further understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and = learning the same prefix from different IGPs. IPFIX may be picking this inf= ormation from a FIB in some implementation where the protocol does not matt= er and this information is not available therein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control pl= ane elements and we can be sure more get added. Is there really much value = in differentiation between say an Adjacency SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update... Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools..ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_ZRAP278MB0125BF3D5977184EBB6A929D895C0ZRAP278MB0125CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_ZRAP278MB0125BF3D5977184EBB6A929D895C0ZRAP278MB0125CHEP_-- ------=_Part_103898_1492735026.1597754821823 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE4MTI0NzAxWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCBc8dzv LxNtaGKjyM/RJkxQVZWpOX0QFL+BQaQNTgCIVjB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAQXVIugH8ZP3U6sJ4MwKgblhaE6M7bHFOODhkSdnn2/8HDrv4wNul+X8V 5L+WhZtv8/B2Zq0SBjVnIpLvFMt03qBEahYAvU4HILXb8LBdxYyU0q0oKA7NIEfOyUl50bxANlSp U6YggYLJog3nZeRHEtDdrO9cJr+qMJ7Jc3VE1GoVEyV38HLf7/e/jcewgny5E5NJ3/+QAGoFKnJ0 pVvD4OWiaQViT6EFWNo9Ek02xZyXzsK+oWLsvgPwfA5N6J57gCbp+lk1zyoUuJ57VYBVw1bc/F8c 7m/Sul9cJDXrqZMhD6LYcbCHqr7/B1lJcECPeo2zojPwJs6BOgxLjp49VAAAAAAAAA== ------=_Part_103898_1492735026.1597754821823-- From nobody Tue Aug 18 05:58:29 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839303A09AB; Tue, 18 Aug 2020 05:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 WQDU2kHQz-ZW; Tue, 18 Aug 2020 05:58:19 -0700 (PDT) Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 A5C493A09A6; Tue, 18 Aug 2020 05:58:18 -0700 (PDT) Received: by mail.swisscom.com; Tue, 18 Aug 2020 14:58:13 +0200 Message-ID: <731376225.102325.1597755492826@ss007564> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_102323_411295030.1597755492826" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jYKvl/eVnqozzq9Yrmw0numqtrWPBdD9g9OB/UZEdV6o9kUbWWldT8lvjGhPq0+JFNK4oQjEp/qoSl/z6Z+iqtUoRvu08egV/mJo3jiH6g0+w869vwfma2RcMltZg9JrhJDb09MZTWCLpYoj+DAHhD8Kbgjbcx65IDkQrsjxgC4EtZw+wzck2ZX32gQxDPO93HGlAn4uDM+HsL+ORAA4xpy+/ZFinFRH9DIsPDksw754KyyfQYRvx4+mO5XuOuAMdaJeVc+4ZsMElkDI9wJ1X0HuYAzlUIV3FrJxU+7yYY1hZ6rrbtkbbmmu83lTnyb9roaanJs1jaO6uWD65Y9esw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y03FdxGxxzWoCcprybSOxnwaidzD4XJBhSiYHgCSMzg=; b=Nt2Fvtke7L6oAsGURwst10NBsrk3ONb22eD8oyJXapA9j2pkwVJy3tmBRNSrLXYnNB4I/PeMcPqRytzHdChHrR0Z/7rJWqSax9OKb4E55JkRJR5HMV/uf3T9+BDpAqOGtjoZJdodwN1WUyHg1urh7ums+XEt822zYQD7pb9vVfdjJyP8FIcHaMUiAzUxwbK96SV3zcCYh+r3GtPaDZGJcDvpdIfiAJAFppM3lxMWbVDWZL1BRRus5+z0mA0TY0yqCnbnQH3s89PyY+jptk43ezcV+4O3eKmrne9BuULp6/ZtkZaK42u9J87l0h4oYKAzFS2IVU7MIFiDqlAz+7fDqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , CC: , , Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AQHWZXpAYzBRFTPdWk2PQZUrWhbqXAAxTF+AAHUFTIACvTCesAAduZCAAAG4RsAAAinugABlpowAqR6bEOA= Date: Tue, 18 Aug 2020 12:58:09 +0000 References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [138.188.143.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 151e65e0-a905-4bfa-a8f7-08d843765b84 x-ms-traffictypediagnostic: ZRAP278MB0095: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rxKFfNgiWltidpfCtV2BAvOMZRCW/QkP87JtxGAmEocFllJgjfJbDfYK6xC/oL4uHSvMtAibkV/3APmKxzocP1F1HcMd4hTLoV03X7dxheRLJdSJh0QD3EurNhDcmqg3b7+gOb3RGiqzNsFsGJVz6XXt+RqD/ji5BLNBmLhSydPjQ8YDBrv8hycD2xnwBtxOyDzfthuwk7B0GyWWKinx93ZMxd/osnfZvt+z2ZyTEb1hVzbkHj15ymvVRMxydCIX80aEhlFkt35y2FK1hDOs2PMh9empIlyAFe6CqSldEA6UGQmA2KXK9BAJegAQ0u9vcObgIpO3d0fX1ZNfNwdz4+jB56Yz4aRUNMXBiblxkFbUWQdAshuGzwSg8QYnkkAMXCtUz0RDSB/Ad0mtoBS7ug== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(396003)(346002)(376002)(83380400001)(86362001)(33656002)(66556008)(166002)(10300500001)(2906002)(66446008)(66574015)(64756008)(8936002)(8676002)(5660300002)(66476007)(76116006)(66946007)(26005)(6506007)(53546011)(316002)(71200400001)(7696005)(4326008)(186003)(10290500003)(478600001)(9686003)(54906003)(30864003)(55016002)(19627235002)(52536014)(966005)(110136005)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: p06lqf1xM8tl0L9496uJy6qyV1DH7sbZhAhuULtMhRG50hORYv6404u/KBbNooFLHzSuoH7GIBK5r1UaspVCO22e7OX/+OV9ZUblcevLb+p4g4aAVVZ78FvZpiDbNZc98IJ/KW7a8qjh4QwJO/mxgorXY0zTChkGY1/IudUESeuDMEMSNW5HWb70Bp1tKKsPv/m6oCg4x2TXvZU8ROM9DAnGormY3ZZgz7IfV4jsedHmh3D1FifLJ2zrE+D20S75VA1mme/jQQBj+FM+vVBdowcIwGQ/he/MOjNpc1zJE1d4yWclKwuDrcmm+vSRUA2v2n836lGsFlWgAINbKvmH9euZ+SXADEc/sXzu2G21Bomr6pGhVe7d0En0lt8TCz2jkVEmYbHq05snGLU/nrMIhGgZX1hz/bd1CzXxrvudUL7Bw2HVH+ijqpL1TqCIbV9L6JDAFr+TsTes+qiz/tICm9wzg7RM7Iw4bdviLZaNN/TGeucEVLh8Af1+zI8sOv9QsCaX+6SmLo2rn+jIXqu5Mg+gyujuXIHIHWDbm1bO33XTPf2kIBNbw/GAgD6uG+HW/bp9IXD1E0pe2x+0mSdGmPtr1Cr3enaGD4ztIVgTWk8EUH96wCFrKztBWxwBeyVEJornwaP68nw9ZTyJlFQM4g== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 151e65e0-a905-4bfa-a8f7-08d843765b84 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 12:58:09.2950 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8QX7EAIySLJYPJbg9QGn0hwGPV1yryKbT/P8+CWupx0tHmtpx9ts1+I3SesSC4xMiHLS+1gaJDkuZkXWOjf0GYSwoLqRW6iisrYeziBUDAk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZRAP278MB0095 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 12:58:24 -0000 ------=_Part_102323_411295030.1597755492826 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB0125F39119B8ABBF7F2A2ACD895C0ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB0125F39119B8ABBF7F2A2ACD895C0ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan, Thank you very much for the feedback. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR= Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment ty= pes from RFC8402)? It's a simpler change to an existing element/field that = makes it easier for routers, collectors and analysers? Thomas> I am open to this approach to change IE46 to include segment types = for RFC8402. I understand your concern to add additional fields. I would ap= preciate feedback from the wg if that is the path we like to go. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? Thomas> "admin distance" is one reason why one path is considered over anot= her from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an = examples, it is "sr-prefer" configuration option. [KT] From the document, I believe we are still talking only about the top o= f the stack label ... Thomas> Correct [KT] My point is why do we need to introduce another ElementID and why not = use the existing Type 46 as suggested above? Thomas> See feedback above. [KT] To be clear, I am not talking from the POV of a specific implementatio= n. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nu= ances into IPFIX since they require all that additional context/information= to be made available at the "layer" (or component) from where IPFIX picks = this info (traditionally from the "FIB"). This added information should hav= e a strong enough justification of benefit - e.g. How does difference betwe= en Adj SID and LAN Adj SID matter? How relevant it is to determine if the = SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount= and sufficient information that is necessary for flow analysis. We need to= note that there may be many more/other sources for "off-box enrichment" of= flow information collected and perhaps not everything needs to be determin= ed and reported by routers. Thomas> Absolutely. I fully agree on your feedback. We need to have the min= imum possible in order to have a clear view about the MPL-SR forwarding. Si= nce IPFIX using UDP for transport, without the possibility of fragmentation= , we need to be careful as well not to add many more dimension's/fields. Best Wishes Thomas From: Ketan Talaulikar (ketant) Sent: Monday, August 17, 2020 8:51 AM To: Graf Thomas, INI-NET-DCF ; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, Please check inline below. From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 11:31 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, * This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR= Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment ty= pes from RFC8402)? It's a simpler change to an existing element/field that = makes it easier for routers, collectors and analysers? * What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? It is important to distinguish between intend and result. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets = with the label distribution protocol which needs to be removed or not. IE46= enables that by looking at the result of the forwarded traffic and not at = the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section= -3, describes the context. [KT] Sure, so adding the SR Segments to IE46, one can check whether the tra= ffic forwarding is happening using LDP or SR labels at any link in the netw= ork. * What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decision= s, the node can change the forwarding by pushing additional labels. [KT] From the document, I believe we are still talking only about the top o= f the stack label ... With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling= to analyze the result of this decision. The example with " Adjacency SID o= r a LAN Adjacency SID" is not very useful because the difference of the two= is the topology among the adjacency. If you compare " Adjacency SID with P= refix SID", that makes much more sense. Since it describes that a particula= r adjacency is chosen to forward the packet instead of a prefix. If IE 89, = ForwardingStatus is drop, we understand that result of that decision lead t= o the drop and this enables to narrow down forwarding issues in segment rou= ting networks more efficiently and quickly. [KT] My point is why do we need to introduce another ElementID and why not = use the existing Type 46 as suggested above? * am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a bette= r understanding where your fear is coming from. I would appreciate if you c= ould differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= . [KT] To be clear, I am not talking from the POV of a specific implementatio= n. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nu= ances into IPFIX since they require all that additional context/information= to be made available at the "layer" (or component) from where IPFIX picks = this info (traditionally from the "FIB"). This added information should hav= e a strong enough justification of benefit - e.g. How does difference betwe= en Adj SID and LAN Adj SID matter? How relevant it is to determine if the = SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount= and sufficient information that is necessary for flow analysis. We need to= note that there may be many more/other sources for "off-box enrichment" of= flow information collected and perhaps not everything needs to be determin= ed and reported by routers. Thanks, Ketan Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters = and is more important is that it is a Prefix SID. Hardly any deployments wo= uld be running multiple protocols and learning the same prefix from differe= nt IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available= therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not p= ossible to different between Prefix and Node and Anycast SID. Many of these= types are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update.. Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_ZRAP278MB0125F39119B8ABBF7F2A2ACD895C0ZRAP278MB0125CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Ketan,

     

    Thank you very mu= ch for the feedback.

     =

    [KT] Why not extend the existing IPFIX MPLS Label Type (value 4= 6) to add SR Prefix SID, SR Adjacency SID, SR Binding SID … (basicall= y the segment types from RFC8402)? It’s a simpler change to an existing element/field that makes it easier for routers, coll= ectors and analysers?

    Thomas> I am o= pen to this approach to change IE46 to include segment types for RFC8402. I= understand your concern to add additional fields. I would appreciate feedback from the wg if that is the path we like to go.=

     =

    [KT] By giving different = types for OSPF and ISIS, is the intention to troubleshoot routing preferenc= e selection (done based on “admin distance” between protocol se= lection in RIB)?

    Thomas> "= admin distance" is one reason why one path is considered over another = from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an examples, it is "sr-prefer" configuration option.

     =

    [KT] From the document, I= believe we are still talking only about the top of the stack label …=

    Thomas> Correc= t

     =

    [KT] My point is why do w= e need to introduce another ElementID and why not use the existing Type 46 = as suggested above?

    Thomas> See fe= edback above.

     =

     =

    [KT] To be clear, I am no= t talking from the POV of a specific implementation. Let me summarize my fe= edback and perspective:

    • Carefully consider the addition of more co= ntrol plane elements and nuances into IPFIX since they require all that add= itional context/information to be made available at the “layer” (or component) from where IPFIX picks= this info (traditionally from the “FIB”). This added informati= on should have a strong enough justification of benefit – e.g. How do= es difference between Adj SID and LAN Adj SID matter?  How relevant it is to determine if the SR signaling protocol is OSPF or ISIS?
    • Try to add/extend existing elements/fields with just the right amoun= t and sufficient information that is necessary for flow analysis. We need t= o note that there may be many more/other sources for “off-box enrichment” = of flow information collected and perhaps not everything needs to be determ= ined and reported by routers.

     =

    Thomas> Absolu= tely. I fully agree on your feedback. We need to have the minimum possible = in order to have a clear view about the MPL-SR forwarding. Since IPFIX using UDP for transport, without the possibility of fragmentat= ion, we need to be careful as well not to add many more dimension's/fields.=

     =

    Best Wishes<= /o:p>

    Thomas=

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Monday, August 17, 2020 8:51 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hanne= s@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas,

     

    Please check inline below.

     

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 11:31
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     

    • This helps = identification of specific SR-MPLS segment types as well as differentiating= them from LDP, RSVP-TE, etc.

     =

    To be precise, th= e existing MPLS Label Type identifier differentiates from LDP, RSVP-TE. Not= the new SrSidType IPFIX IE being proposed.

    [KT] Why not extend the existing IPFIX MPLS Label Type (value 4= 6) to add SR Prefix SID, SR Adjacency SID, SR Binding SID … (basicall= y the segment types from RFC8402)? It’s a simpler change to an existing element/field that makes it easier for routers, coll= ectors and analysers?

     

    • What value = is provided for IPFIX analysis if the SR Prefix SID was being signalled via= OSPF or ISIS?

     

    It is important t= o distinguish between intend and result.

    [KT] By giving different = types for OSPF and ISIS, is the intention to troubleshoot routing preferenc= e selection (done based on “admin distance” between protocol se= lection in RIB)?

     

    If you migrate fr= om one label distribution protocol to another, a network operator want's to= understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or = not. IE46 enables that by looking at the result of the forwarded traffic an= d not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context.

    [KT] Sure, so adding the SR Segments to IE46, one can check whe= ther the traffic forwarding is happening using LDP or SR labels at any link= in the network.

     

    • What value = is provided for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency= SID?

     =

    Quote from RFC840= 2. "Segment Routing (SR) leverages the source routing paradigm". = Means that not the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels= .

    [KT] From the document, I= believe we are still talking only about the top of the stack label …=

     

    With IPFIX SrSidT= ype we are able to cover this dimension in IPFIX. Enabling to analyze the r= esult of this decision. The example with " Adjacency SID or a LAN Adjacency SID" is not very useful because the difference= of the two is the topology among the adjacency. If you compare " Adja= cency SID with Prefix SID", that makes much more sense. Since it descr= ibes that a particular adjacency is chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we und= erstand that result of that decision lead to the drop and this enables to n= arrow down forwarding issues in segment routing networks more efficiently a= nd quickly.

    [KT] My point is why do w= e need to introduce another ElementID and why not use the existing Type 46 = as suggested above?

     =

    • = am asking for WG to weigh the implementation complexities

     =

    For the WG and me= , I would be important if you can describe more detailed what you mean with implementa= tion complexities. I would like to have a better understanding where your f= ear is coming from. I would appreciate if you could differentiate between MPLS Label Type identifier, IE46,= from which label protocol the label was coming from and SrSidType which SI= D type was used.

    [KT] To be clear, I am no= t talking from the POV of a specific implementation. Let me summarize my fe= edback and perspective:

    • Carefully consider the addition of more co= ntrol plane elements and nuances into IPFIX since they require all that add= itional context/information to be made available at the “layer” (or component) from where IPFIX picks= this info (traditionally from the “FIB”). This added informati= on should have a strong enough justification of benefit – e.g. How do= es difference between Adj SID and LAN Adj SID matter?  How relevant it is to determine if the SR signaling protocol is OSPF or ISIS?
    • Try to add/extend existing elements/fields with just the right amoun= t and sufficient information that is necessary for flow analysis. We need t= o note that there may be many more/other sources for “off-box enrichment” = of flow information collected and perhaps not everything needs to be determ= ined and reported by routers.

     

    Thanks,=

    Ketan

     =

    Best wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Saturday, August 15, 2020 7:09 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas,

     

    I should have been more clear in my email.

     

    The proposal/suggestion is to add the following to the IPFIX MPLS Lab= el type identifier registry:

    • SR Prefix S= ID
    • SR Adjacency SID
    • SR Binding SID<= /li>
    • SR BGP = Peering SID
    • … and so on

     

    This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc.

     

    And my questions were:

    1. What value = is provided for IPFIX analysis if the SR Prefix SID was being signalled via= OSPF or ISIS?
    2. What value is provided for IPFIX analysis if it was a Adjacency= SID or a LAN Adjacency SID?

     

    I am asking for WG to weigh the implementation complexities and overh= eads with the proposed details of SR-MPLS segments in IPFIX against the ben= efit (if any) that they provide for the flow analysis and monitoring.

     

    Thanks,

    Ketan

     

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 09:40
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     

    Thank you very mu= ch for the review and feedback.

     =

    • What or how= much value be there on determining whether a SR Prefix SID was signalled/p= rogrammed on a node via OSPFv2/OSPFv3/ISIS – what matters and is more important is that it is a Prefix SID. Har= dly any deployments would be running multiple protocols and learning the sa= me prefix from different IGPs.

     

    As Jeff already pointed out. Mul= tiple IGP labelling protocols are used  in networks when migrations ar= e ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom wh= en we first discovered this shortcoming in vendor implementations. The key = point here, with these additional IPFIX MPLS Label Type identifiers we enab= le the possibility to verify the label protocol migration without taking the label value into the considera= tion.

     

    • IPFIX may b= e picking this information from a FIB in some implementation where the prot= ocol does not matter and this information is not available therein.

     

    I am not sure if you have seen t= he presentation in IETF 108 at OPSAWG and SPRING.

    https://www.ie= tf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-typ= e-information-in-ipfix-00.pdf

     

    Slide 2 shows Cisco as example v= endor which implemented IE 46, MPLS Label Type identifier. There is an open= ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.=

     

    I do understand y= our point that not all the vendors are capable to implement IE 46. But that= ’s not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementa= tion can refer to the right code point. With RFC 5102 the decision has been= made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends = the IE 46 registry with the Segment Routing label protocol code points so w= hen OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX im= plementation can point to the right code point.

     

    • On some nod= es, the same Prefix SID may be learnt via both BGP and IGP – what wou= ld we use/show?

     =

    In this case the = IE 46 shows the label protocol which was used to program the FIB.

     =

    • = For that table proposal, it is very difficult and in some cases not possibl= e to different between Prefix and Node and Anycast SID. Many of these types= are control plane elements and we can be sure more get added.
      • =

     =

    I fully agree. As= a network operator its still hard to understand the architecture and const= raints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what mak= e sense. By purpose, all available SID types are listed in the draft. This = with the aim to start the discussion in the working groups what is possible= what makes sense. I would be interested to get your and also Jeff's feedback.

     =

    In above mentione= d slides I described how TI-LFA application would benefit of visibility in = the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which lab= el protocol was used to forward a particular packet, but also which SID typ= e to further understand the intend why this label is being pushed.

     =

    I hope this makes= all sense. Looking forward for reply.

     

    Best wishes

    Thomas

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020 7:35 PM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; SPRING WG <= spring@ietf.org>
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    < also copying Spring WG for their review/inputs >

     

    Hi Thomas/All,

     

    I have reviewed the draft and would like to share a different perspec= tive.

     

    What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS – what ma= tters and is more important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and= learning the same prefix from different IGPs. IPFIX may be picking this in= formation from a FIB in some implementation where the protocol does not mat= ter and this information is not available therein.

     

    On some nodes, the same Prefix SID may be learnt via both BGP and IGP= – what would we use/show?

     

    I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding S= ID, SR BGP Peering SID and so on … for the MPLS Label Type.

     

    This also takes away the need for the second table that is being prop= osed to a large extent. For that table proposal, it is very difficult and i= n some cases not possible to different between Prefix and Node and Anycast SID. Many of these types are control p= lane elements and we can be sure more get added. Is there really much value= in differentiation between say an Adjacency SID and LAN Adjacency SID?

     

    Could we evaluate the implementation overhead and complexity of this = level of categorization/information in IPFIX against their value in flow an= alysis to perhaps consider a middle ground?

     

    Thanks,

    Ketan

     

    From: Lsr <lsr-bounces@iet= f.org> On Behalf Of Thomas.Graf= @swisscom.com
    Sent: 31 July 2020 20:52
    To: hannes@gredler.at
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Hannes,

     

    Thanks a lot for = the feedback. Yes, makes completely sense. Will take it for the next update= ..

     =

    Best Wishes<= /o:p>

    Thomas=

     

     

    From: Hannes Gredler <hannes@= gredler.at>
    Sent: Wednesday, July 29, 2020 9:31 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Thomas,

     

    I have one comment/suggestion to Paragraph 4 (IANA C= onsiderations).

     

    Please add also a code point for BGP Prefix-SID - it= ’s quite popular in DC deployments.

     

    thanks,

     

    /hannes

     

    On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

     

    Dear lsr,

     

    I presented the following draft=

     

    Export of MPLS Segment Routing = Label Type Information in IP Flow Information Export (IPFIX)

     

    at the spring working group at = IETF 108 yesterday

     

    and today at OPSAWG where I cal= l for adoption.

     

    This draft adds additional segm= ent routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 an= d OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

     

    I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link state routing protocols and mpls data plane.

     

    I am looking forward to your fe= edback and input.

     

    Best Wishes

    Thomas Graf

    _______________________________________________ Lsr mailing list
    Lsr@ietf.org<= /a>
    https://w= ww.ietf.org/mailman/listinfo/lsr

     

    --_000_ZRAP278MB0125F39119B8ABBF7F2A2ACD895C0ZRAP278MB0125CHEP_-- ------=_Part_102323_411295030.1597755492826 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwODE4MTI1ODEyWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCBODV69 ka4rBCgRTDJ8jBfdheMVDj5XN0pkBw/thE+S2DB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAE6S17r/XZOC6Z2ywKKDEdYGPZMOKUSwqCvSlQj32zlNxOanfu3xTktxM Z8g+DigQ0B1oKQxQk+U1tDQdVVoe86QNMdoWIrsexlWI/vppcHgr41kMqk19ncIU2IC2MpsLjoYV W0b525m6nhRNYOeAMp7VaagogSyfIuLrhgZ8JXZJeutJH89txR6Cab+cz1+AS3FNVnDDGZzQQb21 VYeuNIcVznKiHdk1ugiYn2+nMdFPkJkgRFUi8Pu+zzUsobr6SIGa8+TiTOVKd6KU8xRtFBiAv6JG /7g9nmZU2PSTLmqZGd2hMNIqiJtMTiMYapnlOC05+GEfUTflJojM6il55AAAAAAAAA== ------=_Part_102323_411295030.1597755492826-- From nobody Tue Aug 18 07:23:22 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6053A0B3B; Tue, 18 Aug 2020 07:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.487 X-Spam-Level: X-Spam-Status: No, score=-9.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=EpxeAAh+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gXxLH1Q3 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 MxFKfO7JhRCW; Tue, 18 Aug 2020 07:23:13 -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 2C1433A0ABB; Tue, 18 Aug 2020 07:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85629; q=dns/txt; s=iport; t=1597760593; x=1598970193; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Pt0Ym8yScBrS10AHQzPGvkVLrkaYK0QesH59Pv15iwA=; b=EpxeAAh+/YcIWZUuyWLlQdt/v4JqsGqh+u13Hjd/svXquhYE9Dad9Qbh ePi+MJicZdEIH6sibUwYaMS2pZ0GLrk96CXc7hsPbFSPiZ7X6+e5deW9D JDo1Ca2L/V9YYC5Oi2Zosikx+ihtjIE6DOyVNV/GIusMN6QK/lx6RXW2w g=; IronPort-PHdr: =?us-ascii?q?9a23=3AvTm6jBB0OVcoqQj9HTHTUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw31A3SQoTA8PlDjqzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutfELTuWa56jtUER?= =?us-ascii?q?L6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYCQDd4ztf/5JdJa1fHgEBCxIMQIJ?= =?us-ascii?q?tLyMGKAdwWC8sCoYKgWkDjVqYaYFCgREDUAULAQEBDAEBGAEJCwIEAQGBbYJ?= =?us-ascii?q?fAoIfAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQICAQEQCAECEBMBASo?= =?us-ascii?q?BAQgDAQ8CAQgRAQMBASEBBgcnCxQDBggCBAENBQgRCYJ/BAKBfk0DLgEOpWg?= =?us-ascii?q?CgTmIYXSBNIMBAQEFgTMBAwICg3gDFYIOAwaBOIJxii4bgUE/gRABQ4FPfj6?= =?us-ascii?q?COiIBAQEBARaBDAUbHAwYBwkCgxKCLY9WISEDiUmLXZByCoJiiGSFfFCLEoM?= =?us-ascii?q?AiVwFkRuCJ5I7gW2IV5IbgmECBAIEBQIOAQEFgWojDVpwcBU7gmkTPRcCDY1?= =?us-ascii?q?8IwwXgQIBCYJChRSFQnQCAQEBMgIGCgEBAwl8jVUtgQYBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,327,1592870400"; d="scan'208,217";a="528292896" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2020 14:23:11 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 07IENBAs032090 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2020 14:23:11 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 09:23:10 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 10:23:10 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 18 Aug 2020 09:23:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bT1WpqJ/bp4MKxyJDR22zbPmYaBhPNuEiKsWzKgj8hm81dZgBopjFOhyvtwjpgGF/9vw54Z8wagJGN9dcDWuBMYxhvvOsnnCGQ0xo7NUwSMAhZAqz11VEeGi0TraugLLROrs+f9OjTObyWXkubqlnSCir2xyYxi/JnoTMyJeRm+0IYtxdJ5gm6kSRDfd6GCQV7Da8NYwVCvcBhcLoaMt/RhxLAo+q4hhPgcB97fLahso731ydcurt1HJpI0Yz9RjwMjryXSj8hbkg4/nU1jcCCxFVwut4ZcIhXqcsRatSEvjNGbW2UWhhT+h1CL54fCz7FuSp2wyDou82oVIpMM7TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=viKf0mtyXm5Uf/mefLGr0S3GGteg6IY8tAvoDNiBy90=; b=GJbbnp2IBBFJG8fUFPBu5aCfhkOPktbcoRjd7DR6oJI1hWz/geJXw/XWhMHh8SdXn1pn5ahkfDJpvpyf/Tt22amecEVxwhzNQJMIAw/b5jrQXkbyupbVraGvkIoNj+FK2jYCChufd0lYTVG7RX9deecqSgRjvLl9wFlafLEwXR67R7aor6eoIRih1d7bANi26vKKadCvo8QHXEdVpjTI3WMOHswWAuSxvBuxCMen6LnovsYIqLeX75dLzdo0sZthGa+4suZZGELDwYRNWiTXlgqVDHPA0vFRk/97CliZNpGmDzLjqpOuL6d1A32hcIyfFM58r7TbQl6wbpDFkkUihQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=viKf0mtyXm5Uf/mefLGr0S3GGteg6IY8tAvoDNiBy90=; b=gXxLH1Q3PBzHD7ivvjysXemOXaanzKl6mCstLPEUVWl9qaLPSxwMSbgkBWtfV/bRmdz+4G/n3gFZTBrd2sDuS3mPwCtXCd91L75UgdUkfNzuWcyMvGWlb+52MMi9FQdDVyDZMsji4ItsPHKre685QP/02slAWy5PdnnK04FgwsM= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2173.namprd11.prod.outlook.com (2603:10b6:301:5a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Tue, 18 Aug 2020 14:23:08 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135%8]) with mapi id 15.20.3305.024; Tue, 18 Aug 2020 14:23:08 +0000 From: "Ketan Talaulikar (ketant)" To: "Thomas.Graf@swisscom.com" , "hannes@gredler.at" CC: "lsr@ietf.org" , "spring@ietf.org" , "opsawg@ietf.org" Thread-Topic: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AdZktQw6qX35tZ6KQpiaZtLipXAiTwAxTF+AAHUFTIACvTCesAAduZCAAAG4RsAAAinugABlpowAAD/GjoAAAsKqkA== Date: Tue, 18 Aug 2020 14:23:08 +0000 Message-ID: References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> <731376225.102325.1597755492826@ss007564> In-Reply-To: <731376225.102325.1597755492826@ss007564> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-07-31T15:21:53.9494170Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=73c27161-9613-4286-9d47-bdfc43f1b8bc; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: swisscom.com; dkim=none (message not signed) header.d=none;swisscom.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e6ea54f-8fb8-4535-34b0-08d843823acc x-ms-traffictypediagnostic: MWHPR1101MB2173: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tvzFOqKTriXugsWU95zizyfl83d81OZo6I2bcm0pwIZY9uiztCglfLZih+uyxndpYqzTu36cMPYsdl2gku8KsQBldIehvEYLSq5thrDYcZJqRxBG6MDoOhq6SktHh4buu3kM1TtY42r3wyJ15olW52BZ/pQLQIg0E2Xvaen3Nb7wLjyhW6+g68CSktmSGL5rpk4k5/kF/neGm9324gxQSFi9j6FHSorx29pLE4VK1xjTUpi3w5qL3gcJG31/kDBvYGDzBPuNqRWmmiz5fkJHhisxs+PgMtfJyOe5pP3i/NWjxk/YFvgeGptaybHuUKIyzuAfAhdefAEcaWozBEV85K0sY4O3aE/aa+WRESfmPjcksXxq+9gKm6xNuz9UwCf70XNoiOe1EnB5FKGqB2tGrQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(366004)(136003)(39860400002)(76116006)(9326002)(316002)(966005)(83380400001)(53546011)(110136005)(5660300002)(66946007)(186003)(52536014)(30864003)(6506007)(19627235002)(33656002)(8676002)(2906002)(71200400001)(54906003)(8936002)(26005)(66556008)(64756008)(55016002)(66446008)(86362001)(7696005)(66476007)(66574015)(478600001)(9686003)(4326008)(166002)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Gg8a+6fhtYzIbszxbui5mvFMhS5V+043iciTSy9fKUc5qahC08TINuGcHb22pY7+w6rdJCXmI88QNmwb1N46VB/GFp7dP3CCQojMvSpS0476gDHqm+BY0OX3Yl9cjvAURm+wcONq9rX/55lFqw4uYnUJx+u6+s336d4FnG5E05RSY/Wvf2ctEiB41iLSBuGqK3/U9DX0hhMqLAOfFPbAtBASXnbK2E0+Y84JTMV4DpJbtdkHfNP6aZ9aJnLqk/sVBKiFSzLXzFDTcePCADkYI6LiQM895I046gd3jMd3RTh7PzJ/I9971eDI64rxsFX9pj8u3f3SBpbtYQXoklCz7F4tQn9tvrszZmE1ZR5qpNWVw4Yv+xFsoU187EICDcX78Vq9J1th5EiZSA5Y6KJzCvT5QynWqhPT/Ch4RMMMFDiIQrP97UKj3XULyvgdChbFNRhpcP4PKCE7VGlcPngABCCZ5WY+Fusib31FaFRvozr1ikBepQ0voKe7E+vWWR4lY4cSEZFkr68JSergQvCXW22bqb4iWGIu7rT/8cp01aSmpF3NZUGWVo9jMqY9/ma5H/Glt1BAFFkZOVkdFGspZkqhRBaJRu+fxuyCTejdHkT2i5cl//FYHmAYJnet5nAwKJ7vRgBcPDEClygZNKt7tQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB45701AD46D77ED33C31BFC4BC15C0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e6ea54f-8fb8-4535-34b0-08d843823acc X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 14:23:08.1806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lIPqtTOLkl1gNefoMfzTC7Vk+ldJmN/3M3KGxr0/GPClcNhCrzHEh3p798vdPP8y0DBXWFz0yE2GP7lvYJAbUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2173 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 14:23:18 -0000 --_000_MW3PR11MB45701AD46D77ED33C31BFC4BC15C0MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks for your response. Let us also wait for inputs from others in the WG= s. One small bit. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? Thomas> "admin distance" is one reason why one path is considered over anot= her from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an = examples, it is "sr-prefer" configuration option. KT2> The proposal to extend IE46 will cover the "sr-prefer" scenario and in= dicate whether the forwarding is happening with SR or LDP label. IMHO OSPF = SR vs ISIS SR is perhaps not as useful? Also, from an operational perspective (looking holistically), we have LSP p= ing/trace tools specified for MPLS (including SR segments/labels) to verify= /validate consistency between forwarding and control plane to determine whi= ch protocol/label is being used and lot's more details. Thanks, Ketan From: Thomas.Graf@swisscom.com Sent: 18 August 2020 18:28 To: Ketan Talaulikar (ketant) ; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the feedback. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR= Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment ty= pes from RFC8402)? It's a simpler change to an existing element/field that = makes it easier for routers, collectors and analysers? Thomas> I am open to this approach to change IE46 to include segment types = for RFC8402. I understand your concern to add additional fields. I would ap= preciate feedback from the wg if that is the path we like to go. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? Thomas> "admin distance" is one reason why one path is considered over anot= her from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an = examples, it is "sr-prefer" configuration option. [KT] From the document, I believe we are still talking only about the top o= f the stack label ... Thomas> Correct [KT] My point is why do we need to introduce another ElementID and why not = use the existing Type 46 as suggested above? Thomas> See feedback above. [KT] To be clear, I am not talking from the POV of a specific implementatio= n. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nu= ances into IPFIX since they require all that additional context/information= to be made available at the "layer" (or component) from where IPFIX picks = this info (traditionally from the "FIB"). This added information should hav= e a strong enough justification of benefit - e.g. How does difference betwe= en Adj SID and LAN Adj SID matter? How relevant it is to determine if the = SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount= and sufficient information that is necessary for flow analysis. We need to= note that there may be many more/other sources for "off-box enrichment" of= flow information collected and perhaps not everything needs to be determin= ed and reported by routers. Thomas> Absolutely. I fully agree on your feedback. We need to have the min= imum possible in order to have a clear view about the MPL-SR forwarding. Si= nce IPFIX using UDP for transport, without the possibility of fragmentation= , we need to be careful as well not to add many more dimension's/fields. Best Wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Monday, August 17, 2020 8:51 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, Please check inline below. From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 11:31 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, * This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR= Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment ty= pes from RFC8402)? It's a simpler change to an existing element/field that = makes it easier for routers, collectors and analysers? * What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? It is important to distinguish between intend and result. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets = with the label distribution protocol which needs to be removed or not. IE46= enables that by looking at the result of the forwarded traffic and not at = the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section= -3, describes the context. [KT] Sure, so adding the SR Segments to IE46, one can check whether the tra= ffic forwarding is happening using LDP or SR labels at any link in the netw= ork. * What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decision= s, the node can change the forwarding by pushing additional labels. [KT] From the document, I believe we are still talking only about the top o= f the stack label ... With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling= to analyze the result of this decision. The example with " Adjacency SID o= r a LAN Adjacency SID" is not very useful because the difference of the two= is the topology among the adjacency. If you compare " Adjacency SID with P= refix SID", that makes much more sense. Since it describes that a particula= r adjacency is chosen to forward the packet instead of a prefix. If IE 89, = ForwardingStatus is drop, we understand that result of that decision lead t= o the drop and this enables to narrow down forwarding issues in segment rou= ting networks more efficiently and quickly. [KT] My point is why do we need to introduce another ElementID and why not = use the existing Type 46 as suggested above? * am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a bette= r understanding where your fear is coming from. I would appreciate if you c= ould differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= . [KT] To be clear, I am not talking from the POV of a specific implementatio= n. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nu= ances into IPFIX since they require all that additional context/information= to be made available at the "layer" (or component) from where IPFIX picks = this info (traditionally from the "FIB"). This added information should hav= e a strong enough justification of benefit - e.g. How does difference betwe= en Adj SID and LAN Adj SID matter? How relevant it is to determine if the = SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount= and sufficient information that is necessary for flow analysis. We need to= note that there may be many more/other sources for "off-box enrichment" of= flow information collected and perhaps not everything needs to be determin= ed and reported by routers. Thanks, Ketan Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters = and is more important is that it is a Prefix SID. Hardly any deployments wo= uld be running multiple protocols and learning the same prefix from differe= nt IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available= therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not p= ossible to different between Prefix and Node and Anycast SID. Many of these= types are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update.. Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_MW3PR11MB45701AD46D77ED33C31BFC4BC15C0MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Thomas= ,

    &nbs= p;

    Thanks fo= r your response. Let us also wait for inputs from others in the WGs.

    &nbs= p;

    One small= bit.

    &nbs= p;

    [KT] By giving different = types for OSPF and ISIS, is the intention to troubleshoot routing preferenc= e selection (done based on “admin distance” between protocol se= lection in RIB)?

    Thomas> "= admin distance" is one reason why one path is considered over another = from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an examples, it is "sr-prefer" configuration option.

    KT2> T= he proposal to extend IE46 will cover the “sr-prefer” scenario = and indicate whether the forwarding is happening with SR or LDP label. IMHO= OSPF SR vs ISIS SR is perhaps not as useful?

    &nbs= p;

    Also, fro= m an operational perspective (looking holistically), we have LSP ping/trace= tools specified for MPLS (including SR segments/labels) to verify/validate= consistency between forwarding and control plane to determine which protocol/label is being used and lot̵= 7;s more details.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 18 August 2020 18:28
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredl= er.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    Thank you very mu= ch for the feedback.

     =

    [KT= ] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR Pr= efix SID, SR Adjacency SID, SR Binding SID … (basically the segment t= ypes from RFC8402)? It’s a simpler change to an existing element/field that makes it easier for routers, collectors = and analysers?

    Thomas> I am open to this app= roach to change IE46 to include segment types for RFC8402. I understand you= r concern to add additional fields. I would appreciate feedback from the wg if that is the path we like to go.<= /p>

     

    [KT] By giving different = types for OSPF and ISIS, is the intention to troubleshoot routing preferenc= e selection (done based on “admin distance” between protocol se= lection in RIB)?

    Thomas> "= admin distance" is one reason why one path is considered over another = from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an examples, it is "sr-prefer" configuration option.

     =

    [KT] From the document, I= believe we are still talking only about the top of the stack label …=

    Thomas> Correc= t

     =

    [KT] My point is why do w= e need to introduce another ElementID and why not use the existing Type 46 = as suggested above?

    Thomas> See fe= edback above.

     =

     =

    [KT] To be clear, I am no= t talking from the POV of a specific implementation. Let me summarize my fe= edback and perspective:

    • Carefully consider the addition of more co= ntrol plane elements and nuances into IPFIX since they require all that add= itional context/information to be made available at the “layer” (or component) from where IPFIX picks= this info (traditionally from the “FIB”). This added informati= on should have a strong enough justification of benefit – e.g. How do= es difference between Adj SID and LAN Adj SID matter?  How relevant it is to determine if the SR signaling protocol is OSPF or ISIS?
    • Try to add/extend existing elements/fields with just the right amoun= t and sufficient information that is necessary for flow analysis. We need t= o note that there may be many more/other sources for “off-box enrichment” = of flow information collected and perhaps not everything needs to be determ= ined and reported by routers.

     =

    Thomas> Absolu= tely. I fully agree on your feedback. We need to have the minimum possible = in order to have a clear view about the MPL-SR forwarding. Since IPFIX using UDP for transport, without the possibility of fragmentat= ion, we need to be careful as well not to add many more dimension's/fields.=

     =

    Best Wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Monday, August 17, 2020 8:51 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas= ,

    &nbs= p;

    Please ch= eck inline below.

    &nbs= p;

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 11:31
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    • This helps identification = of specific SR-MPLS segment types as well as differentiating them from LDP,= RSVP-TE, etc.

     =

    To be precise, th= e existing MPLS Label Type identifier differentiates from LDP, RSVP-TE. Not= the new SrSidType IPFIX IE being proposed.

    [KT= ] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR Pr= efix SID, SR Adjacency SID, SR Binding SID … (basically the segment t= ypes from RFC8402)? It’s a simpler change to an existing element/field that makes it easier for routers, collectors = and analysers?

    &nbs= p;

    • What value is provided for= IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?

    &nbs= p;

    It is important t= o distinguish between intend and result.

    [KT] By giving different = types for OSPF and ISIS, is the intention to troubleshoot routing preferenc= e selection (done based on “admin distance” between protocol se= lection in RIB)?

    &nbs= p;

    If you migrate fr= om one label distribution protocol to another, a network operator want's to= understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or = not. IE46 enables that by looking at the result of the forwarded traffic an= d not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, describes the context.

    [KT= ] Sure, so adding the SR Segments to IE46, one can check whether the traffi= c forwarding is happening using LDP or SR labels at any link in the network= .

     

    • What value is provided for= IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?

     =

    Quote from RFC840= 2. "Segment Routing (SR) leverages the source routing paradigm". = Means that not the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels= .

    [KT] From the document, I= believe we are still talking only about the top of the stack label …=

     

    With IPFIX SrSidT= ype we are able to cover this dimension in IPFIX. Enabling to analyze the r= esult of this decision. The example with " Adjacency SID or a LAN Adjacency SID" is not very useful because the difference= of the two is the topology among the adjacency. If you compare " Adja= cency SID with Prefix SID", that makes much more sense. Since it descr= ibes that a particular adjacency is chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we und= erstand that result of that decision lead to the drop and this enables to n= arrow down forwarding issues in segment routing networks more efficiently a= nd quickly.

    [KT] My point is why do w= e need to introduce another ElementID and why not use the existing Type 46 = as suggested above?

     =

    • am asking for W= G to weigh the implementation complexities=

     =

    For the WG and me= , I would be important if you can describe more detailed what you mean with implementation complexiti= es. I would like to have a better understanding where your fear is coming f= rom. I would appreciate if you could differentiate between MPLS Label Type identifier, IE46,= from which label protocol the label was coming from and SrSidType which SI= D type was used.

    [KT] To be clear, I am no= t talking from the POV of a specific implementation. Let me summarize my fe= edback and perspective:

    • Carefully consider the addition of more co= ntrol plane elements and nuances into IPFIX since they require all that add= itional context/information to be made available at the “layer” (or component) from where IPFIX picks= this info (traditionally from the “FIB”). This added informati= on should have a strong enough justification of benefit – e.g. How do= es difference between Adj SID and LAN Adj SID matter?  How relevant it is to determine if the SR signaling protocol is OSPF or ISIS?
    • Try to add/extend existing elements/fields with just the right amoun= t and sufficient information that is necessary for flow analysis. We need t= o note that there may be many more/other sources for “off-box enrichment” = of flow information collected and perhaps not everything needs to be determ= ined and reported by routers.

     

    Thanks,=

    Ketan

     =

    Best wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Saturday, August 15, 2020 7:09 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas= ,

    &nbs= p;

    I should = have been more clear in my email.

    &nbs= p;

    The propo= sal/suggestion is to add the following to the IPFIX MPLS Label type identif= ier registry:

    • SR Prefix SID
    • SR Adjacency SID=
    • SR = Binding SID
    • SR BGP Peering SID
    • … and so on

    &nbs= p;

    This help= s identification of specific SR-MPLS segment types as well as differentiati= ng them from LDP, RSVP-TE, etc.

    &nbs= p;

    And my qu= estions were:

    1. What value is provided for= IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?
    2. Wha= t value is provided for IPFIX analysis if it was a Adjacency SID or a LAN A= djacency SID?

    &nbs= p;

    I am aski= ng for WG to weigh the implementation complexities and overheads with the p= roposed details of SR-MPLS segments in IPFIX against the benefit (if any) t= hat they provide for the flow analysis and monitoring.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 09:40
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    Thank you very mu= ch for the review and feedback.

     =

    • What or how much value be = there on determining whether a SR Prefix SID was signalled/programmed on a = node via OSPFv2/OSPFv3/ISIS – what matters and is more important is that it is a Prefix SID. Hardly any deployments w= ould be running multiple protocols and learning the same prefix from differ= ent IGPs.

    &nbs= p;

    As Jeff already p= ointed out. Multiple IGP labelling protocols are used  in networks whe= n migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swissc= om when we first discovered this shortcoming in vendor implementations. The= key point here, with these additional IPFIX MPLS Label Type identifiers we= enable the possibility to verify the label protocol migration without taking the label value into the consi= deration.

    &nbs= p;

    • IPFIX may be picking this = information from a FIB in some implementation where the protocol does not m= atter and this information is not available therein.

    &nbs= p;

    I am not sure if = you have seen the presentation in IETF 108 at OPSAWG and SPRING.=

    https://www.ietf.org/procee= dings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-information= -in-ipfix-00.pdf

    &nbs= p;

    Slide 2 shows Cis= co as example vendor which implemented IE 46, MPLS Label Type identifier. T= here is an open ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.

     =

    I do understand y= our point that not all the vendors are capable to implement IE 46. But that= ’s not the point about the IPFIX IE registry. The IE registry enables that an I= PFIX implementation can refer to the right code point. With RFC 5102 the de= cision has been made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type ju= st extends the IE 46 registry with the Segment Routing label protocol code = points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, t= he IPFIX implementation can point to the right code point.

    &nbs= p;

    • On some nodes, the same Pr= efix SID may be learnt via both BGP and IGP – what would we use/show?=

     

    In this case the IE 46 shows the= label protocol which was used to program the FIB.

     

    • For that table = proposal, it is very difficult and in some cases not possible to different = between Prefix and Node and Anycast SID. Many of these types are control pl= ane elements and we can be sure more get added.

     =

    I fully agree. As= a network operator its still hard to understand the architecture and const= raints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what mak= e sense. By purpose, all available SID types are listed in the draft. This = with the aim to start the discussion in the working groups what is possible= what makes sense. I would be interested to get your and also Jeff's feedback.

     =

    In above mentione= d slides I described how TI-LFA application would benefit of visibility in = the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which lab= el protocol was used to forward a particular packet, but also which SID typ= e to further understand the intend why this label is being pushed.

     =

    I hope this makes= all sense. Looking forward for reply.

     =

    Best wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020 7:35 PM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; SPRING WG <= spring@ietf.org>
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    < also= copying Spring WG for their review/inputs >

    &nbs= p;

    Hi Thomas= /All,

    &nbs= p;

    I have re= viewed the draft and would like to share a different perspective.

    &nbs= p;

    What or h= ow much value be there on determining whether a SR Prefix SID was signalled= /programmed on a node via OSPFv2/OSPFv3/ISIS – what matters and is mo= re important is that it is a Prefix SID. Hardly any deployments would be running multiple protocols and learning the same = prefix from different IGPs. IPFIX may be picking this information from a FI= B in some implementation where the protocol does not matter and this inform= ation is not available therein.

    &nbs= p;

    On some n= odes, the same Prefix SID may be learnt via both BGP and IGP – what w= ould we use/show?

    &nbs= p;

    I would r= ecommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP Peer= ing SID and so on … for the MPLS Label Type.

    &nbs= p;

    This also= takes away the need for the second table that is being proposed to a large= extent. For that table proposal, it is very difficult and in some cases no= t possible to different between Prefix and Node and Anycast SID. Many of these types are control plane elements a= nd we can be sure more get added. Is there really much value in differentia= tion between say an Adjacency SID and LAN Adjacency SID?<= /p>

    &nbs= p;

    Could we = evaluate the implementation overhead and complexity of this level of catego= rization/information in IPFIX against their value in flow analysis to perha= ps consider a middle ground?

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Lsr <lsr-bounces@iet= f.org> On Behalf Of Thomas.Graf= @swisscom.com
    Sent: 31 July 2020 20:52
    To: hannes@gredler.at
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Hannes,

     =

    Thanks a lot for = the feedback. Yes, makes completely sense. Will take it for the next update= ..

     =

    Best Wishes<= /o:p>

    Thomas=

     

     =

    From: Hannes Gredler <hannes@= gredler.at>
    Sent: Wednesday, July 29, 2020 9:31 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Thomas,

     

    I have one comment/suggestion t= o Paragraph 4 (IANA Considerations).

     

    Please add also a code point fo= r BGP Prefix-SID - it’s quite popular in DC deployments.

     

    thanks,

     

    /hannes

    =  

    On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

     

    Dear lsr,

     

    I presented the following draft=

     

    Export of MPLS Segment Routing = Label Type Information in IP Flow Information Export (IPFIX)

     

    at the spring working group at = IETF 108 yesterday

     

    and today at OPSAWG where I cal= l for adoption.

     

    This draft adds additional segm= ent routing code points for in the IANA IPFIX registry for IS-IS, OPSFv2 an= d OPSF v3 and segment routing SID types to gain further insights into the MPLS-SR forwarding-plane.

     

    I have been asked to not only g= ather feedback from spring and opsawg but also from lsr and mpls working gr= oups since these code points are related to link state routing protocols and mpls data plane.

     

    I am looking forward to your fe= edback and input.

     

    Best Wishes

    Thomas Graf

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

     

    --_000_MW3PR11MB45701AD46D77ED33C31BFC4BC15C0MW3PR11MB4570namp_-- From nobody Tue Aug 18 07:51:08 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33FF3A0BCB for ; Tue, 18 Aug 2020 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.497, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, NICE_REPLY_A=-0.949, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=lab.dtag.de 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 au5y88hQqCAQ for ; Tue, 18 Aug 2020 07:50:59 -0700 (PDT) Received: from OldBailey.lab.dtag.de (OldBailey.lab.DTAG.DE [194.25.1.220]) (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 B0E963A0BB6 for ; Tue, 18 Aug 2020 07:50:58 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 4434BD17F4; Tue, 18 Aug 2020 16:50:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1597762242; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VHToI2TwzRqn63QNd5eG6gj2wIfLKdqzF5Wb/0aGpLE=; b=aDR4zIEcpCUfXkdybo6+G+y9rJXGY/9q+PUOvF1EpX8ZWqWZjcp84R5sLB33Avlmo314C2 QTFzPBifwmynrilXvn0P+6KyqNFBdAZdx7RjkxMG2L57jCO6rr4jLGOvLDL3RS/rWUKJhH KHkbU62vlOOBWhAQdcj1wmeDrRXbuauAh69AVIZ4joUa3/EBeRFOZ+cU+DUarDfPw2nwcv HrDCeqMBTn+cAQmoHBgf05VFTGRkck89zU0Zzrh+eQTMVSpl1fKgDD/f/XzdoG/QxyMRbC 6PWa4YiH0M1GAr+WhLipcLAAf8dr7Fr+c4Vt8OxWERZUQdcmfDELH6T/Iki+cw== To: "spring@ietf.org" Cc: "Ketan Talaulikar (ketant)" , Robert Raszuk , Alexander Vainshtein , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> From: Martin Horneffer Message-ID: <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> Date: Tue, 18 Aug 2020 16:50:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3C8CB6A8A5DE048843B56172" X-Last-TLS-Session-Version: TLSv1.3 Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 14:51:06 -0000 This is a multi-part message in MIME format. --------------3C8CB6A8A5DE048843B56172 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit A few thoughts from my (operator's) PoV:  - The disussion is a very good and important one. It probably should be discussed and documented well in order to justify the proposed protections mechanisms.  - Not all operators seem to have the same requirements.     (A somewhat similar discussion might be the one for disjoint paths. Those are often equired by voice signalling applications. In some cases the voice service demands that traffic is blackholed rather than on forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forwarded on the wrong path, as long as the network just makes sure the traffic on the other path is never affected by the same failure.)  - Personally I would hate to see yet another IGP extension for this purpose.  - I would rather prefer a good discussion of what can be achieved by using easy to make switches:     - The protection behaviour could be switched on or off per node.        - An operator with strict "some traffic may never touch certain parts of the network" requirements might switch off the behaviour, while others might switch it on.     - A node could allow a switch even individually for every port or neighbor.        - If a node knows that one of it's neighbours is a service node rather than a plain topological one, it could switch off protection. This is how I would prefer to solve the problem with serrvice nodes. Should this be discussed in the protection document, or in a separate one? Best regards, Martin Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant): > > Hi Robert, > > We do not have a signalling mechanism in IGPs today to indicate a > “bypass-able†indication for Prefix SIDs. If there was a desire for > it, an IGP extension would be required (there is none in progress > AFAIK). Note that this results in doubling the prefix SID scale > (global labels) in the network. So I would not go about this trivially. > > I think it helps to get more inputs and perspectives from operators on > their views for doing a bypass via local protection for segments in an > SR Policy. There may be those that prefer end-to-end path protection > using a fallback path that is say disjoint with the primary but > provides an appropriate SLA/intent? > > Thanks, > > Ketan > > *From:*Robert Raszuk > *Sent:* 14 August 2020 23:04 > *To:* Ketan Talaulikar (ketant) > *Cc:* Alexander Vainshtein ; Joel M. > Halpern ; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > Ketan, > > Looks like we are pretty much in sync here. > > But let me just observe that I purposely did not mention about SR > policies as we are not able to signal the intent with the packets itself. > > So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded > with information if policies build with using them are bypass eligible > or not. > > I was actually under the impression that this is already there and I > am just not aware, but looking deeper indeed I do not see this marking > neither in ISIS nor OSPF for prefix SIDs. > > Is there some work in progress to add it to those protocols or have we > just documented need for a short LSR draft  ? > > Thx, > > R. > > On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) > > wrote: > > Hi Robert, > > Please check inline below. > > *From:*Robert Raszuk > > *Sent:* 14 August 2020 21:13 > *To:* Ketan Talaulikar (ketant) > > *Cc:* Alexander Vainshtein >; Joel M. Halpern > >; Shraddha Hegde > >; > EXT-Andrew.Alston@liquidtelecom.com > > >; spring@ietf.org > > *Subject:* Re: [spring] Spring protection - determining applicability > > Hi Ketan, > > While I completely agree with your note the consequences of it are > pretty sevre. > > */[KT] I understand. We need to be mindful of implications of > protection schemes for the SLAs/intent of SR Policies./* > > Unless we signal which prefix SID is protection eligible and which > is not how would other nodes know if they can protect it or not ? > > */[KT] Correct. To be more accurate, we need to consider this more > in the context of SLA or “intent†of SR Policies and which > segments may be “bypass-able†for local protection for some of > those SR Policies. We also have path-protection mechanisms./* > > It seems that today's safe thing is not to apply any node > protection on SR flows at the PLRs then. > > And link protection MUST assure that packets will arrive at the > neighbor node via some other link regardless of further path > towards destination. > > */[KT] Yes. We have a mechanism to indicate which adj-SIDs have > protection (that mechanism only provides link protection to get to > the neighbor node) so the SR Policy computation is able to > indicate whether that specific link is “bypass-able†or not by its > choice of protected or unprotected adj-SIDs respectively./* > > *//* > > */Thanks,/* > > */Ketan/* > > Is it correct ? > > Thx > > R > > On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) > > wrote: > > Hi Sasha, > > The service node advertises its own Prefix SID. The service > function that this service node implements does not require > any context (i.e. all packets arriving at the node are > subjected to that service). Therefore the service node does > not need to receive a packet with it’s own Prefix SID. > > Thus, we cannot assume that when PHP is used, then the SID is > only associated with a topological instruction. > > Hope that clarifies? > > Thanks, > > Ketan > > *From:*Alexander Vainshtein > > *Sent:* 14 August 2020 20:24 > *To:* Ketan Talaulikar (ketant) >; Joel M. Halpern > >; Shraddha > Hegde >; > EXT-Andrew.Alston@liquidtelecom.com > > >; Robert Raszuk > > > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining > applicability > > Ketan, and all, > > I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix > SIDs that are advertised with PHP can  ONLY represent > topological instructions in SR-MPLS - because the advertising > node will not receive them and therefore can hardly be > expected to associate any service function with them. > > This is complementary to what you have said. > > Hope this clarifies my position. > > What, if anything, did I miss? > > Regards, > > Sasha > > Get Outlook for Android > > ------------------------------------------------------------------------ > > *From:* Ketan Talaulikar (ketant) > > *Sent:* Friday, August 14, 2020, 16:23 > *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com > ; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* RE: [spring] Spring protection - determining > applicability > > ------------------------------------------------------------------------ > > NOTICE: This email was received from an EXTERNAL sender > > ------------------------------------------------------------------------ > > Hi Sasha, > > If the service does not need any additional context (e.g. a > firewall that just applies locally configured default rules on > it), then I don’t see why PHP could not be done for a Prefix > SID associated with a service node. > > Also, I didn’t follow the point that you were trying to make > about Adj-SIDs. > > Thanks, > > Ketan > > *From:*Alexander Vainshtein > > *Sent:* 14 August 2020 18:24 > *To:* Ketan Talaulikar (ketant) >; Joel M. Halpern > >; Alexander > Vainshtein >; Shraddha Hegde > >; > EXT-Andrew.Alston@liquidtelecom.com > > >; Robert Raszuk > > > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining > applicability > > Hi all, > > Regarding the statement "Prefix SID could be just a > topological instruction or may also be used to steer the flow > to a node which is applying a service function to it": > > I think that in SR-MPLS a Node SID that is advertised with PHP > aciton can be safely considered as "just a topological > instruction" by the PLR because the originating node will not > receive it. > > The same applies to Adj-SDIs. > > My 2c. > > Get Outlook for Android > > > ------------------------------------------------------------------------ > > *From:* spring > on behalf of Ketan > Talaulikar (ketant) > > *Sent:* Friday, August 14, 2020, 15:00 > *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com > ; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining > applicability > > Hi All, > > I would like to share a different perspective on this. > > First, thanks to Joel for bringing up the discussion. Clearly > we need a well-defined applicability statement for determining > applicability of protection for segment used in an SR Policy. > Some of this is captured in [1]. > > This is about local repair at a PLR. By it's very nature, the > PLR does not have a notion of how "strict or not" is the SLA > that is being provided by the SR Policy. Awareness of that > notion exists at the SR Policy headend and/or computation-node. > > We have protected and un-protected variants of adjacency SIDs > to enable the computation to pick or the other based on the > "strictness" of the SLA requirement for picking that link. We > do not have such a notion for Prefix SIDs. One can say that we > could introduce signalling (e.g. a B flag) to indicate whether > a Prefix SID can be bypassed or not. This provides the > opportunity for the computation to use one or the other flavor > depending on the nature of the SLA for the SR Policy. > > I have a problem and a concern in the assumption that PLRs can > assume that the currently defined variant of Prefix SIDs in > RFC8402 (and IGP specs) are "bypass-able". > > As Joel and others have brought out, the Prefix SID could be > just a topological instruction or may also be used to steer > the flow to a node which is applying a service function to it. > In order to support a mix of SR Policies of different SLAs > (strict and not-strict), we need to enable the choice of SIDs > that indicates to the PLR whether they are "bypass-able" or not. > > For the cases, where the SR Policy has a specific SLA, it is > required for nodes to drop the packets meant for the "active > segment" than to bypass it. When this mechanism is used along > side SRTE path monitoring mechanisms, it enables the headend > to detect the failure and fallback to an alternate path using > the path protection approach. This is something that is > described and in use in deployments today [1].. > > Thanks, > Ketan > > [1] > https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9 > [2] > https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9.3 > > -----Original Message----- > From: spring > On Behalf Of Joel M. Halpern > Sent: 04 August 2020 20:25 > To: Alexander Vainshtein >; Shraddha Hegde > >; > EXT-Andrew.Alston@liquidtelecom.com > > >; Robert Raszuk > > > Cc: spring@ietf.org ; Joel M. Halpern > > > Subject: Re: [spring] Spring protection - determining > applicability > > There are, as far as I can tell, a number of ways to address > this family of related questions. > What struck me, and prompted the starting question, was that > none of them were spelled out.  I see lots of interesting > ideas / proposals. > Some of them are compatible with others.   Some are not. > It would be good if we could reach agreement on how we thought > it should be handled. > > Thank you, > Joel > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > Hi all, > > > > I am still not sure that the problem of bypass going thru > undesirable > > links/nodes exists in the case of topological SIDs. > > > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > > > ) > has been successfully deployed > > for many years before SR-MPLS has been introduced. What’s more, > > signaling of bypass tunnels he PLR usually did not include > any of the > > constraints used for computing of any specific LSP that the > bypass LSP > > would protect – because in the Facility Protection mode the > same > > bypass LSP would be used to protect multiple LSPs passing > thru the > > failed link/node. > > > >  From my POV the only difference between this behavior and that > > introduced by the “bypassing†drafts in SR is that, in the > case of > > RSVP-TE, the operator would explicitly indicate, as part of LSP > > signaling, whether it would or would not use FRR; LSPs that > would not > > use FRR would then drop traffic rather than delivering it > the wrong way. > > > > Such an option indeed does not exist in SR-TE today, but > would be easy > > to provide if so desired IMHO. > > > > Did I miss something substantial? > > > > Regards, and lots of thanks in advance, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell:      +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > *From:* spring > *On Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > *To:* EXT-Andrew.Alston@liquidtelecom.com > > > >; Robert Raszuk > > > > *Cc:* spring@ietf.org ; Joel M. > Halpern > > > *Subject:* Re: [spring] Spring protection - determining > applicability > > > > All, > > > > This is a very interesting discussion and thanks to Joel for > starting > > this discussion. IMO, when there are strict requirements of > avoiding > > certain nodes/links it can be realized  either by defining a > flex-algo > > avoiding those > > > > Nodes and links or by using a stack of unprotected adj-sids > that avoid > > restricted nodes and links. When a stack of adj-sids is used to > > realize the path, the head-end based (sBFD) protection > mechanisms can be applied. > > > > If Node-sids/prefix-sid/anycast-sids are used to build the > stack, the > > failure events may cause traffic to go through restricted > nodes and > > links. This would happen regardless of whether any kind of > protection > > is in use or not. > > > > Rgds > > > > Shraddha > > > > Juniper Business Use Only > > > > *From:* spring > > > *On Behalf Of *Andrew Alston > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > *To:* Robert Raszuk > > > *Cc:* spring@ietf.org > ; Joel M. Halpern > > > > > > *Subject:* Re: [spring] Spring protection - determining > applicability > > > > *[External Email. Be cautious of content]* > > > > Robert this is actually far more difficult when – it can be > an entire > > (long) series of nodes that need to be avoided. > > > > It could potentially be made to work but I’d worry that to > do this – > > you’d have to stack 10 – 20 – 30 negative labels – and that > wouldn’t > > be viable. > > > > It’s easier to use algorithms and adjacency sids and other > such things > > to calculate paths – the biggest trick is about the stack > depth.  When > > you have this need for node avoidance – the need for 10+ > label depth > > is critical – unless you wanna be applying one hell of a lot of > > binding labels along the way which is a nightmare. > > > > But to answer your question, is this a common use case – > it’s a use > > case that most of the people I discuss this with certain > have – I cant > > comment on a global scale, or for anyone else, but every > indication I > > have is that yes – its something people need, and want > > > > Andrew > > > > *From:* Robert Raszuk > > > *Sent:* Tuesday, 4 August 2020 01:27 > > *To:* Andrew Alston > > > > > *Cc:* Joel M. Halpern > > >; spring@ietf.org > > > > > *Subject:* Re: [spring] Spring protection - determining > applicability > > > > Is this a common use case ie. "but rather – which nodes / > network > > segments it can never touch or flow through." > > > > If so perhaps its time to define notion of *negative-SID* > ie. list in > > the packet resources which given packet MUST not ever traverse. > > > > Put in the packet set of nodes or links which the packet > should never > > traverse. > > > > That goes in line of recent wave of negative routing > implementations > > (RIFT) or discussions (LSR) > > > > Best, > > R. > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > > > wrote: > > > >     So – > > > >     One of the use cases, in fact, some very major use cases > in any > >     spring technology for us revolve around the following > > > >     a.The explicit avoidance of certain nodes > > > >     b.The explicit avoidance of certain sections of the network > > > >     Anything that could result in that explicit avoidance > being violated > >     – would create, shall we say significant problems. > > > >     Much of the use case is not a case of which nodes the > packets flow > >     through – but rather – which nodes / network segments it > can never > >     touch or flow through. Effectively, to be used as a > technology to > >     avoid certain things for specific reasons. > > > >     This is also one of the reasons for needing such deep > label stacks – > >     this kind of detailed path programming tends to deepen > the stack > >     because you sometimes have to be pretty explicit. > > > >     It is absolutely critical to us that this functionality > is there – > >     and that we can avoid situations which could cause > traffic to > >     accidently hit things explicitly avoided. > > > >     I wish I could be more specific than this, but it is > what it is. > > > >     Thanks > > > >     Andrew > > > >     *From:* spring >     > > *On Behalf Of *Joel M. Halpern > >     *Sent:* Monday, 3 August 2020 21:36 > >     *To:* Robert Raszuk > > >     *Cc:* spring@ietf..org > > >     *Subject:* Re: [spring] Spring protection - determining > > applicability > > > >     (Since the thread has gotten long enough, reiterating > that this is as a > >     participant, not a WG chair.) > > > >     Yes, we are talking IP networks. And yes, I have seen IP > networks that > >     choose to drop packets. For all sorts of reasons. > >     I think there are likely other reasons why one may not > want a random > >     path rather than a chosen TE path. I think it is > important we be clear > >     about what constraints may be / are violated when we > tell people they > >     have this tool (protective rerouting) that is intended > to preserve QoS. > > > >     Let's be clear. I am not arguing that this is not a good > idea. It is a > >     good idea. And useful. I am trying to figure otu what > combination of > >     additional mechanisms and clear descriptions will lead > to everyone > >     getting the behavior they expect (which may not be the > behavior they > >     desire, but sometimes is the best we can do.) > > > >     Yours, > >     Joel > > > >     On 8/3/2020 2:30 PM, Robert Raszuk wrote: > >      > Joel, > >      > > >      > Are we still talking about IP networks here ? Or > perhaps some hard > >      > slicing with real resource reservations or detnets ? > >      > > >      > Because if we are talking about IP networking I have two > >     observations: > >      > > >      > A) If you need to traverse via a specific node (ie. > firewall) you > >     better > >      > apply IP encapsulation to that node.. I don't think IP > >     encapsulation can > >      > be hijacked today such that destination address of > the packet is > >     ignored. > >      > > >      > B) Have you seen any IP network where upon topology > change (link > >     or node > >      > failure) you suddenly start dropping flows in spite > of SPT offering > >      > perhaps few ms longer path with 10 ms more jitter ? > >      > > >      > Or are some SR marketing slides promise to turn IP > networks in > >      > something new ? Worse ... do they mention path > quality guarantees, > >      > resource reservations ? I hope not. > >      > > >      > Thx, > >      > R. > >      > > >      > > >      > > >      > > >      > > >      > > >      > > >      > > >      > > >      > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > >     > > > > wrote: > >      > > >      > Well less serious for TE SIDs, I am not sure the > problem is > >     restricted > >      > to just service SIDs. > >      > > >      > Suppose that the PCE has specified the path to meet > some complex te > >      > objective.  The bypass node has no way of knowing > what those > >      > constraints > >      > were.  And for some kinds of traffic, it is better to > drop the packet > >      > than to deliver it outside the envelop.  I suspect > that the right > >      > answer > >      > to this is "too bad". If so, as with the distinction > regarding > >     service > >      > nodes, we should say so, shouldn't we? > >      > > >      > Yours, > >      > Joel > >      > > >      > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > >      > > Mach, Joel and all, > >      > > > >      > > I think that in most cases: > >      > > > >      > > 1.There is clear differentiation between > "topological" and > >     "service" > >      > > instructions in SID advertisements. E.g.: > >      > > > >      > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as > such in the > >      > > corresponding IGP advertisements) represent topological > >     instructions > >      > > > >      > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay > Services > >      > > > >      > > >     > >     > > > >      > > >      > > draft) unsurprisingly represent “service†instructions > >      > > > >      > > 2.Segments that represent topological instructions > can be bypassed, > >      > > while segments that represent service instructions > require > >      > alternative > >      > > protection mechanisms. > >      > > > >      > > This view seems to be aligned with RFC 8402 > >      > > > >     > > > >     that says in Section 1: > >      > > > >      > >     In the context of an IGP-based distributed > control plane, two > >      > > > >      > > topological segments are defined: the IGP-Adjacency > segment and the > >      > > > >      > >     IGP-Prefix segment. > >      > > > >      > >     In the context of a BGP-based distributed > control plane, two > >      > > > >      > > topological segments are defined: the BGP peering > segment and the > >      > > > >      > >     BGP-Prefix segment. > >      > > > >      > > In the case of SR-MPLS this differentiation is > assumed in Section > >      > 3.4 of > >      > > the Node Protection for SR-TE Path > >      > > > >      > > >     > >     > > > >      > > >      > > draft that says: > >      > > > >      > >     The node protection mechanism described in the > previous > >     sections > >      > > > >      > >     depends on the assumption that the label > immediately below > >      > the top > >      > > > >      > > label in the label stack is understood in the IGP > domain.  When the > >      > > > >      > >     provider edge routers exchange service labels > via BGP or some > >      > other > >      > > > >      > >     non-IGP mechanism the bottom label is not > understood in the IGP > >      > > > >      > >     domain. > >      > > > >      > >     The egress node protection mechanisms described > in the draft > >      > > > >      > >     [RFC8679 > >     > >] > >     is > >      > > applicable to this use case and no additional changes > >      > > > >      > >     will be required for SR based networks > >      > > > >      > > The scenarios in which  differentiation between > “topological†and > >      > > “service†instructions is broken are indeed > problematic. E.g., > >      > consider > >      > > the use case in which a Node SID in the ERO of a > SR-TE path > >      > identifies a > >      > > node that acts as a firewall for all packets it > receives, i.e., > >      > provides > >      > > the firewall service without any dedicated service SID > >      > identifying it. > >      > > One could say that the Node SID of such a node > would combine > >      > topological > >      > > and service instructions thus breaking the > differentiation > >      > between the two. > >      > > > >      > > I am not sure if usage of such “combined†SIDs > could be prevented > >      > or at > >      > > least discouraged. > >      > > > >      > > If not, providing an ability to identify such SIDs > in the > >      > advertisement > >      > > mechanisms would be useful IMHO. > >      > > > >      > > My 2c, > >      > > > >      > > Sasha > >      > > > >      > > Office: +972-39266302 > >      > > > >      > > Cell: +972-549266302 > >      > > > >      > > Email: Alexander.Vainshtein@ecitele.com > > >     > >      > > >      > > > >      > > -----Original Message----- > >      > > From: spring >     > > > >     > On Behalf Of Mach Chen > >      > > Sent: Monday, August 3, 2020 6:30 AM > >      > > To: Joel M. Halpern >     > > >; > > spring@ietf.org > > >      > > Subject: Re: [spring] Spring protection - > determining applicability > >      > > > >      > > Hi Joel, > >      > > > >      > > I think this is a good point that may not be > discussed in the > >      > past. And > >      > > I also don't think there is a "can be bypassed" > indication in the > >      > > routing advertisement for now. > >      > > > >      > > IMHO, the information advertised by routing is > neutral, such > >      > information > >      > > (can or cannot be bypassed) is more path specific, thus > >     normally the > >      > > controller should be responsible for deciding > whether/which SID > >      > can be > >      > > bypassed. > >      > > > >      > > Best regards, > >      > > > >      > > Mach > >      > > > >      > >  > -----Original Message----- > >      > > > >      > >  > From: spring [mailto:spring-bounces@ietf.org > > >      > > >     > ] > >     On Behalf Of Joel M. > >      > > > >      > >  > Halpern > >      > > > >      > >  > Sent: Monday, August 3, 2020 7:51 AM > >      > > > >      > >  > To: spring@ietf.org > > >     > >      > >     > >> > >      > > > >      > >  > Subject: [spring] Spring protection - > determining applicability > >      > > > >      > >  > > >      > > > >      > >  > (WG Chair hat Off, this is merely a note from a > slightly > >      > confused WG > >      > > > >      > >  > participant.) > >      > > > >      > >  > > >      > > > >      > >  > I have been reading the various repair drafts, > and the various > >      > > > >      > >  > networks programming and service programming > draft, and I am > >      > trying to > >      > > > >      > >  > figure out one aspect of the combination. > >      > > > >      > >  > > >      > > > >      > >  > How does a node that is doing some form of > bypass (suppose, for > >      > > > >      > >  > simplicity, it is Node N2 deciding to bypass the > next SID for > >      > a failed > >      > > > >      > >  > node N3) know that it is safe to do so? > >      > > > >      > >  > > >      > > > >      > >  > If the path was just for TE, then it is "safe" > if the new path > >      > meets > >      > > > >      > >  > the TE criteria.  or maybe it is safe if it is > even close, as > >      > long as > >      > > > >      > >  > it is not used for too long. > >      > > > >      > >  > > >      > > > >      > >  > But what if the node were a Firewall, included > to meet legal > >      > > requirements? > >      > > > >      > >  > Or was some other necessary programmatic > transform (wince we are > >      > > > >      > >  > deliberately vague about what nodes can do when > asked suitably.) > >      > > > >      > >  > > >      > > > >      > >  > Is there some "can be bypassed" indication in > the routing > >      > > > >      > >  > advertisements that I missed? > >      > > > >      > >  > > >      > > > >      > >  > Thank you, > >      > > > >      > >  > Yours, > >      > > > >      > >  > Joel > >      > > > >      > >  > > >      > > > >      > >  > _______________________________________________ > >      > > > >      > >  > spring mailing list > >      > > > >      > >  > spring@ietf.org > > >     > >      > >     > >> > >      > > > >      > >  > > >      > > > >      > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2 > > >     > > >      > > > >      > > >     > >     > > > >      > > > >      > >  > F%2Fwww.ietf.org > >     > > >      > > >     > >%2Fmailman%2Flistinfo%2Fspring > >      > > > >      > > _______________________________________________ > >      > > > >      > > spring mailing list > >      > > > >      > > spring@ietf.org > > >     >     > > > > >      > > > >      > > > >      > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > >     > > >      > > > >      > > > >      > > > >      > > > >      > > > > ------------------------------------------------------------------------ > >      > > Notice: This e-mail together with any attachments > may contain > >      > > information of Ribbon Communications Inc. that is > confidential > >      > and/or > >      > > proprietary for the sole use of the intended > recipient. Any review, > >      > > disclosure, reliance or distribution by others or > forwarding > >     without > >      > > express permission is strictly prohibited. If you > are not the > >      > intended > >      > > recipient, please notify the sender immediately and > then delete all > >      > > copies, including any attachments. > >      > > > >      > > > > ------------------------------------------------------------------------ > >      > > > >      > > _______________________________________________ > >      > > spring mailing list > >      > > spring@ietf.org > > >      > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > >     > > >      > > > >      > > >      > _______________________________________________ > >      > spring mailing list > >      > spring@ietf.org > > >      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > >     > > >      > > > > > _______________________________________________ > >     spring mailing list > > spring@ietf.org > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org > %2Fmailman%2Flisti > > > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > > ---------------------------------------------------------------------- > > -- > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is > confidential and/or > > proprietary for the sole use of the intended recipient. Any > review, > > disclosure, reliance or distribution by others or forwarding > without > > express permission is strictly prohibited. If you are not > the intended > > recipient, please notify the sender immediately and then > delete all > > copies, including any attachments. > > > ---------------------------------------------------------------------- > > -- > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > ------------------------------------------------------------------------ > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential > and/or proprietary for the sole use of the intended recipient. > Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. > If you are not the intended recipient, please notify the > sender immediately and then delete all copies, including any > attachments. > > ------------------------------------------------------------------------ > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------3C8CB6A8A5DE048843B56172 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit A few thoughts from my (operator's) PoV:

     - The disussion is a very good and important one. It probably should be discussed and documented well in order to justify the proposed protections mechanisms.

     - Not all operators seem to have the same requirements.
        (A somewhat similar discussion might be the one for disjoint paths. Those are often equired by voice signalling applications. In some cases the voice service demands that traffic is blackholed rather than on forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forwarded on the wrong path, as long as the network just makes sure the traffic on the other path is never affected by the same failure.)

     - Personally I would hate to see yet another IGP extension for this purpose.

     - I would rather prefer a good discussion of what can be achieved by using easy to make switches:
        - The protection behaviour could be switched on or off per node.
           - An operator with strict "some traffic may never touch certain parts of the network" requirements might switch off the behaviour, while others might switch it on.
        - A node could allow a switch even individually for every port or neighbor.
           - If a node knows that one of it's neighbours is a service node rather than a plain topological one, it could switch off protection. This is how I would prefer to solve the problem with serrvice nodes.

    Should this be discussed in the protection document, or in a separate one?

    Best regards, Martin


    Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant):

    Hi Robert,

     

    We do not have a signalling mechanism in IGPs today to indicate a “bypass-able†indication for Prefix SIDs. If there was a desire for it, an IGP extension would be required (there is none in progress AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go about this trivially.

     

    I think it helps to get more inputs and perspectives from operators on their views for doing a bypass via local protection for segments in an SR Policy. There may be those that prefer end-to-end path protection using a fallback path that is say disjoint with the primary but provides an appropriate SLA/intent?

     

    Thanks,

    Ketan

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 23:04
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability

     

    Ketan,

     

    Looks like we are pretty much in sync here. 

     

    But let me just observe that I purposely did not mention about SR policies as we are not able to signal the intent with the packets itself. 

     

    So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with information if policies build with using them are bypass eligible or not. 

     

    I was actually under the impression that this is already there and I am just not aware, but looking deeper indeed I do not see this marking neither in ISIS nor OSPF for prefix SIDs. 

     

    Is there some work in progress to add it to those protocols or have we just documented need for a short LSR draft  ? 

     

    Thx,

    R.

     

     

    On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:

    Hi Robert,

     

    Please check inline below.

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 21:13
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability

     

    Hi Ketan,

     

    While I completely agree with your note the consequences of it are pretty sevre. 

    [KT] I understand. We need to be mindful of implications of protection schemes for the SLAs/intent of SR Policies.

     

    Unless we signal which prefix SID is protection eligible and which is not how would other nodes know if they can protect it or not ? 

    [KT] Correct. To be more accurate, we need to consider this more in the context of SLA or “intent†of SR Policies and which segments may be “bypass-able†for local protection for some of those SR Policies. We also have path-protection mechanisms.

     

    It seems that today's safe thing is not to apply any node protection on SR flows at the PLRs then. 

     

    And link protection MUST assure that packets will arrive at the neighbor node via some other link regardless of further path towards destination. 

    [KT] Yes. We have a mechanism to indicate which adj-SIDs have protection (that mechanism only provides link protection to get to the neighbor node) so the SR Policy computation is able to indicate whether that specific link is “bypass-able†or not by its choice of protected or unprotected adj-SIDs respectively.

     

    Thanks,

    Ketan

     

    Is it correct ? 

     

    Thx

    R

     

    On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:

    Hi Sasha,

     

    The service node advertises its own Prefix SID. The service function that this service node implements does not require any context (i.e. all packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a packet with it’s own Prefix SID.

     

    Thus, we cannot assume that when PHP is used, then the SID is only associated with a topological instruction.

     

    Hope that clarifies?

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
    Sent: 14 August 2020 20:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    Cc: spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability

     

    Ketan, and all,

    I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are advertised with PHP can  ONLY represent topological instructions in SR-MPLS - because the advertising node will not receive them and therefore can hardly be expected to associate any service function with them.

     

    This is complementary to what you have said.

     

    Hope this clarifies my position.

    What, if anything, did I miss?

     

    Regards,

    Sasha

     

    Get Outlook for Android

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020, 16:23
    To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject: RE: [spring] Spring protection - determining applicability

     

    NOTICE: This email was received from an EXTERNAL sender

     

    Hi Sasha,

     

    If the service does not need any additional context (e.g. a firewall that just applies locally configured default rules on it), then I don’t see why PHP could not be done for a Prefix SID associated with a service node.

     

    Also, I didn’t follow the point that you were trying to make about Adj-SIDs.

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
    Sent: 14 August 2020 18:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com>; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    Cc: spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability

     

    Hi all,

    Regarding the statement "Prefix SID could be just a topological instruction or may also be used to steer the flow to a node which is applying a service function to it":

     

     

    I think that in SR-MPLS a Node SID that is advertised with PHP aciton can be safely considered as "just a topological instruction" by the PLR because the originating node will not receive it.

    The same applies to Adj-SDIs.

     

    My 2c.

     

    Get Outlook for Android

     

    From: spring <spring-bounces@ietf.org> on behalf of Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>
    Sent: Friday, August 14, 2020, 15:00
    To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability

     

    Hi All,

    I would like to share a different perspective on this.

    First, thanks to Joel for bringing up the discussion. Clearly we need a well-defined applicability statement for determining applicability of protection for segment used in an SR Policy. Some of this is captured in [1].

    This is about local repair at a PLR. By it's very nature, the PLR does not have a notion of how "strict or not" is the SLA that is being provided by the SR Policy. Awareness of that notion exists at the SR Policy headend and/or computation-node.

    We have protected and un-protected variants of adjacency SIDs to enable the computation to pick or the other based on the "strictness" of the SLA requirement for picking that link. We do not have such a notion for Prefix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypassed or not. This provides the opportunity for the computation to use one or the other flavor depending on the nature of the SLA for the SR Policy.

    I have a problem and a concern in the assumption that PLRs can assume that the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are "bypass-able".

    As Joel and others have brought out, the Prefix SID could be just a topological instruction or may also be used to steer the flow to a node which is applying a service function to it. In order to support a mix of SR Policies of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether they are "bypass-able" or not.

    For the cases, where the SR Policy has a specific SLA, it is required for nodes to drop the packets meant for the "active segment" than to bypass it. When this mechanism is used along side SRTE path monitoring mechanisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approach. This is something that is described and in use in deployments today [1]..

    Thanks,
    Ketan

    [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9
    [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23section-9.3

    -----Original Message-----
    From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
    Sent: 04 August 2020 20:25
    To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability

    There are, as far as I can tell, a number of ways to address this family of related questions.
    What struck me, and prompted the starting question, was that none of them were spelled out.  I see lots of interesting ideas / proposals.
    Some of them are compatible with others.   Some are not.
    It would be good if we could reach agreement on how we thought it should be handled.

    Thank you,
    Joel

    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
    > Hi all,
    >
    > I am still not sure that the problem of bypass going thru undesirable
    > links/nodes exists in the case of topological SIDs.
    >
    > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
    > <https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
    > for many years before SR-MPLS has been introduced. What’s more,
    > signaling of bypass tunnels he PLR usually did not include any of the
    > constraints used for computing of any specific LSP that the bypass LSP
    > would protect – because in the Facility Protection mode the same
    > bypass LSP would be used to protect multiple LSPs passing thru the
    > failed link/node.
    >
    >  From my POV the only difference between this behavior and that
    > introduced by the “bypassing†drafts in SR is that, in the case of
    > RSVP-TE, the operator would explicitly indicate, as part of LSP
    > signaling, whether it would or would not use FRR; LSPs that would not
    > use FRR would then drop traffic rather than delivering it the wrong way.
    >
    > Such an option indeed does not exist in SR-TE today, but would be easy
    > to provide if so desired IMHO.
    >
    > Did I miss something substantial?
    >
    > Regards, and lots of thanks in advance,
    >
    > Sasha
    >
    > Office: +972-39266302
    >
    > Cell:      +972-549266302
    >
    > Email:   Alexander.Vainshtein@ecitele.com
    >
    > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde
    > *Sent:* Tuesday, August 4, 2020 9:41 AM
    > *To:* EXT-Andrew.Alston@liquidtelecom.com
    > <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    > *Cc:* spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
    > *Subject:* Re: [spring] Spring protection - determining applicability
    >
    > All,
    >
    > This is a very interesting discussion and thanks to Joel for starting
    > this discussion. IMO, when there are strict requirements of avoiding
    > certain nodes/links it can be realized  either by defining a flex-algo
    > avoiding those
    >
    > Nodes and links or by using a stack of unprotected adj-sids that avoid
    > restricted nodes and links. When a stack of adj-sids is used to
    > realize the path, the head-end based (sBFD) protection mechanisms can be applied.
    >
    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the
    > failure events may cause traffic to go through restricted nodes and
    > links. This would happen regardless of whether any kind of protection
    > is in use or not.
    >
    > Rgds
    >
    > Shraddha
    >
    > Juniper Business Use Only
    >
    > *From:* spring <spring-bounces@ietf.org
    > <mailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
    > *Sent:* Tuesday, August 4, 2020 5:41 AM
    > *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Cc:* spring@ietf.org <mailto:spring@ietf.org>; Joel M. Halpern
    > <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
    > *Subject:* Re: [spring] Spring protection - determining applicability
    >
    > *[External Email. Be cautious of content]*
    >
    > Robert this is actually far more difficult when – it can be an entire
    > (long) series of nodes that need to be avoided.
    >
    > It could potentially be made to work but I’d worry that to do this –
    > you’d have to stack 10 – 20 – 30 negative labels – and that wouldn’t
    > be viable.
    >
    > It’s easier to use algorithms and adjacency sids and other such things
    > to calculate paths – the biggest trick is about the stack depth.  When
    > you have this need for node avoidance – the need for 10+ label depth
    > is critical – unless you wanna be applying one hell of a lot of
    > binding labels along the way which is a nightmare.
    >
    > But to answer your question, is this a common use case – it’s a use
    > case that most of the people I discuss this with certain have – I cant
    > comment on a global scale, or for anyone else, but every indication I
    > have is that yes – its something people need, and want
    >
    > Andrew
    >
    > *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Sent:* Tuesday, 4 August 2020 01:27
    > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>>
    > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
    > <mailto:jmh@joelhalpern.com>>; spring@ietf.org
    > <mailto:spring@ietf.org>
    > *Subject:* Re: [spring] Spring protection - determining applicability
    >
    > Is this a common use case ie.  "but rather – which nodes / network
    > segments it can never touch or flow through."
    >
    > If so perhaps its time to define notion of *negative-SID* ie. list in
    > the packet resources which given packet MUST not ever traverse.
    >
    > Put in the packet set of nodes or links which the packet should never
    > traverse.
    >
    > That goes in line of recent wave of negative routing implementations
    > (RIFT) or discussions (LSR)
    >
    > Best,
    > R.
    >
    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
    > <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
    >
    >     So –
    >
    >     One of the use cases, in fact, some very major use cases in any
    >     spring technology for us revolve around the following
    >
    >     a.The explicit avoidance of certain nodes
    >
    >     b.The explicit avoidance of certain sections of the network
    >
    >     Anything that could result in that explicit avoidance being violated
    >     – would create, shall we say significant problems.
    >
    >     Much of the use case is not a case of which nodes the packets flow
    >     through – but rather – which nodes / network segments it can never
    >     touch or flow through.  Effectively, to be used as a technology to
    >     avoid certain things for specific reasons.
    >
    >     This is also one of the reasons for needing such deep label stacks –
    >     this kind of detailed path programming tends to deepen the stack
    >     because you sometimes have to be pretty explicit.
    >
    >     It is absolutely critical to us that this functionality is there –
    >     and that we can avoid situations which could cause traffic to
    >     accidently hit things explicitly avoided.
    >
    >     I wish I could be more specific than this, but it is what it is.
    >
    >     Thanks
    >
    >     Andrew
    >
    >     *From:* spring <spring-bounces@ietf.org
    >     <mailto:spring-bounces@ietf.org>> *On Behalf Of *Joel M. Halpern
    >     *Sent:* Monday, 3 August 2020 21:36
    >     *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    >     *Cc:* spring@ietf..org <mailto:spring@ietf.org>
    >     *Subject:* Re: [spring] Spring protection - determining
    > applicability
    >
    >     (Since the thread has gotten long enough, reiterating that this is as a
    >     participant, not a WG chair.)
    >
    >     Yes, we are talking IP networks. And yes, I have seen IP networks that
    >     choose to drop packets. For all sorts of reasons.
    >     I think there are likely other reasons why one may not want a random
    >     path rather than a chosen TE path. I think it is important we be clear
    >     about what constraints may be / are violated when we tell people they
    >     have this tool (protective rerouting) that is intended to preserve QoS.
    >
    >     Let's be clear. I am not arguing that this is not a good idea. It is a
    >     good idea. And useful. I am trying to figure otu what combination of
    >     additional mechanisms and clear descriptions will lead to everyone
    >     getting the behavior they expect (which may not be the behavior they
    >     desire, but sometimes is the best we can do.)
    >
    >     Yours,
    >     Joel
    >
    >     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
    >      > Joel,
    >      >
    >      > Are we still talking about IP networks here ? Or perhaps some hard
    >      > slicing with real resource reservations or detnets ?
    >      >
    >      > Because if we are talking about IP networking I have two
    >     observations:
    >      >
    >      > A) If you need to traverse via a specific node (ie. firewall) you
    >     better
    >      > apply IP encapsulation to that node.. I don't think IP
    >     encapsulation can
    >      > be hijacked today such that destination address of the packet is
    >     ignored.
    >      >
    >      > B) Have you seen any IP network where upon topology change (link
    >     or node
    >      > failure) you suddenly start dropping flows in spite of SPT offering
    >      > perhaps few ms longer path with 10 ms more jitter ?
    >      >
    >      > Or are some SR marketing slides promise to turn IP networks in
    >      > something new ? Worse ... do they mention path quality guarantees,
    >      > resource reservations ? I hope not.
    >      >
    >      > Thx,
    >      > R.
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern <jmh@joelhalpern.com
    >     <mailto:jmh@joelhalpern.com%20%0b>> <mailto:jmh@joelhalpern.com>> wrote:
    >      >
    >      > Well less serious for TE SIDs, I am not sure the problem is
    >     restricted
    >      > to just service SIDs.
    >      >
    >      > Suppose that the PCE has specified the path to meet some complex te
    >      > objective.  The bypass node has no way of knowing what those
    >      > constraints
    >      > were.  And for some kinds of traffic, it is better to drop the packet
    >      > than to deliver it outside the envelop.  I suspect that the right
    >      > answer
    >      > to this is "too bad".  If so, as with the distinction regarding
    >     service
    >      > nodes, we should say so, shouldn't we?
    >      >
    >      > Yours,
    >      > Joel
    >      >
    >      > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote:
    >      > > Mach, Joel and all,
    >      > >
    >      > > I think that in most cases:
    >      > >
    >      > > 1.There is clear differentiation between "topological" and
    >     "service"
    >      > > instructions in SID advertisements. E.g.:
    >      > >
    >      > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the
    >      > > corresponding IGP advertisements) represent topological
    >     instructions
    >      > >
    >      > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services
    >      > >
    >      >
    >     <https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
    >     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>>
    >      >
    >      > > draft) unsurprisingly represent “service†instructions
    >      > >
    >      > > 2.Segments that represent topological instructions can be bypassed,
    >      > > while segments that represent service instructions require
    >      > alternative
    >      > > protection mechanisms.
    >      > >
    >      > > This view seems to be aligned with RFC 8402
    >      > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
    >     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>>
    >     that says in Section 1:
    >      > >
    >      > >     In the context of an IGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defined: the IGP-Adjacency segment and the
    >      > >
    >      > >     IGP-Prefix segment.
    >      > >
    >      > >     In the context of a BGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defined: the BGP peering segment and the
    >      > >
    >      > >     BGP-Prefix segment.
    >      > >
    >      > > In the case of SR-MPLS this differentiation is assumed in Section
    >      > 3.4 of
    >      > > the Node Protection for SR-TE Path
    >      > >
    >      >
    >     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%23section-3.4
    >     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>>
    >      >
    >      > > draft that says:
    >      > >
    >      > >     The node protection mechanism described in the previous
    >     sections
    >      > >
    >      > >     depends on the assumption that the label immediately below
    >      > the top
    >      > >
    >      > > label in the label stack is understood in the IGP domain.  When the
    >      > >
    >      > >     provider edge routers exchange service labels via BGP or some
    >      > other
    >      > >
    >      > >     non-IGP mechanism the bottom label is not understood in the IGP
    >      > >
    >      > >     domain.
    >      > >
    >      > >     The egress node protection mechanisms described in the draft
    >      > >
    >      > >     [RFC8679 <https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
    >     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
    >     is
    >      > > applicable to this use case and no additional changes
    >      > >
    >      > >     will be required for SR based networks
    >      > >
    >      > > The scenarios in which  differentiation between “topological†and
    >      > > “service†instructions is broken are indeed problematic. E.g.,
    >      > consider
    >      > > the use case in which a Node SID in the ERO of a SR-TE path
    >      > identifies a
    >      > > node that acts as a firewall for all packets it receives, i.e.,
    >      > provides
    >      > > the firewall service without any dedicated service SID
    >      > identifying it.
    >      > > One could say that the Node SID of such a node would combine
    >      > topological
    >      > > and service instructions thus breaking the differentiation
    >      > between the two.
    >      > >
    >      > > I am not sure if usage of such “combined†SIDs could be prevented
    >      > or at
    >      > > least discouraged.
    >      > >
    >      > > If not, providing an ability to identify such SIDs in the
    >      > advertisement
    >      > > mechanisms would be useful IMHO.
    >      > >
    >      > > My 2c,
    >      > >
    >      > > Sasha
    >      > >
    >      > > Office: +972-39266302
    >      > >
    >      > > Cell:      +972-549266302
    >      > >
    >      > > Email: Alexander.Vainshtein@ecitele.com
    >     <mailto:Alexander.Vainshtein@ecitele.com>
    >      > <mailto:Alexander.Vainshtein@ecitele.com>
    >      > >
    >      > > -----Original Message-----
    >      > > From: spring <spring-bounces@ietf.org
    >     <mailto:spring-bounces@ietf.org%0b>>
    >     <mailto:spring-bounces@ietf.org>> On Behalf Of Mach Chen
    >      > > Sent: Monday, August 3, 2020 6:30 AM
    >      > > To: Joel M. Halpern <jmh@joelhalpern.com
    >     <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.com>>;
    >     spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > Subject: Re: [spring] Spring protection - determining applicability
    >      > >
    >      > > Hi Joel,
    >      > >
    >      > > I think this is a good point that may not be discussed in the
    >      > past. And
    >      > > I also don't think there is a "can be bypassed" indication in the
    >      > > routing advertisement for now.
    >      > >
    >      > > IMHO, the information advertised by routing is neutral, such
    >      > information
    >      > > (can or cannot be bypassed) is more path specific, thus
    >     normally the
    >      > > controller should be responsible for deciding whether/which SID
    >      > can be
    >      > > bypassed.
    >      > >
    >      > > Best regards,
    >      > >
    >      > > Mach
    >      > >
    >      > >  > -----Original Message-----
    >      > >
    >      > >  > From: spring [mailto:spring-bounces@ietf.org
    >      > <mailto:spring-bounces@ietf.org>
    >     <mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>]
    >     On Behalf Of Joel M.
    >      > >
    >      > >  > Halpern
    >      > >
    >      > >  > Sent: Monday, August 3, 2020 7:51 AM
    >      > >
    >      > >  > To: spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>
    >      > >
    >      > >  > Subject: [spring] Spring protection - determining applicability
    >      > >
    >      > >  >
    >      > >
    >      > >  > (WG Chair hat Off, this is merely a note from a slightly
    >      > confused WG
    >      > >
    >      > >  > participant.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > I have been reading the various repair drafts, and the various
    >      > >
    >      > >  > networks programming and service programming draft, and I am
    >      > trying to
    >      > >
    >      > >  > figure out one aspect of the combination.
    >      > >
    >      > >  >
    >      > >
    >      > >  > How does a node that is doing some form of bypass (suppose, for
    >      > >
    >      > >  > simplicity, it is Node N2 deciding to bypass the next SID for
    >      > a failed
    >      > >
    >      > >  > node N3) know that it is safe to do so?
    >      > >
    >      > >  >
    >      > >
    >      > >  > If the path was just for TE, then it is "safe" if the new path
    >      > meets
    >      > >
    >      > >  > the TE criteria.  or maybe it is safe if it is even close, as
    >      > long as
    >      > >
    >      > >  > it is not used for too long.
    >      > >
    >      > >  >
    >      > >
    >      > >  > But what if the node were a Firewall, included to meet legal
    >      > > requirements?
    >      > >
    >      > >  > Or was some other necessary programmatic transform (wince we are
    >      > >
    >      > >  > deliberately vague about what nodes can do when asked suitably.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > Is there some "can be bypassed" indication in the routing
    >      > >
    >      > >  > advertisements that I missed?
    >      > >
    >      > >  >
    >      > >
    >      > >  > Thank you,
    >      > >
    >      > >  > Yours,
    >      > >
    >      > >  > Joel
    >      > >
    >      > >  >
    >      > >
    >      > >  > _______________________________________________
    >      > >
    >      > >  > spring mailing list
    >      > >
    >      > >  > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmailto:spring@ietf.org>>>
    >      > >
    >      > >  >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2
    >     <https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24>
    >      > >
    >      >
    >     <https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%252
    >     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24>>
    >      > >
    >      > >  > F%2Fwww.ietf.org
    >     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
    >      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=http%3A%2F%2F2Fwww.ietf.org
    >     <https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
    >      > >
    >      > > _______________________________________________
    >      > >
    >      > > spring mailing list
    >      > >
    >      > > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org> <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>>
    >      > >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
    >      > >
    >      > >
    >      > >
    >      > >
    >      >
    >     ------------------------------------------------------------------------
    >      > > Notice: This e-mail together with any attachments may contain
    >      > > information of Ribbon Communications Inc. that is confidential
    >      > and/or
    >      > > proprietary for the sole use of the intended recipient. Any review,
    >      > > disclosure, reliance or distribution by others or forwarding
    >     without
    >      > > express permission is strictly prohibited. If you are not the
    >      > intended
    >      > > recipient, please notify the sender immediately and then delete all
    >      > > copies, including any attachments.
    >      > >
    >      >
    >     ------------------------------------------------------------------------
    >      > >
    >      > > _______________________________________________
    >      > > spring mailing list
    >      > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >      > >
    >      >
    >      > _______________________________________________
    >      > spring mailing list
    >      > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >      >
    >
    >     _______________________________________________
    >     spring mailing list
    >     spring@ietf.org <mailto:spring@ietf.org>
    >     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >    
    > <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=https%3A%
    > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
    > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu
    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >
    >
    >
    > ----------------------------------------------------------------------
    > --
    > Notice: This e-mail together with any attachments may contain
    > information of Ribbon Communications Inc. that is confidential and/or
    > proprietary for the sole use of the intended recipient. Any review,
    > disclosure, reliance or distribution by others or forwarding without
    > express permission is strictly prohibited. If you are not the intended
    > recipient, please notify the sender immediately and then delete all
    > copies, including any attachments.
    > ----------------------------------------------------------------------
    > --

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

     

     

    Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

     


    _______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

    --------------3C8CB6A8A5DE048843B56172-- From nobody Tue Aug 18 08:44:45 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7730F3A0DC6 for ; Tue, 18 Aug 2020 08:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 xH_AqXy3XdVL for ; Tue, 18 Aug 2020 08:44:37 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284613A0DC3 for ; Tue, 18 Aug 2020 08:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1597765475; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tNxAdr/AbqQc9E7DZ3sMKgn9Q6ASpkYXJyhmxp6u+YE=; b=Ze4AdvbGVXvU7ZrSCZjQ/Gb97+iI2mSFFeZGPgMBsY+x/ZlGgLRp4DbivfRkLOkKdfNVfA CYYA0973Cqk9zj/wZtS8Gt2uXubuorH1e+Rp8z0OtF17Q/m+WqPqpdrGgPFn9KwfPASju9 xCPdC6odpWkuczYvsjtQD/cXun+SV80= Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-38-LnjXguOdNLi993Ggq0ns-g-1; Tue, 18 Aug 2020 11:44:29 -0400 X-MC-Unique: LnjXguOdNLi993Ggq0ns-g-1 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (104.47.2.50) by AZWPVEXEdge02.ecitele.com (10.0.2.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Tue, 18 Aug 2020 18:44:27 +0300 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR0302MB3236.eurprd03.prod.outlook.com (2603:10a6:208:8::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Tue, 18 Aug 2020 15:44:25 +0000 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1]) by AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1%6]) with mapi id 15.20.3283.027; Tue, 18 Aug 2020 15:44:25 +0000 From: Alexander Vainshtein To: Martin Horneffer CC: Robert Raszuk , "EXT-Andrew.Alston@liquidtelecom.com" , Shraddha Hegde , "Ketan Talaulikar (ketant)" , "Joel M. Halpern" , "spring@ietf.org" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JCAAMsLAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAD7UQgAB6ewCAD4ZhAIAAC+KLgAALZwCAABX95oAADfeAgAAC7gCAAAmbgIAAFWyAgAADZQCABhhmgIAACWPQ Date: Tue, 18 Aug 2020 15:44:25 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> In-Reply-To: <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.183.63.9] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 41660d20-3239-43d7-2c76-08d8438d9598 x-ms-traffictypediagnostic: AM0PR0302MB3236: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aLXkQd857dfl8basuWknNSlwBHzFoz2uxkTu33btKd+jbgOaO4uZtd+kBA6+ucNBpBnR9pAfqalYs3P8w5fg9KRvXus8+MhVPbZDgBoqcOYZxs8JEVgTmA05W4SCBmOZEBGqB70uvSvbrq8lzsZdyUjBBoGC+K0sJIySlrfTCZ0BW02bAOZBy6D0E2pV0Pk3tZJChhpdOsAlh2b1hHotuu7Cq0LqxEwIAIcp70bxKX6jqnRCf7Rv2X1Px/o+zKaRfUYEQTpP7kGIiTmAAXTwVapNZe2gW0329CAhddWjo1YduA7JbOKSluWqcYuuq41vHhClxwkvHgOxyeuduFrB5s0jGZko9iINESNxum+hEjMQ6hwBF9fB1DyOrHJXjex5TvDK/7bzJGAwog84vifMGw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4499.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39860400002)(376002)(396003)(346002)(76116006)(66946007)(54906003)(478600001)(33656002)(86362001)(55016002)(316002)(4326008)(52536014)(83380400001)(166002)(9686003)(53546011)(6506007)(66446008)(64756008)(66556008)(66476007)(6916009)(7696005)(30864003)(186003)(2906002)(5660300002)(45080400002)(26005)(8676002)(71200400001)(8936002)(966005)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 1r8Ah697cVqqWsmReRg6iGhALduSxSkrgPq42GQKgqb5nUJa7F32u5E1bU+DeFmC+hv740Gzhhvjt7yNhggUuP2rGWSkvvxVkvmDw0fMASQjy3qP2HI3wgh8Ew2WvwxAsPYesY2JcfRO5wiIpBupgBr3o82l5hZOEm+ujkV2QpBI8DqXCHsdxxA3Ud3Ij7hU0ga9yBQuB8OyD4qp8q0YyN+NkniMdKjWbj8aocl0+ym8AxCge8BM4YtXDSvKwbFAPICy+y4yHZ2vDM0GFupNK3jXc3AP5ULXDmxCzJrcqfT5dD1NmFJWbNBnmT6xUk+wmtojEaG8YB82p1ZcZ2ccSHq5HPXuhB+wFxeAt0VwE0BHL5K0EEpam3fhDXujRUw2s4Gj8cTCy7kdkgtedZrFlV6tCRJpdij9RdngEOK+b3TF9wP1fVgtVlsanNWRvpw7D2vVOXHxLNL1WRBbAiRRy5XHqDVgNxvJUQCyV7dF8wM4boMC4dS6C0+HNJ4d6GTzSi4h4t426m53k/plUZS3hIhGukmpPXX7JaU1cNywf+e4AJ6auj4T1MJiCkVueL1BL/aiShtz81Bo5fO4ix0nXXIYcCEET26nmcc0HAC/EY4kOn8U/RQxJeZb7nx181Av05Wp2fz1PAJ3rhHkUvJfTw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4499.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41660d20-3239-43d7-2c76-08d8438d9598 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 15:44:25.0773 (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-CrossTenant-userprincipalname: hwKpYVJCKfLD7W8d/dNH5iAtcpm79zy4y3nnHO8/N9W6F3FLJa91zqwiZ22a11DQL2QwrDWnEuWaGxkKYqSdzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3236 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA81A106 smtp.mailfrom=alexander.vainshtein@rbbn.com X-Mimecast-Spam-Score: 0.004 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_AM0PR03MB449963FAF42D748F7FD7F2E09D5C0AM0PR03MB4499eurp_" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 15:44:44 -0000 --_000_AM0PR03MB449963FAF42D748F7FD7F2E09D5C0AM0PR03MB4499eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TWFydGluLA0KTG90cyBvZiB0aGFua3MgZm9yIGFuIGltcG9ydGFudCBpbnB1dCB0byB0aGlzIGRp c2N1c3Npb24uDQoNCkkgZnVsbHkgYWdyZWUgd2l0aCB5b3UgdGhhdCBhYmlsaXR5IHRvIHR1cm4g b2ZmIHRoZSBub2RlIHByb3RlY3Rpb24gc2NoZW1lIGZvciBhIHNwZWNpZmljIFBMUiBuZWlnaGJv ciAoaS5lLiwgb24gYSBzcGVjaWZpYyBQTFIgcG9ydCkgYnkgc3VpdGFibGUgbG9jYWwgY29uZmln dXJhdGlvbiBpbiB0aGUgUExSIGlzIGRlZmluaXRlbHkgcmVxdWlyZWQuIFN1Y2ggYW4gYWJpbGl0 eSB3b3VsZCBwcm9iYWJseSBhZGRyZXNzIG1vc3QgKGlmIG5vdCBhbGwpIHNjZW5hcmlvcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIHNvLWNhbGxlZCDigJxzZXJ2aWNlIG5vZGVz4oCdIHRoYXQgY2Fubm90 IGJlIGJ5cGFzc2VkLg0KDQpJIGFsc28gdGhpbmsgdGhhdCBzZXJ2aWNlIG5vZGVzIHRoYXQgY2Fu bm90IGJlIGJ5cGFzc2VkIHR5cGljYWxseSB3b3VsZCBhZHZlcnRpc2UgdGhlbXNlbHZlcyBhcyDi gJxzdHViIG5vZGVz4oCdIGluIElHUCBpbiBvcmRlciB0byBwcmV2ZW50IGluYWR2ZXJ0ZW50IGFw cGxpY2F0aW9uIG9mIHRoZWlyIHNlcnZpY2UgZnVuY3Rpb24gdG8gdHJhbnNpdCB0cmFmZmljICh3 aGljaCBjb3VsZCBvdGhlcndpc2UgcGFzcyB0aHJ1IHRoZSBzZXJ2aWNlIG5vZGUgZHVlIHRvIHNv bWUgdG9wb2xvZ3kgY2hhbmdlKS4gVGhlcmVmb3JlIGEgbG9jYWwgcG9saWN5IHRoYXQgd291bGQg ZXhjbHVkZSBJR1AgbmVpZ2hib3JzIGFkdmVydGlzaW5nICB0aGVtc2VsdmVzIGFzIHN0dWIgbm9k ZXMgaW4gSUdQIGZyb20gdGhlIG5vZGUgcHJvdGVjdGlvbiBzY2hlbWUgY291bGQgYmUgYWxzbyB1 c2VmdWwuDQoNCkxhc3QgYnV0IG5vdCBsZWFzdCwgYWJpbGl0eSBvZiB0aGUgbm9kZSB0byBhZHZl cnRpc2UgYSBzcGVjaWZpYyBQcmVmaXggU0lEIGl0IG9yaWdpbmF0ZXMgYXMg4oCcbm90IGVsaWdp YmxlIGZvciBieXBhc3MgcHJvdGVjdGlvbuKAnSAoZS5nLiwgdXNpbmcgYSBuZXcgZmxhZyBpbiB0 aGUgUHJlZml4IE5vZGUgVExWIGZvciBJUy1JUyBvciBPU1BGKSBzaG91bGQgYmUgY29uc2lkZXJl ZC4NCg0KTXkgMmMsDQpTYXNoYQ0KDQpPZmZpY2U6ICs5NzItMzkyNjYzMDINCkNlbGw6ICAgICAg Kzk3Mi01NDkyNjYzMDINCkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t DQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBN YXJ0aW4gSG9ybmVmZmVyDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTgsIDIwMjAgNTo1MSBQTQ0K VG86IHNwcmluZ0BpZXRmLm9yZw0KQ2M6IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIu VmFpbnNodGVpbkByYmJuLmNvbT47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pjsg RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20gPEFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb20+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFAanVuaXBlci5uZXQ+OyBLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+ OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+DQpTdWJqZWN0OiBSZTogW3Nw cmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCkEg ZmV3IHRob3VnaHRzIGZyb20gbXkgKG9wZXJhdG9yJ3MpIFBvVjoNCg0KIC0gVGhlIGRpc3Vzc2lv biBpcyBhIHZlcnkgZ29vZCBhbmQgaW1wb3J0YW50IG9uZS4gSXQgcHJvYmFibHkgc2hvdWxkIGJl IGRpc2N1c3NlZCBhbmQgZG9jdW1lbnRlZCB3ZWxsIGluIG9yZGVyIHRvIGp1c3RpZnkgdGhlIHBy b3Bvc2VkIHByb3RlY3Rpb25zIG1lY2hhbmlzbXMuDQoNCiAtIE5vdCBhbGwgb3BlcmF0b3JzIHNl ZW0gdG8gaGF2ZSB0aGUgc2FtZSByZXF1aXJlbWVudHMuDQogICAgKEEgc29tZXdoYXQgc2ltaWxh ciBkaXNjdXNzaW9uIG1pZ2h0IGJlIHRoZSBvbmUgZm9yIGRpc2pvaW50IHBhdGhzLiBUaG9zZSBh cmUgb2Z0ZW4gZXF1aXJlZCBieSB2b2ljZSBzaWduYWxsaW5nIGFwcGxpY2F0aW9ucy4gSW4gc29t ZSBjYXNlcyB0aGUgdm9pY2Ugc2VydmljZSBkZW1hbmRzIHRoYXQgdHJhZmZpYyBpcyBibGFja2hv bGVkIHJhdGhlciB0aGFuIG9uIGZvcndhcmRlZCBvbiB0aGUgd3JvbmcgcGF0aC4gSW4gb3RoZXIg Y2FzZXMgZGlzam9pbnQgcGF0aHMgYXJlIGp1c3QgcmVxdWlyZWQgZm9yIHRoZSAiZ29vZCBjYXNl Ii4gVHJhZmZpYyBNQVkgYmUgZm9yd2FyZGVkIG9uIHRoZSB3cm9uZyBwYXRoLCBhcyBsb25nIGFz IHRoZSBuZXR3b3JrIGp1c3QgbWFrZXMgc3VyZSB0aGUgdHJhZmZpYyBvbiB0aGUgb3RoZXIgcGF0 aCBpcyBuZXZlciBhZmZlY3RlZCBieSB0aGUgc2FtZSBmYWlsdXJlLikNCg0KIC0gUGVyc29uYWxs eSBJIHdvdWxkIGhhdGUgdG8gc2VlIHlldCBhbm90aGVyIElHUCBleHRlbnNpb24gZm9yIHRoaXMg cHVycG9zZS4NCg0KIC0gSSB3b3VsZCByYXRoZXIgcHJlZmVyIGEgZ29vZCBkaXNjdXNzaW9uIG9m IHdoYXQgY2FuIGJlIGFjaGlldmVkIGJ5IHVzaW5nIGVhc3kgdG8gbWFrZSBzd2l0Y2hlczoNCiAg ICAtIFRoZSBwcm90ZWN0aW9uIGJlaGF2aW91ciBjb3VsZCBiZSBzd2l0Y2hlZCBvbiBvciBvZmYg cGVyIG5vZGUuDQogICAgICAgLSBBbiBvcGVyYXRvciB3aXRoIHN0cmljdCAic29tZSB0cmFmZmlj IG1heSBuZXZlciB0b3VjaCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBuZXR3b3JrIiByZXF1aXJlbWVu dHMgbWlnaHQgc3dpdGNoIG9mZiB0aGUgYmVoYXZpb3VyLCB3aGlsZSBvdGhlcnMgbWlnaHQgc3dp dGNoIGl0IG9uLg0KICAgIC0gQSBub2RlIGNvdWxkIGFsbG93IGEgc3dpdGNoIGV2ZW4gaW5kaXZp ZHVhbGx5IGZvciBldmVyeSBwb3J0IG9yIG5laWdoYm9yLg0KICAgICAgIC0gSWYgYSBub2RlIGtu b3dzIHRoYXQgb25lIG9mIGl0J3MgbmVpZ2hib3VycyBpcyBhIHNlcnZpY2Ugbm9kZSByYXRoZXIg dGhhbiBhIHBsYWluIHRvcG9sb2dpY2FsIG9uZSwgaXQgY291bGQgc3dpdGNoIG9mZiBwcm90ZWN0 aW9uLiBUaGlzIGlzIGhvdyBJIHdvdWxkIHByZWZlciB0byBzb2x2ZSB0aGUgcHJvYmxlbSB3aXRo IHNlcnJ2aWNlIG5vZGVzLg0KDQpTaG91bGQgdGhpcyBiZSBkaXNjdXNzZWQgaW4gdGhlIHByb3Rl Y3Rpb24gZG9jdW1lbnQsIG9yIGluIGEgc2VwYXJhdGUgb25lPw0KDQpCZXN0IHJlZ2FyZHMsIE1h cnRpbg0KDQpBbSAxNC4wOC4yMCB1bSAxOTo0NSBzY2hyaWViIEtldGFuIFRhbGF1bGlrYXIgKGtl dGFudCk6DQpIaSBSb2JlcnQsDQoNCldlIGRvIG5vdCBoYXZlIGEgc2lnbmFsbGluZyBtZWNoYW5p c20gaW4gSUdQcyB0b2RheSB0byBpbmRpY2F0ZSBhIOKAnGJ5cGFzcy1hYmxl4oCdIGluZGljYXRp b24gZm9yIFByZWZpeCBTSURzLiBJZiB0aGVyZSB3YXMgYSBkZXNpcmUgZm9yIGl0LCBhbiBJR1Ag ZXh0ZW5zaW9uIHdvdWxkIGJlIHJlcXVpcmVkICh0aGVyZSBpcyBub25lIGluIHByb2dyZXNzIEFG QUlLKS4gTm90ZSB0aGF0IHRoaXMgcmVzdWx0cyBpbiBkb3VibGluZyB0aGUgcHJlZml4IFNJRCBz Y2FsZSAoZ2xvYmFsIGxhYmVscykgaW4gdGhlIG5ldHdvcmsuIFNvIEkgd291bGQgbm90IGdvIGFi b3V0IHRoaXMgdHJpdmlhbGx5Lg0KDQpJIHRoaW5rIGl0IGhlbHBzIHRvIGdldCBtb3JlIGlucHV0 cyBhbmQgcGVyc3BlY3RpdmVzIGZyb20gb3BlcmF0b3JzIG9uIHRoZWlyIHZpZXdzIGZvciBkb2lu ZyBhIGJ5cGFzcyB2aWEgbG9jYWwgcHJvdGVjdGlvbiBmb3Igc2VnbWVudHMgaW4gYW4gU1IgUG9s aWN5LiBUaGVyZSBtYXkgYmUgdGhvc2UgdGhhdCBwcmVmZXIgZW5kLXRvLWVuZCBwYXRoIHByb3Rl Y3Rpb24gdXNpbmcgYSBmYWxsYmFjayBwYXRoIHRoYXQgaXMgc2F5IGRpc2pvaW50IHdpdGggdGhl IHByaW1hcnkgYnV0IHByb3ZpZGVzIGFuIGFwcHJvcHJpYXRlIFNMQS9pbnRlbnQ/DQoNClRoYW5r cywNCktldGFuDQoNCkZyb206IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PjxtYWls dG86cm9iZXJ0QHJhc3p1ay5uZXQ+DQpTZW50OiAxNCBBdWd1c3QgMjAyMCAyMzowNA0KVG86IEtl dGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb20+PG1haWx0bzprZXRhbnRA Y2lzY28uY29tPg0KQ2M6IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVp bkByYmJuLmNvbT48bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPjsgSm9lbCBN LiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bT47IFNocmFkZGhhIEhlZ2RlIDxzaHJhZGRoYUBqdW5pcGVyLm5ldD48bWFpbHRvOnNocmFkZGhh QGp1bmlwZXIubmV0PjsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRv OkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPiA8QW5kcmV3LkFsc3RvbkBsaXF1 aWR0ZWxlY29tLmNvbT48bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+OyBz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3By aW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KS2V0 YW4sDQoNCkxvb2tzIGxpa2Ugd2UgYXJlIHByZXR0eSBtdWNoIGluIHN5bmMgaGVyZS4NCg0KQnV0 IGxldCBtZSBqdXN0IG9ic2VydmUgdGhhdCBJIHB1cnBvc2VseSBkaWQgbm90IG1lbnRpb24gYWJv dXQgU1IgcG9saWNpZXMgYXMgd2UgYXJlIG5vdCBhYmxlIHRvIHNpZ25hbCB0aGUgaW50ZW50IHdp dGggdGhlIHBhY2tldHMgaXRzZWxmLg0KDQpTbyBhbGwgd2UgaGF2ZSB0aGVyZSBpcyBTSURzLiBC U0lEcyBvciBwcmVmaXggU0lEcyBuZWVkIHRvIGJlIGZsb29kZWQgd2l0aCBpbmZvcm1hdGlvbiBp ZiBwb2xpY2llcyBidWlsZCB3aXRoIHVzaW5nIHRoZW0gYXJlIGJ5cGFzcyBlbGlnaWJsZSBvciBu b3QuDQoNCkkgd2FzIGFjdHVhbGx5IHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhpcyBpcyBh bHJlYWR5IHRoZXJlIGFuZCBJIGFtIGp1c3Qgbm90IGF3YXJlLCBidXQgbG9va2luZyBkZWVwZXIg aW5kZWVkIEkgZG8gbm90IHNlZSB0aGlzIG1hcmtpbmcgbmVpdGhlciBpbiBJU0lTIG5vciBPU1BG IGZvciBwcmVmaXggU0lEcy4NCg0KSXMgdGhlcmUgc29tZSB3b3JrIGluIHByb2dyZXNzIHRvIGFk ZCBpdCB0byB0aG9zZSBwcm90b2NvbHMgb3IgaGF2ZSB3ZSBqdXN0IGRvY3VtZW50ZWQgbmVlZCBm b3IgYSBzaG9ydCBMU1IgZHJhZnQgID8NCg0KVGh4LA0KUi4NCg0KDQpPbiBGcmksIEF1ZyAxNCwg MjAyMCBhdCA2OjE3IFBNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5j b208bWFpbHRvOmtldGFudEBjaXNjby5jb20+PiB3cm90ZToNCkhpIFJvYmVydCwNCg0KUGxlYXNl IGNoZWNrIGlubGluZSBiZWxvdy4NCg0KRnJvbTogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1 ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NClNlbnQ6IDE0IEF1Z3VzdCAyMDIwIDIx OjEzDQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbTxtYWls dG86a2V0YW50QGNpc2NvLmNvbT4+DQpDYzogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRl ci5WYWluc2h0ZWluQHJiYm4uY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNv bT4+OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20+PjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PG1haWx0 bzpzaHJhZGRoYUBqdW5pcGVyLm5ldD4+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+IDxBbmRyZXcu QWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVj b20uY29tPj47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJp bGl0eQ0KDQpIaSBLZXRhbiwNCg0KV2hpbGUgSSBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91ciBu b3RlIHRoZSBjb25zZXF1ZW5jZXMgb2YgaXQgYXJlIHByZXR0eSBzZXZyZS4NCltLVF0gSSB1bmRl cnN0YW5kLiBXZSBuZWVkIHRvIGJlIG1pbmRmdWwgb2YgaW1wbGljYXRpb25zIG9mIHByb3RlY3Rp b24gc2NoZW1lcyBmb3IgdGhlIFNMQXMvaW50ZW50IG9mIFNSIFBvbGljaWVzLg0KDQpVbmxlc3Mg d2Ugc2lnbmFsIHdoaWNoIHByZWZpeCBTSUQgaXMgcHJvdGVjdGlvbiBlbGlnaWJsZSBhbmQgd2hp Y2ggaXMgbm90IGhvdyB3b3VsZCBvdGhlciBub2RlcyBrbm93IGlmIHRoZXkgY2FuIHByb3RlY3Qg aXQgb3Igbm90ID8NCltLVF0gQ29ycmVjdC4gVG8gYmUgbW9yZSBhY2N1cmF0ZSwgd2UgbmVlZCB0 byBjb25zaWRlciB0aGlzIG1vcmUgaW4gdGhlIGNvbnRleHQgb2YgU0xBIG9yIOKAnGludGVudOKA nSBvZiBTUiBQb2xpY2llcyBhbmQgd2hpY2ggc2VnbWVudHMgbWF5IGJlIOKAnGJ5cGFzcy1hYmxl 4oCdIGZvciBsb2NhbCBwcm90ZWN0aW9uIGZvciBzb21lIG9mIHRob3NlIFNSIFBvbGljaWVzLiBX ZSBhbHNvIGhhdmUgcGF0aC1wcm90ZWN0aW9uIG1lY2hhbmlzbXMuDQoNCkl0IHNlZW1zIHRoYXQg dG9kYXkncyBzYWZlIHRoaW5nIGlzIG5vdCB0byBhcHBseSBhbnkgbm9kZSBwcm90ZWN0aW9uIG9u IFNSIGZsb3dzIGF0IHRoZSBQTFJzIHRoZW4uDQoNCkFuZCBsaW5rIHByb3RlY3Rpb24gTVVTVCBh c3N1cmUgdGhhdCBwYWNrZXRzIHdpbGwgYXJyaXZlIGF0IHRoZSBuZWlnaGJvciBub2RlIHZpYSBz b21lIG90aGVyIGxpbmsgcmVnYXJkbGVzcyBvZiBmdXJ0aGVyIHBhdGggdG93YXJkcyBkZXN0aW5h dGlvbi4NCltLVF0gWWVzLiBXZSBoYXZlIGEgbWVjaGFuaXNtIHRvIGluZGljYXRlIHdoaWNoIGFk ai1TSURzIGhhdmUgcHJvdGVjdGlvbiAodGhhdCBtZWNoYW5pc20gb25seSBwcm92aWRlcyBsaW5r IHByb3RlY3Rpb24gdG8gZ2V0IHRvIHRoZSBuZWlnaGJvciBub2RlKSBzbyB0aGUgU1IgUG9saWN5 IGNvbXB1dGF0aW9uIGlzIGFibGUgdG8gaW5kaWNhdGUgd2hldGhlciB0aGF0IHNwZWNpZmljIGxp bmsgaXMg4oCcYnlwYXNzLWFibGXigJ0gb3Igbm90IGJ5IGl0cyBjaG9pY2Ugb2YgcHJvdGVjdGVk IG9yIHVucHJvdGVjdGVkIGFkai1TSURzIHJlc3BlY3RpdmVseS4NCg0KVGhhbmtzLA0KS2V0YW4N Cg0KSXMgaXQgY29ycmVjdCA/DQoNClRoeA0KUg0KDQpPbiBGcmksIEF1ZyAxNCwgMjAyMCBhdCA1 OjMyIFBNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb208bWFpbHRv OmtldGFudEBjaXNjby5jb20+PiB3cm90ZToNCkhpIFNhc2hhLA0KDQpUaGUgc2VydmljZSBub2Rl IGFkdmVydGlzZXMgaXRzIG93biBQcmVmaXggU0lELiBUaGUgc2VydmljZSBmdW5jdGlvbiB0aGF0 IHRoaXMgc2VydmljZSBub2RlIGltcGxlbWVudHMgZG9lcyBub3QgcmVxdWlyZSBhbnkgY29udGV4 dCAoaS5lLiBhbGwgcGFja2V0cyBhcnJpdmluZyBhdCB0aGUgbm9kZSBhcmUgc3ViamVjdGVkIHRv IHRoYXQgc2VydmljZSkuIFRoZXJlZm9yZSB0aGUgc2VydmljZSBub2RlIGRvZXMgbm90IG5lZWQg dG8gcmVjZWl2ZSBhIHBhY2tldCB3aXRoIGl04oCZcyBvd24gUHJlZml4IFNJRC4NCg0KVGh1cywg d2UgY2Fubm90IGFzc3VtZSB0aGF0IHdoZW4gUEhQIGlzIHVzZWQsIHRoZW4gdGhlIFNJRCBpcyBv bmx5IGFzc29jaWF0ZWQgd2l0aCBhIHRvcG9sb2dpY2FsIGluc3RydWN0aW9uLg0KDQpIb3BlIHRo YXQgY2xhcmlmaWVzPw0KDQpUaGFua3MsDQpLZXRhbg0KDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNo dGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQHJiYm4uY29tPj4NClNlbnQ6IDE0IEF1Z3VzdCAyMDIwIDIwOjI0DQpUbzogS2V0YW4g VGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2Nv LmNvbT4+OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20+PjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PG1h aWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldD4+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+IDxBbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPj47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2Jl cnRAcmFzenVrLm5ldD4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmlu ZyBhcHBsaWNhYmlsaXR5DQoNCktldGFuLCBhbmQgYWxsLA0KSSBoYXZlIHN0YXRlZCB0aGF0LCBJ TUhPIGFuZCBGV0lXLCBib3RoIEFkai1TSURzIGFuZCBQcmVmaXggU0lEcyB0aGF0IGFyZSBhZHZl cnRpc2VkIHdpdGggUEhQIGNhbiAgT05MWSByZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rp b25zIGluIFNSLU1QTFMgLSBiZWNhdXNlIHRoZSBhZHZlcnRpc2luZyBub2RlIHdpbGwgbm90IHJl Y2VpdmUgdGhlbSBhbmQgdGhlcmVmb3JlIGNhbiBoYXJkbHkgYmUgZXhwZWN0ZWQgdG8gYXNzb2Np YXRlIGFueSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGggdGhlbS4NCg0KVGhpcyBpcyBjb21wbGVtZW50 YXJ5IHRvIHdoYXQgeW91IGhhdmUgc2FpZC4NCg0KSG9wZSB0aGlzIGNsYXJpZmllcyBteSBwb3Np dGlvbi4NCldoYXQsIGlmIGFueXRoaW5nLCBkaWQgSSBtaXNzPw0KDQpSZWdhcmRzLA0KU2FzaGEN Cg0KR2V0IE91dGxvb2sgZm9yIEFuZHJvaWQ8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzMzR2k3enB0RHlScFJreDRSY0RwYlVDNkgyP3U9aHR0cHMlM0ElMkYlMkZha2EubXMlMkZnaGVp MzY+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBLZXRhbiBUYWxh dWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lzY28uY29t Pj4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNjoyMw0KVG86IEFsZXhhbmRlciBW YWluc2h0ZWluOyBKb2VsIE0uIEhhbHBlcm47IFNocmFkZGhhIEhlZ2RlOyBFWFQtQW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20+OyBSb2JlcnQgUmFzenVrDQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBk ZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpOT1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwgc2Vu ZGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpIaSBTYXNoYSwNCg0KSWYg dGhlIHNlcnZpY2UgZG9lcyBub3QgbmVlZCBhbnkgYWRkaXRpb25hbCBjb250ZXh0IChlLmcuIGEg ZmlyZXdhbGwgdGhhdCBqdXN0IGFwcGxpZXMgbG9jYWxseSBjb25maWd1cmVkIGRlZmF1bHQgcnVs ZXMgb24gaXQpLCB0aGVuIEkgZG9u4oCZdCBzZWUgd2h5IFBIUCBjb3VsZCBub3QgYmUgZG9uZSBm b3IgYSBQcmVmaXggU0lEIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2Ugbm9kZS4NCg0KQWxzbywg SSBkaWRu4oCZdCBmb2xsb3cgdGhlIHBvaW50IHRoYXQgeW91IHdlcmUgdHJ5aW5nIHRvIG1ha2Ug YWJvdXQgQWRqLVNJRHMuDQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IEFsZXhhbmRlciBWYWlu c2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbTxtYWlsdG86QWxleGFuZGVyLlZh aW5zaHRlaW5AcmJibi5jb20+Pg0KU2VudDogMTQgQXVndXN0IDIwMjAgMTg6MjQNClRvOiBLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lz Y28uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4+OyBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5z aHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPj47IFNo cmFkZGhhIEhlZ2RlIDxzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hyYWRkaGFAanVuaXBl ci5uZXQ+PjsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkVYVC1B bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbTxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+OyBSb2JlcnQg UmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KQ2M6 IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtz cHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KDQpI aSBhbGwsDQpSZWdhcmRpbmcgdGhlIHN0YXRlbWVudCAiUHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0 IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0 aGUgZmxvdyB0byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRv IGl0IjoNCg0KDQpJIHRoaW5rIHRoYXQgaW4gU1ItTVBMUyBhIE5vZGUgU0lEIHRoYXQgaXMgYWR2 ZXJ0aXNlZCB3aXRoIFBIUCBhY2l0b24gY2FuIGJlIHNhZmVseSBjb25zaWRlcmVkIGFzICJqdXN0 IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24iIGJ5IHRoZSBQTFIgYmVjYXVzZSB0aGUgb3JpZ2lu YXRpbmcgbm9kZSB3aWxsIG5vdCByZWNlaXZlIGl0Lg0KVGhlIHNhbWUgYXBwbGllcyB0byBBZGot U0RJcy4NCg0KTXkgMmMuDQoNCkdldCBPdXRsb29rIGZvciBBbmRyb2lkPGh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zNzVjNVlZQmVFYmFFWndVY0hwQ1kxbTZIMj91PWh0dHBzJTNBJTJG JTJGYWthLm1zJTJGZ2hlaTM2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0 YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzprZXRhbnQ9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTQsIDIwMjAsIDE1OjAwDQpU bzogSm9lbCBNLiBIYWxwZXJuOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgU2hyYWRkaGEgSGVnZGU7 IEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IFJvYmVydCBSYXN6dWsNCkNjOiBzcHJpbmdAaWV0Zi5v cmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcg cHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KSGkgQWxsLA0KDQpJIHdv dWxkIGxpa2UgdG8gc2hhcmUgYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUgb24gdGhpcy4NCg0KRmly c3QsIHRoYW5rcyB0byBKb2VsIGZvciBicmluZ2luZyB1cCB0aGUgZGlzY3Vzc2lvbi4gQ2xlYXJs eSB3ZSBuZWVkIGEgd2VsbC1kZWZpbmVkIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGZvciBkZXRl cm1pbmluZyBhcHBsaWNhYmlsaXR5IG9mIHByb3RlY3Rpb24gZm9yIHNlZ21lbnQgdXNlZCBpbiBh biBTUiBQb2xpY3kuIFNvbWUgb2YgdGhpcyBpcyBjYXB0dXJlZCBpbiBbMV0uDQoNClRoaXMgaXMg YWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkgbmF0dXJlLCB0aGUgUExS IGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICJzdHJpY3Qgb3Igbm90IiBpcyB0aGUgU0xB IHRoYXQgaXMgYmVpbmcgcHJvdmlkZWQgYnkgdGhlIFNSIFBvbGljeS4gQXdhcmVuZXNzIG9mIHRo YXQgbm90aW9uIGV4aXN0cyBhdCB0aGUgU1IgUG9saWN5IGhlYWRlbmQgYW5kL29yIGNvbXB1dGF0 aW9uLW5vZGUuDQoNCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0ZWQgdmFyaWFudHMg b2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0byBwaWNrIG9yIHRo ZSBvdGhlciBiYXNlZCBvbiB0aGUgInN0cmljdG5lc3MiIG9mIHRoZSBTTEEgcmVxdWlyZW1lbnQg Zm9yIHBpY2tpbmcgdGhhdCBsaW5rLiBXZSBkbyBub3QgaGF2ZSBzdWNoIGEgbm90aW9uIGZvciBQ cmVmaXggU0lEcy4gT25lIGNhbiBzYXkgdGhhdCB3ZSBjb3VsZCBpbnRyb2R1Y2Ugc2lnbmFsbGlu ZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFByZWZpeCBTSUQgY2FuIGJl IGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHRoZSBj b21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3IgZGVwZW5kaW5nIG9uIHRo ZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS4NCg0KSSBoYXZlIGEgcHJvYmxl bSBhbmQgYSBjb25jZXJuIGluIHRoZSBhc3N1bXB0aW9uIHRoYXQgUExScyBjYW4gYXNzdW1lIHRo YXQgdGhlIGN1cnJlbnRseSBkZWZpbmVkIHZhcmlhbnQgb2YgUHJlZml4IFNJRHMgaW4gUkZDODQw MiAoYW5kIElHUCBzcGVjcykgYXJlICJieXBhc3MtYWJsZSIuDQoNCkFzIEpvZWwgYW5kIG90aGVy cyBoYXZlIGJyb3VnaHQgb3V0LCB0aGUgUHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0IGEgdG9wb2xv Z2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0aGUgZmxvdyB0 byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGl0LiBJbiBv cmRlciB0byBzdXBwb3J0IGEgbWl4IG9mIFNSIFBvbGljaWVzIG9mIGRpZmZlcmVudCBTTEFzIChz dHJpY3QgYW5kIG5vdC1zdHJpY3QpLCB3ZSBuZWVkIHRvIGVuYWJsZSB0aGUgY2hvaWNlIG9mIFNJ RHMgdGhhdCBpbmRpY2F0ZXMgdG8gdGhlIFBMUiB3aGV0aGVyIHRoZXkgYXJlICJieXBhc3MtYWJs ZSIgb3Igbm90Lg0KDQpGb3IgdGhlIGNhc2VzLCB3aGVyZSB0aGUgU1IgUG9saWN5IGhhcyBhIHNw ZWNpZmljIFNMQSwgaXQgaXMgcmVxdWlyZWQgZm9yIG5vZGVzIHRvIGRyb3AgdGhlIHBhY2tldHMg bWVhbnQgZm9yIHRoZSAiYWN0aXZlIHNlZ21lbnQiIHRoYW4gdG8gYnlwYXNzIGl0LiBXaGVuIHRo aXMgbWVjaGFuaXNtIGlzIHVzZWQgYWxvbmcgc2lkZSBTUlRFIHBhdGggbW9uaXRvcmluZyBtZWNo YW5pc21zLCBpdCBlbmFibGVzIHRoZSBoZWFkZW5kIHRvIGRldGVjdCB0aGUgZmFpbHVyZSBhbmQg ZmFsbGJhY2sgdG8gYW4gYWx0ZXJuYXRlIHBhdGggdXNpbmcgdGhlIHBhdGggcHJvdGVjdGlvbiBh cHByb2FjaC4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyBkZXNjcmliZWQgYW5kIGluIHVzZSBp biBkZXBsb3ltZW50cyB0b2RheSBbMV0uLg0KDQpUaGFua3MsDQpLZXRhbg0KDQpbMV0gaHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1zNkgyP3U9aHR0 cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05DQpbMl0gaHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzM2ZkNNcmdtRWV3QzRhNEFKUnJtbjdINkgyP3U9aHR0cHMlM0ElMkYlMkZ0 b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5LTA4JTIzc2VjdGlvbi05LjMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogMDQgQXVndXN0 IDIwMjAgMjA6MjUNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRl aW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPj47IFNocmFk ZGhhIEhlZ2RlIDxzaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzpz aHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPj47IEVYVC1BbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8 bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNClRoZXJlIGFyZSwgYXMgZmFy IGFzIEkgY2FuIHRlbGwsIGEgbnVtYmVyIG9mIHdheXMgdG8gYWRkcmVzcyB0aGlzIGZhbWlseSBv ZiByZWxhdGVkIHF1ZXN0aW9ucy4NCldoYXQgc3RydWNrIG1lLCBhbmQgcHJvbXB0ZWQgdGhlIHN0 YXJ0aW5nIHF1ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2VyZSBzcGVsbGVkIG91dC4g IEkgc2VlIGxvdHMgb2YgaW50ZXJlc3RpbmcgaWRlYXMgLyBwcm9wb3NhbHMuDQpTb21lIG9mIHRo ZW0gYXJlIGNvbXBhdGlibGUgd2l0aCBvdGhlcnMuICAgU29tZSBhcmUgbm90Lg0KSXQgd291bGQg YmUgZ29vZCBpZiB3ZSBjb3VsZCByZWFjaCBhZ3JlZW1lbnQgb24gaG93IHdlIHRob3VnaHQgaXQg c2hvdWxkIGJlIGhhbmRsZWQuDQoNClRoYW5rIHlvdSwNCkpvZWwNCg0KT24gOC80LzIwMjAgMzo1 NCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+IEhpIGFsbCwNCj4NCj4gSSBhbSBz dGlsbCBub3Qgc3VyZSB0aGF0IHRoZSBwcm9ibGVtIG9mIGJ5cGFzcyBnb2luZyB0aHJ1IHVuZGVz aXJhYmxlDQo+IGxpbmtzL25vZGVzIGV4aXN0cyBpbiB0aGUgY2FzZSBvZiB0b3BvbG9naWNhbCBT SURzLg0KPg0KPiBBRkFJSywgRmFjaWxpdHkgUHJvdGVjdGlvbiBpbiBSU1ZQLVRFIEZSUiAoUkZD IDQwOTANCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTkya25FOVhKdWpyZjhC azdvSnZzNkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM0MDkw PikgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IGRlcGxveWVkDQo+IGZvciBtYW55IHllYXJzIGJlZm9y ZSBTUi1NUExTIGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTigJlzIG1vcmUsDQo+IHNpZ25hbGlu ZyBvZiBieXBhc3MgdHVubmVscyBoZSBQTFIgdXN1YWxseSBkaWQgbm90IGluY2x1ZGUgYW55IG9m IHRoZQ0KPiBjb25zdHJhaW50cyB1c2VkIGZvciBjb21wdXRpbmcgb2YgYW55IHNwZWNpZmljIExT UCB0aGF0IHRoZSBieXBhc3MgTFNQDQo+IHdvdWxkIHByb3RlY3Qg4oCTIGJlY2F1c2UgaW4gdGhl IEZhY2lsaXR5IFByb3RlY3Rpb24gbW9kZSB0aGUgc2FtZQ0KPiBieXBhc3MgTFNQIHdvdWxkIGJl IHVzZWQgdG8gcHJvdGVjdCBtdWx0aXBsZSBMU1BzIHBhc3NpbmcgdGhydSB0aGUNCj4gZmFpbGVk IGxpbmsvbm9kZS4NCj4NCj4gIEZyb20gbXkgUE9WIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2Vl biB0aGlzIGJlaGF2aW9yIGFuZCB0aGF0DQo+IGludHJvZHVjZWQgYnkgdGhlIOKAnGJ5cGFzc2lu Z+KAnSBkcmFmdHMgaW4gU1IgaXMgdGhhdCwgaW4gdGhlIGNhc2Ugb2YNCj4gUlNWUC1URSwgdGhl IG9wZXJhdG9yIHdvdWxkIGV4cGxpY2l0bHkgaW5kaWNhdGUsIGFzIHBhcnQgb2YgTFNQDQo+IHNp Z25hbGluZywgd2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBub3QgdXNlIEZSUjsgTFNQcyB0aGF0 IHdvdWxkIG5vdA0KPiB1c2UgRlJSIHdvdWxkIHRoZW4gZHJvcCB0cmFmZmljIHJhdGhlciB0aGFu IGRlbGl2ZXJpbmcgaXQgdGhlIHdyb25nIHdheS4NCj4NCj4gU3VjaCBhbiBvcHRpb24gaW5kZWVk IGRvZXMgbm90IGV4aXN0IGluIFNSLVRFIHRvZGF5LCBidXQgd291bGQgYmUgZWFzeQ0KPiB0byBw cm92aWRlIGlmIHNvIGRlc2lyZWQgSU1ITy4NCj4NCj4gRGlkIEkgbWlzcyBzb21ldGhpbmcgc3Vi c3RhbnRpYWw/DQo+DQo+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNlLA0K Pg0KPiBTYXNoYQ0KPg0KPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4NCj4gQ2VsbDogICAgICAr OTcyLTU0OTI2NjMwMg0KPg0KPiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+DQo+ICpGcm9t Oiogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpTaHJhZGRoYSBIZWdkZQ0KPiAqU2VudDoqIFR1ZXNk YXksIEF1Z3VzdCA0LCAyMDIwIDk6NDEgQU0NCj4gKlRvOiogRVhULUFuZHJldy5BbHN0b25AbGlx dWlkdGVsZWNvbS5jb208bWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29t Pg0KPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86QW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbT4+OyBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqQ2M6KiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPg0KPiBBbGwsDQo+ DQo+IFRoaXMgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIHRoYW5rcyB0byBK b2VsIGZvciBzdGFydGluZw0KPiB0aGlzIGRpc2N1c3Npb24uIElNTywgd2hlbiB0aGVyZSBhcmUg c3RyaWN0IHJlcXVpcmVtZW50cyBvZiBhdm9pZGluZw0KPiBjZXJ0YWluIG5vZGVzL2xpbmtzIGl0 IGNhbiBiZSByZWFsaXplZCAgZWl0aGVyIGJ5IGRlZmluaW5nIGEgZmxleC1hbGdvDQo+IGF2b2lk aW5nIHRob3NlDQo+DQo+IE5vZGVzIGFuZCBsaW5rcyBvciBieSB1c2luZyBhIHN0YWNrIG9mIHVu cHJvdGVjdGVkIGFkai1zaWRzIHRoYXQgYXZvaWQNCj4gcmVzdHJpY3RlZCBub2RlcyBhbmQgbGlu a3MuIFdoZW4gYSBzdGFjayBvZiBhZGotc2lkcyBpcyB1c2VkIHRvDQo+IHJlYWxpemUgdGhlIHBh dGgsIHRoZSBoZWFkLWVuZCBiYXNlZCAoc0JGRCkgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGNhbiBi ZSBhcHBsaWVkLg0KPg0KPiBJZiBOb2RlLXNpZHMvcHJlZml4LXNpZC9hbnljYXN0LXNpZHMgYXJl IHVzZWQgdG8gYnVpbGQgdGhlIHN0YWNrLCB0aGUNCj4gZmFpbHVyZSBldmVudHMgbWF5IGNhdXNl IHRyYWZmaWMgdG8gZ28gdGhyb3VnaCByZXN0cmljdGVkIG5vZGVzIGFuZA0KPiBsaW5rcy4gVGhp cyB3b3VsZCBoYXBwZW4gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFueSBraW5kIG9mIHByb3RlY3Rp b24NCj4gaXMgaW4gdXNlIG9yIG5vdC4NCj4NCj4gUmdkcw0KPg0KPiBTaHJhZGRoYQ0KPg0KPiBK dW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+DQo+ICpGcm9tOiogc3ByaW5nIDxzcHJpbmctYm91 bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUyMCUwYj4+IDxt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpBbmRyZXcgQWxz dG9uDQo+ICpTZW50OiogVHVlc2RheSwgQXVndXN0IDQsIDIwMjAgNTo0MSBBTQ0KPiAqVG86KiBS b2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+ IDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqQ2M6KiBzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBKb2VsIE0uIEhh bHBlcm4NCj4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+ IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6IFtzcHJpbmdd IFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPg0KPiAqW0V4 dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XSoNCj4NCj4gUm9iZXJ0IHRoaXMg aXMgYWN0dWFsbHkgZmFyIG1vcmUgZGlmZmljdWx0IHdoZW4g4oCTIGl0IGNhbiBiZSBhbiBlbnRp cmUNCj4gKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0IG5lZWQgdG8gYmUgYXZvaWRlZC4NCj4N Cj4gSXQgY291bGQgcG90ZW50aWFsbHkgYmUgbWFkZSB0byB3b3JrIGJ1dCBJ4oCZZCB3b3JyeSB0 aGF0IHRvIGRvIHRoaXMg4oCTDQo+IHlvdeKAmWQgaGF2ZSB0byBzdGFjayAxMCDigJMgMjAg4oCT IDMwIG5lZ2F0aXZlIGxhYmVscyDigJMgYW5kIHRoYXQgd291bGRu4oCZdA0KPiBiZSB2aWFibGUu DQo+DQo+IEl04oCZcyBlYXNpZXIgdG8gdXNlIGFsZ29yaXRobXMgYW5kIGFkamFjZW5jeSBzaWRz IGFuZCBvdGhlciBzdWNoIHRoaW5ncw0KPiB0byBjYWxjdWxhdGUgcGF0aHMg4oCTIHRoZSBiaWdn ZXN0IHRyaWNrIGlzIGFib3V0IHRoZSBzdGFjayBkZXB0aC4gIFdoZW4NCj4geW91IGhhdmUgdGhp cyBuZWVkIGZvciBub2RlIGF2b2lkYW5jZSDigJMgdGhlIG5lZWQgZm9yIDEwKyBsYWJlbCBkZXB0 aA0KPiBpcyBjcml0aWNhbCDigJMgdW5sZXNzIHlvdSB3YW5uYSBiZSBhcHBseWluZyBvbmUgaGVs bCBvZiBhIGxvdCBvZg0KPiBiaW5kaW5nIGxhYmVscyBhbG9uZyB0aGUgd2F5IHdoaWNoIGlzIGEg bmlnaHRtYXJlLg0KPg0KPiBCdXQgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGlzIHRoaXMgYSBj b21tb24gdXNlIGNhc2Ug4oCTIGl04oCZcyBhIHVzZQ0KPiBjYXNlIHRoYXQgbW9zdCBvZiB0aGUg cGVvcGxlIEkgZGlzY3VzcyB0aGlzIHdpdGggY2VydGFpbiBoYXZlIOKAkyBJIGNhbnQNCj4gY29t bWVudCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFueW9uZSBlbHNlLCBidXQgZXZlcnkgaW5k aWNhdGlvbiBJDQo+IGhhdmUgaXMgdGhhdCB5ZXMg4oCTIGl0cyBzb21ldGhpbmcgcGVvcGxlIG5l ZWQsIGFuZCB3YW50DQo+DQo+IEFuZHJldw0KPg0KPiAqRnJvbToqIFJvYmVydCBSYXN6dWsgPHJv YmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4gPG1haWx0bzpyb2JlcnRA cmFzenVrLm5ldD4+DQo+ICpTZW50OiogVHVlc2RheSwgNCBBdWd1c3QgMjAyMCAwMToyNw0KPiAq VG86KiBBbmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8bWFp bHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGI+PiA8bWFpbHRvOkFuZHJl dy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+Pg0KPiAqQ2M6KiBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20NCjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYj4+IDxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NCj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICpTdWJqZWN0OiogUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0K Pg0KPiBJcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNlIGllLiAgImJ1dCByYXRoZXIg4oCTIHdoaWNo IG5vZGVzIC8gbmV0d29yaw0KPiBzZWdtZW50cyBpdCBjYW4gbmV2ZXIgdG91Y2ggb3IgZmxvdyB0 aHJvdWdoLiINCj4NCj4gSWYgc28gcGVyaGFwcyBpdHMgdGltZSB0byBkZWZpbmUgbm90aW9uIG9m ICpuZWdhdGl2ZS1TSUQqIGllLiBsaXN0IGluDQo+IHRoZSBwYWNrZXQgcmVzb3VyY2VzIHdoaWNo IGdpdmVuIHBhY2tldCBNVVNUIG5vdCBldmVyIHRyYXZlcnNlLg0KPg0KPiBQdXQgaW4gdGhlIHBh Y2tldCBzZXQgb2Ygbm9kZXMgb3IgbGlua3Mgd2hpY2ggdGhlIHBhY2tldCBzaG91bGQgbmV2ZXIN Cj4gdHJhdmVyc2UuDQo+DQo+IFRoYXQgZ29lcyBpbiBsaW5lIG9mIHJlY2VudCB3YXZlIG9mIG5l Z2F0aXZlIHJvdXRpbmcgaW1wbGVtZW50YXRpb25zDQo+IChSSUZUKSBvciBkaXNjdXNzaW9ucyAo TFNSKQ0KPg0KPiBCZXN0LA0KPiBSLg0KPg0KPiBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDExOjQ2 IFBNIEFuZHJldyBBbHN0b24NCj4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20NCjxt YWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSUyMCUwYj4+IDxtYWlsdG86QW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+IHdyb3RlOg0KPg0KPiAgICAgU28g4oCTDQo+ DQo+ICAgICBPbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2ZXJ5IG1ham9yIHVz ZSBjYXNlcyBpbiBhbnkNCj4gICAgIHNwcmluZyB0ZWNobm9sb2d5IGZvciB1cyByZXZvbHZlIGFy b3VuZCB0aGUgZm9sbG93aW5nDQo+DQo+ICAgICBhLlRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2Yg Y2VydGFpbiBub2Rlcw0KPg0KPiAgICAgYi5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRh aW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdvcmsNCj4NCj4gICAgIEFueXRoaW5nIHRoYXQgY291bGQg cmVzdWx0IGluIHRoYXQgZXhwbGljaXQgYXZvaWRhbmNlIGJlaW5nIHZpb2xhdGVkDQo+ICAgICDi gJMgd291bGQgY3JlYXRlLCBzaGFsbCB3ZSBzYXkgc2lnbmlmaWNhbnQgcHJvYmxlbXMuDQo+DQo+ ICAgICBNdWNoIG9mIHRoZSB1c2UgY2FzZSBpcyBub3QgYSBjYXNlIG9mIHdoaWNoIG5vZGVzIHRo ZSBwYWNrZXRzIGZsb3cNCj4gICAgIHRocm91Z2gg4oCTIGJ1dCByYXRoZXIg4oCTIHdoaWNoIG5v ZGVzIC8gbmV0d29yayBzZWdtZW50cyBpdCBjYW4gbmV2ZXINCj4gICAgIHRvdWNoIG9yIGZsb3cg dGhyb3VnaC4gIEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9neSB0bw0KPiAg ICAgYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuDQo+DQo+ICAgICBU aGlzIGlzIGFsc28gb25lIG9mIHRoZSByZWFzb25zIGZvciBuZWVkaW5nIHN1Y2ggZGVlcCBsYWJl bCBzdGFja3Mg4oCTDQo+ICAgICB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgcGF0aCBwcm9ncmFtbWlu ZyB0ZW5kcyB0byBkZWVwZW4gdGhlIHN0YWNrDQo+ICAgICBiZWNhdXNlIHlvdSBzb21ldGltZXMg aGF2ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuDQo+DQo+ICAgICBJdCBpcyBhYnNvbHV0ZWx5IGNy aXRpY2FsIHRvIHVzIHRoYXQgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIHRoZXJlIOKAkw0KPiAgICAg YW5kIHRoYXQgd2UgY2FuIGF2b2lkIHNpdHVhdGlvbnMgd2hpY2ggY291bGQgY2F1c2UgdHJhZmZp YyB0bw0KPiAgICAgYWNjaWRlbnRseSBoaXQgdGhpbmdzIGV4cGxpY2l0bHkgYXZvaWRlZC4NCj4N Cj4gICAgIEkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgdGhhbiB0aGlzLCBidXQgaXQg aXMgd2hhdCBpdCBpcy4NCj4NCj4gICAgIFRoYW5rcw0KPg0KPiAgICAgQW5kcmV3DQo+DQo+ICAg ICAqRnJvbToqIHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxtYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y Zz4+ICpPbiBCZWhhbGYgT2YgKkpvZWwgTS4gSGFscGVybg0KPiAgICAgKlNlbnQ6KiBNb25kYXks IDMgQXVndXN0IDIwMjAgMjE6MzYNCj4gICAgICpUbzoqIFJvYmVydCBSYXN6dWsgPHJvYmVydEBy YXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4gPG1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldD4+DQo+ICAgICAqQ2M6KiBzcHJpbmdAaWV0Zi4ub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi4u b3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtzcHJp bmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcNCj4gYXBwbGljYWJpbGl0eQ0KPg0K PiAgICAgKFNpbmNlIHRoZSB0aHJlYWQgaGFzIGdvdHRlbiBsb25nIGVub3VnaCwgcmVpdGVyYXRp bmcgdGhhdCB0aGlzIGlzIGFzIGENCj4gICAgIHBhcnRpY2lwYW50LCBub3QgYSBXRyBjaGFpci4p DQo+DQo+ICAgICBZZXMsIHdlIGFyZSB0YWxraW5nIElQIG5ldHdvcmtzLiBBbmQgeWVzLCBJIGhh dmUgc2VlbiBJUCBuZXR3b3JrcyB0aGF0DQo+ICAgICBjaG9vc2UgdG8gZHJvcCBwYWNrZXRzLiBG b3IgYWxsIHNvcnRzIG9mIHJlYXNvbnMuDQo+ICAgICBJIHRoaW5rIHRoZXJlIGFyZSBsaWtlbHkg b3RoZXIgcmVhc29ucyB3aHkgb25lIG1heSBub3Qgd2FudCBhIHJhbmRvbQ0KPiAgICAgcGF0aCBy YXRoZXIgdGhhbiBhIGNob3NlbiBURSBwYXRoLiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB3ZSBi ZSBjbGVhcg0KPiAgICAgYWJvdXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlvbGF0 ZWQgd2hlbiB3ZSB0ZWxsIHBlb3BsZSB0aGV5DQo+ICAgICBoYXZlIHRoaXMgdG9vbCAocHJvdGVj dGl2ZSByZXJvdXRpbmcpIHRoYXQgaXMgaW50ZW5kZWQgdG8gcHJlc2VydmUgUW9TLg0KPg0KPiAg ICAgTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlzIGlzIG5vdCBhIGdv b2QgaWRlYS4gSXQgaXMgYQ0KPiAgICAgZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJIGFtIHRyeWlu ZyB0byBmaWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2YNCj4gICAgIGFkZGl0aW9uYWwgbWVj aGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVyeW9uZQ0KPiAg ICAgZ2V0dGluZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhl IGJlaGF2aW9yIHRoZXkNCj4gICAgIGRlc2lyZSwgYnV0IHNvbWV0aW1lcyBpcyB0aGUgYmVzdCB3 ZSBjYW4gZG8uKQ0KPg0KPiAgICAgWW91cnMsDQo+ICAgICBKb2VsDQo+DQo+ICAgICBPbiA4LzMv MjAyMCAyOjMwIFBNLCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KPiAgICAgID4gSm9lbCwNCj4gICAg ICA+DQo+ICAgICAgPiBBcmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JrcyBoZXJl ID8gT3IgcGVyaGFwcyBzb21lIGhhcmQNCj4gICAgICA+IHNsaWNpbmcgd2l0aCByZWFsIHJlc291 cmNlIHJlc2VydmF0aW9ucyBvciBkZXRuZXRzID8NCj4gICAgICA+DQo+ICAgICAgPiBCZWNhdXNl IGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtpbmcgSSBoYXZlIHR3bw0KPiAgICAg b2JzZXJ2YXRpb25zOg0KPiAgICAgID4NCj4gICAgICA+IEEpIElmIHlvdSBuZWVkIHRvIHRyYXZl cnNlIHZpYSBhIHNwZWNpZmljIG5vZGUgKGllLiBmaXJld2FsbCkgeW91DQo+ICAgICBiZXR0ZXIN Cj4gICAgICA+IGFwcGx5IElQIGVuY2Fwc3VsYXRpb24gdG8gdGhhdCBub2RlLi4gSSBkb24ndCB0 aGluayBJUA0KPiAgICAgZW5jYXBzdWxhdGlvbiBjYW4NCj4gICAgICA+IGJlIGhpamFja2VkIHRv ZGF5IHN1Y2ggdGhhdCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXMNCj4gICAg IGlnbm9yZWQuDQo+ICAgICAgPg0KPiAgICAgID4gQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0 d29yayB3aGVyZSB1cG9uIHRvcG9sb2d5IGNoYW5nZSAobGluaw0KPiAgICAgb3Igbm9kZQ0KPiAg ICAgID4gZmFpbHVyZSkgeW91IHN1ZGRlbmx5IHN0YXJ0IGRyb3BwaW5nIGZsb3dzIGluIHNwaXRl IG9mIFNQVCBvZmZlcmluZw0KPiAgICAgID4gcGVyaGFwcyBmZXcgbXMgbG9uZ2VyIHBhdGggd2l0 aCAxMCBtcyBtb3JlIGppdHRlciA/DQo+ICAgICAgPg0KPiAgICAgID4gT3IgYXJlIHNvbWUgU1Ig bWFya2V0aW5nIHNsaWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4NCj4gICAgICA+ IHNvbWV0aGluZyBuZXcgPyBXb3JzZSAuLi4gZG8gdGhleSBtZW50aW9uIHBhdGggcXVhbGl0eSBn dWFyYW50ZWVzLA0KPiAgICAgID4gcmVzb3VyY2UgcmVzZXJ2YXRpb25zID8gSSBob3BlIG5vdC4N Cj4gICAgICA+DQo+ICAgICAgPiBUaHgsDQo+ICAgICAgPiBSLg0KPiAgICAgID4NCj4gICAgICA+ DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAg ICA+DQo+ICAgICAgPg0KPiAgICAgID4gT24gTW9uLCBBdWcgMywgMjAyMCBhdCA4OjEwIFBNIEpv ZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tJTBiPj4gICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYj4+IDxtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KPiAgICAgID4NCj4gICAgICA+IFdlbGwg bGVzcyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRoZSBwcm9ibGVtIGlzDQo+ ICAgICByZXN0cmljdGVkDQo+ICAgICAgPiB0byBqdXN0IHNlcnZpY2UgU0lEcy4NCj4gICAgICA+ DQo+ICAgICAgPiBTdXBwb3NlIHRoYXQgdGhlIFBDRSBoYXMgc3BlY2lmaWVkIHRoZSBwYXRoIHRv IG1lZXQgc29tZSBjb21wbGV4IHRlDQo+ICAgICAgPiBvYmplY3RpdmUuICBUaGUgYnlwYXNzIG5v ZGUgaGFzIG5vIHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2UNCj4gICAgICA+IGNvbnN0cmFpbnRz DQo+ICAgICAgPiB3ZXJlLiAgQW5kIGZvciBzb21lIGtpbmRzIG9mIHRyYWZmaWMsIGl0IGlzIGJl dHRlciB0byBkcm9wIHRoZSBwYWNrZXQNCj4gICAgICA+IHRoYW4gdG8gZGVsaXZlciBpdCBvdXRz aWRlIHRoZSBlbnZlbG9wLiAgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0DQo+ICAgICAgPiBhbnN3 ZXINCj4gICAgICA+IHRvIHRoaXMgaXMgInRvbyBiYWQiLiAgSWYgc28sIGFzIHdpdGggdGhlIGRp c3RpbmN0aW9uIHJlZ2FyZGluZw0KPiAgICAgc2VydmljZQ0KPiAgICAgID4gbm9kZXMsIHdlIHNo b3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT8NCj4gICAgICA+DQo+ICAgICAgPiBZb3VycywNCj4g ICAgICA+IEpvZWwNCj4gICAgICA+DQo+ICAgICAgPiBPbiA4LzMvMjAyMCAyOjM2IEFNLCBBbGV4 YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gICAgICA+ID4gTWFjaCwgSm9lbCBhbmQgYWxsLA0K PiAgICAgID4gPg0KPiAgICAgID4gPiBJIHRoaW5rIHRoYXQgaW4gbW9zdCBjYXNlczoNCj4gICAg ICA+ID4NCj4gICAgICA+ID4gMS5UaGVyZSBpcyBjbGVhciBkaWZmZXJlbnRpYXRpb24gYmV0d2Vl biAidG9wb2xvZ2ljYWwiIGFuZA0KPiAgICAgInNlcnZpY2UiDQo+ICAgICAgPiA+IGluc3RydWN0 aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ IG9JR1AgUHJlZml4IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZpZWQgYXMgc3VjaCBp biB0aGUNCj4gICAgICA+ID4gY29ycmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMpIHJlcHJl c2VudCB0b3BvbG9naWNhbA0KPiAgICAgaW5zdHJ1Y3Rpb25zDQo+ICAgICAgPiA+DQo+ICAgICAg PiA+IG9TZXJ2aWNlIFNJRHMgZm9yIFNSdjYgKHNlZSBTUnY2IEJHUC1CYXNlZCBPdmVybGF5IFNl cnZpY2VzDQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zQ0NjeTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2Vy dmljZXMtMDQNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0NDY3k5bVk2Y01mYms3 UWZqaGlBM1I2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJG aHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0JTBiPj4gICAgIDxodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dDNWFmMnozSnpwaFpEa1BuY0hBUWk2SDI/dT1odHRw cyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIu aWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDRf XyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1 b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNFQtTDBubCUyND4+DQo+ICAgICAgPg0KPiAgICAgID4g PiBkcmFmdCkgdW5zdXJwcmlzaW5nbHkgcmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rp b25zDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9w b2xvZ2ljYWwgaW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCwNCj4gICAgICA+ID4gd2hpbGUg c2VnbWVudHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMgcmVxdWlyZQ0KPiAg ICAgID4gYWx0ZXJuYXRpdmUNCj4gICAgICA+ID4gcHJvdGVjdGlvbiBtZWNoYW5pc21zLg0KPiAg ICAgID4gPg0KPiAgICAgID4gPiBUaGlzIHZpZXcgc2VlbXMgdG8gYmUgYWxpZ25lZCB3aXRoIFJG QyA4NDAyDQo+ICAgICAgPiA+IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzQ1TkxD QjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRt bCUyRnJmYzg0MDINCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzQ1TkxDQjZUeWR4 dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJm Yzg0MDIlMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zN1B6VUtBRDgy Y2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9f aHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyX18lM0IlMjElMjFORXQ2 eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0 OEFrVFJEdWlEbzBJNFlidG0lMjQ+Pg0KPiAgICAgdGhhdCBzYXlzIGluIFNlY3Rpb24gMToNCj4g ICAgICA+ID4NCj4gICAgICA+ID4gICAgIEluIHRoZSBjb250ZXh0IG9mIGFuIElHUC1iYXNlZCBk aXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28NCj4gICAgICA+ID4NCj4gICAgICA+ID4gdG9w b2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNlZ21lbnQg YW5kIHRoZQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSUdQLVByZWZpeCBzZWdtZW50Lg0K PiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQg ZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwgdHdvDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IHRv cG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBh bmQgdGhlDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBCR1AtUHJlZml4IHNlZ21lbnQuDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMgdGhpcyBkaWZmZXJl bnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uDQo+ICAgICAgPiAzLjQgb2YNCj4gICAgICA+ ID4gdGhlIE5vZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aA0KPiAgICAgID4gPg0KPiAgICAg ID4NCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0piU1dHeDVEQWZOUHNa ZGhwRXh4eDk2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJG aHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBhdGhz LTA3JTIzc2VjdGlvbi0zLjQNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0piU1dH eDVEQWZOUHNaZGhwRXh4eDk2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNy LXRlLXBhdGhzLTA3JTIzc2VjdGlvbi0zLjQlMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zQ3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1w YXRocy0wNyUyQXNlY3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZ TkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNzbiUy ND4+DQo+ICAgICAgPg0KPiAgICAgID4gPiBkcmFmdCB0aGF0IHNheXM6DQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+ICAgICBUaGUgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4g dGhlIHByZXZpb3VzDQo+ICAgICBzZWN0aW9ucw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAg ZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBsYWJlbCBpbW1lZGlhdGVseSBiZWxv dw0KPiAgICAgID4gdGhlIHRvcA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBsYWJlbCBpbiB0aGUg bGFiZWwgc3RhY2sgaXMgdW5kZXJzdG9vZCBpbiB0aGUgSUdQIGRvbWFpbi4gIFdoZW4gdGhlDQo+ ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBwcm92aWRlciBlZGdlIHJvdXRlcnMgZXhjaGFuZ2Ug c2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBzb21lDQo+ICAgICAgPiBvdGhlcg0KPiAgICAgID4g Pg0KPiAgICAgID4gPiAgICAgbm9uLUlHUCBtZWNoYW5pc20gdGhlIGJvdHRvbSBsYWJlbCBpcyBu b3QgdW5kZXJzdG9vZCBpbiB0aGUgSUdQDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBkb21h aW4uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlv biBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQNCj4gICAgICA+ID4NCj4gICAgICA+ ID4gICAgIFtSRkM4Njc5IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0pmdnRCQW1h UVBOMWpBM3BNNlRkQ0U2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJG ZG9jJTJGaHRtbCUyRnJmYzg2NzkNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0pm dnRCQW1hUVBOMWpBM3BNNlRkQ0U2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRnJmYzg2NzklMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zNmRNQWp1WVRRb3ZvOGpId21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZyZmM4Njc5X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVf UjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQ+Pl0N Cj4gICAgIGlzDQo+ICAgICAgPiA+IGFwcGxpY2FibGUgdG8gdGhpcyB1c2UgY2FzZSBhbmQgbm8g YWRkaXRpb25hbCBjaGFuZ2VzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICB3aWxsIGJlIHJl cXVpcmVkIGZvciBTUiBiYXNlZCBuZXR3b3Jrcw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBUaGUg c2NlbmFyaW9zIGluIHdoaWNoICBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiDigJx0b3BvbG9naWNh bOKAnSBhbmQNCj4gICAgICA+ID4g4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnMgaXMgYnJva2Vu IGFyZSBpbmRlZWQgcHJvYmxlbWF0aWMuIEUuZy4sDQo+ICAgICAgPiBjb25zaWRlcg0KPiAgICAg ID4gPiB0aGUgdXNlIGNhc2UgaW4gd2hpY2ggYSBOb2RlIFNJRCBpbiB0aGUgRVJPIG9mIGEgU1It VEUgcGF0aA0KPiAgICAgID4gaWRlbnRpZmllcyBhDQo+ICAgICAgPiA+IG5vZGUgdGhhdCBhY3Rz IGFzIGEgZmlyZXdhbGwgZm9yIGFsbCBwYWNrZXRzIGl0IHJlY2VpdmVzLCBpLmUuLA0KPiAgICAg ID4gcHJvdmlkZXMNCj4gICAgICA+ID4gdGhlIGZpcmV3YWxsIHNlcnZpY2Ugd2l0aG91dCBhbnkg ZGVkaWNhdGVkIHNlcnZpY2UgU0lEDQo+ICAgICAgPiBpZGVudGlmeWluZyBpdC4NCj4gICAgICA+ ID4gT25lIGNvdWxkIHNheSB0aGF0IHRoZSBOb2RlIFNJRCBvZiBzdWNoIGEgbm9kZSB3b3VsZCBj b21iaW5lDQo+ICAgICAgPiB0b3BvbG9naWNhbA0KPiAgICAgID4gPiBhbmQgc2VydmljZSBpbnN0 cnVjdGlvbnMgdGh1cyBicmVha2luZyB0aGUgZGlmZmVyZW50aWF0aW9uDQo+ICAgICAgPiBiZXR3 ZWVuIHRoZSB0d28uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgYW0gbm90IHN1cmUgaWYgdXNh Z2Ugb2Ygc3VjaCDigJxjb21iaW5lZOKAnSBTSURzIGNvdWxkIGJlIHByZXZlbnRlZA0KPiAgICAg ID4gb3IgYXQNCj4gICAgICA+ID4gbGVhc3QgZGlzY291cmFnZWQuDQo+ICAgICAgPiA+DQo+ICAg ICAgPiA+IElmIG5vdCwgcHJvdmlkaW5nIGFuIGFiaWxpdHkgdG8gaWRlbnRpZnkgc3VjaCBTSURz IGluIHRoZQ0KPiAgICAgID4gYWR2ZXJ0aXNlbWVudA0KPiAgICAgID4gPiBtZWNoYW5pc21zIHdv dWxkIGJlIHVzZWZ1bCBJTUhPLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBNeSAyYywNCj4gICAg ICA+ID4NCj4gICAgICA+ID4gU2FzaGENCj4gICAgICA+ID4NCj4gICAgICA+ID4gT2ZmaWNlOiAr OTcyLTM5MjY2MzAyDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IENlbGw6ICAgICAgKzk3Mi01NDky NjYzMDINCj4gICAgICA+ID4NCj4gICAgICA+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4g ICAgIDxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICAgPiA8 bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgICAgID4gPiBGcm9tOiBzcHJp bmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnJTBiPj4gICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI+Pg0KPiAgICAg PG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNYWNoIENoZW4N Cj4gICAgICA+ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMwIEFNDQo+ICAgICAg PiA+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20NCjxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbSUwYj4+ICAgICA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMGI+ PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PjsNCj4gICAgIHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcg cHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4gICAgICA+ID4NCj4gICAg ICA+ID4gSGkgSm9lbCwNCj4gICAgICA+ID4NCj4gICAgICA+ID4gSSB0aGluayB0aGlzIGlzIGEg Z29vZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZQ0KPiAgICAgID4gcGFz dC4gQW5kDQo+ICAgICAgPiA+IEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSBpcyBhICJjYW4gYmUg YnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlDQo+ICAgICAgPiA+IHJvdXRpbmcgYWR2ZXJ0aXNl bWVudCBmb3Igbm93Lg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJTUhPLCB0aGUgaW5mb3JtYXRp b24gYWR2ZXJ0aXNlZCBieSByb3V0aW5nIGlzIG5ldXRyYWwsIHN1Y2gNCj4gICAgICA+IGluZm9y bWF0aW9uDQo+ICAgICAgPiA+IChjYW4gb3IgY2Fubm90IGJlIGJ5cGFzc2VkKSBpcyBtb3JlIHBh dGggc3BlY2lmaWMsIHRodXMNCj4gICAgIG5vcm1hbGx5IHRoZQ0KPiAgICAgID4gPiBjb250cm9s bGVyIHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBTSUQN Cj4gICAgICA+IGNhbiBiZQ0KPiAgICAgID4gPiBieXBhc3NlZC4NCj4gICAgICA+ID4NCj4gICAg ICA+ID4gQmVzdCByZWdhcmRzLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBNYWNoDQo+ICAgICAg PiA+DQo+ICAgICAgPiA+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+ICA+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgICA+IDxtYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnJTBiJTNlJTIwJTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTNlPl0NCj4gICAg IE9uIEJlaGFsZiBPZiBKb2VsIE0uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IEhhbHBlcm4N Cj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA3 OjUxIEFNDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFRvOiBzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnIDxt YWlsdG86c3ByaW5nQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0 bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2Nt YWlsdG86c3ByaW5nQGlldGYub3JnPj4+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFN1Ympl Y3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiAo V0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20gYSBzbGlnaHRseQ0K PiAgICAgID4gY29uZnVzZWQgV0cNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gcGFydGljaXBh bnQuKQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAg PiBJIGhhdmUgYmVlbiByZWFkaW5nIHRoZSB2YXJpb3VzIHJlcGFpciBkcmFmdHMsIGFuZCB0aGUg dmFyaW91cw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBuZXR3b3JrcyBwcm9ncmFtbWluZyBh bmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW0NCj4gICAgICA+IHRyeWluZyB0 bw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBmaWd1cmUgb3V0IG9uZSBhc3BlY3Qgb2YgdGhl IGNvbWJpbmF0aW9uLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgPiBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2YgYnlw YXNzIChzdXBwb3NlLCBmb3INCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gc2ltcGxpY2l0eSwg aXQgaXMgTm9kZSBOMiBkZWNpZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcg0KPiAgICAg ID4gYSBmYWlsZWQNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gbm9kZSBOMykga25vdyB0aGF0 IGl0IGlzIHNhZmUgdG8gZG8gc28/DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAg PiA+DQo+ICAgICAgPiA+ICA+IElmIHRoZSBwYXRoIHdhcyBqdXN0IGZvciBURSwgdGhlbiBpdCBp cyAic2FmZSIgaWYgdGhlIG5ldyBwYXRoDQo+ICAgICAgPiBtZWV0cw0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgPiB0aGUgVEUgY3JpdGVyaWEuICBvciBtYXliZSBpdCBpcyBzYWZlIGlmIGl0IGlz IGV2ZW4gY2xvc2UsIGFzDQo+ICAgICAgPiBsb25nIGFzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICA+IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy4NCj4gICAgICA+ID4NCj4gICAgICA+ID4g ID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gQnV0IHdoYXQgaWYgdGhlIG5vZGUgd2VyZSBh IEZpcmV3YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsDQo+ICAgICAgPiA+IHJlcXVpcmVtZW50 cz8NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5 IHByb2dyYW1tYXRpYyB0cmFuc2Zvcm0gKHdpbmNlIHdlIGFyZQ0KPiAgICAgID4gPg0KPiAgICAg ID4gPiAgPiBkZWxpYmVyYXRlbHkgdmFndWUgYWJvdXQgd2hhdCBub2RlcyBjYW4gZG8gd2hlbiBh c2tlZCBzdWl0YWJseS4pDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+ICA+IElzIHRoZXJlIHNvbWUgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBp biB0aGUgcm91dGluZw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBhZHZlcnRpc2VtZW50cyB0 aGF0IEkgbWlzc2VkPw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgPiBUaGFuayB5b3UsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFlvdXJzLA0K PiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBKb2VsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+ DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IHNwcmluZyBtYWls aW5nIGxpc3QNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gc3ByaW5nQGlldGYub3JnPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86 c3ByaW5nQGlldGYub3JnJTBiPj4gICAgIDxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4+Pg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAg ID4gPg0KPiAgICAgID4NCj4gICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdx aFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyPg0KPiAg ICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTd2WDJxV1NVZFdWYzg5Mlh1WHky SDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZj bGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNE aHR0cHMlMkEzQSUyQTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9S MW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNkh3UExpbCUyND4NCj4g ICAgICA+ID4NCj4gICAgICA+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyDQo8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0El MjUyJTBiPj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0E1QjhIMkZtMXJQ bmFaM1N1cGp3cjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0 cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2 SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTI1Ml9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1 c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG96b1Fp QUhrJTI0Pj4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gRiUyRnd3dy5pZXRmLm9yZzxodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzJ5Q2tQS1JydVJqMVpmQ3ZLZ0wyR3E2SDI/dT1o dHRwJTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmc+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxk ZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5F dDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhP R3Q4QWtUUkR1aURvLXBQQ2p2UiUyND4NCj4gICAgICA+IDxodHRwczovL2NsaWNrdGltZS5zeW1h bnRlYy5jb20vM0dXVDlmeWphRmkzRmN2SER2b29kdlM2SDI/dT1odHRwJTNBJTJGJTJGMkZ3d3cu aWV0Zi5vcmcNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dXVDlmeWphRmkzRmN2 SER2b29kdlM2SDI/dT1odHRwJTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmclMGI+PiAgICAgPGh0dHBz Oi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0 dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYu b3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3 eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQ+PiUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnNwcmluZw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBzcHJp bmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIDxt YWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAgPg0K PiAgICAgaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVB dlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZzcHJpbmcNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0JoeUV0eDRR N243NEJoaVJuZk1KdFQ2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZf X2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVB dlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyRiUyQTJGd3d3LmlldGYub3JnJTJBMkZtYWlsbWFu JTJBMkZsaXN0aW5mbyUyQTJGc3ByaW5nX18lM0JKU1VsSlNVbCUyMSUyMU5FdDZ5TWFPLWdrJTIx UzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURv LWhSM2dBRCUyND4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4gICAgICA+ ID4NCj4gICAgICA+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICA+ID4gTm90aWNlOiBU aGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0KPiAg ICAgID4gPiBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlz IGNvbmZpZGVudGlhbA0KPiAgICAgID4gYW5kL29yDQo+ICAgICAgPiA+IHByb3ByaWV0YXJ5IGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywNCj4g ICAgICA+ID4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBv ciBmb3J3YXJkaW5nDQo+ICAgICB3aXRob3V0DQo+ICAgICAgPiA+IGV4cHJlc3MgcGVybWlzc2lv biBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4gICAgICA+IGlu dGVuZGVkDQo+ICAgICAgPiA+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwNCj4gICAgICA+ID4gY29waWVzLCBpbmNsdWRp bmcgYW55IGF0dGFjaG1lbnRzLg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ ICAgICAgPiA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA+IGh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91 PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5n DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5 QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUz QSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIx TkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBS SE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0Pg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgICA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAg PiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGll dGYub3JnPg0KPiAgICAgID4gaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5 TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzcHJpbmcNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2Uu Y29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4 Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQ+DQo+ICAgICAgPg0K Pg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gICAgIHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgIHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+DQo+ IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2 SDI/dT1odHRwcyUzQSUNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJl WGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyNSUwYj4+IDJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmc8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzMyeUNrUEtScnVSajFaZkN2S2dMMkdxNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3Lmll dGYub3JnPiUyRm1haWxtYW4lMkZsaXN0aQ0KPiBuZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5 TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1DQo+IG9aSGd3cDZ2cFJI T0d0OEFrVFJEdWlEbzVLbFBuYmolMjQ+DQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0N Cj4gTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkg Y29udGFpbg0KPiBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0 IGlzIGNvbmZpZGVudGlhbCBhbmQvb3INCj4gcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LA0KPiBkaXNjbG9zdXJlLCByZWxp YW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dA0KPiBl eHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkDQo+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwNCj4gY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFj aG1lbnRzLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0 Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9u cyBJbmMuIHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmlldGFyeSBmb3IgdGhlIHNv bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIGRpc2Nsb3N1cmUs IHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0 IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbCBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpzcHJpbmcgbWFpbGluZyBs aXN0DQoNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzVQWGtLS1Q2RXpMVVZmRFQ0NDNRb3k2SDI/dT1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZz4NCg0K --_000_AM0PR03MB449963FAF42D748F7FD7F2E09D5C0AM0PR03MB4499eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+TWFydGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Mb3RzIG9mIHRoYW5rcyBmb3Ig YW4gaW1wb3J0YW50IGlucHV0IHRvIHRoaXMgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkkgZnVsbHkgYWdyZWUgd2l0aCB5b3UgdGhhdCBhYmlsaXR5IHRv IHR1cm4gb2ZmIHRoZSBub2RlIHByb3RlY3Rpb24gc2NoZW1lIGZvciBhIHNwZWNpZmljIFBMUiBu ZWlnaGJvciAoaS5lLiwgb24gYSBzcGVjaWZpYyBQTFIgcG9ydCkgYnkgc3VpdGFibGUgbG9jYWwg Y29uZmlndXJhdGlvbiBpbiB0aGUgUExSIGlzIGRlZmluaXRlbHkgcmVxdWlyZWQuIFN1Y2ggYW4N CiBhYmlsaXR5IHdvdWxkIHByb2JhYmx5IGFkZHJlc3MgbW9zdCAoaWYgbm90IGFsbCkgc2NlbmFy aW9zIGFzc29jaWF0ZWQgd2l0aCB0aGUgc28tY2FsbGVkIOKAnHNlcnZpY2Ugbm9kZXPigJ0gdGhh dCBjYW5ub3QgYmUgYnlwYXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5JIGFsc28gdGhpbmsgdGhhdCBzZXJ2aWNlIG5vZGVzIHRoYXQgY2Fubm90IGJlIGJ5cGFzc2Vk IHR5cGljYWxseSB3b3VsZCBhZHZlcnRpc2UgdGhlbXNlbHZlcyBhcyDigJxzdHViIG5vZGVz4oCd IGluIElHUCBpbiBvcmRlciB0byBwcmV2ZW50IGluYWR2ZXJ0ZW50IGFwcGxpY2F0aW9uIG9mIHRo ZWlyIHNlcnZpY2UgZnVuY3Rpb24gdG8gdHJhbnNpdCB0cmFmZmljICh3aGljaA0KIGNvdWxkIG90 aGVyd2lzZSBwYXNzIHRocnUgdGhlIHNlcnZpY2Ugbm9kZSBkdWUgdG8gc29tZSB0b3BvbG9neSBj aGFuZ2UpLiBUaGVyZWZvcmUgYSBsb2NhbCBwb2xpY3kgdGhhdCB3b3VsZCBleGNsdWRlIElHUCBu ZWlnaGJvcnMgYWR2ZXJ0aXNpbmcgJm5ic3A7dGhlbXNlbHZlcyBhcyBzdHViIG5vZGVzIGluIElH UCBmcm9tIHRoZSBub2RlIHByb3RlY3Rpb24gc2NoZW1lIGNvdWxkIGJlIGFsc28gdXNlZnVsLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGFzdCBidXQgbm90IGxlYXN0LCBh YmlsaXR5IG9mIHRoZSBub2RlIHRvIGFkdmVydGlzZSBhIHNwZWNpZmljIFByZWZpeCBTSUQgaXQg b3JpZ2luYXRlcyBhcyDigJxub3QgZWxpZ2libGUgZm9yIGJ5cGFzcyBwcm90ZWN0aW9u4oCdIChl LmcuLCB1c2luZyBhIG5ldyBmbGFnIGluIHRoZSBQcmVmaXggTm9kZSBUTFYgZm9yIElTLUlTIG9y IE9TUEYpIHNob3VsZCBiZSBjb25zaWRlcmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+TXkgMmMsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+U2FzaGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPk9mZmljZTogKzk3Mi0zOTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DZWxsOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyArOTcyLTU0OTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5FbWFpbDom bmJzcDsmbmJzcDsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHNwcmlu ZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZg0KPC9iPk1h cnRpbiBIb3JuZWZmZXI8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDE4LCAyMDIw IDU6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IHNwcmluZ0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4g QWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tJmd0 OzsgUm9iZXJ0IFJhc3p1ayAmbHQ7cm9iZXJ0QHJhc3p1ay5uZXQmZ3Q7OyBFWFQtQW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbSAmbHQ7QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bSZndDs7IFNocmFkZGhhIEhlZ2RlICZsdDtzaHJhZGRoYUBqdW5pcGVyLm5ldCZndDs7IEtldGFu IFRhbGF1bGlrYXIgKGtldGFudCkgJmx0O2tldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y ZyZndDs7DQogSm9lbCBNLiBIYWxwZXJuICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1p bmluZyBhcHBsaWNhYmlsaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkEgZmV3IHRob3VnaHRzIGZyb20gbXkgKG9w ZXJhdG9yJ3MpIFBvVjo8YnI+DQo8YnI+DQombmJzcDstIFRoZSBkaXN1c3Npb24gaXMgYSB2ZXJ5 IGdvb2QgYW5kIGltcG9ydGFudCBvbmUuIEl0IHByb2JhYmx5IHNob3VsZCBiZSBkaXNjdXNzZWQg YW5kIGRvY3VtZW50ZWQgd2VsbCBpbiBvcmRlciB0byBqdXN0aWZ5IHRoZSBwcm9wb3NlZCBwcm90 ZWN0aW9ucyBtZWNoYW5pc21zLjxicj4NCjxicj4NCiZuYnNwOy0gTm90IGFsbCBvcGVyYXRvcnMg c2VlbSB0byBoYXZlIHRoZSBzYW1lIHJlcXVpcmVtZW50cy48YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgKEEgc29tZXdoYXQgc2ltaWxhciBkaXNjdXNzaW9uIG1pZ2h0IGJlIHRoZSBvbmUgZm9yIGRp c2pvaW50IHBhdGhzLiBUaG9zZSBhcmUgb2Z0ZW4gZXF1aXJlZCBieSB2b2ljZSBzaWduYWxsaW5n IGFwcGxpY2F0aW9ucy4gSW4gc29tZSBjYXNlcyB0aGUgdm9pY2Ugc2VydmljZSBkZW1hbmRzIHRo YXQgdHJhZmZpYyBpcyBibGFja2hvbGVkIHJhdGhlciB0aGFuIG9uIGZvcndhcmRlZCBvbiB0aGUg d3JvbmcgcGF0aC4gSW4gb3RoZXIgY2FzZXMgZGlzam9pbnQNCiBwYXRocyBhcmUganVzdCByZXF1 aXJlZCBmb3IgdGhlICZxdW90O2dvb2QgY2FzZSZxdW90Oy4gVHJhZmZpYyBNQVkgYmUgZm9yd2Fy ZGVkIG9uIHRoZSB3cm9uZyBwYXRoLCBhcyBsb25nIGFzIHRoZSBuZXR3b3JrIGp1c3QgbWFrZXMg c3VyZSB0aGUgdHJhZmZpYyBvbiB0aGUgb3RoZXIgcGF0aCBpcyBuZXZlciBhZmZlY3RlZCBieSB0 aGUgc2FtZSBmYWlsdXJlLik8YnI+DQo8YnI+DQombmJzcDstIFBlcnNvbmFsbHkgSSB3b3VsZCBo YXRlIHRvIHNlZSB5ZXQgYW5vdGhlciBJR1AgZXh0ZW5zaW9uIGZvciB0aGlzIHB1cnBvc2UuPGJy Pg0KPGJyPg0KJm5ic3A7LSBJIHdvdWxkIHJhdGhlciBwcmVmZXIgYSBnb29kIGRpc2N1c3Npb24g b2Ygd2hhdCBjYW4gYmUgYWNoaWV2ZWQgYnkgdXNpbmcgZWFzeSB0byBtYWtlIHN3aXRjaGVzOjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBwcm90ZWN0aW9uIGJlaGF2aW91ciBjb3VsZCBi ZSBzd2l0Y2hlZCBvbiBvciBvZmYgcGVyIG5vZGUuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gQW4gb3BlcmF0b3Igd2l0aCBzdHJpY3QgJnF1b3Q7c29tZSB0cmFm ZmljIG1heSBuZXZlciB0b3VjaCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBuZXR3b3JrJnF1b3Q7IHJl cXVpcmVtZW50cyBtaWdodCBzd2l0Y2ggb2ZmIHRoZSBiZWhhdmlvdXIsIHdoaWxlIG90aGVycyBt aWdodCBzd2l0Y2ggaXQgb24uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gQSBub2RlIGNvdWxk IGFsbG93IGEgc3dpdGNoIGV2ZW4gaW5kaXZpZHVhbGx5IGZvciBldmVyeSBwb3J0IG9yIG5laWdo Ym9yLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIElmIGEgbm9k ZSBrbm93cyB0aGF0IG9uZSBvZiBpdCdzIG5laWdoYm91cnMgaXMgYSBzZXJ2aWNlIG5vZGUgcmF0 aGVyIHRoYW4gYSBwbGFpbiB0b3BvbG9naWNhbCBvbmUsIGl0IGNvdWxkIHN3aXRjaCBvZmYgcHJv dGVjdGlvbi4gVGhpcyBpcyBob3cgSSB3b3VsZCBwcmVmZXIgdG8gc29sdmUgdGhlIHByb2JsZW0g d2l0aCBzZXJydmljZSBub2Rlcy48YnI+DQo8YnI+DQpTaG91bGQgdGhpcyBiZSBkaXNjdXNzZWQg aW4gdGhlIHByb3RlY3Rpb24gZG9jdW1lbnQsIG9yIGluIGEgc2VwYXJhdGUgb25lPzxicj4NCjxi cj4NCkJlc3QgcmVnYXJkcywgTWFydGluPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbSAxNC4wOC4yMCB1bSAxOTo0NSBzY2hyaWViIEtldGFuIFRhbGF1bGlrYXIgKGtldGFu dCk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9i ZXJ0LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBkbyBub3QgaGF2ZSBhIHNpZ25hbGxpbmcg bWVjaGFuaXNtIGluIElHUHMgdG9kYXkgdG8gaW5kaWNhdGUgYSDigJxieXBhc3MtYWJsZeKAnSBp bmRpY2F0aW9uIGZvciBQcmVmaXggU0lEcy4gSWYgdGhlcmUgd2FzIGEgZGVzaXJlIGZvciBpdCwg YW4gSUdQIGV4dGVuc2lvbiB3b3VsZCBiZSByZXF1aXJlZCAodGhlcmUgaXMgbm9uZSBpbiBwcm9n cmVzcyBBRkFJSykuIE5vdGUgdGhhdCB0aGlzIHJlc3VsdHMgaW4gZG91YmxpbmcNCiB0aGUgcHJl Zml4IFNJRCBzY2FsZSAoZ2xvYmFsIGxhYmVscykgaW4gdGhlIG5ldHdvcmsuIFNvIEkgd291bGQg bm90IGdvIGFib3V0IHRoaXMgdHJpdmlhbGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIGl0IGhlbHBzIHRvIGdldCBtb3JlIGlucHV0cyBhbmQgcGVyc3BlY3RpdmVzIGZyb20gb3Bl cmF0b3JzIG9uIHRoZWlyIHZpZXdzIGZvciBkb2luZyBhIGJ5cGFzcyB2aWEgbG9jYWwgcHJvdGVj dGlvbiBmb3Igc2VnbWVudHMgaW4gYW4gU1IgUG9saWN5LiBUaGVyZSBtYXkgYmUgdGhvc2UgdGhh dCBwcmVmZXIgZW5kLXRvLWVuZCBwYXRoIHByb3RlY3Rpb24gdXNpbmcgYSBmYWxsYmFjayBwYXRo IHRoYXQNCiBpcyBzYXkgZGlzam9pbnQgd2l0aCB0aGUgcHJpbWFyeSBidXQgcHJvdmlkZXMgYW4g YXBwcm9wcmlhdGUgU0xBL2ludGVudD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2V0YW48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJvYmVydCBS YXN6dWsgPGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij4NCiZsdDtyb2JlcnRAcmFz enVrLm5ldCZndDs8L2E+IDxicj4NCjxiPlNlbnQ6PC9iPiAxNCBBdWd1c3QgMjAyMCAyMzowNDxi cj4NCjxiPlRvOjwvYj4gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8YSBocmVmPSJtYWlsdG86 a2V0YW50QGNpc2NvLmNvbSI+Jmx0O2tldGFudEBjaXNjby5jb20mZ3Q7PC9hPjxicj4NCjxiPkNj OjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQHJiYm4uY29tIj4mbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20mZ3Q7PC9h PjsgSm9lbCBNLiBIYWxwZXJuDQo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+ Jmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7PC9hPjsgU2hyYWRkaGEgSGVnZGUgPGEgaHJlZj0i bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Ij4NCiZsdDtzaHJhZGRoYUBqdW5pcGVyLm5ldCZn dDs8L2E+OyA8YSBocmVmPSJtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5j b20iPg0KRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+IDxhIGhyZWY9Im1h aWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIj4NCiZsdDtBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tJmd0OzwvYT47IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmdd IFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXRhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tzIGxpa2Ugd2UgYXJlIHByZXR0eSBtdWNoIGlu IHN5bmMgaGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QnV0IGxldCBtZSBqdXN0IG9ic2VydmUgdGhhdCBJIHB1cnBvc2VseSZu YnNwO2RpZCBub3QgbWVudGlvbiBhYm91dCBTUiBwb2xpY2llcyBhcyB3ZSBhcmUgbm90IGFibGUg dG8gc2lnbmFsIHRoZSBpbnRlbnQgd2l0aCB0aGUgcGFja2V0cyBpdHNlbGYuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGFsbCB3 ZSBoYXZlIHRoZXJlIGlzIFNJRHMuIEJTSURzIG9yIHByZWZpeCBTSURzIG5lZWQgdG8gYmUgZmxv b2RlZCB3aXRoIGluZm9ybWF0aW9uIGlmIHBvbGljaWVzIGJ1aWxkIHdpdGggdXNpbmcgdGhlbSBh cmUgYnlwYXNzIGVsaWdpYmxlIG9yIG5vdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgYWN0dWFsbHkgdW5kZXIgdGhlIGlt cHJlc3Npb24gdGhhdCB0aGlzIGlzIGFscmVhZHkgdGhlcmUgYW5kIEkgYW0ganVzdCBub3QgYXdh cmUsIGJ1dCBsb29raW5nIGRlZXBlciBpbmRlZWQgSSBkbyBub3Qgc2VlIHRoaXMgbWFya2luZyBu ZWl0aGVyIGluIElTSVMgbm9yIE9TUEYgZm9yIHByZWZpeCBTSURzLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGVyZSBzb21l IHdvcmsgaW4gcHJvZ3Jlc3MgdG8gYWRkIGl0IHRvIHRob3NlIHByb3RvY29scyBvciBoYXZlIHdl IGp1c3QgZG9jdW1lbnRlZCBuZWVkJm5ic3A7Zm9yIGEgc2hvcnQgTFNSIGRyYWZ0Jm5ic3A7ID8m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGh4LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Ui48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGcmksIEF1ZyAxNCwgMjAyMCBhdCA2OjE3IFBNIEtldGFuIFRhbGF1bGlrYXIgKGtl dGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIj5rZXRhbnRAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBs ZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUm9iZXJ0IFJhc3p1ayAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJh c3p1ay5uZXQ8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE0IEF1Z3VzdCAyMDIwIDIxOjEz PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJt YWlsdG86a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFs ZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPC9hPiZndDs7IEpvZWwgTS4gSGFscGVybiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiZndDs7IFNocmFkZGhhIEhlZ2RlICZsdDs8YSBocmVmPSJtYWls dG86c2hyYWRkaGFAanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5zaHJhZGRoYUBqdW5pcGVy Lm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+ Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z cHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTcHJp bmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEtldGFuLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoaWxlIEkgY29tcGxldGVseSBhZ3JlZSB3 aXRoIHlvdXIgbm90ZSB0aGUgY29uc2VxdWVuY2VzIG9mIGl0IGFyZSBwcmV0dHkgc2V2cmUuJm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPltLVF0gSSB1 bmRlcnN0YW5kLiBXZSBuZWVkIHRvIGJlIG1pbmRmdWwgb2YgaW1wbGljYXRpb25zIG9mIHByb3Rl Y3Rpb24gc2NoZW1lcyBmb3IgdGhlIFNMQXMvaW50ZW50IG9mIFNSIFBvbGljaWVzLjwvaT48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Vbmxlc3Mgd2Ugc2lnbmFsIHdoaWNoIHByZWZpeCBTSUQgaXMgcHJvdGVjdGlvbiBlbGlnaWJs ZSBhbmQgd2hpY2ggaXMgbm90IGhvdyB3b3VsZCBvdGhlciBub2RlcyBrbm93IGlmIHRoZXkgY2Fu IHByb3RlY3QgaXQgb3Igbm90ID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PGk+W0tUXSBDb3JyZWN0LiBUbyBiZSBtb3JlIGFjY3VyYXRlLCB3ZSBuZWVk IHRvIGNvbnNpZGVyIHRoaXMgbW9yZSBpbiB0aGUgY29udGV4dCBvZiBTTEEgb3Ig4oCcaW50ZW50 4oCdIG9mIFNSIFBvbGljaWVzIGFuZCB3aGljaCBzZWdtZW50cyBtYXkgYmUg4oCcYnlwYXNzLWFi bGXigJ0gZm9yIGxvY2FsIHByb3RlY3Rpb24NCiBmb3Igc29tZSBvZiB0aG9zZSBTUiBQb2xpY2ll cy4gV2UgYWxzbyBoYXZlIHBhdGgtcHJvdGVjdGlvbiBtZWNoYW5pc21zLjwvaT48L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBz ZWVtcyB0aGF0IHRvZGF5J3Mgc2FmZSB0aGluZyBpcyBub3QgdG8gYXBwbHkgYW55IG5vZGUgcHJv dGVjdGlvbiBvbiBTUiBmbG93cyBhdCB0aGUgUExScyB0aGVuLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIGxpbmsgcHJv dGVjdGlvbiBNVVNUIGFzc3VyZSB0aGF0IHBhY2tldHMgd2lsbCBhcnJpdmUgYXQgdGhlIG5laWdo Ym9yIG5vZGUgdmlhIHNvbWUgb3RoZXIgbGluayByZWdhcmRsZXNzIG9mIGZ1cnRoZXIgcGF0aCB0 b3dhcmRzIGRlc3RpbmF0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48aT5bS1RdIFllcy4gV2UgaGF2ZSBhIG1lY2hhbmlzbSB0byBpbmRpY2F0ZSB3 aGljaCBhZGotU0lEcyBoYXZlIHByb3RlY3Rpb24gKHRoYXQgbWVjaGFuaXNtIG9ubHkgcHJvdmlk ZXMgbGluayBwcm90ZWN0aW9uIHRvIGdldCB0byB0aGUgbmVpZ2hib3Igbm9kZSkgc28gdGhlIFNS IFBvbGljeSBjb21wdXRhdGlvbg0KIGlzIGFibGUgdG8gaW5kaWNhdGUgd2hldGhlciB0aGF0IHNw ZWNpZmljIGxpbmsgaXMg4oCcYnlwYXNzLWFibGXigJ0gb3Igbm90IGJ5IGl0cyBjaG9pY2Ugb2Yg cHJvdGVjdGVkIG9yIHVucHJvdGVjdGVkIGFkai1TSURzIHJlc3BlY3RpdmVseS48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT4mbmJzcDs8L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5UaGFua3MsPC9p PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+S2V0YW48 L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SXMgaXQgY29ycmVjdCA/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaHg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBBdWcgMTQsIDIwMjAg YXQgNTozMiBQTSBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86 a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SGkgU2FzaGEsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgc2VydmljZSBu b2RlIGFkdmVydGlzZXMgaXRzIG93biBQcmVmaXggU0lELiBUaGUgc2VydmljZSBmdW5jdGlvbiB0 aGF0IHRoaXMgc2VydmljZSBub2RlIGltcGxlbWVudHMgZG9lcyBub3QgcmVxdWlyZSBhbnkgY29u dGV4dCAoaS5lLiBhbGwgcGFja2V0cyBhcnJpdmluZyBhdCB0aGUgbm9kZSBhcmUgc3ViamVjdGVk DQogdG8gdGhhdCBzZXJ2aWNlKS4gVGhlcmVmb3JlIHRoZSBzZXJ2aWNlIG5vZGUgZG9lcyBub3Qg bmVlZCB0byByZWNlaXZlIGEgcGFja2V0IHdpdGggaXTigJlzIG93biBQcmVmaXggU0lELg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaHVzLCB3ZSBjYW5ub3QgYXNzdW1lIHRoYXQgd2hl biBQSFAgaXMgdXNlZCwgdGhlbiB0aGUgU0lEIGlzIG9ubHkgYXNzb2NpYXRlZCB3aXRoIGEgdG9w b2xvZ2ljYWwgaW5zdHJ1Y3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3BlIHRo YXQgY2xhcmlmaWVzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5LZXRhbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBB bGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0 ZWluQHJiYm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5j b208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE0IEF1Z3VzdCAyMDIwIDIwOjI0PGJyPg0K PGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86 a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208L2E+Jmd0 OzsgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OzsgU2hyYWRkaGEg SGVnZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJf YmxhbmsiPnNocmFkZGhhQGp1bmlwZXIubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86RVhU LUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5FWFQtQW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5l dDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmls aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5LZXRhbiwgYW5kIGFsbCw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+SSBoYXZlIHN0YXRlZCB0aGF0LCBJTUhP IGFuZCBGV0lXLCBib3RoIEFkai1TSURzIGFuZCBQcmVmaXggU0lEcyB0aGF0IGFyZSBhZHZlcnRp c2VkIHdpdGggUEhQIGNhbiZuYnNwOyBPTkxZIHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0cnVj dGlvbnMgaW4gU1ItTVBMUyAtIGJlY2F1c2UgdGhlIGFkdmVydGlzaW5nIG5vZGUgd2lsbCBub3Qg cmVjZWl2ZSB0aGVtIGFuZCB0aGVyZWZvcmUgY2FuIGhhcmRseSBiZQ0KIGV4cGVjdGVkIHRvIGFz c29jaWF0ZSBhbnkgc2VydmljZSBmdW5jdGlvbiB3aXRoIHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEy MTIxIj5UaGlzIGlzIGNvbXBsZW1lbnRhcnkgdG8gd2hhdCB5b3UgaGF2ZSBzYWlkLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzIxMjEyMSI+SG9wZSB0aGlzIGNsYXJpZmllcyBteSBwb3NpdGlvbi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+V2hhdCwgaWYgYW55dGhpbmcsIGRpZCBJIG1pc3M/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMjEyMTIxIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjojMjEyMTIxIj5TYXNoYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9ImdtYWlsLW1f LTE2OTk1MjI0MTk1NDYzMDA2NDNnbWFpbC1tXy01NzU2MDY1NDU1ODQzMjUwOTBtcy1vdXRsb29r LW1vYmlsZS1zaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R2V0DQo8YSBo cmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzNHaTd6cHREeVJwUmt4NFJjRHBi VUM2SDI/dT1odHRwcyUzQSUyRiUyRmFrYS5tcyUyRmdoZWkzNiIgdGFyZ2V0PSJfYmxhbmsiPg0K T3V0bG9vayBmb3IgQW5kcm9pZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIi IHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy0x Njk5NTIyNDE5NTQ2MzAwNjQzZ21haWwtbV8tNTc1NjA2NTQ1NTg0MzI1MDkwZGl2UnBseUZ3ZE1z ZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+ IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5TZW50Ojwvc3Bhbj48L3N0cm9uZz4gRnJpZGF5LCBBdWd1c3QgMTQsIDIwMjAsIDE2OjIz PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Ubzo8L3NwYW4+PC9zdHJvbmc+IEFsZXhhbmRlciBWYWluc2h0ZWluOyBK b2VsIE0uIEhhbHBlcm47IFNocmFkZGhhIEhlZ2RlOw0KPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+OyBSb2JlcnQgUmFzenVrPGJyPg0KPHN0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5D Yzo8L3NwYW4+PC9zdHJvbmc+IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YmplY3Q6PC9z cGFuPjwvc3Ryb25nPiBSRTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmlu ZyBhcHBsaWNhYmlsaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUi IGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5PVElDRTog VGhpcyBlbWFpbCB3YXMgcmVjZWl2ZWQgZnJvbSBhbiBFWFRFUk5BTCBzZW5kZXI8bzpwPjwvbzpw PjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBTYXNoYSw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPklmIHRoZSBzZXJ2aWNlIGRvZXMgbm90IG5lZWQgYW55IGFkZGl0aW9uYWwgY29u dGV4dCAoZS5nLiBhIGZpcmV3YWxsIHRoYXQganVzdCBhcHBsaWVzIGxvY2FsbHkgY29uZmlndXJl ZCBkZWZhdWx0IHJ1bGVzIG9uIGl0KSwgdGhlbiBJIGRvbuKAmXQgc2VlIHdoeSBQSFAgY291bGQg bm90IGJlIGRvbmUgZm9yIGENCiBQcmVmaXggU0lEIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2Ug bm9kZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsc28sIEkgZGlkbuKAmXQgZm9sbG93 IHRoZSBwb2ludCB0aGF0IHlvdSB3ZXJlIHRyeWluZyB0byBtYWtlIGFib3V0IEFkai1TSURzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5LZXRhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBBbGV4YW5kZXIgVmFpbnNo dGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tIiB0 YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208L2E+Jmd0Ow0KPGJy Pg0KPGI+U2VudDo8L2I+IDE0IEF1Z3VzdCAyMDIwIDE4OjI0PGJyPg0KPGI+VG86PC9iPiBLZXRh biBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50QGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208L2E+Jmd0OzsgSm9lbCBNLiBIYWxw ZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OzsgQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPC9hPiZndDs7DQogU2hyYWRkaGEg SGVnZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJf YmxhbmsiPnNocmFkZGhhQGp1bmlwZXIubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86RVhU LUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5FWFQtQW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5l dDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmls aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5IaSBhbGwsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPlJlZ2FyZGluZyB0aGUgc3RhdGVtZW50ICZxdW90O1By ZWZpeCBTSUQgY291bGQgYmUganVzdCBhIHRvcG9sb2dpY2FsIGluc3RydWN0aW9uIG9yIG1heSBh bHNvIGJlIHVzZWQgdG8gc3RlZXIgdGhlIGZsb3cgdG8gYSBub2RlIHdoaWNoIGlzIGFwcGx5aW5n IGEgc2VydmljZSBmdW5jdGlvbiB0byBpdCZxdW90Ozo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IzIxMjEyMSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5JIHRoaW5rIHRoYXQgaW4g U1ItTVBMUyBhIE5vZGUgU0lEIHRoYXQgaXMgYWR2ZXJ0aXNlZCB3aXRoIFBIUCBhY2l0b24gY2Fu IGJlIHNhZmVseSBjb25zaWRlcmVkIGFzICZxdW90O2p1c3QgYSB0b3BvbG9naWNhbCBpbnN0cnVj dGlvbiZxdW90OyBieSB0aGUgUExSIGJlY2F1c2UgdGhlIG9yaWdpbmF0aW5nIG5vZGUgd2lsbCBu b3QgcmVjZWl2ZSBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+VGhlIHNh bWUgYXBwbGllcyB0byBBZGotU0RJcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEy MSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPk15IDJjLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9ImdtYWlsLW1fLTE2OTk1MjI0MTk1NDYzMDA2NDNn bWFpbC1tXy01NzU2MDY1NDU1ODQzMjUwOTBtcy1vdXRsb29rLW1vYmlsZS1zaWduYXR1cmUiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R2V0DQo8YSBocmVmPSJodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzc1YzVZWUJlRWJhRVp3VWNIcENZMW02SDI/dT1odHRwcyUzQSUyRiUy RmFrYS5tcyUyRmdoZWkzNiIgdGFyZ2V0PSJfYmxhbmsiPg0KT3V0bG9vayBmb3IgQW5kcm9pZDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJj ZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy0xNjk5NTIyNDE5NTQ2MzAwNjQzZ21h aWwtbV8tNTc1NjA2NTQ1NTg0MzI1MDkwZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+IHNwcmluZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYNCiBvZiBLZXRhbiBUYWxhdWxpa2FyIChr ZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDs8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiBGcmlkYXksIEF1Z3VzdCAx NCwgMjAyMCwgMTU6MDA8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvOjwvc3Bhbj48L3N0cm9uZz4gSm9lbCBNLiBI YWxwZXJuOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgU2hyYWRkaGEgSGVnZGU7DQo8YSBocmVmPSJt YWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5r Ij5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT47IFJvYmVydCBSYXN6dWs8 YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkNjOjwvc3Bhbj48L3N0cm9uZz4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlv biAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkhpIEFsbCw8YnI+DQo8YnI+DQpJIHdvdWxkIGxpa2UgdG8gc2hhcmUgYSBkaWZm ZXJlbnQgcGVyc3BlY3RpdmUgb24gdGhpcy48YnI+DQo8YnI+DQpGaXJzdCwgdGhhbmtzIHRvIEpv ZWwgZm9yIGJyaW5naW5nIHVwIHRoZSBkaXNjdXNzaW9uLiBDbGVhcmx5IHdlIG5lZWQgYSB3ZWxs LWRlZmluZWQgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZm9yIGRldGVybWluaW5nIGFwcGxpY2Fi aWxpdHkgb2YgcHJvdGVjdGlvbiBmb3Igc2VnbWVudCB1c2VkIGluIGFuIFNSIFBvbGljeS4gU29t ZSBvZiB0aGlzIGlzIGNhcHR1cmVkIGluIFsxXS48YnI+DQo8YnI+DQpUaGlzIGlzIGFib3V0IGxv Y2FsIHJlcGFpciBhdCBhIFBMUi4gQnkgaXQncyB2ZXJ5IG5hdHVyZSwgdGhlIFBMUiBkb2VzIG5v dCBoYXZlIGEgbm90aW9uIG9mIGhvdyAmcXVvdDtzdHJpY3Qgb3Igbm90JnF1b3Q7IGlzIHRoZSBT TEEgdGhhdCBpcyBiZWluZyBwcm92aWRlZCBieSB0aGUgU1IgUG9saWN5LiBBd2FyZW5lc3Mgb2Yg dGhhdCBub3Rpb24gZXhpc3RzIGF0IHRoZSBTUiBQb2xpY3kgaGVhZGVuZCBhbmQvb3IgY29tcHV0 YXRpb24tbm9kZS48YnI+DQo8YnI+DQpXZSBoYXZlIHByb3RlY3RlZCBhbmQgdW4tcHJvdGVjdGVk IHZhcmlhbnRzIG9mIGFkamFjZW5jeSBTSURzIHRvIGVuYWJsZSB0aGUgY29tcHV0YXRpb24gdG8g cGljayBvciB0aGUgb3RoZXIgYmFzZWQgb24gdGhlICZxdW90O3N0cmljdG5lc3MmcXVvdDsgb2Yg dGhlIFNMQSByZXF1aXJlbWVudCBmb3IgcGlja2luZyB0aGF0IGxpbmsuIFdlIGRvIG5vdCBoYXZl IHN1Y2ggYSBub3Rpb24gZm9yIFByZWZpeCBTSURzLiBPbmUgY2FuIHNheSB0aGF0IHdlIGNvdWxk IGludHJvZHVjZQ0KIHNpZ25hbGxpbmcgKGUuZy4gYSBCIGZsYWcpIHRvIGluZGljYXRlIHdoZXRo ZXIgYSBQcmVmaXggU0lEIGNhbiBiZSBieXBhc3NlZCBvciBub3QuIFRoaXMgcHJvdmlkZXMgdGhl IG9wcG9ydHVuaXR5IGZvciB0aGUgY29tcHV0YXRpb24gdG8gdXNlIG9uZSBvciB0aGUgb3RoZXIg Zmxhdm9yIGRlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9mIHRoZSBTTEEgZm9yIHRoZSBTUiBQb2xp Y3kuPGJyPg0KPGJyPg0KSSBoYXZlIGEgcHJvYmxlbSBhbmQgYSBjb25jZXJuIGluIHRoZSBhc3N1 bXB0aW9uIHRoYXQgUExScyBjYW4gYXNzdW1lIHRoYXQgdGhlIGN1cnJlbnRseSBkZWZpbmVkIHZh cmlhbnQgb2YgUHJlZml4IFNJRHMgaW4gUkZDODQwMiAoYW5kIElHUCBzcGVjcykgYXJlICZxdW90 O2J5cGFzcy1hYmxlJnF1b3Q7Ljxicj4NCjxicj4NCkFzIEpvZWwgYW5kIG90aGVycyBoYXZlIGJy b3VnaHQgb3V0LCB0aGUgUHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0IGEgdG9wb2xvZ2ljYWwgaW5z dHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0aGUgZmxvdyB0byBhIG5vZGUg d2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGl0LiBJbiBvcmRlciB0byBz dXBwb3J0IGEgbWl4IG9mIFNSIFBvbGljaWVzIG9mIGRpZmZlcmVudCBTTEFzIChzdHJpY3QgYW5k IG5vdC1zdHJpY3QpLA0KIHdlIG5lZWQgdG8gZW5hYmxlIHRoZSBjaG9pY2Ugb2YgU0lEcyB0aGF0 IGluZGljYXRlcyB0byB0aGUgUExSIHdoZXRoZXIgdGhleSBhcmUgJnF1b3Q7YnlwYXNzLWFibGUm cXVvdDsgb3Igbm90Ljxicj4NCjxicj4NCkZvciB0aGUgY2FzZXMsIHdoZXJlIHRoZSBTUiBQb2xp Y3kgaGFzIGEgc3BlY2lmaWMgU0xBLCBpdCBpcyByZXF1aXJlZCBmb3Igbm9kZXMgdG8gZHJvcCB0 aGUgcGFja2V0cyBtZWFudCBmb3IgdGhlICZxdW90O2FjdGl2ZSBzZWdtZW50JnF1b3Q7IHRoYW4g dG8gYnlwYXNzIGl0LiBXaGVuIHRoaXMgbWVjaGFuaXNtIGlzIHVzZWQgYWxvbmcgc2lkZSBTUlRF IHBhdGggbW9uaXRvcmluZyBtZWNoYW5pc21zLCBpdCBlbmFibGVzIHRoZSBoZWFkZW5kIHRvIGRl dGVjdCB0aGUNCiBmYWlsdXJlIGFuZCBmYWxsYmFjayB0byBhbiBhbHRlcm5hdGUgcGF0aCB1c2lu ZyB0aGUgcGF0aCBwcm90ZWN0aW9uIGFwcHJvYWNoLiBUaGlzIGlzIHNvbWV0aGluZyB0aGF0IGlz IGRlc2NyaWJlZCBhbmQgaW4gdXNlIGluIGRlcGxveW1lbnRzIHRvZGF5IFsxXS4uPGJyPg0KPGJy Pg0KVGhhbmtzLDxicj4NCktldGFuPGJyPg0KPGJyPg0KWzFdIDxhIGhyZWY9Imh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zWTNmV3VORllDak1KVWlpQWlXd1VtczZIMj91PWh0dHBzJTNB JTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLXBvbGljeS0wOCUyM3NlY3Rpb24tOSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1zNkgyP3U9aHR0cHMl M0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05PC9hPjxicj4NClsyXSA8YSBocmVmPSJodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzZmQ01yZ21FZXdDNGE0QUpScm1uN0g2SDI/dT1o dHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5nLXNl Z21lbnQtcm91dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTkuMyIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2ZkNNcmdtRWV3QzRhNEFKUnJtbjdINkgy P3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05LjM8L2E+PGJyPg0KPGJyPg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBzcHJpbmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybjxicj4N ClNlbnQ6IDA0IEF1Z3VzdCAyMDIwIDIwOjI1PGJyPg0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWlu ICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20iIHRhcmdl dD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbTwvYT4mZ3Q7OyBTaHJhZGRo YSBIZWdkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhPTQwanVuaXBlci5uZXRAZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmll dGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVj b20uY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwv YT4mZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5u ZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KQ2M6IDxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0 Zi5vcmc8L2E+OyBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJy Pg0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcg YXBwbGljYWJpbGl0eTxicj4NCjxicj4NClRoZXJlIGFyZSwgYXMgZmFyIGFzIEkgY2FuIHRlbGws IGEgbnVtYmVyIG9mIHdheXMgdG8gYWRkcmVzcyB0aGlzIGZhbWlseSBvZiByZWxhdGVkIHF1ZXN0 aW9ucy48YnI+DQpXaGF0IHN0cnVjayBtZSwgYW5kIHByb21wdGVkIHRoZSBzdGFydGluZyBxdWVz dGlvbiwgd2FzIHRoYXQgbm9uZSBvZiB0aGVtIHdlcmUgc3BlbGxlZCBvdXQuJm5ic3A7IEkgc2Vl IGxvdHMgb2YgaW50ZXJlc3RpbmcgaWRlYXMgLyBwcm9wb3NhbHMuPGJyPg0KU29tZSBvZiB0aGVt IGFyZSBjb21wYXRpYmxlIHdpdGggb3RoZXJzLiZuYnNwOyZuYnNwOyBTb21lIGFyZSBub3QuPGJy Pg0KSXQgd291bGQgYmUgZ29vZCBpZiB3ZSBjb3VsZCByZWFjaCBhZ3JlZW1lbnQgb24gaG93IHdl IHRob3VnaHQgaXQgc2hvdWxkIGJlIGhhbmRsZWQuPGJyPg0KPGJyPg0KVGhhbmsgeW91LDxicj4N CkpvZWw8YnI+DQo8YnI+DQpPbiA4LzQvMjAyMCAzOjU0IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVp biB3cm90ZTo8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhbSBzdGls bCBub3Qgc3VyZSB0aGF0IHRoZSBwcm9ibGVtIG9mIGJ5cGFzcyBnb2luZyB0aHJ1IHVuZGVzaXJh YmxlIDxicj4NCiZndDsgbGlua3Mvbm9kZXMgZXhpc3RzIGluIHRoZSBjYXNlIG9mIHRvcG9sb2dp Y2FsIFNJRHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFGQUlLLCBGYWNpbGl0eSBQcm90ZWN0aW9u IGluIFJTVlAtVEUgRlJSIChSRkMgNDA5MDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTkya25FOVhKdWpyZjhCazdvSnZzNkgyP3U9aHR0cHMl M0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM0MDkwIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNROTJrbkU5WEp1anJmOEJrN29KdnM2SDI/ dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzQwOTA8L2E+Jmd0Oykg aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5DQogZGVwbG95ZWQgPGJyPg0KJmd0OyBmb3IgbWFueSB5ZWFy cyBiZWZvcmUgU1ItTVBMUyBoYXMgYmVlbiBpbnRyb2R1Y2VkLiBXaGF04oCZcyBtb3JlLCA8YnI+ DQomZ3Q7IHNpZ25hbGluZyBvZiBieXBhc3MgdHVubmVscyBoZSBQTFIgdXN1YWxseSBkaWQgbm90 IGluY2x1ZGUgYW55IG9mIHRoZSA8YnI+DQomZ3Q7IGNvbnN0cmFpbnRzIHVzZWQgZm9yIGNvbXB1 dGluZyBvZiBhbnkgc3BlY2lmaWMgTFNQIHRoYXQgdGhlIGJ5cGFzcyBMU1AgPGJyPg0KJmd0OyB3 b3VsZCBwcm90ZWN0IOKAkyBiZWNhdXNlIGluIHRoZSBGYWNpbGl0eSBQcm90ZWN0aW9uIG1vZGUg dGhlIHNhbWUgPGJyPg0KJmd0OyBieXBhc3MgTFNQIHdvdWxkIGJlIHVzZWQgdG8gcHJvdGVjdCBt dWx0aXBsZSBMU1BzIHBhc3NpbmcgdGhydSB0aGUgPGJyPg0KJmd0OyBmYWlsZWQgbGluay9ub2Rl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyBGcm9tIG15IFBPViB0aGUgb25seSBkaWZmZXJl bmNlIGJldHdlZW4gdGhpcyBiZWhhdmlvciBhbmQgdGhhdCA8YnI+DQomZ3Q7IGludHJvZHVjZWQg YnkgdGhlIOKAnGJ5cGFzc2luZ+KAnSBkcmFmdHMgaW4gU1IgaXMgdGhhdCwgaW4gdGhlIGNhc2Ug b2YgPGJyPg0KJmd0OyBSU1ZQLVRFLCB0aGUgb3BlcmF0b3Igd291bGQgZXhwbGljaXRseSBpbmRp Y2F0ZSwgYXMgcGFydCBvZiBMU1AgPGJyPg0KJmd0OyBzaWduYWxpbmcsIHdoZXRoZXIgaXQgd291 bGQgb3Igd291bGQgbm90IHVzZSBGUlI7IExTUHMgdGhhdCB3b3VsZCBub3QgPGJyPg0KJmd0OyB1 c2UgRlJSIHdvdWxkIHRoZW4gZHJvcCB0cmFmZmljIHJhdGhlciB0aGFuIGRlbGl2ZXJpbmcgaXQg dGhlIHdyb25nIHdheS48YnI+DQomZ3Q7IDxicj4NCiZndDsgU3VjaCBhbiBvcHRpb24gaW5kZWVk IGRvZXMgbm90IGV4aXN0IGluIFNSLVRFIHRvZGF5LCBidXQgd291bGQgYmUgZWFzeSA8YnI+DQom Z3Q7IHRvIHByb3ZpZGUgaWYgc28gZGVzaXJlZCBJTUhPLjxicj4NCiZndDsgPGJyPg0KJmd0OyBE aWQgSSBtaXNzIHNvbWV0aGluZyBzdWJzdGFudGlhbD88YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVn YXJkcywgYW5kIGxvdHMgb2YgdGhhbmtzIGluIGFkdmFuY2UsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFNhc2hhPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9mZmljZTogKzk3Mi0zOTI2NjMwMjxicj4NCiZn dDsgPGJyPg0KJmd0OyBDZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArOTcyLTU0 OTI2NjMwMjxicj4NCiZndDsgPGJyPg0KJmd0OyBFbWFpbDombmJzcDsmbmJzcDsgPGEgaHJlZj0i bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICpGcm9tOiogc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7ICpPbiBC ZWhhbGYgT2YgKlNocmFkZGhhIEhlZ2RlPGJyPg0KJmd0OyAqU2VudDoqIFR1ZXNkYXksIEF1Z3Vz dCA0LCAyMDIwIDk6NDEgQU08YnI+DQomZ3Q7ICpUbzoqIDxhIGhyZWY9Im1haWx0bzpFWFQtQW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcu QWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDs8YSBo cmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFz enVrLm5ldDwvYT4mZ3Q7PGJyPg0KJmd0OyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjsgSm9lbCBNLiBIYWxw ZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTog W3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEFsbCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBpcyBhIHZl cnkgaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBhbmQgdGhhbmtzIHRvIEpvZWwgZm9yIHN0YXJ0aW5n IDxicj4NCiZndDsgdGhpcyBkaXNjdXNzaW9uLiBJTU8sIHdoZW4gdGhlcmUgYXJlIHN0cmljdCBy ZXF1aXJlbWVudHMgb2YgYXZvaWRpbmcgPGJyPg0KJmd0OyBjZXJ0YWluIG5vZGVzL2xpbmtzIGl0 IGNhbiBiZSByZWFsaXplZCZuYnNwOyBlaXRoZXIgYnkgZGVmaW5pbmcgYSBmbGV4LWFsZ28gPGJy Pg0KJmd0OyBhdm9pZGluZyB0aG9zZTxicj4NCiZndDsgPGJyPg0KJmd0OyBOb2RlcyBhbmQgbGlu a3Mgb3IgYnkgdXNpbmcgYSBzdGFjayBvZiB1bnByb3RlY3RlZCBhZGotc2lkcyB0aGF0IGF2b2lk IDxicj4NCiZndDsgcmVzdHJpY3RlZCBub2RlcyBhbmQgbGlua3MuIFdoZW4gYSBzdGFjayBvZiBh ZGotc2lkcyBpcyB1c2VkIHRvIDxicj4NCiZndDsgcmVhbGl6ZSB0aGUgcGF0aCwgdGhlIGhlYWQt ZW5kIGJhc2VkIChzQkZEKSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgY2FuIGJlIGFwcGxpZWQuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IElmIE5vZGUtc2lkcy9wcmVmaXgtc2lkL2FueWNhc3Qtc2lkcyBh cmUgdXNlZCB0byBidWlsZCB0aGUgc3RhY2ssIHRoZSA8YnI+DQomZ3Q7IGZhaWx1cmUgZXZlbnRz IG1heSBjYXVzZSB0cmFmZmljIHRvIGdvIHRocm91Z2ggcmVzdHJpY3RlZCBub2RlcyBhbmQgPGJy Pg0KJmd0OyBsaW5rcy4gVGhpcyB3b3VsZCBoYXBwZW4gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFu eSBraW5kIG9mIHByb3RlY3Rpb24gPGJyPg0KJmd0OyBpcyBpbiB1c2Ugb3Igbm90Ljxicj4NCiZn dDsgPGJyPg0KJmd0OyBSZ2RzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNocmFkZGhhPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHk8YnI+DQomZ3Q7IDxicj4NCiZn dDsgKkZyb206KiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZyUyMCUwYiIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo8YnI+ DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7 ICpPbiBCZWhhbGYgT2YgKkFuZHJldyBBbHN0b248YnI+DQomZ3Q7ICpTZW50OiogVHVlc2RheSwg QXVndXN0IDQsIDIwMjAgNTo0MSBBTTxicj4NCiZndDsgKlRvOiogUm9iZXJ0IFJhc3p1ayAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0 QHJhc3p1ay5uZXQ8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyZndDs8YnI+DQom Z3Q7ICpDYzoqIDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7OyBKb2VsIE0u IEhhbHBlcm4NCjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4gJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb208L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICpTdWJqZWN0OiogUmU6IFtzcHJp bmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZn dDsgPGJyPg0KJmd0OyAqW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XSo8 YnI+DQomZ3Q7IDxicj4NCiZndDsgUm9iZXJ0IHRoaXMgaXMgYWN0dWFsbHkgZmFyIG1vcmUgZGlm ZmljdWx0IHdoZW4g4oCTIGl0IGNhbiBiZSBhbiBlbnRpcmU8YnI+DQomZ3Q7IChsb25nKSBzZXJp ZXMgb2Ygbm9kZXMgdGhhdCBuZWVkIHRvIGJlIGF2b2lkZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEl0IGNvdWxkIHBvdGVudGlhbGx5IGJlIG1hZGUgdG8gd29yayBidXQgSeKAmWQgd29ycnkgdGhh dCB0byBkbyB0aGlzIOKAkyA8YnI+DQomZ3Q7IHlvdeKAmWQgaGF2ZSB0byBzdGFjayAxMCDigJMg MjAg4oCTIDMwIG5lZ2F0aXZlIGxhYmVscyDigJMgYW5kIHRoYXQgd291bGRu4oCZdCA8YnI+DQom Z3Q7IGJlIHZpYWJsZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXTigJlzIGVhc2llciB0byB1c2Ug YWxnb3JpdGhtcyBhbmQgYWRqYWNlbmN5IHNpZHMgYW5kIG90aGVyIHN1Y2ggdGhpbmdzIDxicj4N CiZndDsgdG8gY2FsY3VsYXRlIHBhdGhzIOKAkyB0aGUgYmlnZ2VzdCB0cmljayBpcyBhYm91dCB0 aGUgc3RhY2sgZGVwdGguJm5ic3A7IFdoZW4gPGJyPg0KJmd0OyB5b3UgaGF2ZSB0aGlzIG5lZWQg Zm9yIG5vZGUgYXZvaWRhbmNlIOKAkyB0aGUgbmVlZCBmb3IgMTArIGxhYmVsIGRlcHRoIDxicj4N CiZndDsgaXMgY3JpdGljYWwg4oCTIHVubGVzcyB5b3Ugd2FubmEgYmUgYXBwbHlpbmcgb25lIGhl bGwgb2YgYSBsb3Qgb2YgPGJyPg0KJmd0OyBiaW5kaW5nIGxhYmVscyBhbG9uZyB0aGUgd2F5IHdo aWNoIGlzIGEgbmlnaHRtYXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBCdXQgdG8gYW5zd2VyIHlv dXIgcXVlc3Rpb24sIGlzIHRoaXMgYSBjb21tb24gdXNlIGNhc2Ug4oCTIGl04oCZcyBhIHVzZSA8 YnI+DQomZ3Q7IGNhc2UgdGhhdCBtb3N0IG9mIHRoZSBwZW9wbGUgSSBkaXNjdXNzIHRoaXMgd2l0 aCBjZXJ0YWluIGhhdmUg4oCTIEkgY2FudCA8YnI+DQomZ3Q7IGNvbW1lbnQgb24gYSBnbG9iYWwg c2NhbGUsIG9yIGZvciBhbnlvbmUgZWxzZSwgYnV0IGV2ZXJ5IGluZGljYXRpb24gSSA8YnI+DQom Z3Q7IGhhdmUgaXMgdGhhdCB5ZXMg4oCTIGl0cyBzb21ldGhpbmcgcGVvcGxlIG5lZWQsIGFuZCB3 YW50PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFuZHJldzxicj4NCiZndDsgPGJyPg0KJmd0OyAqRnJv bToqIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJvYmVydEByYXN6dWsu bmV0PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyAqU2VudDoqIFR1ZXNkYXksIDQgQXVndXN0IDIwMjAg MDE6Mjc8YnI+DQomZ3Q7ICpUbzoqIEFuZHJldyBBbHN0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpB bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tJTIwJTBiIiB0YXJnZXQ9Il9ibGFuayI+QW5k cmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbQ0KPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+ bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0OyZndDs8YnI+DQom Z3Q7ICpDYzoqIEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20lMjAlMGIiIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tDQo8YnI+ DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0OzsNCjxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5v cmc8L2E+IDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICpT dWJqZWN0OiogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBw bGljYWJpbGl0eTxicj4NCiZndDsgPGJyPg0KJmd0OyBJcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNl IGllLiZuYnNwOyAmcXVvdDtidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgPGJy Pg0KJmd0OyBzZWdtZW50cyBpdCBjYW4gbmV2ZXIgdG91Y2ggb3IgZmxvdyB0aHJvdWdoLiZxdW90 Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBzbyBwZXJoYXBzIGl0cyB0aW1lIHRvIGRlZmluZSBu b3Rpb24gb2YgKm5lZ2F0aXZlLVNJRCogaWUuIGxpc3QgaW4gPGJyPg0KJmd0OyB0aGUgcGFja2V0 IHJlc291cmNlcyB3aGljaCBnaXZlbiZuYnNwO3BhY2tldCBNVVNUIG5vdCBldmVyIHRyYXZlcnNl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBQdXQgaW4gdGhlIHBhY2tldCBzZXQgb2Ygbm9kZXMgb3Ig bGlua3Mgd2hpY2ggdGhlIHBhY2tldCBzaG91bGQgbmV2ZXIgPGJyPg0KJmd0OyB0cmF2ZXJzZS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhdCBnb2VzIGluIGxpbmUgb2YgcmVjZW50IHdhdmUgb2Yg bmVnYXRpdmUgcm91dGluZyBpbXBsZW1lbnRhdGlvbnM8YnI+DQomZ3Q7IChSSUZUKSBvciBkaXNj dXNzaW9ucyAoTFNSKTxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0LDxicj4NCiZndDsgUi48YnI+ DQomZ3Q7IDxicj4NCiZndDsgT24gTW9uLCBBdWcgMywgMjAyMCBhdCAxMTo0NiBQTSBBbmRyZXcg QWxzdG9uIDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tJTIwJTBiIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0 ZWxlY29tLmNvbQ0KPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOkFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNvIOKAkzxicj4NCiZndDsgPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29t ZSB2ZXJ5IG1ham9yIHVzZSBjYXNlcyBpbiBhbnk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNwcmluZyB0ZWNobm9sb2d5IGZvciB1cyByZXZvbHZlIGFyb3VuZCB0aGUgZm9sbG93 aW5nPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEuVGhlIGV4 cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWluIG5vZGVzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGIuVGhlIGV4cGxpY2l0IGF2b2lkYW5jZSBvZiBjZXJ0YWlu IHNlY3Rpb25zIG9mIHRoZSBuZXR3b3JrPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFueXRoaW5nIHRoYXQgY291bGQgcmVzdWx0IGluIHRoYXQgZXhwbGljaXQg YXZvaWRhbmNlIGJlaW5nIHZpb2xhdGVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyDigJMgd291bGQgY3JlYXRlLCBzaGFsbCB3ZSBzYXkgc2lnbmlmaWNhbnQgcHJvYmxlbXMuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE11Y2ggb2YgdGhlIHVz ZSBjYXNlIGlzIG5vdCBhIGNhc2Ugb2Ygd2hpY2ggbm9kZXMgdGhlIHBhY2tldHMgZmxvdzxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhyb3VnaCDigJMgYnV0IHJhdGhlciDigJMg d2hpY2ggbm9kZXMgLyBuZXR3b3JrIHNlZ21lbnRzIGl0IGNhbiBuZXZlcjxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdG91Y2ggb3IgZmxvdyB0aHJvdWdoLiZuYnNwOyBFZmZlY3Rp dmVseSwgdG8gYmUgdXNlZCBhcyBhIHRlY2hub2xvZ3kgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGF2b2lkIGNlcnRhaW4gdGhpbmdzIGZvciBzcGVjaWZpYyByZWFzb25zLjxi cj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIGFsc28g b25lIG9mIHRoZSByZWFzb25zIGZvciBuZWVkaW5nIHN1Y2ggZGVlcCBsYWJlbCBzdGFja3Mg4oCT PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIGtpbmQgb2YgZGV0YWlsZWQg cGF0aCBwcm9ncmFtbWluZyB0ZW5kcyB0byBkZWVwZW4gdGhlIHN0YWNrPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBiZWNhdXNlIHlvdSBzb21ldGltZXMgaGF2ZSB0byBiZSBwcmV0 dHkgZXhwbGljaXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEl0IGlzIGFic29sdXRlbHkgY3JpdGljYWwgdG8gdXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkg aXMgdGhlcmUg4oCTPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgdGhhdCB3 ZSBjYW4gYXZvaWQgc2l0dWF0aW9ucyB3aGljaCBjb3VsZCBjYXVzZSB0cmFmZmljIHRvPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhwbGlj aXRseSBhdm9pZGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJIHdpc2ggSSBjb3VsZCBiZSBtb3JlIHNwZWNpZmljIHRoYW4gdGhpcywgYnV0IGl0IGlzIHdo YXQgaXQgaXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo YW5rczxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbmRyZXc8 YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKkZyb206KiBzcHJp bmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiIgdGFyZ2V0 PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 Jmd0OyAqT24gQmVoYWxmIE9mICpKb2VsIE0uIEhhbHBlcm48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICpTZW50OiogTW9uZGF5LCAzIEF1Z3VzdCAyMDIwIDIxOjM2PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqVG86KiBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVm PSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVr Lm5ldDwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJf YmxhbmsiPm1haWx0bzpyb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKkNjOiogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi4ub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlN1YmplY3Q6KiBS ZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyA8YnI+DQomZ3Q7IGFw cGxpY2FiaWxpdHk8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg KFNpbmNlIHRoZSB0aHJlYWQgaGFzIGdvdHRlbiBsb25nIGVub3VnaCwgcmVpdGVyYXRpbmcgdGhh dCB0aGlzIGlzIGFzIGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcnRpY2lw YW50LCBub3QgYSBXRyBjaGFpci4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFllcywgd2UgYXJlIHRhbGtpbmcgSVAgbmV0d29ya3MuIEFuZCB5ZXMsIEkgaGF2 ZSBzZWVuIElQIG5ldHdvcmtzIHRoYXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNob29zZSB0byBkcm9wIHBhY2tldHMuIEZvciBhbGwgc29ydHMgb2YgcmVhc29ucy48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhlcmUgYXJlIGxpa2VseSBvdGhl ciByZWFzb25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9tPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBwYXRoIHJhdGhlciB0aGFuIGEgY2hvc2VuIFRFIHBhdGguIEkgdGhp bmsgaXQgaXMgaW1wb3J0YW50IHdlIGJlIGNsZWFyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhYm91dCB3aGF0IGNvbnN0cmFpbnRzIG1heSBiZSAvIGFyZSB2aW9sYXRlZCB3aGVu IHdlIHRlbGwgcGVvcGxlIHRoZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhh dmUgdGhpcyB0b29sIChwcm90ZWN0aXZlIHJlcm91dGluZykgdGhhdCBpcyBpbnRlbmRlZCB0byBw cmVzZXJ2ZSBRb1MuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IExldCdzIGJlIGNsZWFyLiBJIGFtIG5vdCBhcmd1aW5nIHRoYXQgdGhpcyBpcyBub3QgYSBnb29k IGlkZWEuIEl0IGlzIGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdvb2QgaWRl YS4gQW5kIHVzZWZ1bC4gSSBhbSB0cnlpbmcgdG8gZmlndXJlIG90dSB3aGF0IGNvbWJpbmF0aW9u IG9mPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRpdGlvbmFsIG1lY2hhbmlz bXMgYW5kIGNsZWFyIGRlc2NyaXB0aW9ucyB3aWxsIGxlYWQgdG8gZXZlcnlvbmU8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdldHRpbmcgdGhlIGJlaGF2aW9yIHRoZXkgZXhwZWN0 ICh3aGljaCBtYXkgbm90IGJlIHRoZSBiZWhhdmlvciB0aGV5PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkZXNpcmUsIGJ1dCBzb21ldGltZXMgaXMgdGhlIGJlc3Qgd2UgY2FuIGRv Lik8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWW91cnMsPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKb2VsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIDgvMy8yMDIwIDI6MzAgUE0sIFJvYmVydCBSYXN6 dWsgd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEpv ZWwsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEFyZSB3ZSBzdGlsbCB0YWxraW5n IGFib3V0IElQIG5ldHdvcmtzJm5ic3A7aGVyZSA/IE9yIHBlcmhhcHMgc29tZSBoYXJkPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHNsaWNpbmcgd2l0aCByZWFs IHJlc291cmNlIHJlc2VydmF0aW9ucyBvciBkZXRuZXRzID88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgQmVjYXVzZSZuYnNwO2lmIHdlIGFyZSB0YWxraW5nJm5ic3A7YWJvdXQgSVAg bmV0d29ya2luZyBJIGhhdmUgdHdvPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBv YnNlcnZhdGlvbnM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEEpIElmIHlvdSBu ZWVkIHRvIHRyYXZlcnNlIHZpYSBhIHNwZWNpZmljIG5vZGUgKGllLiBmaXJld2FsbCkgeW91PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZXR0ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0 IG5vZGUuLiBJIGRvbid0IHRoaW5rIElQPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBlbmNhcHN1bGF0aW9uJm5ic3A7Y2FuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IGJlIGhpamFja2VkIHRvZGF5IHN1Y2ggdGhhdCBkZXN0aW5hdGlvbiBhZGRy ZXNzIG9mIHRoZSBwYWNrZXQgaXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGln bm9yZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEIpIEhhdmUgeW91IHNlZW4g YW55IElQIG5ldHdvcmsgd2hlcmUgdXBvbiB0b3BvbG9neSBjaGFuZ2UgKGxpbms8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIG5vZGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgZmFpbHVyZSkgeW91IHN1ZGRlbmx5Jm5ic3A7c3RhcnQgZHJv cHBpbmcmbmJzcDtmbG93cyBpbiBzcGl0ZSBvZiBTUFQgb2ZmZXJpbmc8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcGVyaGFwcyBmZXcgbXMgbG9uZ2VyIHBhdGgg d2l0aCAxMCBtcyBtb3JlIGppdHRlciA/PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IE9yIGFyZSBzb21lIFNSIG1hcmtldGluZyBzbGlkZXMgcHJvbWlzZSB0byB0dXJuIElQIG5ldHdv cmtzIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHNvbWV0 aGluZyZuYnNwO25ldyA/IFdvcnNlIC4uLiBkbyB0aGV5IG1lbnRpb24gcGF0aCBxdWFsaXR5IGd1 YXJhbnRlZXMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHJl c291cmNlIHJlc2VydmF0aW9ucyZuYnNwOz8gSSBob3BlIG5vdC48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgVGh4LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBSLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDg6MTAgUE0gSm9lbCBNLiBIYWxwZXJuICZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYiIgdGFyZ2V0PSJfYmxhbmsiPmpt aEBqb2VsaGFscGVybi5jb208YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMjAlMGIiIHRhcmdldD0iX2Js YW5rIj5tYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYjwvYT4mZ3Q7Jmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgV2VsbCBsZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90IHN1 cmUgdGhlIHByb2JsZW0gaXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3Ry aWN0ZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG8ganVz dCBzZXJ2aWNlIFNJRHMuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFN1cHBvc2Ug dGhhdCB0aGUgUENFIGhhcyBzcGVjaWZpZWQgdGhlIHBhdGggdG8gbWVldCBzb21lIGNvbXBsZXgg dGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgb2JqZWN0aXZl LiZuYnNwOyBUaGUgYnlwYXNzIG5vZGUgaGFzIG5vIHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2U8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgY29uc3RyYWludHM8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgd2VyZS4mbmJzcDsg QW5kIGZvciBzb21lIGtpbmRzIG9mIHRyYWZmaWMsIGl0IGlzIGJldHRlciB0byBkcm9wIHRoZSBw YWNrZXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhhbiB0 byBkZWxpdmVyIGl0IG91dHNpZGUgdGhlIGVudmVsb3AuJm5ic3A7IEkgc3VzcGVjdCB0aGF0IHRo ZSByaWdodDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhbnN3 ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG8gdGhpcyBp cyAmcXVvdDt0b28gYmFkJnF1b3Q7LiZuYnNwOyBJZiBzbywgYXMgd2l0aCB0aGUgZGlzdGluY3Rp b24gcmVnYXJkaW5nPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IG5vZGVzLCB3ZSBzaG91 bGQgc2F5IHNvLCBzaG91bGRuJ3Qgd2U/PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IFlvdXJzLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBKb2Vs PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9uIDgvMy8yMDIwIDI6MzYgQU0sIEFs ZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7IE1hY2gsIEpvZWwgYW5kIGFsbCw8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCBpbiBtb3N0IGNhc2VzOjxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgMS5UaGVyZSBpcyBjbGVhciBk aWZmZXJlbnRpYXRpb24gYmV0d2VlbiAmcXVvdDt0b3BvbG9naWNhbCZxdW90OyBhbmQ8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3NlcnZpY2UmcXVvdDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBpbnN0cnVjdGlvbnMgaW4g U0lEIGFkdmVydGlzZW1lbnRzLiBFLmcuOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgb0lHUCBQcmVmaXggTm9kZSBTSURzIElHUCBBZGotU0lEcyAoaWRlbnRpZmll ZCBhcyBzdWNoIGluIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IGNvcnJlc3BvbmRpbmcgSUdQIGFkdmVydGlzZW1lbnRzKSByZXByZXNlbnQgdG9w b2xvZ2ljYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluc3RydWN0aW9uczxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgb1NlcnZpY2UgU0lEcyBm b3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92ZXJsYXkgU2VydmljZXM8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ0NjeTltWTZj TWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQlMGIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0NDY3k5bVk2Y01mYms3UWZq aGlBM1I2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRt bCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0PGJyPg0KPC9hPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS8zR0M1YWYyejNKenBoWkRrUG5jSEFRaTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5z ZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0 bWwlMkZkcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0wNF9fJTNCJTIxJTIxTkV0NnlNYU8t Z2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RS RHVpRG80VC1MMG5sJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzNHQzVhZjJ6M0p6cGhaRGtQbmNIQVFpNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZl bnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJG aHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0X18lM0IlMjElMjFORXQ2eU1h Ty1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFr VFJEdWlEbzRULUwwbmwlMjQ8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyBkcmFmdCkgdW5zdXJwcmlzaW5nbHkgcmVwcmVzZW50IOKAnHNlcnZpY2XigJ0g aW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAy LlNlZ21lbnRzIHRoYXQgcmVwcmVzZW50IHRvcG9sb2dpY2FsIGluc3RydWN0aW9ucyBjYW4gYmUg YnlwYXNzZWQsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgd2hpbGUgc2VnbWVudHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMgcmVx dWlyZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhbHRlcm5h dGl2ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHBy b3RlY3Rpb24gbWVjaGFuaXNtcy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IFRoaXMgdmlldyBzZWVtcyB0byBiZSBhbGlnbmVkIHdpdGggUkZDIDg0MDI8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM0NU5MQ0I2VHlkeHV1cVVqdGNEUlp5Nkgy P3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyJTBiIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM0NU5MQ0I2VHlkeHV1 cVVqdGNEUlp5NkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4 NDAyPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zN1B6VUtBRDgyY2pTdm1WY0d2cGtoRjZIMj91 PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0b29scy5p ZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlG WU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJNFlidG0l MjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzdQelVL QUQ4MmNqU3ZtVmNHdnBraEY2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMl MkZfX2h0dHBzJTNBJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjODQwMl9fJTNCJTIxJTIx TkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBS SE9HdDhBa1RSRHVpRG8wSTRZYnRtJTI0PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGF0IHNheXMgaW4gU2VjdGlvbiAxOjxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IEluIHRoZSBjb250ZXh0 IG9mIGFuIElHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFy ZSBkZWZpbmVkOiB0aGUgSUdQLUFkamFjZW5jeSBzZWdtZW50IGFuZCB0aGU8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBJR1AtUHJl Zml4IHNlZ21lbnQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFzZWQgZGlzdHJpYnV0 ZWQgY29udHJvbCBwbGFuZSwgdHdvPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIEJHUCBwZWVyaW5n IHNlZ21lbnQgYW5kIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7Jm5ic3A7IEJHUC1QcmVmaXggc2VnbWVudC48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMgdGhpcyBk aWZmZXJlbnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDMuNCBvZjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRoZSBOb2RlIFByb3RlY3Rpb24gZm9yIFNSLVRFIFBh dGg8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS8zSmJTV0d4NURBZk5Qc1pkaHBFeHh4OTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNr ZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVj dGlvbi1mb3Itc3ItdGUtcGF0aHMtMDclMjNzZWN0aW9uLTMuNCUwYiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zSmJTV0d4NURBZk5Qc1pkaHBFeHh4OTZI Mj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJh ZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDclMjNzZWN0 aW9uLTMuNDxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVm PSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0NyVWdBUlc4c29tQWJ3NlRpc2pnSjE2 SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUt cHJvdGVjdGlvbi1mb3Itc3ItdGUtcGF0aHMtMDclMkFzZWN0aW9uLTMuNF9fJTNCSXclMjElMjFO RXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJI T0d0OEFrVFJEdWlEbzl3Ty1Tc24lMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vM0NyVWdBUlc4c29tQWJ3NlRpc2pnSjE2SDI/dT1odHRwcyUzQSUyRiUy RnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3It dGUtcGF0aHMtMDclMkFzZWN0aW9uLTMuNF9fJTNCSXclMjElMjFORXQ2eU1hTy1nayUyMVMwWXVz eDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzl3Ty1T c24lMjQ8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBk cmFmdCB0aGF0IHNheXM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsmbmJzcDsgVGhlIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3Jp YmVkIGluIHRoZSBwcmV2aW91czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vj dGlvbnM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyZuYnNwOyBkZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVsIGltbWVk aWF0ZWx5IGJlbG93PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IHRoZSB0b3A8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGxhYmVs IGluIHRoZSBsYWJlbCBzdGFjayBpcyB1bmRlcnN0b29kIGluIHRoZSBJR1AgZG9tYWluLiZuYnNw OyBXaGVuIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7Jm5ic3A7IHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBleGNoYW5nZSBzZXJ2aWNlIGxh YmVscyB2aWEgQkdQIG9yIHNvbWU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgb3RoZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyZuYnNwOyBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90dG9tIGxhYmVsIGlz IG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1A8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBkb21haW4uPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgVGhlIGVncmVzcyBu b2RlIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgW1JG Qzg2NzkgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zSmZ2dEJB bWFRUE4xakEzcE02VGRDRTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZodG1sJTJGcmZjODY3OSUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zSmZ2dEJBbWFRUE4xakEzcE02VGRDRTZIMj91PWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODY3OTxicj4NCjwvYT4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzZkTUFqdVlUUW92bzhqSHdtbTNlSnc2SDI/dT1odHRwcyUzQSUyRiUy RnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZodG1sJTJGcmZjODY3OV9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllO RThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG84TUdpcFhjJTI0 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2ZE1BanVZ VFFvdm84akh3bW0zZUp3NkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJG X19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRnJmYzg2Nzlf XyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1 b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOE1HaXBYYyUyNDwvYT4mZ3Q7Jmd0O108YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsgYXBwbGljYWJsZSB0byB0aGlzIHVzZSBjYXNlIGFuZCBubyBh ZGRpdGlvbmFsIGNoYW5nZXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyB3aWxsIGJlIHJlcXVpcmVkIGZvciBTUiBiYXNlZCBuZXR3 b3Jrczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgVGhlIHNjZW5h cmlvcyBpbiB3aGljaCAmbmJzcDtkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiDigJx0b3BvbG9naWNh bOKAnSBhbmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBicm9rZW4gYXJlIGluZGVlZCBwcm9ibGVt YXRpYy4gRS5nLiw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Y29uc2lkZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyB0aGUgdXNlIGNhc2UgaW4gd2hpY2ggYSBOb2RlIFNJRCBpbiB0aGUgRVJPIG9mIGEgU1ItVEUg cGF0aDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpZGVudGlm aWVzIGE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBu b2RlIHRoYXQgYWN0cyBhcyBhIGZpcmV3YWxsIGZvciBhbGwgcGFja2V0cyBpdCByZWNlaXZlcywg aS5lLiw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcHJvdmlk ZXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyB0aGUg ZmlyZXdhbGwgc2VydmljZSB3aXRob3V0IGFueSBkZWRpY2F0ZWQgc2VydmljZSBTSUQ8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgaWRlbnRpZnlpbmcgaXQuPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgT25lIGNvdWxk IHNheSB0aGF0IHRoZSBOb2RlIFNJRCBvZiBzdWNoIGEgbm9kZSB3b3VsZCBjb21iaW5lPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRvcG9sb2dpY2FsPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgYW5kIHNlcnZpY2Ug aW5zdHJ1Y3Rpb25zIHRodXMgYnJlYWtpbmcgdGhlIGRpZmZlcmVudGlhdGlvbjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBiZXR3ZWVuIHRoZSB0d28uPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBJIGFtIG5vdCBzdXJlIGlmIHVz YWdlIG9mIHN1Y2gg4oCcY29tYmluZWTigJ0gU0lEcyBjb3VsZCBiZSBwcmV2ZW50ZWQ8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgb3IgYXQ8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBsZWFzdCBkaXNjb3VyYWdlZC48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IElmIG5vdCwgcHJvdmlk aW5nIGFuIGFiaWxpdHkgdG8gaWRlbnRpZnkgc3VjaCBTSURzIGluIHRoZTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhZHZlcnRpc2VtZW50PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgbWVjaGFuaXNtcyB3b3VsZCBi ZSB1c2VmdWwgSU1ITy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 IE15IDJjLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgU2FzaGE8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IE9mZmljZTogKzk3Mi0z OTI2NjMwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgQ2VsbDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKzk3Mi01NDkyNjYzMDI8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEVtYWlsOiA8YSBocmVmPSJtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCkFsZXhhbmRl ci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBGcm9tOiBzcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyUwYiIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPGJyPg0K PC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmctYm91bmNlc0BpZXRmLm9yZyUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZyUwYjwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyBPbiBC ZWhhbGYgT2YgTWFjaCBDaGVuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMwIEFNPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgVG86IEpvZWwgTS4gSGFs cGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMGIiIHRhcmdldD0i X2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiIiB0YXJn ZXQ9Il9ibGFuayI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20lMGI8L2E+Jmd0OyZndDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDs7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpz cHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAt IGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7IEhpIEpvZWwsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIHBvaW50IHRoYXQgbWF5IG5vdCBiZSBkaXNj dXNzZWQgaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IHBhc3QuIEFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7IEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSBpcyBhICZxdW90O2NhbiBiZSBieXBhc3NlZCZx dW90OyBpbmRpY2F0aW9uIGluIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7IHJvdXRpbmcgYWR2ZXJ0aXNlbWVudCBmb3Igbm93Ljxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSU1ITywgdGhlIGluZm9ybWF0aW9uIGFk dmVydGlzZWQgYnkgcm91dGluZyBpcyBuZXV0cmFsLCBzdWNoPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGluZm9ybWF0aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQp IGlzIG1vcmUgcGF0aCBzcGVjaWZpYywgdGh1czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbm9ybWFsbHkgdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgY29udHJvbGxlciBzaG91bGQgYmUgcmVzcG9uc2libGUgZm9yIGRlY2lkaW5n IHdoZXRoZXIvd2hpY2ggU0lEPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IGNhbiBiZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IGJ5cGFzc2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgQmVzdCByZWdhcmRzLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgTWFjaDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBGcm9tOiBzcHJpbmcgW21haWx0bzo8YSBocmVm PSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmct Ym91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnJTBiJTNlJTIwJTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn JTNlIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTBiJTNl JTIwJTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTNlPC9hPiZndDtdPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBCZWhhbGYgT2YgSm9lbCBNLjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBIYWxwZXJuPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IFNlbnQ6IE1v bmRheSwgQXVndXN0IDMsIDIwMjAgNzo1MSBBTTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYu b3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNjbWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgJmx0 O21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNj bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgU3ViamVjdDogW3NwcmluZ10gU3By aW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IChXRyBDaGFpciBoYXQgT2ZmLCB0 aGlzIGlzIG1lcmVseSBhIG5vdGUgZnJvbSBhIHNsaWdodGx5PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGNvbmZ1c2VkIFdHPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IHBhcnRpY2lwYW50Lik8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSSBoYXZlIGJlZW4gcmVh ZGluZyB0aGUgdmFyaW91cyByZXBhaXIgZHJhZnRzLCBhbmQgdGhlIHZhcmlvdXM8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgbmV0d29ya3MgcHJv Z3JhbW1pbmcgYW5kIHNlcnZpY2UgcHJvZ3JhbW1pbmcgZHJhZnQsIGFuZCBJIGFtPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRyeWluZyB0bzxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBmaWd1cmUgb3V0IG9u ZSBhc3BlY3Qgb2YgdGhlIGNvbWJpbmF0aW9uLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21l IGZvcm0gb2YgYnlwYXNzIChzdXBwb3NlLCBmb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgc2ltcGxpY2l0eSwgaXQgaXMgTm9kZSBOMiBkZWNp ZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBhIGZhaWxlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBub2RlIE4zKSBrbm93IHRoYXQgaXQgaXMgc2FmZSB0 byBkbyBzbz88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVuIGl0IGlzICZxdW90O3NhZmUmcXVv dDsgaWYgdGhlIG5ldyBwYXRoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IG1lZXRzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmZ3Q7IHRoZSBURSBjcml0ZXJpYS4mbmJzcDsgb3IgbWF5YmUgaXQgaXMgc2FmZSBpZiBp dCBpcyBldmVuIGNsb3NlLCBhczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBsb25nIGFzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgQnV0IHdoYXQgaWYgdGhlIG5vZGUg d2VyZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcmVxdWlyZW1lbnRzPzxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBPciB3YXMgc29tZSBv dGhlciBuZWNlc3NhcnkgcHJvZ3JhbW1hdGljIHRyYW5zZm9ybSAod2luY2Ugd2UgYXJlPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IGRlbGliZXJh dGVseSB2YWd1ZSBhYm91dCB3aGF0IG5vZGVzIGNhbiBkbyB3aGVuIGFza2VkIHN1aXRhYmx5Lik8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSXMgdGhl cmUgc29tZSAmcXVvdDtjYW4gYmUgYnlwYXNzZWQmcXVvdDsgaW5kaWNhdGlvbiBpbiB0aGUgcm91 dGluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0 OyBhZHZlcnRpc2VtZW50cyB0aGF0IEkgbWlzc2VkPzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBUaGFuayB5b3UsPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IFlvdXJzLDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBKb2VsPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgPGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0 OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNj bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdA aWV0Zi5vcmcgJmx0O21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUz Y21haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGll dGYub3JnJTIwJTNjbWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVr elc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRw cyUzQSUyPC9hPjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9 Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTd2WDJxV1NVZFdWYzg5Mlh1WHkySDZI Mj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlj a3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0 cHMlMkEzQSUyQTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9p UUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNkh3UExpbCUyNCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTd2WDJxV1NVZFdWYzg5 Mlh1WHkySDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIl M0Z1JTNEaHR0cHMlMkEzQSUyQTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZ TkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNkh3UExpbCUy NDwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTIlMGIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtp VWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTI8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNBNUI4SDJGbTFyUG5hWjNTdXBqd3I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29t JTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVr elc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyNTJfXyUzQkpTVSUyMSUyMU5FdDZ5 TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4 QWtUUkR1aURvem9RaUFIayUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zQTVCOEgyRm0xclBuYVozU3VwandyNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxk ZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYz NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMjUyX18lM0JKU1Ul MjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3 cDZ2cFJIT0d0OEFrVFJEdWlEb3pvUWlBSGslMjQ8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgRiU8YSBocmVmPSJodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzJ5Q2tQS1JydVJqMVpmQ3ZLZ0wyR3E2SDI/dT1odHRw JTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4yRnd3dy5pZXRmLm9yZzwv YT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRw cyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9y Z19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hx Z3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8tcFBDanZSJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9 aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0 Zi5vcmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4 MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLXBQQ2p2UiUyNDwvYT4mZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dXVDlmeWphRmkzRmN2SER2b29kdlM2SDI/dT1odHRw JTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmclMGIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vM0dXVDlmeWphRmkzRmN2SER2b29kdlM2SDI/dT1odHRwJTNBJTJG JTJGMkZ3d3cuaWV0Zi5vcmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM5TnpubVlCdFJ1SEFS aEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRw JTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4 RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLXBQQ2p2UiUyNCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRS dUhBUmhHSjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9f aHR0cCUzQSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlG WU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIl MjQ8L2E+Jmd0OyZndDslMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nQGlldGYub3JnPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2JsYW5r Ij5tYWlsdG86c3ByaW5nQGlldGYub3JnJTBiPC9hPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZzwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1o dHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzwv YT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0JoeUV0eDRRN243NEJoaVJuZk1KdFQ2SDI/dT1odHRw cyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5 bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0El MkEyRiUyQTJGd3d3LmlldGYub3JnJTJBMkZtYWlsbWFuJTJBMkZsaXN0aW5mbyUyQTJGc3ByaW5n X18lM0JKU1VsSlNVbCUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhn bTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLWhSM2dBRCUyNCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQmh5RXR4NFE3bjc0QmhpUm5mTUp0 VDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZj bGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNE aHR0cHMlMkEzQSUyQTJGJTJBMkZ3d3cuaWV0Zi5vcmclMkEyRm1haWxtYW4lMkEyRmxpc3RpbmZv JTJBMkZzcHJpbmdfXyUzQkpTVWxKU1VsJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThF X1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8taFIzZ0FEJTI0PC9h PiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsgTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50 cyBtYXkgY29udGFpbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMg Y29uZmlkZW50aWFsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGFuZC9vcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 IHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4g QW55IHJldmlldyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0OyBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZv cndhcmRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGhvdXQ8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBleHByZXNzIHBlcm1p c3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGludGVuZGVkPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGNvcGllcywgaW5jbHVk aW5nIGFueSBhdHRhY2htZW50cy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdA aWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNB JTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5 VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnNwcmluZzwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8 YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlC VkdFcTE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNB JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nX18lM0IlMjElMjFO RXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJI T0d0OEFrVFJEdWlEbzVLbFBuYmolMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyRiUy RnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5F OEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQ8 L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9hPjxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4 OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5i aiUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJE blNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2 MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJp bmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4 cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyNDwvYT4mZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcHJpbmcgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNL eVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzcHJpbmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9hPjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMjUl MGIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5T VFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSU8YnI+DQo8L2E+Jmd0OyAyRiUyRnVybGRl ZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zMnlDa1BLUnJ1UmoxWmZDdktnTDJHcTZIMj91PWh0dHAlM0ElMkYlMkYyRnd3 dy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjJGd3d3LmlldGYub3JnPC9hPiUyRm1haWxtYW4l MkZsaXN0aTxicj4NCiZndDsgbmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMw WXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndTxicj4NCiZndDsgb1pIZ3dwNnZwUkhPR3Q4 QWtUUkR1aURvNUtsUG5iaiUyNCZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBOb3RpY2U6IFRo aXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIDxicj4N CiZndDsgaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmljYXRpb25zIEluYy4gdGhhdCBpcyBj b25maWRlbnRpYWwgYW5kL29yIDxicj4NCiZndDsgcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVz ZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCA8YnI+DQomZ3Q7IGRpc2Ns b3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3 aXRob3V0IDxicj4NCiZndDsgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCA8YnI+DQomZ3Q7IHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwgPGJy Pg0KJmd0OyBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuPGJyPg0KJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyAtLTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNR MXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzwvYT48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmlu ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNB JTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQ QnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZzcHJpbmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+ PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Tm90aWNlOiBUaGlz IGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBpbmZvcm1h dGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbA0K IGFuZC9vciBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQuIEFueSByZXZpZXcsIGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBi eSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkNCiBhbmQgdGhlbiBkZWxldGUgYWxs IGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNwcmluZyBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM1UFhrS0tUNkV6TFVWZkRUNDQzUW95NkgyP3U9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmciPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_AM0PR03MB449963FAF42D748F7FD7F2E09D5C0AM0PR03MB4499eurp_-- From nobody Tue Aug 18 09:02:49 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0983A0E12 for ; Tue, 18 Aug 2020 09:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, 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=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 mZWj5Vrh8qfX for ; Tue, 18 Aug 2020 09:02:42 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450: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 A51AA3A0E26 for ; Tue, 18 Aug 2020 09:02:40 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id l23so15663691edv.11 for ; Tue, 18 Aug 2020 09:02:40 -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=QvyiHX5vGHtctM0OtsVjmF2QYcE8mzh2bU7RXmAdR78=; b=c9LiSfohDkg8Fdwbsx/q/4M6xQxez/O8r7E7WBvVnxPj3um4bOrEhlWOhXfhviP7wx lvGHMKHa2K3QKI2FIHxW/MbYy4hj8rJEK5X5fsTAZue5M0p1bYoDRTV5cuiielUSVuq3 bq2Gyhq814JTDhy8o450o6jLJHxSfFUm9JCqSiAAg13OII8LRpWZvVTDAfRnqcQrl3ps ZyI5f86w7A8DVyKejbgSbwPnPUxRmygkVWfcXhO0QWV8XCfYbx9E1XZkrRY+TlHirLSt 7xRbaAoOvxqMq40EMQXajwkk2mIE7PvG+QJZT8HCv0NoyytM2gyd/Ht0S4LJ5WM8wqFm dL/w== 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=QvyiHX5vGHtctM0OtsVjmF2QYcE8mzh2bU7RXmAdR78=; b=bguyDP53QNNXMXECLpZIc6wX3dxieISEOdcX20JxrEE8dza4X5/LQ0kf+63aw1cbOZ Sz45q85nAtI8YqzWxxc97YICRMngJKdDvZUgMT5GnKx4Cwgo55tsQb7sJ0iXuTt1yoIY YuSXjhKTQOSvOe+SRv7natcMc30sQGXURfSppuJvTh543iW4XEK9W9rGJthMj+VXNeyy 9a88nwTTVirp87q/pYeeyY6mhFKnFItO9jjldYfcmRhoFfLLQImBG7rJPHfQCgV+x3U6 WIGQpn0ULfOYR6SufCvcxvB2vw3/dPrOZf4MASz02aNr5zb5JKH+SuKdvhOOWgZPKodg 3AzQ== X-Gm-Message-State: AOAM532KEGIyhklhpWxvCj2VnGlVqe1BIdAOiRZOzHN/cQKdl6fuI/QU PUUXS8X40j7d43geHMuhQZG26cE9SEbT+qCpVNDnJg== X-Google-Smtp-Source: ABdhPJxYxg+txEHYjc3jU+8BDo2eqcwOGbCxnXE2jbDncJVXgOcYz3Flg1ZrsPgoOgRsMSPLs76tGd4iefFXntQqi/c= X-Received: by 2002:a05:6402:2042:: with SMTP id bc2mr20691389edb.109.1597766558642; Tue, 18 Aug 2020 09:02:38 -0700 (PDT) MIME-Version: 1.0 References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> In-Reply-To: From: Robert Raszuk Date: Tue, 18 Aug 2020 18:02:27 +0200 Message-ID: To: Alexander Vainshtein Cc: Martin Horneffer , "EXT-Andrew.Alston@liquidtelecom.com" , Shraddha Hegde , "Ketan Talaulikar (ketant)" , "Joel M. Halpern" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000298d7405ad2904bb" Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:02:48 -0000 --000000000000298d7405ad2904bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I also think that service nodes that cannot be bypassed typically would advertise themselves as =E2=80=9Cstub nodes=E2=80=9D in IGP That is not always possible without extra cost. I guess "service" means many things to various people :) I have real production case where only a small subset of traffic should be subject to firewall check or even subject to heavy interface ACL processing on a transit node. I guess the hope I have seen in this thread was ability to indicate such mandate with different prefix SID. If not of course there is few alternatives (within and outside of SR domain) to use so this is not like end of the world. I guess here we are sort of discussing how to handle various use cases. Cheers, R. On Tue, Aug 18, 2020 at 5:44 PM Alexander Vainshtein < Alexander.Vainshtein@rbbn.com> wrote: > Martin, > > Lots of thanks for an important input to this discussion. > > > > I fully agree with you that ability to turn off the node protection schem= e > for a specific PLR neighbor (i.e., on a specific PLR port) by suitable > local configuration in the PLR is definitely required. Such an ability > would probably address most (if not all) scenarios associated with the > so-called =E2=80=9Cservice nodes=E2=80=9D that cannot be bypassed. > > > > I also think that service nodes that cannot be bypassed typically would > advertise themselves as =E2=80=9Cstub nodes=E2=80=9D in IGP in order to p= revent inadvertent > application of their service function to transit traffic (which could > otherwise pass thru the service node due to some topology change). > Therefore a local policy that would exclude IGP neighbors advertising > themselves as stub nodes in IGP from the node protection scheme could be > also useful. > > > > Last but not least, ability of the node to advertise a specific Prefix SI= D > it originates as =E2=80=9Cnot eligible for bypass protection=E2=80=9D (e.= g., using a new > flag in the Prefix Node TLV for IS-IS or OSPF) should be considered. > > > > My 2c, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* spring *On Behalf Of *Martin Horneffer > *Sent:* Tuesday, August 18, 2020 5:51 PM > *To:* spring@ietf.org > *Cc:* Alexander Vainshtein ; Robert Raszuk > ; EXT-Andrew.Alston@liquidtelecom.com < > Andrew.Alston@liquidtelecom.com>; Shraddha Hegde ; > Ketan Talaulikar (ketant) ; Joel M. > Halpern > *Subject:* Re: [spring] Spring protection - determining applicability > > > > A few thoughts from my (operator's) PoV: > > - The disussion is a very good and important one. It probably should be > discussed and documented well in order to justify the proposed protection= s > mechanisms. > > - Not all operators seem to have the same requirements. > (A somewhat similar discussion might be the one for disjoint paths. > Those are often equired by voice signalling applications. In some cases t= he > voice service demands that traffic is blackholed rather than on forwarded > on the wrong path. In other cases disjoint paths are just required for th= e > "good case". Traffic MAY be forwarded on the wrong path, as long as the > network just makes sure the traffic on the other path is never affected b= y > the same failure.) > > - Personally I would hate to see yet another IGP extension for this > purpose. > > - I would rather prefer a good discussion of what can be achieved by > using easy to make switches: > - The protection behaviour could be switched on or off per node. > - An operator with strict "some traffic may never touch certain > parts of the network" requirements might switch off the behaviour, while > others might switch it on. > - A node could allow a switch even individually for every port or > neighbor. > - If a node knows that one of it's neighbours is a service node > rather than a plain topological one, it could switch off protection. This > is how I would prefer to solve the problem with serrvice nodes. > > Should this be discussed in the protection document, or in a separate one= ? > > Best regards, Martin > > Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant): > > Hi Robert, > > > > We do not have a signalling mechanism in IGPs today to indicate a > =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If there was a = desire for it, an > IGP extension would be required (there is none in progress AFAIK). Note > that this results in doubling the prefix SID scale (global labels) in the > network. So I would not go about this trivially. > > > > I think it helps to get more inputs and perspectives from operators on > their views for doing a bypass via local protection for segments in an SR > Policy. There may be those that prefer end-to-end path protection using a > fallback path that is say disjoint with the primary but provides an > appropriate SLA/intent? > > > > Thanks, > > Ketan > > > > *From:* Robert Raszuk > *Sent:* 14 August 2020 23:04 > *To:* Ketan Talaulikar (ketant) > *Cc:* Alexander Vainshtein > ; Joel M. Halpern > ; Shraddha Hegde > ; EXT-Andrew.Alston@liquidtelecom.com > ; > spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Ketan, > > > > Looks like we are pretty much in sync here. > > > > But let me just observe that I purposely did not mention about SR policie= s > as we are not able to signal the intent with the packets itself. > > > > So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded wit= h > information if policies build with using them are bypass eligible or not. > > > > I was actually under the impression that this is already there and I am > just not aware, but looking deeper indeed I do not see this marking neith= er > in ISIS nor OSPF for prefix SIDs. > > > > Is there some work in progress to add it to those protocols or have we > just documented need for a short LSR draft ? > > > > Thx, > > R. > > > > > > On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) < > ketant@cisco.com> wrote: > > Hi Robert, > > > > Please check inline below. > > > > *From:* Robert Raszuk > *Sent:* 14 August 2020 21:13 > *To:* Ketan Talaulikar (ketant) > *Cc:* Alexander Vainshtein ; Joel M. > Halpern ; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi Ketan, > > > > While I completely agree with your note the consequences of it are pretty > sevre. > > *[KT] I understand. We need to be mindful of implications of protection > schemes for the SLAs/intent of SR Policies.* > > > > Unless we signal which prefix SID is protection eligible and which is not > how would other nodes know if they can protect it or not ? > > *[KT] Correct. To be more accurate, we need to consider this more in the > context of SLA or =E2=80=9Cintent=E2=80=9D of SR Policies and which segme= nts may be > =E2=80=9Cbypass-able=E2=80=9D for local protection for some of those SR P= olicies. We also > have path-protection mechanisms.* > > > > It seems that today's safe thing is not to apply any node protection on S= R > flows at the PLRs then. > > > > And link protection MUST assure that packets will arrive at the neighbor > node via some other link regardless of further path towards destination. > > *[KT] Yes. We have a mechanism to indicate which adj-SIDs have protection > (that mechanism only provides link protection to get to the neighbor node= ) > so the SR Policy computation is able to indicate whether that specific li= nk > is =E2=80=9Cbypass-able=E2=80=9D or not by its choice of protected or unp= rotected adj-SIDs > respectively.* > > > > *Thanks,* > > *Ketan* > > > > Is it correct ? > > > > Thx > > R > > > > On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) < > ketant@cisco.com> wrote: > > Hi Sasha, > > > > The service node advertises its own Prefix SID. The service function that > this service node implements does not require any context (i.e. all packe= ts > arriving at the node are subjected to that service). Therefore the servic= e > node does not need to receive a packet with it=E2=80=99s own Prefix SID. > > > > Thus, we cannot assume that when PHP is used, then the SID is only > associated with a topological instruction. > > > > Hope that clarifies? > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 20:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Shraddha Hegde ; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Ketan, and all, > > I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are > advertised with PHP can ONLY represent topological instructions in SR-MP= LS > - because the advertising node will not receive them and therefore can > hardly be expected to associate any service function with them. > > > > This is complementary to what you have said. > > > > Hope this clarifies my position. > > What, if anything, did I miss? > > > > Regards, > > Sasha > > > > Get Outlook for Android > > > > ------------------------------ > > *From:* Ketan Talaulikar (ketant) > *Sent:* Friday, August 14, 2020, 16:23 > *To:* Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* RE: [spring] Spring protection - determining applicability > > > ------------------------------ > > NOTICE: This email was received from an EXTERNAL sender > ------------------------------ > > > > Hi Sasha, > > > > If the service does not need any additional context (e.g. a firewall that > just applies locally configured default rules on it), then I don=E2=80=99= t see why > PHP could not be done for a Prefix SID associated with a service node. > > > > Also, I didn=E2=80=99t follow the point that you were trying to make abou= t > Adj-SIDs. > > > > Thanks, > > Ketan > > > > *From:* Alexander Vainshtein > *Sent:* 14 August 2020 18:24 > *To:* Ketan Talaulikar (ketant) ; Joel M. Halpern < > jmh@joelhalpern.com>; Alexander Vainshtein ; > Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.co= m > ; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi all, > > Regarding the statement "Prefix SID could be just a topological > instruction or may also be used to steer the flow to a node which is > applying a service function to it": > > > > > > I think that in SR-MPLS a Node SID that is advertised with PHP aciton can > be safely considered as "just a topological instruction" by the PLR becau= se > the originating node will not receive it. > > The same applies to Adj-SDIs. > > > > My 2c. > > > > Get Outlook for Android > > > > ------------------------------ > > *From:* spring on behalf of Ketan Talaulikar > (ketant) > *Sent:* Friday, August 14, 2020, 15:00 > *To:* Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; > EXT-Andrew.Alston@liquidtelecom.com; Robert Raszuk > *Cc:* spring@ietf.org > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Hi All, > > I would like to share a different perspective on this. > > First, thanks to Joel for bringing up the discussion. Clearly we need a > well-defined applicability statement for determining applicability of > protection for segment used in an SR Policy. Some of this is captured in > [1]. > > This is about local repair at a PLR. By it's very nature, the PLR does no= t > have a notion of how "strict or not" is the SLA that is being provided by > the SR Policy. Awareness of that notion exists at the SR Policy headend > and/or computation-node. > > We have protected and un-protected variants of adjacency SIDs to enable > the computation to pick or the other based on the "strictness" of the SLA > requirement for picking that link. We do not have such a notion for Prefi= x > SIDs. One can say that we could introduce signalling (e.g. a B flag) to > indicate whether a Prefix SID can be bypassed or not. This provides the > opportunity for the computation to use one or the other flavor depending = on > the nature of the SLA for the SR Policy. > > I have a problem and a concern in the assumption that PLRs can assume tha= t > the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) a= re > "bypass-able". > > As Joel and others have brought out, the Prefix SID could be just a > topological instruction or may also be used to steer the flow to a node > which is applying a service function to it. In order to support a mix of = SR > Policies of different SLAs (strict and not-strict), we need to enable the > choice of SIDs that indicates to the PLR whether they are "bypass-able" o= r > not. > > For the cases, where the SR Policy has a specific SLA, it is required for > nodes to drop the packets meant for the "active segment" than to bypass i= t. > When this mechanism is used along side SRTE path monitoring mechanisms, i= t > enables the headend to detect the failure and fallback to an alternate pa= th > using the path protection approach. This is something that is described a= nd > in use in deployments today [1].. > > Thanks, > Ketan > > [1] > https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9 > [2] > https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23se= ction-9.3 > > -----Original Message----- > From: spring On Behalf Of Joel M. Halpern > Sent: 04 August 2020 20:25 > To: Alexander Vainshtein ; Shraddha Hegde = < > shraddha=3D40juniper.net@dmarc.ietf.org>; > EXT-Andrew.Alston@liquidtelecom.com ; > Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability > > There are, as far as I can tell, a number of ways to address this family > of related questions. > What struck me, and prompted the starting question, was that none of them > were spelled out. I see lots of interesting ideas / proposals. > Some of them are compatible with others. Some are not. > It would be good if we could reach agreement on how we thought it should > be handled. > > Thank you, > Joel > > On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > > Hi all, > > > > I am still not sure that the problem of bypass going thru undesirable > > links/nodes exists in the case of topological SIDs. > > > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > > < > https://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%= 2Ftools.ietf.org%2Fhtml%2Frfc4090>) > has been successfully deployed > > for many years before SR-MPLS has been introduced. What=E2=80=99s more, > > signaling of bypass tunnels he PLR usually did not include any of the > > constraints used for computing of any specific LSP that the bypass LSP > > would protect =E2=80=93 because in the Facility Protection mode the sam= e > > bypass LSP would be used to protect multiple LSPs passing thru the > > failed link/node. > > > > From my POV the only difference between this behavior and that > > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in = the case of > > RSVP-TE, the operator would explicitly indicate, as part of LSP > > signaling, whether it would or would not use FRR; LSPs that would not > > use FRR would then drop traffic rather than delivering it the wrong way= . > > > > Such an option indeed does not exist in SR-TE today, but would be easy > > to provide if so desired IMHO. > > > > Did I miss something substantial? > > > > Regards, and lots of thanks in advance, > > > > Sasha > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* spring *On Behalf Of *Shraddha Hegde > > *Sent:* Tuesday, August 4, 2020 9:41 AM > > *To:* EXT-Andrew.Alston@liquidtelecom.com > > ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > All, > > > > This is a very interesting discussion and thanks to Joel for starting > > this discussion. IMO, when there are strict requirements of avoiding > > certain nodes/links it can be realized either by defining a flex-algo > > avoiding those > > > > Nodes and links or by using a stack of unprotected adj-sids that avoid > > restricted nodes and links. When a stack of adj-sids is used to > > realize the path, the head-end based (sBFD) protection mechanisms can b= e > applied. > > > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > > failure events may cause traffic to go through restricted nodes and > > links. This would happen regardless of whether any kind of protection > > is in use or not. > > > > Rgds > > > > Shraddha > > > > Juniper Business Use Only > > > > *From:* spring > >> *On Behalf Of *Andrew Alston > > *Sent:* Tuesday, August 4, 2020 5:41 AM > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf.org >; Joel > M. Halpern > > >= > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > *[External Email. Be cautious of content]* > > > > Robert this is actually far more difficult when =E2=80=93 it can be an = entire > > (long) series of nodes that need to be avoided. > > > > It could potentially be made to work but I=E2=80=99d worry that to do t= his =E2=80=93 > > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative label= s =E2=80=93 and that wouldn=E2=80=99t > > be viable. > > > > It=E2=80=99s easier to use algorithms and adjacency sids and other such= things > > to calculate paths =E2=80=93 the biggest trick is about the stack depth= . When > > you have this need for node avoidance =E2=80=93 the need for 10+ label = depth > > is critical =E2=80=93 unless you wanna be applying one hell of a lot of > > binding labels along the way which is a nightmare. > > > > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use > > case that most of the people I discuss this with certain have =E2=80=93= I cant > > comment on a global scale, or for anyone else, but every indication I > > have is that yes =E2=80=93 its something people need, and want > > > > Andrew > > > > *From:* Robert Raszuk >> > > *Sent:* Tuesday, 4 August 2020 01:27 > > *To:* Andrew Alston > < > mailto:Andrew.Alston@liquidtelecom.com >= > > > *Cc:* Joel M. Halpern > >>; spring@ietf.org > > > > > *Subject:* Re: [spring] Spring protection - determining applicability > > > > Is this a common use case ie. "but rather =E2=80=93 which nodes / netw= ork > > segments it can never touch or flow through." > > > > If so perhaps its time to define notion of *negative-SID* ie. list in > > the packet resources which given packet MUST not ever traverse. > > > > Put in the packet set of nodes or links which the packet should never > > traverse. > > > > That goes in line of recent wave of negative routing implementations > > (RIFT) or discussions (LSR) > > > > Best, > > R. > > > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > < > mailto:Andrew.Alston@liquidtelecom.com >= > > wrote: > > > > So =E2=80=93 > > > > One of the use cases, in fact, some very major use cases in any > > spring technology for us revolve around the following > > > > a.The explicit avoidance of certain nodes > > > > b.The explicit avoidance of certain sections of the network > > > > Anything that could result in that explicit avoidance being violate= d > > =E2=80=93 would create, shall we say significant problems. > > > > Much of the use case is not a case of which nodes the packets flow > > through =E2=80=93 but rather =E2=80=93 which nodes / network segmen= ts it can never > > touch or flow through. Effectively, to be used as a technology to > > avoid certain things for specific reasons. > > > > This is also one of the reasons for needing such deep label stacks = =E2=80=93 > > this kind of detailed path programming tends to deepen the stack > > because you sometimes have to be pretty explicit. > > > > It is absolutely critical to us that this functionality is there = =E2=80=93 > > and that we can avoid situations which could cause traffic to > > accidently hit things explicitly avoided. > > > > I wish I could be more specific than this, but it is what it is. > > > > Thanks > > > > Andrew > > > > *From:* spring > >> *On Behalf Of *Joel M. Halpern > > *Sent:* Monday, 3 August 2020 21:36 > > *To:* Robert Raszuk >> > > *Cc:* spring@ietf..org > > > *Subject:* Re: [spring] Spring protection - determining > > applicability > > > > (Since the thread has gotten long enough, reiterating that this is > as a > > participant, not a WG chair.) > > > > Yes, we are talking IP networks. And yes, I have seen IP networks > that > > choose to drop packets. For all sorts of reasons. > > I think there are likely other reasons why one may not want a rando= m > > path rather than a chosen TE path. I think it is important we be > clear > > about what constraints may be / are violated when we tell people th= ey > > have this tool (protective rerouting) that is intended to preserve > QoS. > > > > Let's be clear. I am not arguing that this is not a good idea. It i= s > a > > good idea. And useful. I am trying to figure otu what combination o= f > > additional mechanisms and clear descriptions will lead to everyone > > getting the behavior they expect (which may not be the behavior the= y > > desire, but sometimes is the best we can do.) > > > > Yours, > > Joel > > > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > > Joel, > > > > > > Are we still talking about IP networks here ? Or perhaps some ha= rd > > > slicing with real resource reservations or detnets ? > > > > > > Because if we are talking about IP networking I have two > > observations: > > > > > > A) If you need to traverse via a specific node (ie. firewall) yo= u > > better > > > apply IP encapsulation to that node.. I don't think IP > > encapsulation can > > > be hijacked today such that destination address of the packet is > > ignored. > > > > > > B) Have you seen any IP network where upon topology change (link > > or node > > > failure) you suddenly start dropping flows in spite of SPT > offering > > > perhaps few ms longer path with 10 ms more jitter ? > > > > > > Or are some SR marketing slides promise to turn IP networks in > > > something new ? Worse ... do they mention path quality guarantee= s, > > > resource reservations ? I hope not. > > > > > > Thx, > > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern < > jmh@joelhalpern.com > > >> >> wrote: > > > > > > Well less serious for TE SIDs, I am not sure the problem is > > restricted > > > to just service SIDs. > > > > > > Suppose that the PCE has specified the path to meet some complex > te > > > objective. The bypass node has no way of knowing what those > > > constraints > > > were. And for some kinds of traffic, it is better to drop the > packet > > > than to deliver it outside the envelop. I suspect that the righ= t > > > answer > > > to this is "too bad". If so, as with the distinction regarding > > service > > > nodes, we should say so, shouldn't we? > > > > > > Yours, > > > Joel > > > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > > Mach, Joel and all, > > > > > > > > I think that in most cases: > > > > > > > > 1.There is clear differentiation between "topological" and > > "service" > > > > instructions in SID advertisements. E.g.: > > > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > > corresponding IGP advertisements) represent topological > > instructions > > > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > > > < > https://clicktime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04 > > > > < > https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQ= AtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24 > >> > > > > > > > draft) unsurprisingly represent =E2=80=9Cservice=E2=80=9D inst= ructions > > > > > > > > 2.Segments that represent topological instructions can be > bypassed, > > > > while segments that represent service instructions require > > > alternative > > > > protection mechanisms. > > > > > > > > This view seems to be aligned with RFC 8402 > > > > < > https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Frfc8402 > > > > < > https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24 > >> > > that says in Section 1: > > > > > > > > In the context of an IGP-based distributed control plane, > two > > > > > > > > topological segments are defined: the IGP-Adjacency segment an= d > the > > > > > > > > IGP-Prefix segment. > > > > > > > > In the context of a BGP-based distributed control plane, t= wo > > > > > > > > topological segments are defined: the BGP peering segment and > the > > > > > > > > BGP-Prefix segment. > > > > > > > > In the case of SR-MPLS this differentiation is assumed in > Section > > > 3.4 of > > > > the Node Protection for SR-TE Path > > > > > > > > > < > https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-f= or-sr-te-paths-07%23section-3.4 > > > > < > https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fd= raft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 9wO-Ssn%24 > >> > > > > > > > draft that says: > > > > > > > > The node protection mechanism described in the previous > > sections > > > > > > > > depends on the assumption that the label immediately below > > > the top > > > > > > > > label in the label stack is understood in the IGP domain. Whe= n > the > > > > > > > > provider edge routers exchange service labels via BGP or > some > > > other > > > > > > > > non-IGP mechanism the bottom label is not understood in th= e > IGP > > > > > > > > domain. > > > > > > > > The egress node protection mechanisms described in the dra= ft > > > > > > > > [RFC8679 < > https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679 > > > > < > https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fr= fc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRH= OGt8AkTRDuiDo8MGipXc%24 > >>] > > is > > > > applicable to this use case and no additional changes > > > > > > > > will be required for SR based networks > > > > > > > > The scenarios in which differentiation between =E2=80=9Ctopol= ogical=E2=80=9D > and > > > > =E2=80=9Cservice=E2=80=9D instructions is broken are indeed pr= oblematic. E.g., > > > consider > > > > the use case in which a Node SID in the ERO of a SR-TE path > > > identifies a > > > > node that acts as a firewall for all packets it receives, i.e.= , > > > provides > > > > the firewall service without any dedicated service SID > > > identifying it. > > > > One could say that the Node SID of such a node would combine > > > topological > > > > and service instructions thus breaking the differentiation > > > between the two. > > > > > > > > I am not sure if usage of such =E2=80=9Ccombined=E2=80=9D SIDs= could be > prevented > > > or at > > > > least discouraged. > > > > > > > > If not, providing an ability to identify such SIDs in the > > > advertisement > > > > mechanisms would be useful IMHO. > > > > > > > > My 2c, > > > > > > > > Sasha > > > > > > > > Office: +972-39266302 > > > > > > > > Cell: +972-549266302 > > > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > > > > > > > -----Original Message----- > > > > From: spring > >> > > >> On > Behalf Of Mach Chen > > > > Sent: Monday, August 3, 2020 6:30 AM > > > > To: Joel M. Halpern > >> >>; > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > Subject: Re: [spring] Spring protection - determining > applicability > > > > > > > > Hi Joel, > > > > > > > > I think this is a good point that may not be discussed in the > > > past. And > > > > I also don't think there is a "can be bypassed" indication in > the > > > > routing advertisement for now. > > > > > > > > IMHO, the information advertised by routing is neutral, such > > > information > > > > (can or cannot be bypassed) is more path specific, thus > > normally the > > > > controller should be responsible for deciding whether/which SI= D > > > can be > > > > bypassed. > > > > > > > > Best regards, > > > > > > > > Mach > > > > > > > > > -----Original Message----- > > > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > > > > < > mailto:spring-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%= 3e > >] > > On Behalf Of Joel M. > > > > > > > > > Halpern > > > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > > > To: spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > Subject: [spring] Spring protection - determining > applicability > > > > > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > > confused WG > > > > > > > > > participant.) > > > > > > > > > > > > > > > > > > I have been reading the various repair drafts, and the > various > > > > > > > > > networks programming and service programming draft, and I a= m > > > trying to > > > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, > for > > > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID f= or > > > a failed > > > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new > path > > > meets > > > > > > > > > the TE criteria. or maybe it is safe if it is even close, = as > > > long as > > > > > > > > > it is not used for too long. > > > > > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet lega= l > > > > requirements? > > > > > > > > > Or was some other necessary programmatic transform (wince w= e > are > > > > > > > > > deliberately vague about what nodes can do when asked > suitably.) > > > > > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > Yours, > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > spring mailing list > > > > > > > > > spring@ietf.org > > > > > > > > < > mailto:spring@ietf.org%20%3cmailto:spring@ietf.org > >>> > > > > > > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2 > > > < > https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8= E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%24 > > > > > > > > > > > < > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%25= 2 > > > > < > https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW= 9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE= 8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozoQiAHk%24 > >> > > > > > > > > > F%2Fwww.ietf.org > > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > > > > > < > https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%= 2F2Fwww.ietf.org > > > > < > https://clicktime.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%2= 1S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24 > >>%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > > > > > > > spring mailing list > > > > > > > > spring@ietf.org > > > > > = >> > >> > > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F367qhU4KiUkz= W9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flisti= nfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0= wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24 > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Notice: This e-mail together with any attachments may contain > > > > information of Ribbon Communications Inc. that is confidential > > > and/or > > > > proprietary for the sole use of the intended recipient. Any > review, > > > > disclosure, reliance or distribution by others or forwarding > > without > > > > express permission is strictly prohibited. If you are not the > > > intended > > > > recipient, please notify the sender immediately and then delet= e > all > > > > copies, including any attachments. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > < > mailto:spring@ietf.org > > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > < > https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHO= Gt8AkTRDuiDo5KlPnbj%24 > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org > > %2Fmailman%2Flisti > > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > > > > > ---------------------------------------------------------------------- > > -- > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. that is confidential and/or > > proprietary for the sole use of the intended recipient. Any review, > > disclosure, reliance or distribution by others or forwarding without > > express permission is strictly prohibited. If you are not the intended > > recipient, please notify the sender immediately and then delete all > > copies, including any attachments. > > ---------------------------------------------------------------------- > > -- > > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > _______________________________________________ > spring mailing list > spring@ietf.org > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > ------------------------------ > > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. that is confidential and/or proprietary for > the sole use of the intended recipient. Any review, disclosure, reliance = or > distribution by others or forwarding without express permission is strict= ly > prohibited. If you are not the intended recipient, please notify the send= er > immediately and then delete all copies, including any attachments. > ------------------------------ > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > --000000000000298d7405ad2904bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    > I also think that service nodes = that cannot be bypassed typically would advertise themselves as =E2=80=9Cst= ub nodes=E2=80=9D in IGP=C2=A0=C2=A0

    That is = not always possible without extra cost. I guess "service" means m= any things to various=C2=A0people :)=C2=A0

    I have = real production case where only a small subset of traffic should be subject= to firewall check or even subject to heavy interface ACL processing on a t= ransit node.=C2=A0

    I guess the hope I have seen in= this thread was ability to indicate such mandate with different=C2=A0prefi= x=C2=A0SID.=C2=A0

    If not of course there is few al= ternatives (within and outside of SR domain) to use so this is not like end= of the world. I guess here we are sort of discussing how to handle various= use cases.=C2=A0

    Cheers,
    R.
    <= br>




    On Tue, Aug 18, 2020= at 5:44 PM Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> wrote:

    Martin,<= u>

    Lots of thanks = for an important input to this discussion.

    =C2=A0

    I fully agree w= ith you that ability to turn off the node protection scheme for a specific = PLR neighbor (i.e., on a specific PLR port) by suitable local configuration= in the PLR is definitely required. Such an ability would probably address most (if not all) scenarios associated with= the so-called =E2=80=9Cservice nodes=E2=80=9D that cannot be bypassed.<= /u>

    =C2=A0

    I also think th= at service nodes that cannot be bypassed typically would advertise themselv= es as =E2=80=9Cstub nodes=E2=80=9D in IGP in order to prevent inadvertent a= pplication of their service function to transit traffic (which could otherwise pass thru the service node due to some topology change). T= herefore a local policy that would exclude IGP neighbors advertising =C2=A0= themselves as stub nodes in IGP from the node protection scheme could be al= so useful.

    =C2=A0

    Last but not le= ast, ability of the node to advertise a specific Prefix SID it originates a= s =E2=80=9Cnot eligible for bypass protection=E2=80=9D (e.g., using a new f= lag in the Prefix Node TLV for IS-IS or OSPF) should be considered.

    =C2=A0

    My 2c,

    Sasha=

    =C2=A0

    Office: +972-39= 266302

    Cell:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 +972-549266302

    Email:=C2=A0=C2= =A0 A= lexander.Vainshtein@ecitele.com

    =C2=A0

    From: spring <spring-bounces@ietf.org> On Beha= lf Of Martin Horneffer
    Sent: Tuesday, August 18, 2020 5:51 PM
    To: spring@ietf= .org
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Robert R= aszuk <robert@ras= zuk.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidte= lecom.com>; Shraddha Hegde <shraddha@juniper.net>; Ketan Talaulikar (ketant= ) <ketant=3D40cisco.com@dmarc.ietf.org>; Joel M. Halpern <jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability<= u>

    =C2=A0

    A few thoughts from my = (operator's) PoV:

    =C2=A0- The disussion is a very good and important one. It probably should = be discussed and documented well in order to justify the proposed protectio= ns mechanisms.

    =C2=A0- Not all operators seem to have the same requirements.
    =C2=A0=C2=A0=C2=A0 (A somewhat similar discussion might be the one for disj= oint paths. Those are often equired by voice signalling applications. In so= me cases the voice service demands that traffic is blackholed rather than o= n forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forw= arded on the wrong path, as long as the network just makes sure the traffic= on the other path is never affected by the same failure.)

    =C2=A0- Personally I would hate to see yet another IGP extension for this p= urpose.

    =C2=A0- I would rather prefer a good discussion of what can be achieved by = using easy to make switches:
    =C2=A0=C2=A0=C2=A0 - The protection behaviour could be switched on or off p= er node.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - An operator with strict "some t= raffic may never touch certain parts of the network" requirements migh= t switch off the behaviour, while others might switch it on.
    =C2=A0=C2=A0=C2=A0 - A node could allow a switch even individually for ever= y port or neighbor.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - If a node knows that one of it's= neighbours is a service node rather than a plain topological one, it could= switch off protection. This is how I would prefer to solve the problem wit= h serrvice nodes.

    Should this be discussed in the protection document, or in a separate one?<= br>
    Best regards, Martin

    Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketan= t):

    Hi Robert,

    =C2=A0

    We do not have a signalling mechanism in IGPs today = to indicate a =E2=80=9Cbypass-able=E2=80=9D indication for Prefix SIDs. If = there was a desire for it, an IGP extension would be required (there is non= e in progress AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go abo= ut this trivially.

    =C2=A0

    I think it helps to get more inputs and perspectives= from operators on their views for doing a bypass via local protection for = segments in an SR Policy. There may be those that prefer end-to-end path pr= otection using a fallback path that is say disjoint with the primary but provides an appropriate SLA/intent?

    =C2=A0

    Thanks,

    Ketan

    =C2=A0

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 23:04
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@joelhalper= n.com>; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability<= u>

    =C2=A0

    Ketan,

    =C2=A0

    Looks like we are pretty much in sync here.=C2=A0=

    =C2=A0

    But let me just observe that I purposely=C2=A0did no= t mention about SR policies as we are not able to signal the intent with th= e packets itself.=C2=A0

    =C2=A0

    So all we have there is SIDs. BSIDs or prefix SIDs n= eed to be flooded with information if policies build with using them are by= pass eligible or not.=C2=A0

    =C2=A0

    I was actually under the impression that this is alr= eady there and I am just not aware, but looking deeper indeed I do not see = this marking neither in ISIS nor OSPF for prefix SIDs.=C2=A0<= /p>

    =C2=A0

    Is there some work in progress to add it to those pr= otocols or have we just documented need=C2=A0for a short LSR draft=C2=A0 ?= =C2=A0

    =C2=A0

    Thx,

    R.

    =C2=A0

    =C2=A0

    On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:

    Hi Robert,

    =C2=A0

    Please check inline below.

    =C2=A0

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 21:13
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability<= u>

    =C2=A0

    Hi Ketan,

    =C2=A0

    While I completely agree with your note the conseque= nces of it are pretty sevre.=C2=A0

    [KT] I understand. We need to be mindful of im= plications of protection schemes for the SLAs/intent of SR Policies.

    =C2=A0

    Unless we signal which prefix SID is protection elig= ible and which is not how would other nodes know if they can protect it or = not ?=C2=A0

    [KT] Correct. To be more accurate, we need to = consider this more in the context of SLA or =E2=80=9Cintent=E2=80=9D of SR = Policies and which segments may be =E2=80=9Cbypass-able=E2=80=9D for local = protection for some of those SR Policies. We also have path-protection mechanisms.

    =C2=A0

    It seems that today's safe thing is not to apply= any node protection on SR flows at the PLRs then.=C2=A0

    =C2=A0

    And link protection MUST assure that packets will ar= rive at the neighbor node via some other link regardless of further path to= wards destination.=C2=A0

    [KT] Yes. We have a mechanism to indicate whic= h adj-SIDs have protection (that mechanism only provides link protection to= get to the neighbor node) so the SR Policy computation is able to indicate whether that specific link is =E2=80=9Cbypass-able=E2= =80=9D or not by its choice of protected or unprotected adj-SIDs respective= ly.

    =C2=A0

    Thanks,

    Ketan

    =C2=A0

    Is it correct ?=C2=A0

    =C2=A0

    Thx

    R

    =C2=A0

    On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:

    Hi Sasha,

    =C2=A0

    The service node advertises its own Prefix SID. The = service function that this service node implements does not require any con= text (i.e. all packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a pa= cket with it=E2=80=99s own Prefix SID.

    =C2=A0

    Thus, we cannot assume that when PHP is used, then t= he SID is only associated with a topological instruction.

    =C2=A0

    Hope that clarifies?

    =C2=A0

    Thanks,

    Ketan

    =C2=A0

    From: Alexander Vainshtein <Alexander.Vainshtein@r= bbn.com>
    Sent: 14 August 2020 20:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= u>

    =C2=A0

    Ketan, and all,

    I have stated that, IMHO and FWIW, both= Adj-SIDs and Prefix SIDs that are advertised with PHP can=C2=A0 ONLY repre= sent topological instructions in SR-MPLS - because the advertising node wil= l not receive them and therefore can hardly be expected to associate any service function with them.=

    =C2=A0

    This is complementary to what you have = said.

    =C2=A0

    Hope this clarifies my position.=

    What, if anything, did I miss?

    =C2=A0

    Regards,

    Sasha

    =C2=A0

    Get Outlook for Android

    =C2=A0

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020, 16:23
    To: = Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: = spring@ietf.org
    Subject: RE: [spring] Spring protection - determining applicability

    =C2=A0

    NOTICE: This email was received from an EXTERNAL sen= der

    =C2=A0

    Hi Sasha,

    =C2=A0

    If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don=E2=80=99t see why PHP could not be done for a Prefix SID associated with a service node.

    =C2=A0

    Also, I didn=E2=80=99t follow the point that you wer= e trying to make about Adj-SIDs.

    =C2=A0

    Thanks,

    Ketan

    =C2=A0

    From: Alexander Vainshtein <Alexander.Vainshtein@r= bbn.com>
    Sent: 14 August 2020 18:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= u>

    =C2=A0

    Hi all,

    Regarding the statement "Prefix SI= D could be just a topological instruction or may also be used to steer the = flow to a node which is applying a service function to it":<= /u>

    =C2=A0

    =C2=A0

    I think that in SR-MPLS a Node SID that= is advertised with PHP aciton can be safely considered as "just a top= ological instruction" by the PLR because the originating node will not= receive it.

    The same applies to Adj-SDIs.=

    =C2=A0

    My 2c.

    =C2=A0

    Get Outlook for Android

    =C2=A0

    From: spring <spring-bounces@ietf.org> on behalf of Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>=
    Sent: Friday, August 14, 2020, 15:00
    To: = Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: = spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability

    =C2=A0

    Hi All,

    I would like to share a different perspective on this.

    First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

    This is about local repair at a PLR. By it's very nature, the PLR does = not have a notion of how "strict or not" is the SLA that is being= provided by the SR Policy. Awareness of that notion exists at the SR Polic= y headend and/or computation-node.

    We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

    I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

    As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

    For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

    Thanks,
    Ketan

    [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
    [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

    -----Original Message-----
    From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
    Sent: 04 August 2020 20:25
    To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability

    There are, as far as I can tell, a number of ways to address this family of= related questions.
    What struck me, and prompted the starting question, was that none of them w= ere spelled out.=C2=A0 I see lots of interesting ideas / proposals.
    Some of them are compatible with others.=C2=A0=C2=A0 Some are not.
    It would be good if we could reach agreement on how we thought it should be= handled.

    Thank you,
    Joel

    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
    > Hi all,
    >
    > I am still not sure that the problem of bypass going thru undesirable =
    > links/nodes exists in the case of topological SIDs.
    >
    > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
    > <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
    > for many years before SR-MPLS has been introduced. What=E2=80=99s more= ,
    > signaling of bypass tunnels he PLR usually did not include any of the =
    > constraints used for computing of any specific LSP that the bypass LSP=
    > would protect =E2=80=93 because in the Facility Protection mode the sa= me
    > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
    >
    >=C2=A0 From my POV the only difference between this behavior and that <= br> > introduced by the =E2=80=9Cbypassing=E2=80=9D drafts in SR is that, in= the case of
    > RSVP-TE, the operator would explicitly indicate, as part of LSP
    > signaling, whether it would or would not use FRR; LSPs that would not =
    > use FRR would then drop traffic rather than delivering it the wrong wa= y.
    >
    > Such an option indeed does not exist in SR-TE today, but would be easy=
    > to provide if so desired IMHO.
    >
    > Did I miss something substantial?
    >
    > Regards, and lots of thanks in advance,
    >
    > Sasha
    >
    > Office: +972-39266302
    >
    > Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
    >
    > Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com
    >
    > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM
    > *To:* EXT-Andrew.Alston@liquidtelecom.com
    > <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    > *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > All,
    >
    > This is a very interesting discussion and thanks to Joel for starting =
    > this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized=C2=A0 either by defining a flex= -algo
    > avoiding those
    >
    > Nodes and links or by using a stack of unprotected adj-sids that avoid=
    > restricted nodes and links. When a stack of adj-sids is used to
    > realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
    >
    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
    > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
    > is in use or not.
    >
    > Rgds
    >
    > Shraddha
    >
    > Juniper Business Use Only
    >
    > *From:* spring <spring-bounces@ietf.org
    > <m= ailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
    > *Sent:* Tuesday, August 4, 2020 5:41 AM
    > *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern
    > <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > *[External Email. Be cautious of content]*
    >
    > Robert this is actually far more difficult when =E2=80=93 it can be an= entire
    > (long) series of nodes that need to be avoided.
    >
    > It could potentially be made to work but I=E2=80=99d worry that to do = this =E2=80=93
    > you=E2=80=99d have to stack 10 =E2=80=93 20 =E2=80=93 30 negative labe= ls =E2=80=93 and that wouldn=E2=80=99t
    > be viable.
    >
    > It=E2=80=99s easier to use algorithms and adjacency sids and other suc= h things
    > to calculate paths =E2=80=93 the biggest trick is about the stack dept= h.=C2=A0 When
    > you have this need for node avoidance =E2=80=93 the need for 10+ label= depth
    > is critical =E2=80=93 unless you wanna be applying one hell of a lot o= f
    > binding labels along the way which is a nightmare.
    >
    > But to answer your question, is this a common use case =E2=80=93 it=E2= =80=99s a use
    > case that most of the people I discuss this with certain have =E2=80= =93 I cant
    > comment on a global scale, or for anyone else, but every indication I =
    > have is that yes =E2=80=93 its something people need, and want
    >
    > Andrew
    >
    > *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Sent:* Tuesday, 4 August 2020 01:27
    > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>>
    > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
    > <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org > <mailto:spring= @ietf.org>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > Is this a common use case ie.=C2=A0 "but rather =E2=80=93 which n= odes / network
    > segments it can never touch or flow through."
    >
    > If so perhaps its time to define notion of *negative-SID* ie. list in =
    > the packet resources which given=C2=A0packet MUST not ever traverse. >
    > Put in the packet set of nodes or links which the packet should never =
    > traverse.
    >
    > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
    >
    > Best,
    > R.
    >
    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
    > <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 So =E2=80=93
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 One of the use cases, in fact, some very major= use cases in any
    >=C2=A0=C2=A0=C2=A0=C2=A0 spring technology for us revolve around the fo= llowing
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 a.The explicit avoidance of certain nodes
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 b.The explicit avoidance of certain sections o= f the network
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 Anything that could result in that explicit av= oidance being violated
    >=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=93 would create, shall we say significa= nt problems.
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 Much of the use case is not a case of which no= des the packets flow
    >=C2=A0=C2=A0=C2=A0=C2=A0 through =E2=80=93 but rather =E2=80=93 which n= odes / network segments it can never
    >=C2=A0=C2=A0=C2=A0=C2=A0 touch or flow through.=C2=A0 Effectively, to b= e used as a technology to
    >=C2=A0=C2=A0=C2=A0=C2=A0 avoid certain things for specific reasons.
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 This is also one of the reasons for needing su= ch deep label stacks =E2=80=93
    >=C2=A0=C2=A0=C2=A0=C2=A0 this kind of detailed path programming tends t= o deepen the stack
    >=C2=A0=C2=A0=C2=A0=C2=A0 because you sometimes have to be pretty explic= it.
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 It is absolutely critical to us that this func= tionality is there =E2=80=93
    >=C2=A0=C2=A0=C2=A0=C2=A0 and that we can avoid situations which could c= ause traffic to
    >=C2=A0=C2=A0=C2=A0=C2=A0 accidently hit things explicitly avoided.
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 I wish I could be more specific than this, but= it is what it is.
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 Thanks
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 Andrew
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 *From:* spring <spring-bounces@ietf.org
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> *On Behal= f Of *Joel M. Halpern
    >=C2=A0=C2=A0=C2=A0=C2=A0 *Sent:* Monday, 3 August 2020 21:36
    >=C2=A0=C2=A0=C2=A0=C2=A0 *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
    >=C2=A0=C2=A0=C2=A0=C2=A0 *Cc:* spring@ietf..org <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: [spring] Spring protection - de= termining
    > applicability
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 (Since the thread has gotten long enough, reit= erating that this is as a
    >=C2=A0=C2=A0=C2=A0=C2=A0 participant, not a WG chair.)
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
    >=C2=A0=C2=A0=C2=A0=C2=A0 choose to drop packets. For all sorts of reaso= ns.
    >=C2=A0=C2=A0=C2=A0=C2=A0 I think there are likely other reasons why one= may not want a random
    >=C2=A0=C2=A0=C2=A0=C2=A0 path rather than a chosen TE path. I think it = is important we be clear
    >=C2=A0=C2=A0=C2=A0=C2=A0 about what constraints may be / are violated w= hen we tell people they
    >=C2=A0=C2=A0=C2=A0=C2=A0 have this tool (protective rerouting) that is = intended to preserve QoS.
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 Let's be clear. I am not arguing that this= is not a good idea. It is a
    >=C2=A0=C2=A0=C2=A0=C2=A0 good idea. And useful. I am trying to figure o= tu what combination of
    >=C2=A0=C2=A0=C2=A0=C2=A0 additional mechanisms and clear descriptions w= ill lead to everyone
    >=C2=A0=C2=A0=C2=A0=C2=A0 getting the behavior they expect (which may no= t be the behavior they
    >=C2=A0=C2=A0=C2=A0=C2=A0 desire, but sometimes is the best we can do.)<= br> >
    >=C2=A0=C2=A0=C2=A0=C2=A0 Yours,
    >=C2=A0=C2=A0=C2=A0=C2=A0 Joel
    >
    >=C2=A0=C2=A0=C2=A0=C2=A0 On 8/3/2020 2:30 PM, Robert Raszuk wrote:
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are we still talking about IP netwo= rks=C2=A0here ? Or perhaps some hard
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > slicing with real resource reservat= ions or detnets ?
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Because=C2=A0if we are talking=C2= =A0about IP networking I have two
    >=C2=A0=C2=A0=C2=A0=C2=A0 observations:
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > A) If you need to traverse via a sp= ecific node (ie. firewall) you
    >=C2=A0=C2=A0=C2=A0=C2=A0 better
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > apply IP encapsulation to that node= .. I don't think IP
    >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulation=C2=A0can
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > be hijacked today such that destina= tion address of the packet is
    >=C2=A0=C2=A0=C2=A0=C2=A0 ignored.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > B) Have you seen any IP network whe= re upon topology change (link
    >=C2=A0=C2=A0=C2=A0=C2=A0 or node
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > failure) you suddenly=C2=A0start dr= opping=C2=A0flows in spite of SPT offering
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > perhaps few ms longer path with 10 = ms more jitter ?
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Or are some SR marketing slides pro= mise to turn IP networks in
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > something=C2=A0new ? Worse ... do t= hey mention path quality guarantees,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > resource reservations=C2=A0? I hope= not.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thx,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > R.
    >=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=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=A0=C2=A0 > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%20%0b>> <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">mailto:jmh@joelhalp= ern.com>> wrote:
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Well less serious for TE SIDs, I am= not sure the problem is
    >=C2=A0=C2=A0=C2=A0=C2=A0 restricted
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to just service SIDs.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Suppose that the PCE has specified = the path to meet some complex te
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > objective.=C2=A0 The bypass node ha= s no way of knowing what those
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > constraints
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > were.=C2=A0 And for some kinds of t= raffic, it is better to drop the packet
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > than to deliver it outside the enve= lop.=C2=A0 I suspect that the right
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > answer
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > to this is "too bad".=C2= =A0 If so, as with the distinction regarding
    >=C2=A0=C2=A0=C2=A0=C2=A0 service
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > nodes, we should say so, shouldn= 9;t we?
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Yours,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Joel
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach, Joel and all,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think that in most cases: >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 1.There is clear differentiati= on between "topological" and
    >=C2=A0=C2=A0=C2=A0=C2=A0 "service"
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > instructions in SID advertisem= ents. E.g.:
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > corresponding IGP advertisemen= ts) represent topological
    >=C2=A0=C2=A0=C2=A0=C2=A0 instructions
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
    >=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 <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3GC5a= f2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F= datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 4T-L0nl%24>>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft) unsurprisingly represen= t =E2=80=9Cservice=E2=80=9D instructions
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > 2.Segments that represent topo= logical instructions can be bypassed,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > while segments that represent = service instructions require
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > alternative
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > protection mechanisms.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > This view seems to be aligned = with RFC 8402
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24>>
    >=C2=A0=C2=A0=C2=A0=C2=A0 that says in Section 1:
    >=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 In the cont= ext of an IGP-based distributed control plane, two
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the IGP-Adjacency segment and the
    >=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 IGP-Prefix = segment.
    >=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 In the cont= ext of a BGP-based distributed control plane, two
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > topological segments are defin= ed: the BGP peering segment and the
    >=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 BGP-Prefix = segment.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In the case of SR-MPLS this di= fferentiation is assumed in Section
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 3.4 of
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the Node Protection for SR-TE = Path
    >=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 <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdr= aft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21= %21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9= wO-Ssn%24>>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > draft that says:
    >=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 The node pr= otection mechanism described in the previous
    >=C2=A0=C2=A0=C2=A0=C2=A0 sections
    >=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 depends on = the assumption that the label immediately below
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the top
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > label in the label stack is un= derstood in the IGP domain.=C2=A0 When the
    >=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 provider ed= ge routers exchange service labels via BGP or some
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > other
    >=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 non-IGP mec= hanism the bottom label is not understood in the IGP
    >=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 domain.
    >=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 The egress = node protection mechanisms described in the draft
    >=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 [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u= =3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2F= doc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
    >=C2=A0=C2=A0=C2=A0=C2=A0 is
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > applicable to this use case an= d no additional changes
    >=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 will be req= uired for SR based networks
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > The scenarios in which =C2=A0d= ifferentiation between =E2=80=9Ctopological=E2=80=9D and
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > =E2=80=9Cservice=E2=80=9D inst= ructions is broken are indeed problematic. E.g.,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > consider
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the use case in which a Node S= ID in the ERO of a SR-TE path
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifies a
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > node that acts as a firewall f= or all packets it receives, i.e.,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > provides
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > the firewall service without a= ny dedicated service SID
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > identifying it.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > One could say that the Node SI= D of such a node would combine
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > and service instructions thus = breaking the differentiation
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > between the two.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I am not sure if usage of such= =E2=80=9Ccombined=E2=80=9D SIDs could be prevented
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > or at
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > least discouraged.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > If not, providing an ability t= o identify such SIDs in the
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > mechanisms would be useful IMH= O.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > My 2c,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sasha
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Office: +972-39266302
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Cell:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +972-549266302
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Email: Alexander.Vainshtein@ecitele.com
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:Alexander.Vainshtein@ecitele.com>=
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:Alexander.Vainshtein@ecitele.= com>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > -----Original Message-----
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > From: spring <spring-bounces@ietf.org<= br> >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org%0b>>
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Sent: Monday, August 3, 2020 6= :30 AM
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > To: Joel M. Halpern <jmh@joelhalpern.com >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.co= m>>;
    >=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Subject: Re: [spring] Spring p= rotection - determining applicability
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Hi Joel,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I think this is a good point t= hat may not be discussed in the
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > past. And
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > I also don't think there i= s a "can be bypassed" indication in the
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > routing advertisement for now.=
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > IMHO, the information advertis= ed by routing is neutral, such
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > (can or cannot be bypassed) is= more path specific, thus
    >=C2=A0=C2=A0=C2=A0=C2=A0 normally the
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > controller should be responsib= le for deciding whether/which SID
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > can be
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > bypassed.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Best regards,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Mach
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > -----Original Messa= ge-----
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > From: spring [mailt= o:spring-bounc= es@ietf.org
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring-bounces@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>] >=C2=A0=C2=A0=C2=A0=C2=A0 On Behalf Of Joel M.
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Halpern
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Sent: Monday, Augus= t 3, 2020 7:51 AM
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > To: spring@ietf.org <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Subject: [spring] S= pring protection - determining applicability
    >=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 > (WG Chair hat Off, = this is merely a note from a slightly
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > confused WG
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > participant.)
    >=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 > I have been reading= the various repair drafts, and the various
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > networks programmin= g and service programming draft, and I am
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > trying to
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > figure out one aspe= ct of the combination.
    >=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 > How does a node tha= t is doing some form of bypass (suppose, for
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > simplicity, it is N= ode N2 deciding to bypass the next SID for
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a failed
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > node N3) know that = it is safe to do so?
    >=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 > If the path was jus= t for TE, then it is "safe" if the new path
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > meets
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > the TE criteria.=C2= =A0 or maybe it is safe if it is even close, as
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > long as
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > it is not used for = too long.
    >=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 > But what if the nod= e were a Firewall, included to meet legal
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > requirements?
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Or was some other n= ecessary programmatic transform (wince we are
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > deliberately vague = about what nodes can do when asked suitably.)
    >=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 > Is there some "= ;can be bypassed" indication in the routing
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > advertisements that= I missed?
    >=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 > Thank you,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Yours,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > Joel
    >=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=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring mailing list=
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >=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=A0 https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
    >=C2=A0=C2=A0=C2=A0=C2=A0 <    https://clicktime.symantec.com/3Q= 7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A= %2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2= __%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt= 8AkTRDuiDo6HwPLil%24>
    >=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 <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.c= om/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http= s%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A= %2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6v= pRHOGt8AkTRDuiDozoQiAHk%24>>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 > F%2Fwww.ietf.org
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.sy= mantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktim= e.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%= 2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1o= iQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2F= listinfo%2Fspring
    >=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 > > spring mailing list
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org> <mailto:spring@ietf.org
    >=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>> >=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 https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRn= fMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sym= antec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.o= rg%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yu= sx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
    >=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=A0 >
    >=C2=A0=C2=A0=C2=A0=C2=A0 ----------------------------------------------= --------------------------
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Notice: This e-mail together w= ith any attachments may contain
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > information of Ribbon Communic= ations Inc. that is confidential
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > and/or
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > proprietary for the sole use o= f the intended recipient. Any review,
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > disclosure, reliance or distri= bution by others or forwarding
    >=C2=A0=C2=A0=C2=A0=C2=A0 without
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > express permission is strictly= prohibited. If you are not the
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > intended
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > recipient, please notify the s= ender immediately and then delete all
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > copies, including any attachme= nts.
    >=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=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring mailing list
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >=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 > spring mailing list
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >=C2=A0=C2=A0=C2=A0=C2=A0 <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >=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 spring mailing list
    >=C2=A0=C2=A0=C2=A0=C2=A0 spring@ietf.org <mailto:spring@ietf.org>
    >=C2=A0=C2=A0=C2=A0=C2=A0 https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >=C2=A0=C2=A0=C2=A0=C2=A0
    > <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
    > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
    > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >
    >
    >
    > ----------------------------------------------------------------------=
    > --
    > Notice: This e-mail together with any attachments may contain
    > information of Ribbon Communications Inc. that is confidential and/or =
    > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
    > recipient, please notify the sender immediately and then delete all > copies, including any attachments.
    > ----------------------------------------------------------------------=
    > --

    _______________________________________________
    spring mailing list
    spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring
    _______________________________________________
    spring mailing list
    spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring

    =C2=A0

    =C2=A0

    Notice: This e-mail together with any attachments may contain inform= ation of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review,= disclosure, reliance or distribution by others or forwarding without expre= ss permission is strictly prohibited. If you are not the intended recipient= , please notify the sender immediately and then delete all copies, including any attachments.

    =C2=A0



    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    =C2=A0

    --000000000000298d7405ad2904bb-- From nobody Tue Aug 18 09:16:45 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF483A0E91; Tue, 18 Aug 2020 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=qXczG3Ca; dkim=pass (1024-bit key) header.d=juniper.net header.b=CsAjIgjG 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 nOKW0tYW1QJ3; Tue, 18 Aug 2020 09:16:38 -0700 (PDT) Received: from mx0b-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 84E333A0E8C; Tue, 18 Aug 2020 09:16:38 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07IFl68v028155; Tue, 18 Aug 2020 09:16:38 -0700 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 : mime-version; s=PPS1017; bh=pgkUttscA0E6bSz01c7zQEtgseZQBYO2tTiSqhIHymc=; b=qXczG3CaplmBiVW0RWjoAprfunJ0d6ziZVvoIDkyC3sCaN0j1Oai41nt9yOb+gnd0i/h a8trOaOXE5ltIIUzo0+NX+rNOc6qFDXDutXQDEDPY+WBV7/dbDRWHkyVPLO6RkVh4xS0 ciyyCtn+LpAH9JwBPztwJFaFaeqNF22nsQNkcsZXwor86Euv4K9FAoHxFzNRviNph9ky vnvIy7ROUidjjrTfuZh0lX/ztGvJ91F/UkF73wYWdJfehh22xo2fdEgLruOToMbwRu3I VI5T8EFNVmjXeAk1ctsHo6ObaHAh252oxLr/OkmeXGcJlYJn00wUMIt+o5ILDGW1Twwc Xg== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by mx0a-00273201.pphosted.com with ESMTP id 3304jss8bt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 09:16:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JvG07y4i9PMmHLNai8G7Gwe+2UTWAJGGeVeDt3Cmu9JQMiziLuHFH9+a/gzac9X4aU8FPiVqeS9JA0qA+6wScMaZrPNyeSmOdJLw9Rov8Lt3D3qLTsIlumu6IQbZyXW2Z8/yeyuHlhCoYA5JPSOz2W3cAACs0ScgCjdGooqOaEWNCM1ulU8P2Z9CyLsfLWIeQYM1RKCi00sWQrwkTyRk7bpFVaePJVgXObQhm03Qq9/PtSFc+CPBvFTnNQOVVSYNF08jnwScmyhR1dOsou5JPfF2v20UURpew8LBJGVYOeCtjCBykEkRQyAHzh5lVfd3LIbUv3nkqVwVYxWpEgaBuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pgkUttscA0E6bSz01c7zQEtgseZQBYO2tTiSqhIHymc=; b=hfUuWAdSbztm+hgqZGY7YqF5ywcT4WxUbm7G7r5eGZwFwS86HYDTEHQ6ks1R4IzEZalD5+/jx2It5cURfbZCDWV0o/CiVT4zlvs+u3BzinVnw0AeRQPhVJ2Htus7p4jcPnCCjBVzkHho1AgurYwV+oksLnzktuxl/g6ej0DohwPuLu3yAh8+7miuUEjh8Pp2KiorIKDIId3kmHxz179Jh21Cw+VBdsR4d/tPEMbURHQv3BZGoNJBstXj8rCIk4z7HP4Taj3neeKayPvsA1boRakucq3ZDbGrqe2kLwHrsvwzBogJ1X3/QHGszwqp7JIezxkcME5N67ARrnQuENJB2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pgkUttscA0E6bSz01c7zQEtgseZQBYO2tTiSqhIHymc=; b=CsAjIgjGf+6iADmhVxsWjt7oRywxJW7QMrPbz2VdDYs+PFofNFYTrYKhkNSeGHEDGAVMVqGN1PqiZlWclPKq1fZzJITOJW0fiAsL5TfGuPB+9woeqB0O72QobD6JbO9pGGScPMl6i9jx5wYFVScdTxl05QbSS3IYNVnipz10FTM= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB2919.namprd05.prod.outlook.com (2603:10b6:903:11::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Tue, 18 Aug 2020 16:16:34 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::9e0:8539:4bfd:ee3e%7]) with mapi id 15.20.3305.021; Tue, 18 Aug 2020 16:16:33 +0000 From: Shraddha Hegde To: Martin Horneffer , "spring@ietf.org" CC: "Ketan Talaulikar (ketant)" , Robert Raszuk , Alexander Vainshtein , "Joel M. Halpern" , "EXT-Andrew.Alston@liquidtelecom.com" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCmE9nDdjpckqZffxFoYFmAaklun0AgAA0DoCAAMHVAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAD9EYIAAQlMAgAB1eACAD4ZhAIAADzCAgAAIGQCAABlPgIAACqWAgAAC7gCAAAmbgIAAFWyAgAADZQCABhhmgIAAF4tw Date: Tue, 18 Aug 2020 16:16:33 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> In-Reply-To: <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-18T16:16:29Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=cc3e04f7-5f08-4726-8847-3f1e68f4e6e2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.2.0.14 dlp-reaction: no-action authentication-results: lab.dtag.de; dkim=none (message not signed) header.d=none;lab.dtag.de; dmarc=none action=none header.from=juniper.net; x-originating-ip: [122.167.129.47] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 04478b3d-09f6-4aba-b0a7-08d843921332 x-ms-traffictypediagnostic: CY4PR05MB2919: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PypzFGtx7yNVV/xhMqPJnHuJOCm0JBhHhsFDPJTfrstw8Oo3xtJkgWQAFIbmt1egvWzUb7gSdOaTKjfbauIwd+1DmIwEts/5QWJUSP7SEtaQWVbcrdulUNn/EHc20qTtLixHmWfWLS0XPWv0i6zvQQpuA/MoLoi9AcY0PtBln64hl6GO/OBfISjbyHLLyWKwk07BKN2kBVpSfAS3Vm5n0S68qOgw2yUaMuXT/1GRFyBEQUg0CxE1bWt2afVd7A+NwbfX+lZplXR6Tnx8ypEGF+IvHuKUAC4ttJQYnjKsqkHQ5w5gmiXYfG7l8cvqe5kd0DY21V/M8sSXVVgrDvN5eSLwzdGpfbFsS8FBR0EzwqhW375KyMaR+2VLiIEs9Nw/u6fMbG6SU+9ypvF5GaUmmA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(376002)(366004)(39860400002)(396003)(76116006)(316002)(30864003)(8936002)(83380400001)(33656002)(6506007)(26005)(45080400002)(7696005)(66946007)(66556008)(66446008)(66476007)(5660300002)(54906003)(110136005)(53546011)(64756008)(52536014)(966005)(2906002)(4326008)(86362001)(8676002)(186003)(478600001)(9686003)(71200400001)(55016002)(166002)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ELsCtOHx10XCYRnEMly9XNWK5yOJh1192oZMyyltdl64W5VrlM14yarXuXmJWcTIxtLA0WC7uMIvn9XXdKCQMqKAIZQk2gBOhy8FT8o3aRWxdzuYxg+8ZrP9KEeFh27wPDvcg+UvIrDWUqRcTkybXR327ct92DsHTJJ1SjDZTp+JBsyxC0bJEDqhAuQfLKBI5qc7ts/vjJ4UewaAHb7nRdSAPqpq5XMdQhewRIhEjTRcNh+3Z1bES1AyKJW8K1RFCxhRDoVO/BqyLvoqlQJOKm1HNcdMINoJ8Z/OHbmR44A7ZMRgKfHdBaXk/8BUix0yf41KtcppGIlZM3SICEMH9cZ3xpWf9YYUYLHHJ/Bbtt50vR+uVQ9Z6qhYsP6C7b+1CJvOy+I/idBwbi8sHlms3Adt+Zyk0mruzooHbaYtHZBbSDtmPRPAFtef0URAWtuNUtxJ9qeYJg4o8MTvBALkl9fQBoge2AmzaPm4T7Z/92dt+4Sxa14sEmFGPaZ1gtOhmqabFbEeMHAT/d/ql1piK3eEbHE62edyRgU0yB1ro4aOgZFAJutMXBHNBVFLqNlYdRMfZe5a60y8Wq19ZWSzdqJGoDjDkqSKLrHGYgBC4Shw3oMazvqkRUgHNL+HrXfv/kpsQwP03WnSpO4ohC+qSQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR05MB357611A7B87D6F1984ECA700D55C0CY4PR05MB3576namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 04478b3d-09f6-4aba-b0a7-08d843921332 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 16:16:33.8101 (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-CrossTenant-userprincipalname: hTd3BfDNlQp5GMzUj3k3wvtdX14Nd1xpM4fHDN1mhpDIujiCi/P/pMYae9rZrD4ZX1bTu0GQJJ52TU5mHZttgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2919 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_10:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 mlxscore=0 malwarescore=0 suspectscore=0 spamscore=0 phishscore=0 adultscore=0 clxscore=1011 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180113 Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 16:16:44 -0000 --_000_CY4PR05MB357611A7B87D6F1984ECA700D55C0CY4PR05MB3576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Martin, Ability to turn off node protection on a per neighbor/port basis is a usefu= l input. I'll add a "operational consideration" section in the node-protection draft= to include this point. Rgds Shraddha Juniper Business Use Only From: Martin Horneffer Sent: Tuesday, August 18, 2020 8:21 PM To: spring@ietf.org Cc: Ketan Talaulikar (ketant) ; Robert= Raszuk ; Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.com Subject: Re: [spring] Spring protection - determining applicability [External Email. Be cautious of content] A few thoughts from my (operator's) PoV: - The disussion is a very good and important one. It probably should be di= scussed and documented well in order to justify the proposed protections me= chanisms. - Not all operators seem to have the same requirements. (A somewhat similar discussion might be the one for disjoint paths. Tho= se are often equired by voice signalling applications. In some cases the vo= ice service demands that traffic is blackholed rather than on forwarded on = the wrong path. In other cases disjoint paths are just required for the "go= od case". Traffic MAY be forwarded on the wrong path, as long as the networ= k just makes sure the traffic on the other path is never affected by the sa= me failure.) - Personally I would hate to see yet another IGP extension for this purpos= e. - I would rather prefer a good discussion of what can be achieved by using= easy to make switches: - The protection behaviour could be switched on or off per node. - An operator with strict "some traffic may never touch certain part= s of the network" requirements might switch off the behaviour, while others= might switch it on. - A node could allow a switch even individually for every port or neigh= bor. - If a node knows that one of it's neighbours is a service node rath= er than a plain topological one, it could switch off protection. This is ho= w I would prefer to solve the problem with serrvice nodes. Should this be discussed in the protection document, or in a separate one? Best regards, Martin Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant): Hi Robert, We do not have a signalling mechanism in IGPs today to indicate a "bypass-a= ble" indication for Prefix SIDs. If there was a desire for it, an IGP exten= sion would be required (there is none in progress AFAIK). Note that this re= sults in doubling the prefix SID scale (global labels) in the network. So I= would not go about this trivially. I think it helps to get more inputs and perspectives from operators on thei= r views for doing a bypass via local protection for segments in an SR Polic= y. There may be those that prefer end-to-end path protection using a fallba= ck path that is say disjoint with the primary but provides an appropriate S= LA/intent? Thanks, Ketan From: Robert Raszuk Sent: 14 August 2020 23:04 To: Ketan Talaulikar (ketant) Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.com ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Ketan, Looks like we are pretty much in sync here. But let me just observe that I purposely did not mention about SR policies = as we are not able to signal the intent with the packets itself. So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with = information if policies build with using them are bypass eligible or not. I was actually under the impression that this is already there and I am jus= t not aware, but looking deeper indeed I do not see this marking neither in= ISIS nor OSPF for prefix SIDs. Is there some work in progress to add it to those protocols or have we just= documented need for a short LSR draft ? Thx, R. On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) > wrote: Hi Robert, Please check inline below. From: Robert Raszuk > Sent: 14 August 2020 21:13 To: Ketan Talaulikar (ketant) > Cc: Alexander Vainshtein >; Joel M. Halpern >; Shraddha Hegde >; EXT-Andrew.Alston@liquidtelecom.com >; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi Ketan, While I completely agree with your note the consequences of it are pretty s= evre. [KT] I understand. We need to be mindful of implications of protection sche= mes for the SLAs/intent of SR Policies. Unless we signal which prefix SID is protection eligible and which is not h= ow would other nodes know if they can protect it or not ? [KT] Correct. To be more accurate, we need to consider this more in the con= text of SLA or "intent" of SR Policies and which segments may be "bypass-ab= le" for local protection for some of those SR Policies. We also have path-p= rotection mechanisms. It seems that today's safe thing is not to apply any node protection on SR = flows at the PLRs then. And link protection MUST assure that packets will arrive at the neighbor no= de via some other link regardless of further path towards destination. [KT] Yes. We have a mechanism to indicate which adj-SIDs have protection (t= hat mechanism only provides link protection to get to the neighbor node) so= the SR Policy computation is able to indicate whether that specific link i= s "bypass-able" or not by its choice of protected or unprotected adj-SIDs r= espectively. Thanks, Ketan Is it correct ? Thx R On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) > wrote: Hi Sasha, The service node advertises its own Prefix SID. The service function that t= his service node implements does not require any context (i.e. all packets = arriving at the node are subjected to that service). Therefore the service = node does not need to receive a packet with it's own Prefix SID. Thus, we cannot assume that when PHP is used, then the SID is only associat= ed with a topological instruction. Hope that clarifies? Thanks, Ketan From: Alexander Vainshtein > Sent: 14 August 2020 20:24 To: Ketan Talaulikar (ketant) >; = Joel M. Halpern >; Shraddha= Hegde >; EXT-Andrew.Alst= on@liquidtelecom.com >; Robert Ras= zuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Ketan, and all, I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are a= dvertised with PHP can ONLY represent topological instructions in SR-MPLS = - because the advertising node will not receive them and therefore can hard= ly be expected to associate any service function with them. This is complementary to what you have said. Hope this clarifies my position. What, if anything, did I miss? Regards, Sasha Get Outlook for Android ________________________________ From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 16:23 To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: RE: [spring] Spring protection - determining applicability ________________________________ NOTICE: This email was received from an EXTERNAL sender ________________________________ Hi Sasha, If the service does not need any additional context (e.g. a firewall that j= ust applies locally configured default rules on it), then I don't see why P= HP could not be done for a Prefix SID associated with a service node. Also, I didn't follow the point that you were trying to make about Adj-SIDs= . Thanks, Ketan From: Alexander Vainshtein > Sent: 14 August 2020 18:24 To: Ketan Talaulikar (ketant) >; = Joel M. Halpern >; Alexande= r Vainshtein >; Shraddha Hegde >= ; EXT-Andrew.Alston@liquidtelecom.com >; Robert Raszuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi all, Regarding the statement "Prefix SID could be just a topological instruction= or may also be used to steer the flow to a node which is applying a servic= e function to it": I think that in SR-MPLS a Node SID that is advertised with PHP aciton can b= e safely considered as "just a topological instruction" by the PLR because = the originating node will not receive it. The same applies to Adj-SDIs. My 2c. Get Outlook for Android ________________________________ From: spring > on b= ehalf of Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 15:00 To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi All, I would like to share a different perspective on this. First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1]. This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being provided by t= he SR Policy. Awareness of that notion exists at the SR Policy headend and/= or computation-node. We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of the SLA requ= irement for picking that link. We do not have such a notion for Prefix SIDs= . One can say that we could introduce signalling (e.g. a B flag) to indicat= e whether a Prefix SID can be bypassed or not. This provides the opportunit= y for the computation to use one or the other flavor depending on the natur= e of the SLA for the SR Policy. I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able". As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or not. For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to bypass it. = When this mechanism is used along side SRTE path monitoring mechanisms, it = enables the headend to detect the failure and fallback to an alternate path= using the path protection approach. This is something that is described an= d in use in deployments today [1].. Thanks, Ketan [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9 [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9.3 -----Original Message----- From: spring > On B= ehalf Of Joel M. Halpern Sent: 04 August 2020 20:25 To: Alexander Vainshtein >; Shraddha Hegde >; EXT-Andrew.Alston@liqui= dtelecom.com >; Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability There are, as far as I can tell, a number of ways to address this family of= related questions. What struck me, and prompted the starting question, was that none of them w= ere spelled out. I see lots of interesting ideas / proposals. Some of them are compatible with others. Some are not. It would be good if we could reach agreement on how we thought it should be= handled. Thank you, Joel On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > Hi all, > > I am still not sure that the problem of bypass going thru undesirable > links/nodes exists in the case of topological SIDs. > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > >) has been successfully deployed > for many years before SR-MPLS has been introduced. What's more, > signaling of bypass tunnels he PLR usually did not include any of the > constraints used for computing of any specific LSP that the bypass LSP > would protect - because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node. > > From my POV the only difference between this behavior and that > introduced by the "bypassing" drafts in SR is that, in the case of > RSVP-TE, the operator would explicitly indicate, as part of LSP > signaling, whether it would or would not use FRR; LSPs that would not > use FRR would then drop traffic rather than delivering it the wrong way. > > Such an option indeed does not exist in SR-TE today, but would be easy > to provide if so desired IMHO. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:* spring > = *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM > *To:* EXT-Andrew.Alston@liquidtelecom.com > >= ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > All, > > This is a very interesting discussion and thanks to Joel for starting > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized either by defining a flex-algo > avoiding those > > Nodes and links or by using a stack of unprotected adj-sids that avoid > restricted nodes and links. When a stack of adj-sids is used to > realize the path, the head-end based (sBFD) protection mechanisms can be = applied. > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection > is in use or not. > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* spring > > *= On Behalf Of *Andrew Alston > *Sent:* Tuesday, August 4, 2020 5:41 AM > *To:* Robert Raszuk > > *Cc:* spring@ietf.org ; J= oel M. Halpern > > > *Subject:* Re: [spring] Spring protection - determining applicability > > *[External Email. Be cautious of content]* > > Robert this is actually far more difficult when - it can be an entire > (long) series of nodes that need to be avoided. > > It could potentially be made to work but I'd worry that to do this - > you'd have to stack 10 - 20 - 30 negative labels - and that wouldn't > be viable. > > It's easier to use algorithms and adjacency sids and other such things > to calculate paths - the biggest trick is about the stack depth. When > you have this need for node avoidance - the need for 10+ label depth > is critical - unless you wanna be applying one hell of a lot of > binding labels along the way which is a nightmare. > > But to answer your question, is this a common use case - it's a use > case that most of the people I discuss this with certain have - I cant > comment on a global scale, or for anyone else, but every indication I > have is that yes - its something people need, and want > > Andrew > > *From:* Robert Raszuk > > *Sent:* Tuesday, 4 August 2020 01:27 > *To:* Andrew Alston > > > *Cc:* Joel M. Halpern > >; spring@i= etf.org > > *Subject:* Re: [spring] Spring protection - determining applicability > > Is this a common use case ie. "but rather - which nodes / network > segments it can never touch or flow through." > > If so perhaps its time to define notion of *negative-SID* ie. list in > the packet resources which given packet MUST not ever traverse. > > Put in the packet set of nodes or links which the packet should never > traverse. > > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR) > > Best, > R. > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > wrote: > > So - > > One of the use cases, in fact, some very major use cases in any > spring technology for us revolve around the following > > a.The explicit avoidance of certain nodes > > b.The explicit avoidance of certain sections of the network > > Anything that could result in that explicit avoidance being violated > - would create, shall we say significant problems. > > Much of the use case is not a case of which nodes the packets flow > through - but rather - which nodes / network segments it can never > touch or flow through. Effectively, to be used as a technology to > avoid certain things for specific reasons. > > This is also one of the reasons for needing such deep label stacks - > this kind of detailed path programming tends to deepen the stack > because you sometimes have to be pretty explicit. > > It is absolutely critical to us that this functionality is there - > and that we can avoid situations which could cause traffic to > accidently hit things explicitly avoided. > > I wish I could be more specific than this, but it is what it is. > > Thanks > > Andrew > > *From:* spring > > = *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > > *Cc:* spring@ietf..org > *Subject:* Re: [spring] Spring protection - determining > applicability > > (Since the thread has gotten long enough, reiterating that this is as= a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks tha= t > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clea= r > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve Qo= S. > > Let's be clear. I am not arguing that this is not a good idea. It is = a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two > observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you > better > > apply IP encapsulation to that node.. I don't think IP > encapsulation can > > be hijacked today such that destination address of the packet is > ignored. > > > > B) Have you seen any IP network where upon topology change (link > or node > > failure) you suddenly start dropping flows in spite of SPT offerin= g > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > > wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is > restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex t= e > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the pac= ket > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding > service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and > "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological > instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > > >> > > > > > draft) unsurprisingly represent "service" instructions > > > > > > 2.Segments that represent topological instructions can be bypass= ed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > > >> > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, tw= o > > > > > > topological segments are defined: the IGP-Adjacency segment and = the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and th= e > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Sectio= n > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > > > >> > > > > > draft that says: > > > > > > The node protection mechanism described in the previous > sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When = the > > > > > > provider edge routers exchange service labels via BGP or som= e > > other > > > > > > non-IGP mechanism the bottom label is not understood in the = IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 > >>] > is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between "topological" an= d > > > "service" instructions is broken are indeed problematic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such "combined" SIDs could be prevente= d > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > > > > On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > > >; > spring@ietf.org > > > Subject: Re: [spring] Spring protection - determining applicabil= ity > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in th= e > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus > normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicabili= ty > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the variou= s > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, f= or > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new pat= h > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we = are > > > > > > > deliberately vague about what nodes can do when asked suitabl= y.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > > >> > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2 > > > > > > > > > >> > > > > > > > F%2Fwww.ietf.org > > > > > >>%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= --- > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any revi= ew, > > > disclosure, reliance or distribution by others or forwarding > without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete = all > > > copies, including any attachments. > > > > > > ---------------------------------------------------------------------= --- > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org = > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <= mailto:spring@ietf.org> > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > 2F%2Furldefense.com%2Fv3%2F__htt= ps%3A%2Fwww.ietf.org%2Fmailman%2Flisti > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > ---------------------------------------------------------------------- > -- > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ---------------------------------------------------------------------- > -- _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ________________________________ Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for th= e sole use of the intended recipient. Any review, disclosure, reliance or d= istribution by others or forwarding without express permission is strictly = prohibited. If you are not the intended recipient, please notify the sender= immediately and then delete all copies, including any attachments. ________________________________ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CY4PR05MB357611A7B87D6F1984ECA700D55C0CY4PR05MB3576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Martin,

     

    Ability to turn off node protection on a per neighbo= r/port basis is a useful input.

    I’ll add a “operational consideration= 221; section in the node-protection draft to include this point.=

     

    Rgds

    Shraddha

     

     

    Juniper Business Use Only

    From: Martin Horneffer <maho@lab.dtag.de&g= t;
    Sent: Tuesday, August 18, 2020 8:21 PM
    To: spring@ietf.org
    Cc: Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.or= g>; Robert Raszuk <robert@raszuk.net>; Alexander Vainshtein <Al= exander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>= ;; Shraddha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtel= ecom.com <Andrew.Alston@liquidtelecom.com>
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    <= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

     

    A few thoughts from m= y (operator's) PoV:

     - The disussion is a very good and important one. It probably should = be discussed and documented well in order to justify the proposed protectio= ns mechanisms.

     - Not all operators seem to have the same requirements.
        (A somewhat similar discussion might be the one for disj= oint paths. Those are often equired by voice signalling applications. In so= me cases the voice service demands that traffic is blackholed rather than o= n forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forw= arded on the wrong path, as long as the network just makes sure the traffic= on the other path is never affected by the same failure.)

     - Personally I would hate to see yet another IGP extension for this p= urpose.

     - I would rather prefer a good discussion of what can be achieved by = using easy to make switches:
        - The protection behaviour could be switched on or off p= er node.
           - An operator with strict "some t= raffic may never touch certain parts of the network" requirements migh= t switch off the behaviour, while others might switch it on.
        - A node could allow a switch even individually for ever= y port or neighbor.
           - If a node knows that one of it's nei= ghbours is a service node rather than a plain topological one, it could swi= tch off protection. This is how I would prefer to solve the problem with se= rrvice nodes.

    Should this be discussed in the protection document, or in a separate one?<= br>
    Best regards, Martin

    Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketan= t):

    Hi Robert,

     

    We do not have a signalling mechanism in IGPs today = to indicate a “bypass-able” indication for Prefix SIDs. If ther= e was a desire for it, an IGP extension would be required (there is none in= progress AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go abo= ut this trivially.

     

    I think it helps to get more inputs and perspectives= from operators on their views for doing a bypass via local protection for = segments in an SR Policy. There may be those that prefer end-to-end path pr= otection using a fallback path that is say disjoint with the primary but provides an appropriate SLA/intent?

     

    Thanks,

    Ketan

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 23:04
    To: Ketan Talaulikar (ketant) &l= t;ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>; Shr= addha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Ketan,

     

    Looks like we are pretty much in sync here. 

     

    But let me just observe that I purposely did no= t mention about SR policies as we are not able to signal the intent with th= e packets itself. 

     

    So all we have there is SIDs. BSIDs or prefix SIDs n= eed to be flooded with information if policies build with using them are by= pass eligible or not. 

     

    I was actually under the impression that this is alr= eady there and I am just not aware, but looking deeper indeed I do not see = this marking neither in ISIS nor OSPF for prefix SIDs. 

     

    Is there some work in progress to add it to those pr= otocols or have we just documented need for a short LSR draft  ?&= nbsp;

     

    Thx,

    R.

     

     

    On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ke= tant) <ketant@cisco.com> wrot= e:

    Hi Robert,

     

    Please check inline below.

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 21:13
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Hi Ketan,

     

    While I completely agree with your note the consequences of it are= pretty sevre. 

    [KT] I understand. We need to be mindful of implications of = protection schemes for the SLAs/intent of SR Policies.

     

    Unless we signal which prefix SID is protection eligible and which= is not how would other nodes know if they can protect it or not ? 

    [KT] Correct. To be more accurate, we need to consider this = more in the context of SLA or “intent” of SR Policies and which= segments may be “bypass-able” for local protection for some of those SR Policies. We also have path-protection mechanisms.

     

    It seems that today's safe thing is not to apply any node protecti= on on SR flows at the PLRs then. 

     

    And link protection MUST assure that packets will arrive at the ne= ighbor node via some other link regardless of further path towards destinat= ion. 

    [KT] Yes. We have a mechanism to indicate which adj-SIDs hav= e protection (that mechanism only provides link protection to get to the ne= ighbor node) so the SR Policy computation is able to indicate whether that specific link is “bypass-able”= ; or not by its choice of protected or unprotected adj-SIDs respectively.

     

    Thanks,

    Ketan

     

    Is it correct ? 

     

    Thx

    R

     

    On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) <ketant@cisco.com> = wrote:

    Hi Sasha,

     

    The service node advertises its own Prefix SID. The service functi= on that this service node implements does not require any context (i.e. all= packets arriving at the node are subjected to that service). Therefore the service node does not need to receive a pa= cket with it’s own Prefix SID.

     

    Thus, we cannot assume that when PHP is used, then the SID is only= associated with a topological instruction.

     

    Hope that clarifies?

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>= ;
    Sent: 14 August 2020 20:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Ketan, and all,

    I have stated that, IMHO and FWIW, both Adj-S= IDs and Prefix SIDs that are advertised with PHP can  ONLY represent t= opological instructions in SR-MPLS - because the advertising node will not = receive them and therefore can hardly be expected to associate any service function with them.

     

    This is complementary to what you have said.<= /span>

     

    Hope this clarifies my position.<= /o:p>

    What, if anything, did I miss?

     

    Regards,

    Sasha

     

    Get Outlook for Android

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020, 16:23
    To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject:= RE: [spring] Spring protection - determining applicability=

     

    NOTICE: This email was received from an EXTERNAL sender=

     

    Hi Sasha,

     

    If the service does not need any additional context (e.g. a firewa= ll that just applies locally configured default rules on it), then I don= 217;t see why PHP could not be done for a Prefix SID associated with a service node.

     

    Also, I didn’t follow the point that you were trying to make= about Adj-SIDs.

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>= ;
    Sent: 14 August 2020 18:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Hi all,

    Regarding the statement "Prefix SID coul= d be just a topological instruction or may also be used to steer the flow t= o a node which is applying a service function to it":

     

     

    I think that in SR-MPLS a Node SID that is ad= vertised with PHP aciton can be safely considered as "just a topologic= al instruction" by the PLR because the originating node will not recei= ve it.

    The same applies to Adj-SDIs.

     

    My 2c.

     

    Get Outlook for Android

     

    From: spring <spring-bounces@ietf.org> on behalf of Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>=
    Sent: Friday, August 14, 2020, 15:00
    To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject:= Re: [spring] Spring protection - determining applicability=

     

    Hi All,

    I would like to share a different perspective on this.

    First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

    This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being pro= vided by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

    We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

    I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

    As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

    For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

    Thanks,
    Ketan

    [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
    [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

    -----Original Message-----
    From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
    Sent: 04 August 2020 20:25
    To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability

    There are, as far as I can tell, a number of ways to address this family of= related questions.
    What struck me, and prompted the starting question, was that none of them w= ere spelled out.  I see lots of interesting ideas / proposals.
    Some of them are compatible with others.   Some are not.
    It would be good if we could reach agreement on how we thought it should be= handled.

    Thank you,
    Joel

    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
    > Hi all,
    >
    > I am still not sure that the problem of bypass going thru undesirable =
    > links/nodes exists in the case of topological SIDs.
    >
    > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
    > <https://clicktime.symantec.com/3Q92knE= 9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4090>= ;) has been successfully deployed
    > for many years before SR-MPLS has been introduced. What’s more, =
    > signaling of bypass tunnels he PLR usually did not include any of the =
    > constraints used for computing of any specific LSP that the bypass LSP=
    > would protect – because in the Facility Protection mode the same=
    > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
    >
    >  From my POV the only difference between this behavior and that <= br> > introduced by the “bypassing” drafts in SR is that, in the= case of
    > RSVP-TE, the operator would explicitly indicate, as part of LSP
    > signaling, whether it would or would not use FRR; LSPs that would not =
    > use FRR would then drop traffic rather than delivering it the wrong wa= y.
    >
    > Such an option indeed does not exist in SR-TE today, but would be easy=
    > to provide if so desired IMHO.
    >
    > Did I miss something substantial?
    >
    > Regards, and lots of thanks in advance,
    >
    > Sasha
    >
    > Office: +972-39266302
    >
    > Cell:      +972-549266302
    >
    > Email:   Alexander.Vainshtein@ecitele.com
    >
    > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM
    > *To:* EXT-Andrew.Alston@liquidtelecom.com
    > <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    > *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > All,
    >
    > This is a very interesting discussion and thanks to Joel for starting =
    > this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized  either by defining a flex= -algo
    > avoiding those
    >
    > Nodes and links or by using a stack of unprotected adj-sids that avoid=
    > restricted nodes and links. When a stack of adj-sids is used to
    > realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
    >
    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
    > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
    > is in use or not.
    >
    > Rgds
    >
    > Shraddha
    >
    > Juniper Business Use Only
    >
    > *From:* spring <spring-bounces@ietf.org
    > <m= ailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
    > *Sent:* Tuesday, August 4, 2020 5:41 AM
    > *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern
    > <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > *[External Email. Be cautious of content]*
    >
    > Robert this is actually far more difficult when – it can be an e= ntire
    > (long) series of nodes that need to be avoided.
    >
    > It could potentially be made to work but I’d worry that to do th= is –
    > you’d have to stack 10 – 20 – 30 negative labels = 211; and that wouldn’t
    > be viable.
    >
    > It’s easier to use algorithms and adjacency sids and other such = things
    > to calculate paths – the biggest trick is about the stack depth.=   When
    > you have this need for node avoidance – the need for 10+ label d= epth
    > is critical – unless you wanna be applying one hell of a lot of =
    > binding labels along the way which is a nightmare.
    >
    > But to answer your question, is this a common use case – it̵= 7;s a use
    > case that most of the people I discuss this with certain have – = I cant
    > comment on a global scale, or for anyone else, but every indication I =
    > have is that yes – its something people need, and want
    >
    > Andrew
    >
    > *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Sent:* Tuesday, 4 August 2020 01:27
    > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>>
    > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
    > <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org > <mailto:spring= @ietf.org>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > Is this a common use case ie.  "but rather – which nod= es / network
    > segments it can never touch or flow through."
    >
    > If so perhaps its time to define notion of *negative-SID* ie. list in =
    > the packet resources which given packet MUST not ever traverse. >
    > Put in the packet set of nodes or links which the packet should never =
    > traverse.
    >
    > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
    >
    > Best,
    > R.
    >
    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
    > <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
    >
    >     So –
    >
    >     One of the use cases, in fact, some very major= use cases in any
    >     spring technology for us revolve around the fo= llowing
    >
    >     a.The explicit avoidance of certain nodes
    >
    >     b.The explicit avoidance of certain sections o= f the network
    >
    >     Anything that could result in that explicit av= oidance being violated
    >     – would create, shall we say significant= problems.
    >
    >     Much of the use case is not a case of which no= des the packets flow
    >     through – but rather – which nodes= / network segments it can never
    >     touch or flow through.  Effectively, to b= e used as a technology to
    >     avoid certain things for specific reasons.
    >
    >     This is also one of the reasons for needing su= ch deep label stacks –
    >     this kind of detailed path programming tends t= o deepen the stack
    >     because you sometimes have to be pretty explic= it.
    >
    >     It is absolutely critical to us that this func= tionality is there –
    >     and that we can avoid situations which could c= ause traffic to
    >     accidently hit things explicitly avoided.
    >
    >     I wish I could be more specific than this, but= it is what it is.
    >
    >     Thanks
    >
    >     Andrew
    >
    >     *From:* spring <spring-bounces@ietf.org
    >     <mailto:spring-bounces@ietf.org>> *On Behal= f Of *Joel M. Halpern
    >     *Sent:* Monday, 3 August 2020 21:36
    >     *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
    >     *Cc:* spring@ietf..org <mailto:spring@ietf.org>
    >     *Subject:* Re: [spring] Spring protection - de= termining
    > applicability
    >
    >     (Since the thread has gotten long enough, reit= erating that this is as a
    >     participant, not a WG chair.)
    >
    >     Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
    >     choose to drop packets. For all sorts of reaso= ns.
    >     I think there are likely other reasons why one= may not want a random
    >     path rather than a chosen TE path. I think it = is important we be clear
    >     about what constraints may be / are violated w= hen we tell people they
    >     have this tool (protective rerouting) that is = intended to preserve QoS.
    >
    >     Let's be clear. I am not arguing that this is = not a good idea. It is a
    >     good idea. And useful. I am trying to figure o= tu what combination of
    >     additional mechanisms and clear descriptions w= ill lead to everyone
    >     getting the behavior they expect (which may no= t be the behavior they
    >     desire, but sometimes is the best we can do.)<= br> >
    >     Yours,
    >     Joel
    >
    >     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
    >      > Joel,
    >      >
    >      > Are we still talking about IP netwo= rks here ? Or perhaps some hard
    >      > slicing with real resource reservat= ions or detnets ?
    >      >
    >      > Because if we are talking = ;about IP networking I have two
    >     observations:
    >      >
    >      > A) If you need to traverse via a sp= ecific node (ie. firewall) you
    >     better
    >      > apply IP encapsulation to that node= .. I don't think IP
    >     encapsulation can
    >      > be hijacked today such that destina= tion address of the packet is
    >     ignored.
    >      >
    >      > B) Have you seen any IP network whe= re upon topology change (link
    >     or node
    >      > failure) you suddenly start dr= opping flows in spite of SPT offering
    >      > perhaps few ms longer path with 10 = ms more jitter ?
    >      >
    >      > Or are some SR marketing slides pro= mise to turn IP networks in
    >      > something new ? Worse ... do t= hey mention path quality guarantees,
    >      > resource reservations ? I hope= not.
    >      >
    >      > Thx,
    >      > R.
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
    >     <mailto:jmh@joelhalpern.com%20%0b>> <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">mailto:jmh@joelhalp= ern.com>> wrote:
    >      >
    >      > Well less serious for TE SIDs, I am= not sure the problem is
    >     restricted
    >      > to just service SIDs.
    >      >
    >      > Suppose that the PCE has specified = the path to meet some complex te
    >      > objective.  The bypass node ha= s no way of knowing what those
    >      > constraints
    >      > were.  And for some kinds of t= raffic, it is better to drop the packet
    >      > than to deliver it outside the enve= lop.  I suspect that the right
    >      > answer
    >      > to this is "too bad".&nbs= p; If so, as with the distinction regarding
    >     service
    >      > nodes, we should say so, shouldn't = we?
    >      >
    >      > Yours,
    >      > Joel
    >      >
    >      > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
    >      > > Mach, Joel and all,
    >      > >
    >      > > I think that in most cases: >      > >
    >      > > 1.There is clear differentiati= on between "topological" and
    >     "service"
    >      > > instructions in SID advertisem= ents. E.g.:
    >      > >
    >      > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
    >      > > corresponding IGP advertisemen= ts) represent topological
    >     instructions
    >      > >
    >      > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
    >      > >
    >      >
    >     <https://clicktime.symantec.com/3CCcy9mY6cMfbk= 7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ie= tf-bess-srv6-services-04
    >     <https://clicktime.symantec.com/3GC5af2z3JzphZDkPncHAQi6H2= ?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%= 2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo4T-L0nl%24>>= ;
    >      >
    >      > > draft) unsurprisingly represen= t “service” instructions
    >      > >
    >      > > 2.Segments that represent topo= logical instructions can be bypassed,
    >      > > while segments that represent = service instructions require
    >      > alternative
    >      > > protection mechanisms.
    >      > >
    >      > > This view seems to be aligned = with RFC 8402
    >      > > <https://clicktime.symantec.com/345NLCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%= 3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402
    >     <https://clicktime.sy= mantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%21%21NEt6yMaO-gk%21S0Y= usx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo0I4Ybtm%24>>= ;
    >     that says in Section 1:
    >      > >
    >      > >     In the cont= ext of an IGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defin= ed: the IGP-Adjacency segment and the
    >      > >
    >      > >     IGP-Prefix = segment.
    >      > >
    >      > >     In the cont= ext of a BGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defin= ed: the BGP peering segment and the
    >      > >
    >      > >     BGP-Prefix = segment.
    >      > >
    >      > > In the case of SR-MPLS this di= fferentiation is assumed in Section
    >      > 3.4 of
    >      > > the Node Protection for SR-TE = Path
    >      > >
    >      >
    >     <https://c= licktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx96H2?u=3Dhttps%3A%2F%2Fdatatrac= ker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-node-protection-for-sr-te-pa= ths-07%23section-3.4
    >     <https://clicktime.= symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%2Furldefense.com%2F= v3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-spring-no= de-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21%21NEt6yMaO-gk%21S0= Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9wO-Ssn%24>&g= t;
    >      >
    >      > > draft that says:
    >      > >
    >      > >     The node pr= otection mechanism described in the previous
    >     sections
    >      > >
    >      > >     depends on = the assumption that the label immediately below
    >      > the top
    >      > >
    >      > > label in the label stack is un= derstood in the IGP domain.  When the
    >      > >
    >      > >     provider ed= ge routers exchange service labels via BGP or some
    >      > other
    >      > >
    >      > >     non-IGP mec= hanism the bottom label is not understood in the IGP
    >      > >
    >      > >     domain.
    >      > >
    >      > >     The egress = node protection mechanisms described in the draft
    >      > >
    >      > >     [RFC8679 &l= t;https://clicktime.symantec= .com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo= c%2Fhtml%2Frfc8679
    >     <https:/= /clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u=3Dhttps%3A%2F%2Furldef= ense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679__%= 3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRD= uiDo8MGipXc%24>>]
    >     is
    >      > > applicable to this use case an= d no additional changes
    >      > >
    >      > >     will be req= uired for SR based networks
    >      > >
    >      > > The scenarios in which  d= ifferentiation between “topological” and
    >      > > “service” instruct= ions is broken are indeed problematic. E.g.,
    >      > consider
    >      > > the use case in which a Node S= ID in the ERO of a SR-TE path
    >      > identifies a
    >      > > node that acts as a firewall f= or all packets it receives, i.e.,
    >      > provides
    >      > > the firewall service without a= ny dedicated service SID
    >      > identifying it.
    >      > > One could say that the Node SI= D of such a node would combine
    >      > topological
    >      > > and service instructions thus = breaking the differentiation
    >      > between the two.
    >      > >
    >      > > I am not sure if usage of such= “combined” SIDs could be prevented
    >      > or at
    >      > > least discouraged.
    >      > >
    >      > > If not, providing an ability t= o identify such SIDs in the
    >      > advertisement
    >      > > mechanisms would be useful IMH= O.
    >      > >
    >      > > My 2c,
    >      > >
    >      > > Sasha
    >      > >
    >      > > Office: +972-39266302
    >      > >
    >      > > Cell:    &= nbsp; +972-549266302
    >      > >
    >      > > Email: Alexander.Vainshtein@ecitele.com
    >     <mailto:Alexander.Vainshtein@ecitele.com>=
    >      > <mailto:Alexander.Vainshtein@ecitele.= com>
    >      > >
    >      > > -----Original Message-----
    >      > > From: spring <spring-bounces@ietf.org<= br> >     <mailto:spring-bounces@ietf.org%0b>>
    >     <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen
    >      > > Sent: Monday, August 3, 2020 6= :30 AM
    >      > > To: Joel M. Halpern <jmh@joelhalpern.com >     <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.co= m>>;
    >     spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > Subject: Re: [spring] Spring p= rotection - determining applicability
    >      > >
    >      > > Hi Joel,
    >      > >
    >      > > I think this is a good point t= hat may not be discussed in the
    >      > past. And
    >      > > I also don't think there is a = "can be bypassed" indication in the
    >      > > routing advertisement for now.=
    >      > >
    >      > > IMHO, the information advertis= ed by routing is neutral, such
    >      > information
    >      > > (can or cannot be bypassed) is= more path specific, thus
    >     normally the
    >      > > controller should be responsib= le for deciding whether/which SID
    >      > can be
    >      > > bypassed.
    >      > >
    >      > > Best regards,
    >      > >
    >      > > Mach
    >      > >
    >      > >  > -----Original Messa= ge-----
    >      > >
    >      > >  > From: spring [mailt= o:spring-bounc= es@ietf.org
    >      > <mailto:spring-bounces@ietf.org>
    >     <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>] >     On Behalf Of Joel M.
    >      > >
    >      > >  > Halpern
    >      > >
    >      > >  > Sent: Monday, Augus= t 3, 2020 7:51 AM
    >      > >
    >      > >  > To: spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >      > >
    >      > >  > Subject: [spring] S= pring protection - determining applicability
    >      > >
    >      > >  >
    >      > >
    >      > >  > (WG Chair hat Off, = this is merely a note from a slightly
    >      > confused WG
    >      > >
    >      > >  > participant.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > I have been reading= the various repair drafts, and the various
    >      > >
    >      > >  > networks programmin= g and service programming draft, and I am
    >      > trying to
    >      > >
    >      > >  > figure out one aspe= ct of the combination.
    >      > >
    >      > >  >
    >      > >
    >      > >  > How does a node tha= t is doing some form of bypass (suppose, for
    >      > >
    >      > >  > simplicity, it is N= ode N2 deciding to bypass the next SID for
    >      > a failed
    >      > >
    >      > >  > node N3) know that = it is safe to do so?
    >      > >
    >      > >  >
    >      > >
    >      > >  > If the path was jus= t for TE, then it is "safe" if the new path
    >      > meets
    >      > >
    >      > >  > the TE criteria.&nb= sp; or maybe it is safe if it is even close, as
    >      > long as
    >      > >
    >      > >  > it is not used for = too long.
    >      > >
    >      > >  >
    >      > >
    >      > >  > But what if the nod= e were a Firewall, included to meet legal
    >      > > requirements?
    >      > >
    >      > >  > Or was some other n= ecessary programmatic transform (wince we are
    >      > >
    >      > >  > deliberately vague = about what nodes can do when asked suitably.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > Is there some "= ;can be bypassed" indication in the routing
    >      > >
    >      > >  > advertisements that= I missed?
    >      > >
    >      > >  >
    >      > >
    >      > >  > Thank you,
    >      > >
    >      > >  > Yours,
    >      > >
    >      > >  > Joel
    >      > >
    >      > >  >
    >      > >
    >      > >  > ___________________= ____________________________
    >      > >
    >      > >  > spring mailing list=
    >      > >
    >      > >  > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >      > >
    >      > >  >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
    >     <    https://clicktime.symantec.com/3Q7vX2qWSUdWVc892XuX= y2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.syman= tec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2__%3BJSU%21%21NEt6= yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo6HwPLil%= 24>
    >      > >
    >      >
    >     <https://clicktime.symantec.com/367qhU4KiUkzW9u= GC4eAvP46H2?u=3Dhttps%3A%252
    >     <https://clicktime.symantec.com/3A5B8H2Fm1rPnaZ= 3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.s= ymantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A252__%3BJSU%21%= 21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDozo= QiAHk%24>>
    >      > >
    >      > >  > F%2Fwww.= ietf.org
    >     <https://clicktime.symantec.com/39NznmYBtRuHAR= hGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.ietf= .org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOG= t8AkTRDuiDo-pPCjvR%24>
    >      > <https://clicktime.= symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?u=3Dhttp%3A%2F%2F2Fwww.ietf.org
    >     <https://clicktime.symantec.com/39NznmYBtR= uHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F2Fwww.= ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vp= RHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2Flistinfo%2Fspring
    >      > >
    >      > > ______________________________= _________________
    >      > >
    >      > > spring mailing list
    >      > >
    >      > > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org> <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>> >      > >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRnfMJtT6H2?u=3D= https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3= 67qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailma= n%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1o= iQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
    >      > >
    >      > >
    >      > >
    >      > >
    >      >
    >     ----------------------------------------------= --------------------------
    >      > > Notice: This e-mail together w= ith any attachments may contain
    >      > > information of Ribbon Communic= ations Inc. that is confidential
    >      > and/or
    >      > > proprietary for the sole use o= f the intended recipient. Any review,
    >      > > disclosure, reliance or distri= bution by others or forwarding
    >     without
    >      > > express permission is strictly= prohibited. If you are not the
    >      > intended
    >      > > recipient, please notify the s= ender immediately and then delete all
    >      > > copies, including any attachme= nts.
    >      > >
    >      >
    >     ----------------------------------------------= --------------------------
    >      > >
    >      > > ______________________________= _________________
    >      > > spring mailing list
    >      > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clic= ktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Furldefense.= com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%= 21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5K= lPnbj%24>
    >      > >
    >      >
    >      > ___________________________________= ____________
    >      > spring mailing list
    >      > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clic= ktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%2F%2Furldefense.= com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring__%3B%21%= 21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo5K= lPnbj%24>
    >      >
    >
    >     ______________________________________________= _
    >     spring mailing list
    >     spring@ietf.org <mailto:spring@ietf.org>
    >     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >    
    > <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%=
    > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
    > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >
    >
    >
    > ----------------------------------------------------------------------=
    > --
    > Notice: This e-mail together with any attachments may contain
    > information of Ribbon Communications Inc. that is confidential and/or =
    > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
    > recipient, please notify the sender immediately and then delete all > copies, including any attachments.
    > ----------------------------------------------------------------------=
    > --

    _______________________________________________
    spring mailing list
    spring@ietf.org https://clicktime.symantec.com/3Q1= xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo= %2Fspring
    _______________________________________________
    spring mailing list
    spring@ietf.org https://clicktime.symantec.com/3Q1= xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo= %2Fspring

     

     

    Notice: This e-mail together with any attachments may contain inform= ation of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review,= disclosure, reliance or distribution by others or forwarding without expre= ss permission is strictly prohibited. If you are not the intended recipient= , please notify the sender immediately and then delete all copies, including any attachments.

     

     

    _______________________________________________
    spring mailing list
    spring@ietf.org

    https://www.ietf.org/mailman/listinfo/spring<=
/o:p>

     

    --_000_CY4PR05MB357611A7B87D6F1984ECA700D55C0CY4PR05MB3576namp_-- From nobody Tue Aug 18 10:18:36 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 392613A041C; Tue, 18 Aug 2020 10:18:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: Cc: spring@ietf.org, draft-ietf-spring-srv6-network-programming.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159777110816.19994.6000057685104308247@ietfa.amsl.com> Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Date: Tue, 18 Aug 2020 10:18:28 -0700 Archived-At: Subject: [spring] Tsvart last call review of draft-ietf-spring-srv6-network-programming-17 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 17:18:29 -0000 Reviewer: Mirja Kühlewind Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This review did not identify any transport-related issues. Nits: - maybe spell out PE on first occurrence in section 4.8. - Also maybe spell out BUM in section 4.12 (as well as other abbreviation there). Also shouldn't it be s/BUM/BUM traffic/ ? - sec 4.13: s/multiple domains. it is one/multiple domains. It is one/ - Would be good to spell out PSP, USP and USD right at the beginning of section 4.16 From nobody Thu Aug 20 02:43:29 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F51D3A03F4; Thu, 20 Aug 2020 02:43:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: spring@ietf.org, last-call@ietf.org, draft-ietf-spring-srv6-network-programming.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159791658963.13971.1366615479386220756@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Thu, 20 Aug 2020 02:43:09 -0700 Archived-At: Subject: [spring] Opsdir last call review of draft-ietf-spring-srv6-network-programming-17 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 09:43:10 -0000 Reviewer: Dan Romascanu Review result: Has Issues This document together with the companion document [I-D.filsfils-spring-srv6-net-pgm-illustration] defines the SRv6 Network Programming concept and specifies the main segment routing behaviors to enable the creation of interoperable overlays with underlay optimization (Service Level Agreement). The document is Ready. There are a number of issues from an Operations and Management perspective that need further work, and it is assumed that they will be subject to work in the future. Some clarification on these issues would be however welcome before document approval. There are several references that are work-in-progress. For example basic concepts need to be understood from [I-D.filsfils-spring-srv6-net-pgm-illustration]. The control plane interaction is based on BGP-LS [I-D.ietf-idr-bgpls-srv6-ext] or on BGP IP/VPN/EVPN [I-D.ietf-bess-srv6-services]. These documents are listed as Informative References probably in order to avoid a downref for this Standards Track document, but actually this document cannot be implemented or even understood without stable versions of the later. >From the operators point of view I would like to draw the attention on Sections 6 and 8. - Section 6 (Operation) recommends the implementation of a implement a combined traffic counter (packets and bytes) per local SID entry. There is no indication how an operator would retrieve this information and if and how the values of these counters could be used for operational purposes. Adding such information would be useful. - Section 8 (Control Plane) describes how the controllers can explicitly provision the SIDs and/or discover them as part of a service discovery function. Subsections describe the usage of IGP, BGP-LS, and BGP IP/VPN/EVPN for these purposes. Operators should be aware that one or more of these protocols also need to be supported in an SDN deployment. From nobody Thu Aug 20 02:43:42 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE5B3A081B; Thu, 20 Aug 2020 02:43:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: spring@ietf.org, last-call@ietf.org, draft-ietf-spring-srv6-network-programming.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159791658944.18630.11670482592653630698@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Thu, 20 Aug 2020 02:43:09 -0700 Archived-At: Subject: [spring] Opsdir last call review of draft-ietf-spring-srv6-network-programming-17 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 09:43:10 -0000 Reviewer: Dan Romascanu Review result: Has Issues This document together with the companion document [I-D.filsfils-spring-srv6-net-pgm-illustration] defines the SRv6 Network Programming concept and specifies the main segment routing behaviors to enable the creation of interoperable overlays with underlay optimization (Service Level Agreement). The document is Ready. There are a number of issues from an Operations and Management perspective that need further work, and it is assumed that they will be subject to work in the future. Some clarification on these issues would be however welcome before document approval. There are several references that are work-in-progress. For example basic concepts need to be understood from [I-D.filsfils-spring-srv6-net-pgm-illustration]. The control plane interaction is based on BGP-LS [I-D.ietf-idr-bgpls-srv6-ext] or on BGP IP/VPN/EVPN [I-D.ietf-bess-srv6-services]. These documents are listed as Informative References probably in order to avoid a downref for this Standards Track document, but actually this document cannot be implemented or even understood without stable versions of the later. >From the operators point of view I would like to draw the attention on Sections 6 and 8. - Section 6 (Operation) recommends the implementation of a implement a combined traffic counter (packets and bytes) per local SID entry. There is no indication how an operator would retrieve this information and if and how the values of these counters could be used for operational purposes. Adding such information would be useful. - Section 8 (Control Plane) describes how the controllers can explicitly provision the SIDs and/or discover them as part of a service discovery function. Subsections describe the usage of IGP, BGP-LS, and BGP IP/VPN/EVPN for these purposes. Operators should be aware that one or more of these protocols also need to be supported in an SDN deployment. From nobody Thu Aug 20 07:08:34 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE3F3A0A43; Thu, 20 Aug 2020 07:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MUUIyjw7TzzI; Thu, 20 Aug 2020 07:08:30 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 E7AA03A09AD; Thu, 20 Aug 2020 07:08:29 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id c6so1699587ilo.13; Thu, 20 Aug 2020 07:08:29 -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=f5SFo6YDc0eoBzqDfJkYQj/efy46NDH08spevcDezp8=; b=EWzmG9sQhjtzXQYLA+oSPuiLt8cW46gFBZbhulXhcMg58GbRL0GHc4WpDpyFsh+R2i TmyIh5nOn9i1r0SaT+W9ZSIM2xK29u3rbZMWUglS4Tv2HUXpJrw7OhtskIJ2arVu3tdW iDXNyOqx3I/JUhZi299VzBncCdVgFhfcfb7NRhBCVkdJCINT5FoTQUSufy/C1Pm7MVh2 56Btq0EsanpoFpSJwdG1y+wtjyVt9UKlc75JrbLRCJueryN1hujXHFE6Gum0/jm0fHZ8 qKGb6fvru48lXyVP8+QwWr37ayhDtzKKwXYOlb3tsPkF8kGi3fKlnpDcricXiWhfV4TG wVow== 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=f5SFo6YDc0eoBzqDfJkYQj/efy46NDH08spevcDezp8=; b=LKsHi6yXF1k8K/R6WqtBrYdeOySRtpw9B2wfgXljTUv6vbAf7o9TAdCmylhKJ7oq3o 6SnmVpJub7l6zqNowsnL5FF4rNNwupAZURQwPKyBRRxxpx7L2mfiv9/mgQvenAcVyFOP L+GU7FCJwkBUNg4pUzom027eB60zp0SnfyvNn1LlseJrSCHgbDScneo2Yx0VYhZrlE+B 3SvYjS66Heh1E+6DVPI5fNLQ6kmUU14VvVgMT7/W/dp1HnlHDHhPa585whhoS8qHmzDX +oDaLNqj7lUPhyawBRLDfrkNbA+lJl7quaUourKtMdYJ8jmFdsYQFksfxdso0Awbxws/ Sn3g== X-Gm-Message-State: AOAM530yLAqDR2rOO7iPNvcIo9v8zY0d/9WO0G/UbQKAoHh4NZVQSp3y axmAx4j7DBlyVgD9OorPFVvWh/xEZ0lboFOw2Ml7I2o9m6wfeQ== X-Google-Smtp-Source: ABdhPJwV4yOQDDvuR4UBACI3oqz3hotj3ztuE9v2vo/lP7d5QtQwfsgQj3P0/2wIpWfwmauPR+DNLGW/Ms2i3ncFBD8= X-Received: by 2002:a05:6e02:1352:: with SMTP id k18mr2769031ilr.276.1597932507838; Thu, 20 Aug 2020 07:08:27 -0700 (PDT) MIME-Version: 1.0 References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Dhruv Dhody Date: Thu, 20 Aug 2020 19:37:50 +0530 Message-ID: To: bruno.decraene@orange.com Cc: "spring@ietf.org" , "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 14:08:32 -0000 Hi WG, Authors, I support adoption. Looking forward to changes as per the discussion in the other thread started by Joel. I found a few things that can increase the readability of the document. Minor - The document doesn't use normative keywords of RFC 2119 (RFC 2119 is in reference somehow still). I am wondering if section 3 and 4 could use them esp section 4. - Section 6, I feel we should at least add a reference to Section 8.1 of RFC 8402 [ https://tools.ietf.org/html/rfc8402#section-8.1 ] to provide a helpful pointer. Can we add some text regarding the context labels - that they do not impose any security issues with a suitable reference (provided that is true :)? - Can we expand "externally visible forwarding behavior", the reference to draft-bashandy-rtgwg-segment-routing-ti-lfa but I don't see that term being used there - Section 5 could use an example to describe the concept clearly Nits - Expand sids in abstract - Expand SRGB on first use - Should we state it clearly that this document is applicable for SR-MPLS only! - Suggest to use RFC 8402 notations for the all sids: Node-SIDs, Adj-SIDs, BSIDs instead of node-sids, adjacency-sids, binding-sids - Section 2, not sure about "SPRING enabled on each node" - Section tile for 2.1 and 2.3: I am not sure about the terms "node-sid explicit paths" and "adj-sid explicit paths" where the later is actually a mix of node-sids and adj-sids. Perhaps rename them as - section 2.1 to "Node protection for explicit paths with Node-SIDs" and 2.3 to "Node-protection for explicit paths with Adj-SIDs"? - Figures, add a legend stating what does the values "10", "30", "60" on the links mean - it is clear that it is cost, but would be good to be explicit. Thanks! Dhruv On Thu, Jul 30, 2020 at 5:54 PM wrote: > > Hi SPRING WG, > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have asked for WG adoption. > > > > Please indicate your support, comments, or objection, for adopting this draft as a working group item by August 20th 2020. (*) > > > > Could those who are willing to work on this document, please notify the list. That gives us an indication of the energy level in the working group to work on this. > > > > Thanks, > > Regards, > > Bruno, Jim, Joel > > > > [1] https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 > > (*) 3 weeks to account for the IETF meeting week and the august/summer period. > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Aug 20 15:06:29 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E77D3A14AA; Thu, 20 Aug 2020 15:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmA5BexWwczf; Thu, 20 Aug 2020 15:06:19 -0700 (PDT) Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (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 E04A93A1473; Thu, 20 Aug 2020 15:06:14 -0700 (PDT) Received: by mail-pj1-x1041.google.com with SMTP id j13so41355pjd.4; Thu, 20 Aug 2020 15:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Jdo/nHAPUiHaH+9fui/YM+xwSqMm801mROEFWbmSscY=; b=OPLw6Fd9iiPyIphTjDollCg1JQQOus8Hv3Q7wOvDdO9QyRXfuYZnh1vznDUDipgzzo qVlDFwvKSaVaMXs8DuoFL6JF2+yl7EhBIEPHPwqy70Nrqkds1eXthFTZGWnGxdGecTdy KoyvbrbXLyXGKjq9NnFiFUM71D4/Hj3Jamw9Un82hpsyFvmsKl1UByz0qQVfrKMNfPzV R7mv0XFy6HWD1XzQlUpF/87FcfQ0bdgSu8naHeC75Ip8baOEx/t4UauL5q8qBvfTPAQv PPhRlLUQj8vC07iopg2IKGMebQOVivAEE/5rPkTBTLImda9wi8ej+4f/7sIvvPQGyYc6 jg2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Jdo/nHAPUiHaH+9fui/YM+xwSqMm801mROEFWbmSscY=; b=Po8ynXvo3VC88Tym9+5d1wGKjMEx7g61zjug83RZPIAOaP/O8R+GHG41VQGQAbRYCo nWjBFRdGG7mG6e/iiCRsy43PrkLyf+kY5LMyURooIA4IvtUrlJWmIEfnXedTdYYf+29N T+bLC+ghYw8W8wet0qC+g7+gfOEt6oGO1CVOt2uWb1HyRqPUSb25wJIipVQv9Kge79CZ TCcwVTTWaIsmnbKLvn0YCjEeOHbr4YX42xeNxDhKeQm8RmK6dgGoAd+1T+NEznBbyiC9 0oCgvs2aWjhlN9rrga0LT1GW8pZg4PbAR9vxmV2DynydgSclpccxaiHYjkPD4cCl3Rt/ IJnA== X-Gm-Message-State: AOAM531YJZOjVnQTu9RMNHrldxAtppEVvvPQcN0PKYABpFnBh8wtCCmn XTE7xQPA5bc4aHd4rreffqZ07Xz5SE6XlA== X-Google-Smtp-Source: ABdhPJx1S+A4rM+SFRTPF854N7/ZYRQ6M1IyiA4mvDBQSJKQFXyJ7EhYCSEV2R4PDfydDgJ/tCRcaA== X-Received: by 2002:a17:90a:a10c:: with SMTP id s12mr330792pjp.32.1597961174044; Thu, 20 Aug 2020 15:06:14 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id i185sm23439pgd.28.2020.08.20.15.06.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2020 15:06:13 -0700 (PDT) To: last-call@ietf.org Cc: spring@ietf.org, spring-chairs@ietf.org, Bruno Decraene , jmh@joelhalpern.com, draft-ietf-spring-srv6-network-programming@ietf.org References: <159723694970.27067.9766029100632402951@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Fri, 21 Aug 2020 10:06:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <159723694970.27067.9766029100632402951@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] Last Call: (SRv6 Network Programming) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 22:06:28 -0000 IMHO there is still a logical defect in the description of the PSP flavor at https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-17#section-4.16.1 The description of the PSP flavor considers the packet to have (Segments Left == 0 and Destination Address == the PSP node's address). In fact that is *never* the state of the packet on the wire, which is either (Segments Left == 1 and Destination Address == the PSP node's address) when the packet arrives, or (Segments Left == 0 and Destination Address == the final node's address) when the packet departs. So the text does not refer a packet on the wire, whereas RFC8200 only refers to packets on the wire. Thus the test "S14.1. If (Segments Left == 0) {" in section 4.16.1 is confusing because it's applied to a packet that is half way through processing of the routing header inside the node (Segments Left has been updated, but Destination Address has not been updated). This makes it unclear how the spec is claiming to interpret RFC 8200. (This was pointed out a long time ago: https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/ ) The text: > This behavior does not contravene Section 4 of [RFC8200] because the > current destination address of the incoming packet is the address of > the node executing the PSP behavior. is being applied to a packet that never exists on the wire, but only inside the PSP node. Regards Brian Carpenter On 13-Aug-20 00:55, The IESG wrote: > > The IESG has received a request from the Source Packet Routing in Networking > WG (spring) to consider the following document: - 'SRv6 Network Programming' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-08-26. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > The SRv6 Network Programming framework enables a network operator or > an application to specify a packet processing program by encoding a > sequence of instructions in the IPv6 packet header. > > Each instruction is implemented on one or several nodes in the > network and identified by an SRv6 Segment Identifier in the packet. > > This document defines the SRv6 Network Programming concept and > specifies the base set of SRv6 behaviors that enables the creation of > interoperable overlays with underlay optimization (Service Level > Agreements). > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ > > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/3464/ > > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From nobody Fri Aug 21 08:43:47 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F883A0BBE; Fri, 21 Aug 2020 08:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZFrfqPoG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GitRWgVi 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 z8ofpMpvruNW; Fri, 21 Aug 2020 08:43:40 -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 043143A0BD2; Fri, 21 Aug 2020 08:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5136; q=dns/txt; s=iport; t=1598024620; x=1599234220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KwMakZfaibsN3b7ITqcsalONow4W5piC0g8ysDKvXO4=; b=ZFrfqPoGM8r0wYODxibRvFmUwB1RgnG6GBvZ52G3TDn/39svMKVE1s8Q 9l+DUe2d20SxAa9rWdCSSbMEXCbC9VH4E2sHFB7hxYNAldXgsfutr9FDn uvCvL2X6czSpH63DobEy0qKENcUVvwoGQnyNwWtZrwv7EF/hFkDIX0kWV E=; IronPort-PHdr: =?us-ascii?q?9a23=3Ar5CKwhM8rWcgZLEYoSol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3lDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAADl6j9f/4YNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTgFAQELAYFRUQeBSC8sCoQtg0YDjWuKC45kgS6BJQNVCwE?= =?us-ascii?q?BAQwBAS0CBAEBhEwCF4ItAiQ2Bw4CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQE?= =?us-ascii?q?EEhERDAEBNwELBAIBCA4DBAEBAwImAgICHxEVCAgCBAENBQgahVADLgGlbAK?= =?us-ascii?q?BOYhhdoEygwEBAQWFRQ0Lgg4JgQ4qAYJwg2KGTxuBQT+BEUOCTT6CGoFtOIM?= =?us-ascii?q?VM4Iti0OEBimDFqIxN1EKgmOPMIULaQSFHYMEiWKTTJJCgW2LQZIZAgQCBAU?= =?us-ascii?q?CDgEBBYFbCSqBV3AVgyRQFwINjh8JAwUSg06KVnQ3AgYKAQEDCXyPBgEwYAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.76,337,1592870400"; d="scan'208";a="816962097" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2020 15:43:38 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 07LFhcdF000567 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Aug 2020 15:43:38 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 21 Aug 2020 10:43:38 -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.1497.2; Fri, 21 Aug 2020 11:43:37 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 21 Aug 2020 10:43:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PEqldI2DQZSmo+zUB9nhgsH2wWf9Z4+qM+NKLBLe4DZhbDpBaCQP/OV3reZphlYpLIwPUXLXS/rVnhL20pa4EwCpxKxV5KwrjfjpHbVhe5oiKayYBhmHZpfqcdG+tjPWoOR3/hPu5Q56hGJaIevB92V8r5kduRzWlk3Ygw9HbWRg9vyuUI9VXLss8EysDv86M7WB0vUIltwAufQ0xz+iKVW3GLUcnMuvExhvNgbSbPadM7cC4Vj4aI+j70wHWU8q+gy+TnyaFYeXo2ZyMh8Bvtn4Xennkhpyqxbd/l+e5owQJevjaPW7JHv2x4RNe1qWH8e7DccHAd2TcORWaX4AOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KwMakZfaibsN3b7ITqcsalONow4W5piC0g8ysDKvXO4=; b=RnQNdXX/1xCuhOAjqob5SLxp19uFh5is6lbvjY35KL1Sz1otk4AWzgKg4p2LoUdcGJ0pJML5PyeE5/XayfsL8EHOeGeTOqtecmaRkBAEtGtFNKXxHa2QPwa/unr3ANqK2eZadm4nbxv9V13r3pJMj8YXKEchys3xHKqOncanHpAoiLPC4Jtq+9+w8L3W+fEPndwqKrKAqOFiCkPjSQzJJJd2H6JdDwb8125HewoZi/jw/YqSvEmvrSI9RIma2lI6RIwW8GfcD5A/jtAB7/LRbsHOZVONDL/Ava2MPB9x4aIzP7+qFDtcg2IkHog+EDdp7i8+2OmOiTNRuQ6/8NT/IQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KwMakZfaibsN3b7ITqcsalONow4W5piC0g8ysDKvXO4=; b=GitRWgViZ6HX5Sjh2yf6Cn61scY3e0ivAyPmKqiU9iWR12lhpVyhvapqhUHcpIOiuY3mU9dK+/rk1FqYSL2CMwOkAajmFYjdyT7m86Oac+wWc4z4z+VP7xuKQWOYMFL8MZZ4G7MfjfphNJRJ+b+dzRgMIltFI6XSNRAQAOL+xOQ= Received: from MWHPR11MB1374.namprd11.prod.outlook.com (2603:10b6:300:24::8) by MWHPR1101MB2239.namprd11.prod.outlook.com (2603:10b6:301:5b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Fri, 21 Aug 2020 15:43:36 +0000 Received: from MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e]) by MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e%12]) with mapi id 15.20.3305.026; Fri, 21 Aug 2020 15:43:36 +0000 From: "Pablo Camarillo (pcamaril)" To: Dan Romascanu , "ops-dir@ietf.org" CC: "spring@ietf.org" , "last-call@ietf.org" , "draft-ietf-spring-srv6-network-programming.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-spring-srv6-network-programming-17 Thread-Index: AQHWdtZU76jON8NWQEqOHXJMTsteNqlCYrxw Date: Fri, 21 Aug 2020 15:43:36 +0000 Message-ID: References: <159791658944.18630.11670482592653630698@ietfa.amsl.com> In-Reply-To: <159791658944.18630.11670482592653630698@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.43] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22796d2c-cfed-4044-49b1-08d845e8f7ca x-ms-traffictypediagnostic: MWHPR1101MB2239: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0chWcXLMwf63U0uTL0a52tFmgHlZtNg4IYkM2TWEveWqFht4MpLKppWEeBlzwQcQ0FfmR/fdkS8MmVVGYjb7rdxrk3XSaGkeFbKE6lnKh4VVpqrMq2gLpOjaYZF399w87IM6nwHnp/AKT3okuaakOATwFO66zheRc56zrk2+X+RFAxE2EdDQ42hmn/4gV7yOW00kTPOx5uf4+DeZ+8hNnsuWGs9Zli20Z2v0vQkJdKz4z7S3Vm3n9eVz5rh5rwgn3t/E+7+UwFCzF7LLHtQ2b5UjU+hOPK20oEhTWcOlcKgKmZgoY1OqQwdLK98+onDcYjEJl0J787V/OYnpsnqg7A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1374.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(136003)(39860400002)(366004)(55016002)(76116006)(66476007)(64756008)(66446008)(66946007)(8936002)(26005)(186003)(478600001)(52536014)(9686003)(54906003)(33656002)(110136005)(71200400001)(316002)(2906002)(66556008)(86362001)(5660300002)(83380400001)(7696005)(6506007)(8676002)(4326008)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +vhcX2iXoTb4x4Fp78hNpEtq3gPSyRXwm9J2yv1EiTLMZV3A/VIGoJ5uvSPK1r7xmFR/b7pz+xGNGhgcGyDoe2RddAk61VdAWILctEx8kTtsoxjygzZtlOx2oWoxE4/ETmD+2n62U0SkfLw7tZ8NyNE9KrpT7e0p2VR49HqiXIUC4H/Aj2LV51mEUJNLfxjeKgrO5XBi6MDhoFQg3YUHcDmwusRj3qkQ8+WyKHogVE/lOTFnqb9uf8nktFU+nmD3VJ8uFlev3U/Joct+n6jLXoIVLUz2LIfTOexa4wMAwdA0sqZ/Ci6t920ogQAJohT1q4UgxZOE0pZjpLAimT8/ZVT8auuGUrUJp3Ma/sttgrYlmMXXKOhst1oOuw9P814ISxYSFmN6FhaU7uqAp+NlkOtYKTFyMgGED8vui/e/6OwuwkxOAF+shc6AWkW61xlttwoG0HjHYDg2eRPn80g/Kgf0bfKVgvKNac6hMJLDmtJhYYJY1ra/8zA31KizukjqbSOlxl4lUTeJdEUQfG8eTMTQ3J/pXiRY+j4nInfdrh3bbEs5lWn+J59ZFduVg3Z/7jLukTsBo8fGRpyshJzNFlWrzRu/N7tBzFp2Nk8hlgvG6J2iZzhOFwwAw9X4ZkWnbr8XGZU3JLOOWa6aiiPAEA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1374.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22796d2c-cfed-4044-49b1-08d845e8f7ca X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2020 15:43:36.3514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nkER92YyTD7ToUp3lbQmRxqBY2GvBy+TxBam+SqC8C1Dpmc+PGhoMgW/NY6iopvVvGa17/+Bz1MX2nfucNx6Xg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2239 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] Opsdir last call review of draft-ietf-spring-srv6-network-programming-17 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 15:43:42 -0000 SGkgRGFuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgY29tbWVudHMg aW5saW5lIHdpdGggW1BDXS4NCg0KUmVnYXJkcywNClBhYmxvLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRGFuIFJvbWFzY2FudSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlA aWV0Zi5vcmc+IA0KU2VudDoganVldmVzLCAyMCBkZSBhZ29zdG8gZGUgMjAyMCAxMTo0Mw0KVG86 IG9wcy1kaXJAaWV0Zi5vcmcNCkNjOiBzcHJpbmdAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLmFsbEBpZXRmLm9y ZzsgZHJvbWFzY2FAZ21haWwuY29tDQpTdWJqZWN0OiBPcHNkaXIgbGFzdCBjYWxsIHJldmlldyBv ZiBkcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMTcNCg0KUmV2aWV3 ZXI6IERhbiBSb21hc2NhbnUNClJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCg0KVGhpcyBkb2N1 bWVudCB0b2dldGhlciB3aXRoIHRoZSBjb21wYW5pb24gZG9jdW1lbnQgW0ktRC5maWxzZmlscy1z cHJpbmctc3J2Ni1uZXQtcGdtLWlsbHVzdHJhdGlvbl0gZGVmaW5lcyB0aGUgU1J2NiBOZXR3b3Jr IFByb2dyYW1taW5nIGNvbmNlcHQgYW5kIHNwZWNpZmllcyB0aGUgbWFpbiBzZWdtZW50IHJvdXRp bmcgYmVoYXZpb3JzIHRvIGVuYWJsZSB0aGUgY3JlYXRpb24gb2YgaW50ZXJvcGVyYWJsZSBvdmVy bGF5cyB3aXRoIHVuZGVybGF5IG9wdGltaXphdGlvbiAoU2VydmljZSBMZXZlbCBBZ3JlZW1lbnQp Lg0KDQpUaGUgZG9jdW1lbnQgaXMgUmVhZHkuICBUaGVyZSBhcmUgYSBudW1iZXIgb2YgaXNzdWVz IGZyb20gYW4gT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBwZXJzcGVjdGl2ZSB0aGF0IG5lZWQg ZnVydGhlciB3b3JrLCBhbmQgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZXkgd2lsbCBiZSBzdWJqZWN0 IHRvIHdvcmsgaW4gdGhlIGZ1dHVyZS4gU29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZXNlIGlzc3Vl cyB3b3VsZCBiZSBob3dldmVyIHdlbGNvbWUgYmVmb3JlIGRvY3VtZW50IGFwcHJvdmFsLg0KDQpU aGVyZSBhcmUgc2V2ZXJhbCByZWZlcmVuY2VzIHRoYXQgYXJlIHdvcmstaW4tcHJvZ3Jlc3MuIEZv ciBleGFtcGxlIGJhc2ljIGNvbmNlcHRzIG5lZWQgdG8gYmUgdW5kZXJzdG9vZCBmcm9tIFtJLUQu Zmlsc2ZpbHMtc3ByaW5nLXNydjYtbmV0LXBnbS1pbGx1c3RyYXRpb25dLiANCg0KW1BDXSBUaGUg aWxsdXN0cmF0aW9ucyB1c2VkIHRvIGJlIHBhcnQgb2YgdGhpcyBkb2N1bWVudCBvcmlnaW5hbGx5 IGJ1dCB3ZXJlIG1vdmVkIHRvIGEgc2VwYXJhdGUgaW5mb3JtYXRpb25hbCBkb2N1bWVudCBiYXNl ZCBvbiBXRyBmZWVkYmFjay4gDQoNClRoZSBjb250cm9sIHBsYW5lIGludGVyYWN0aW9uIGlzIGJh c2VkIG9uIEJHUC1MUyAgW0ktRC5pZXRmLWlkci1iZ3Bscy1zcnY2LWV4dF0gb3Igb24gQkdQIElQ L1ZQTi9FVlBOIFtJLUQuaWV0Zi1iZXNzLXNydjYtc2VydmljZXNdLiBUaGVzZSBkb2N1bWVudHMg YXJlIGxpc3RlZCBhcyBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIHByb2JhYmx5IGluIG9yZGVyIHRv IGF2b2lkIGEgZG93bnJlZiBmb3IgdGhpcyBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQsIGJ1dCBh Y3R1YWxseSB0aGlzIGRvY3VtZW50IGNhbm5vdCBiZSBpbXBsZW1lbnRlZCBvciBldmVuIHVuZGVy c3Rvb2Qgd2l0aG91dCBzdGFibGUgdmVyc2lvbnMgb2YgdGhlIGxhdGVyLg0KDQpbUENdIEFmdGVy IHJlLXJlYWRpbmcgc2VjdGlvbiA4IEkgZG9uJ3Qgc2VlIGEgbmVlZCBmb3IgdGhlIGluZm9ybWF0 aXZlIHJlZmVyZW5jZXMgdG8gaWV0Zi1pZHItYmdwbHMtc3J2Ni1leHQgYW5kIGlldGYtYmVzcy1z cnY2LXNlcnZpY2VzLiBXZSB3aWxsIHJlbW92ZSB0aG9zZSB0d28uIFRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIGEgc2V0IG9mIFNSdjYgU0lEIGJlaGF2aW9ycyBmb3Igc3VwcG9ydGluZyBvZiBURSBh bmQgb3ZlcmxheSBzZXJ2aWNlcyB1c2luZyBTUnY2OyB0aGVzZSBURSBhbmQgb3ZlcmxheSBzZXJ2 aWNlcyB0aGVtc2VsdmVzIGFyZSBub3QgbmV3IChlLmcuIHRoZXkgYXJlIGF2YWlsYWJsZSB3aXRo IE1QTFMgZGF0YSBwbGFuZSkgYW5kIHRoZSBkb2N1bWVudCBpbmNsdWRlcyByZWZlcmVuY2VzIHRv IHRoZW0uIENvbnRyb2wgcGxhbmUgZXh0ZW5zaW9ucyBhcmUgY292ZXJlZCBieSBkb2N1bWVudHMg cHJvZ3Jlc3NpbmcgaW4gb3RoZXIgUlRHIFdHcy4NCg0KPkZyb20gdGhlIG9wZXJhdG9ycyBwb2lu dCBvZiB2aWV3IEkgd291bGQgbGlrZSB0byBkcmF3IHRoZSBhdHRlbnRpb24gb24gDQo+U2VjdGlv bnMgNiBhbmQgOC4gDQoNCi0gU2VjdGlvbiA2IChPcGVyYXRpb24pIHJlY29tbWVuZHMgdGhlIGlt cGxlbWVudGF0aW9uIG9mIGEgaW1wbGVtZW50IGEgY29tYmluZWQgdHJhZmZpYyBjb3VudGVyIChw YWNrZXRzIGFuZCBieXRlcykgcGVyIGxvY2FsIFNJRCBlbnRyeS4gVGhlcmUgaXMgbm8gaW5kaWNh dGlvbiBob3cgYW4gb3BlcmF0b3Igd291bGQgcmV0cmlldmUgdGhpcyBpbmZvcm1hdGlvbiBhbmQg aWYgYW5kIGhvdyB0aGUgdmFsdWVzIG9mIHRoZXNlIGNvdW50ZXJzIGNvdWxkIGJlIHVzZWQgZm9y IG9wZXJhdGlvbmFsIHB1cnBvc2VzLiBBZGRpbmcgc3VjaCBpbmZvcm1hdGlvbiB3b3VsZCBiZSB1 c2VmdWwuIA0KDQpbUENdIFRoZXNlIGNvdW50ZXJzIGFyZSBpbmNsdWRlZCBpbiB0aGUgZHJhZnQg ZHJhZnQtcmF6YS1zcHJpbmctc3J2Ni15YW5nIHRoYXQgd2FzIGp1c3QgcmVjZW50bHkgYWRvcHRl ZCBieSB0aGUgU3ByaW5nIFdHLiBJJ2xsIHVwZGF0ZSB0aGlzIHNlY3Rpb24gdG8gaW5kaWNhdGUg dGhhdCByZXRyaWV2YWwgb2YgdGhlc2UgY291bnRlcnMgdmlhIE1JQiwgTkVUQ09ORi9ZQU5HIG9y IG90aGVyIG1lYW5zIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQogDQot IFNlY3Rpb24gOCAoQ29udHJvbCBQbGFuZSkgZGVzY3JpYmVzIGhvdyB0aGUgY29udHJvbGxlcnMg Y2FuIGV4cGxpY2l0bHkgcHJvdmlzaW9uIHRoZSBTSURzIGFuZC9vciBkaXNjb3ZlciB0aGVtIGFz IHBhcnQgb2YgYSBzZXJ2aWNlIGRpc2NvdmVyeSBmdW5jdGlvbi4gU3Vic2VjdGlvbnMgZGVzY3Jp YmUgdGhlIHVzYWdlIG9mIElHUCwgQkdQLUxTLCBhbmQgQkdQIElQL1ZQTi9FVlBOIGZvciB0aGVz ZSBwdXJwb3Nlcy4gT3BlcmF0b3JzIHNob3VsZCBiZSBhd2FyZSB0aGF0IG9uZSBvciBtb3JlIG9m IHRoZXNlIHByb3RvY29scyBhbHNvIG5lZWQgdG8gYmUgc3VwcG9ydGVkIGluIGFuIFNETiBkZXBs b3ltZW50Lg0KDQpbUENdIEkgd291bGQgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGRpZmYNCjxvbGQ+ DQpUaGlzIHNlY3Rpb24gcHJvdmlkZXMgYSBoaWdoIGxldmVsIG92ZXJ2aWV3IG9mIHRoZSBjb250 cm9sLXBsYW5lIHByb3RvY29scyBpbnZvbHZlZCB3aXRoIFNSdjYgYW5kIHRoZWlyIHNwZWNpZmlj YXRpb24uDQo8L29sZD4NCjxuZXc+DQpXaGlsZSBub3QgbmVjZXNzYXJ5IGZvciBhbiBTRE4gY29u dHJvbCBwbGFuZSwgdGhlIHJlbWFpbmRlciBvZiB0aGlzIHNlY3Rpb24gcHJvdmlkZXMgYSBoaWdo LWxldmVsIGlsbHVzdHJhdGl2ZSBvdmVydmlldyBvZiBob3cgY29udHJvbC1wbGFuZSBwcm90b2Nv bHMgbWF5IGJlIGludm9sdmVkIHdpdGggU1J2Ni4gVGhlaXIgc3BlY2lmaWNhdGlvbiBpcyBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPC9uZXc+DQoNCg0KDQo= From nobody Fri Aug 21 14:14:26 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D461B3A1294; Fri, 21 Aug 2020 14:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHOuORqLEf0h; Fri, 21 Aug 2020 14:14:21 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 75C0B3A128E; Fri, 21 Aug 2020 14:14:18 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id e11so2552638ils.10; Fri, 21 Aug 2020 14:14:18 -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=zQiQkqIDtPvQby6sCMSSYIxTMr+7LJjIM13eC6lgT6s=; b=gIV+E8ZQtZUEBb5OuwOJbk+uBiKzs9czYgOqDxuTzmmxTFuDL7daFVYEsxnPmlKUjc 8a7vEh7Cn0gZvN65oUMFZLvhJERVxRnGj1gLEpXxgDhXVPJeSDxuijDYRlD6Fl3JzL1O CagEYEeoHgyJVGT7hDE4Mq62M+J6lGQdm84VseiV1LdKOJricxQbCXM2R7oinUGWYKaf kG7Wi2mdUGy+Lm0rk6c60x64RcU7dlAeB6JDBhCAjz4swD8vFspNbYwRwmztKRceFjlE i8AKE2uWTrKI1B/iIcq8aVO1wgI9QCOyKaLhPJqBHo0Oegjqu/J/HEFK0daq5WtD//aP nZjQ== 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=zQiQkqIDtPvQby6sCMSSYIxTMr+7LJjIM13eC6lgT6s=; b=hBQTpk0K8IV2Jr4JqY9J4ETdxD1c037m6oAGY/iuR2bUDy7J+u87ONa840LiFzcUlC oVpenLUvHiJyZ/Pk92HRkAdxHW77T6Z0DItUNJ/SHd8/+g7GHi/FYm5Aa3lPP7iorxzn gGFJnxFtfAkUO/FeFNl0rIhS92BmGdF2hFe7oPuM4Y2iQBcpb9OGwbqTG/dMWLGf7JyC UYtjqSQaoNNSJbB4L8xaeJSsFwgVm9feWcJRQ9kd1n3ODTgml41hmQ6LW6WgNToiRKRM g7/LvhsZBJas5J5VUFxpTRz0Rns2ybUjYkkC4KuME4AqBPhOe+TNEFFnwhdUyx2c+5IJ uyPg== X-Gm-Message-State: AOAM531s8PmRi5wKU/ZXSbCwlmwVMQUQIrRveNHafZXUKAPHTyqnvPAH Riys5EPtyQNdAP1Z9qM7fWRbF+3yzhutPrZlWyWPA+Lkobk= X-Google-Smtp-Source: ABdhPJwap/Gd6jIwqilILwxLz/ycv/+/N3t9MOBxamiVZmqrZlNbF7A1KR02EHjeEmANqrWwSt9OQ4jcqmRsGLZNwDg= X-Received: by 2002:a05:6e02:ea3:: with SMTP id u3mr4094331ilj.49.1598044457537; Fri, 21 Aug 2020 14:14:17 -0700 (PDT) MIME-Version: 1.0 References: <159791658944.18630.11670482592653630698@ietfa.amsl.com> In-Reply-To: From: Dan Romascanu Date: Sat, 22 Aug 2020 00:14:06 +0300 Message-ID: To: "Pablo Camarillo (pcamaril)" Cc: "ops-dir@ietf.org" , "spring@ietf.org" , "last-call@ietf.org" , "draft-ietf-spring-srv6-network-programming.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003a137505ad69b8cd" Archived-At: Subject: Re: [spring] Opsdir last call review of draft-ietf-spring-srv6-network-programming-17 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 21:14:24 -0000 --0000000000003a137505ad69b8cd Content-Type: text/plain; charset="UTF-8" Hi Pablo, Thank you for your quick answer and for addressing my comments. Your suggested edits are fine with me. Regards, Dan On Fri, Aug 21, 2020 at 6:43 PM Pablo Camarillo (pcamaril) < pcamaril@cisco.com> wrote: > Hi Dan, > > Thank you for the review. Please see comments inline with [PC]. > > Regards, > Pablo. > > -----Original Message----- > From: Dan Romascanu via Datatracker > Sent: jueves, 20 de agosto de 2020 11:43 > To: ops-dir@ietf.org > Cc: spring@ietf.org; last-call@ietf.org; > draft-ietf-spring-srv6-network-programming.all@ietf.org; > dromasca@gmail.com > Subject: Opsdir last call review of > draft-ietf-spring-srv6-network-programming-17 > > Reviewer: Dan Romascanu > Review result: Has Issues > > This document together with the companion document > [I-D.filsfils-spring-srv6-net-pgm-illustration] defines the SRv6 Network > Programming concept and specifies the main segment routing behaviors to > enable the creation of interoperable overlays with underlay optimization > (Service Level Agreement). > > The document is Ready. There are a number of issues from an Operations > and Management perspective that need further work, and it is assumed that > they will be subject to work in the future. Some clarification on these > issues would be however welcome before document approval. > > There are several references that are work-in-progress. For example basic > concepts need to be understood from > [I-D.filsfils-spring-srv6-net-pgm-illustration]. > > [PC] The illustrations used to be part of this document originally but > were moved to a separate informational document based on WG feedback. > > The control plane interaction is based on BGP-LS > [I-D.ietf-idr-bgpls-srv6-ext] or on BGP IP/VPN/EVPN > [I-D.ietf-bess-srv6-services]. These documents are listed as Informative > References probably in order to avoid a downref for this Standards Track > document, but actually this document cannot be implemented or even > understood without stable versions of the later. > > [PC] After re-reading section 8 I don't see a need for the informative > references to ietf-idr-bgpls-srv6-ext and ietf-bess-srv6-services. We will > remove those two. This document specifies a set of SRv6 SID behaviors for > supporting of TE and overlay services using SRv6; these TE and overlay > services themselves are not new (e.g. they are available with MPLS data > plane) and the document includes references to them. Control plane > extensions are covered by documents progressing in other RTG WGs. > > >From the operators point of view I would like to draw the attention on > >Sections 6 and 8. > > - Section 6 (Operation) recommends the implementation of a implement a > combined traffic counter (packets and bytes) per local SID entry. There is > no indication how an operator would retrieve this information and if and > how the values of these counters could be used for operational purposes. > Adding such information would be useful. > > [PC] These counters are included in the draft draft-raza-spring-srv6-yang > that was just recently adopted by the Spring WG. I'll update this section > to indicate that retrieval of these counters via MIB, NETCONF/YANG or other > means is outside the scope of this document. > > - Section 8 (Control Plane) describes how the controllers can explicitly > provision the SIDs and/or discover them as part of a service discovery > function. Subsections describe the usage of IGP, BGP-LS, and BGP > IP/VPN/EVPN for these purposes. Operators should be aware that one or more > of these protocols also need to be supported in an SDN deployment. > > [PC] I would propose the following diff > > This section provides a high level overview of the control-plane protocols > involved with SRv6 and their specification. > > > While not necessary for an SDN control plane, the remainder of this > section provides a high-level illustrative overview of how control-plane > protocols may be involved with SRv6. Their specification is outside the > scope of this document. > > > > > --0000000000003a137505ad69b8cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Pablo,

    Thank you for your= quick answer and for addressing my comments.

    Your suggested edits are fine with me.

    Regar= ds,

    Dan


    On Fri, Aug 21, 2020= at 6:43 PM Pablo Camarillo (pcamaril) <pcamaril@cisco.com> wrote:
    Hi Dan,

    Thank you for the review. Please see comments inline with [PC].

    Regards,
    Pablo.

    -----Original Message-----
    From: Dan Romascanu via Datatracker <noreply@ietf.org>
    Sent: jueves, 20 de agosto de 2020 11:43
    To: ops-dir@ietf.org<= /a>
    Cc:     spring@ietf.org; last-call@ietf.o= rg; draft-ietf-spring-srv6-network-programming.all@ie= tf.org; dromasc= a@gmail.com
    Subject: Opsdir last call review of draft-ietf-spring-srv6-network-programm= ing-17

    Reviewer: Dan Romascanu
    Review result: Has Issues

    This document together with the companion document [I-D.filsfils-spring-srv= 6-net-pgm-illustration] defines the SRv6 Network Programming concept and sp= ecifies the main segment routing behaviors to enable the creation of intero= perable overlays with underlay optimization (Service Level Agreement).

    The document is Ready.=C2=A0 There are a number of issues from an Operation= s and Management perspective that need further work, and it is assumed that= they will be subject to work in the future. Some clarification on these is= sues would be however welcome before document approval.

    There are several references that are work-in-progress. For example basic c= oncepts need to be understood from [I-D.filsfils-spring-srv6-net-pgm-illust= ration].

    [PC] The illustrations used to be part of this document originally but were= moved to a separate informational document based on WG feedback.

    The control plane interaction is based on BGP-LS=C2=A0 [I-D.ietf-idr-bgpls-= srv6-ext] or on BGP IP/VPN/EVPN [I-D.ietf-bess-srv6-services]. These docume= nts are listed as Informative References probably in order to avoid a downr= ef for this Standards Track document, but actually this document cannot be = implemented or even understood without stable versions of the later.

    [PC] After re-reading section 8 I don't see a need for the informative = references to ietf-idr-bgpls-srv6-ext and ietf-bess-srv6-services. We will = remove those two. This document specifies a set of SRv6 SID behaviors for s= upporting of TE and overlay services using SRv6; these TE and overlay servi= ces themselves are not new (e.g. they are available with MPLS data plane) a= nd the document includes references to them. Control plane extensions are c= overed by documents progressing in other RTG WGs.

    >From the operators point of view I would like to draw the attention on =
    >Sections 6 and 8.

    - Section 6 (Operation) recommends the implementation of a implement a comb= ined traffic counter (packets and bytes) per local SID entry. There is no i= ndication how an operator would retrieve this information and if and how th= e values of these counters could be used for operational purposes. Adding s= uch information would be useful.

    [PC] These counters are included in the draft draft-raza-spring-srv6-yang t= hat was just recently adopted by the Spring WG. I'll update this sectio= n to indicate that retrieval of these counters via MIB, NETCONF/YANG or oth= er means is outside the scope of this document.

    - Section 8 (Control Plane) describes how the controllers can explicitly pr= ovision the SIDs and/or discover them as part of a service discovery functi= on. Subsections describe the usage of IGP, BGP-LS, and BGP IP/VPN/EVPN for = these purposes. Operators should be aware that one or more of these protoco= ls also need to be supported in an SDN deployment.

    [PC] I would propose the following diff
    <old>
    This section provides a high level overview of the control-plane protocols = involved with SRv6 and their specification.
    </old>
    <new>
    While not necessary for an SDN control plane, the remainder of this section= provides a high-level illustrative overview of how control-plane protocols= may be involved with SRv6. Their specification is outside the scope of thi= s document.
    </new>



    --0000000000003a137505ad69b8cd-- From nobody Fri Aug 21 20:13:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BD23A094A for ; Fri, 21 Aug 2020 20:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=JzaZsxg9; dkim=pass (1024-bit key) header.d=juniper.net header.b=KLkh1mLr 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 nuaEtRVUF2Vq for ; Fri, 21 Aug 2020 20:13:39 -0700 (PDT) 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 BA30A3A0944 for ; Fri, 21 Aug 2020 20:13:39 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07M3DWHt021854; Fri, 21 Aug 2020 20:13:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=TqiT2tW0eDuyRbFjooR+mqQGapbiQkBQx2QapcK4Xaw=; b=JzaZsxg9CwsXU3zgI9kPbTTJ7/r42UJrU1EjpDutgYP7Kvb8ACn6HaT1/pe88XdWNMbj OKVAyKMCg0eZ7xC6wQ7mfnN1ENwquNardeZMLvoBPIooyCKzT1xb8HZ28NBUWSsfmHYQ ORGYcEmpWGuKdUySCD7e/ZRw0VrB9xH8d4KkPLWTTKf1vNP7TO/Uyml2QxthNLlqECme zNDhBmv7QMsjc2wxwLrmvsRrBvUyXhTeF3p1gxHMRYFiMaNVPkqNYo1OmZO1bYqmPL6e S/HhtYAPAeEeDsCwYh4ft8Tvv+duSsL5AI4kPmKhyYlEEPeJOPIt281FMVUqfZYKbYdz Zw== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2103.outbound.protection.outlook.com [104.47.58.103]) by mx0a-00273201.pphosted.com with ESMTP id 331crj40nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Aug 2020 20:13:31 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NEa1NR9sibuJ7qLl2OoR3fsq193XTiZmiKqFrjbMyVJae01NG2n0wq6hePfh3xJDt1J/vXzwBTTbL5P6l92dBrBq0car5cmk8cN8u4AZpzprUEaZhkkeAzZLwlJJChWd8twlUWG171oAtfWu0S2yaAWoGSEzJvXr4Mq7vT8bfFfSa8D1SvvuICcYYN0wkGkLrnX0vZuifZpr+Sg++VpZqTgaT6+oBjDBSMqGlI4ouE+lFcsNnKwGaU+05Ol7QZIMfImj9Rf+K2guXHdRkcUBTdsg5xCuMgmoDDzfd8D70OlW046hi3DDrnfr5xt2EQTBVY3DvTmljsRBtoiIaOQekA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TqiT2tW0eDuyRbFjooR+mqQGapbiQkBQx2QapcK4Xaw=; b=f796+gXoIIytzHNKLfAXXNiMVoG1smwtuLqNWb8P20NeLqfg8KEO+5gQb9V7wU1U/5aqwaOid4sU5aq+TRaFqskh5Y98+iyw9bj/7MdgeEiRZh3KPuaqbySz+LKM/fVukMoydwG0p3p+lxvqkFHd3G1iG/BxtXnKIBj/8NiUoWMHwPaFjOqf6fCOzr3vIrswImhQ61eGhaFvyRDUGHzRzHtYlaGE2cX0Fj/reJ3sIud3bue8O8BCXzqrSoIk0geNRzQOaITCnikw/bWpC1fQ5u5B0EluAiwL8C3dewe3oC5/PZr59ZMM711ld8XSXLkPr+iMRf7nR72qRPBvqibXyg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TqiT2tW0eDuyRbFjooR+mqQGapbiQkBQx2QapcK4Xaw=; b=KLkh1mLr7zXopuwvjBw7c7PnIMlusY9JPI0r+wGf2QVflc130+rfFfn/Fz4iDc7FT1UWcnSCEdzh/inJS/Qvc26XzhzkxvJdNsUndE6ldXrvnTWLylCxxtXuqx/F0SFla/PBA7du/zkwf9t79lkZg7GXvSqpm5Ldty5shWUXLL4= Received: from MN2PR05MB6080.namprd05.prod.outlook.com (2603:10b6:208:c4::21) by MN2PR05MB6030.namprd05.prod.outlook.com (2603:10b6:208:c6::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Sat, 22 Aug 2020 03:13:29 +0000 Received: from MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::409:6521:1e51:f8f5]) by MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::409:6521:1e51:f8f5%4]) with mapi id 15.20.3326.015; Sat, 22 Aug 2020 03:13:29 +0000 From: Rajesh M To: "gdawra.ietf@gmail.com" , "cfilsfil@cisco.com" , "robert@raszuk.net" , "bruno.decraene@orange.com" , "zhuangshunwan@huawei.com" , "jorge.rabadan@nokia.com" CC: "spring@ietf.org" Thread-Topic: https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 Thread-Index: AdZ4MNW2XqUqDnZ6QwCVe2fsN6tJPw== Date: Sat, 22 Aug 2020 03:13:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-22T03:13:26Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=558e4b75-cfc5-4de3-87d0-5beb9c66ec74; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [106.201.60.119] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 94ec8d5d-8dbe-491d-e85e-08d84649580a x-ms-traffictypediagnostic: MN2PR05MB6030: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sRXkfDQ6wfbtLws5JT7Y+bMknI9a1slwWsX01Nu0Vf147rWvrfFhOJMuwJ9fPIsV0UhfPD8S/oTFg4I67M6HYlr4vE+fBDmgwXQNbpjAhVpv0ORb9JU5PNPYVxkMizYRjNfbuZjMgkjLlF+ivMVF48L4ESRxOGRYVJQs7M+TUSWYfJajYSqjLOI7++bZKGtmSRxVTDLSkDeE4ooK/IlhBI22Wzc9Xf2JizsS0McHq8sD9KdZGgiyr1ivdd4xtYSjD5bHXwkTatmlekmK31gh3dLhYELSajLUN8CHML4zcdcBMs6dt0dm1G1FqA1yLx8zuDW1+PyOKeTRDVWq7yb7pbr4pIqRzZQo8FfJW8gQ6fYENNhhcAsWgUOs+um58htS1iWT9E74d3aY9/LwSQ4ikQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6080.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(366004)(55016002)(4744005)(26005)(316002)(186003)(8936002)(33656002)(478600001)(4326008)(8676002)(66946007)(86362001)(55236004)(66556008)(66476007)(66446008)(7696005)(6506007)(110136005)(64756008)(2906002)(9686003)(5660300002)(71200400001)(52536014)(76116006)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ADlpqmOWwe6pZ1O0wZu+3JliD50KZbrMBBeXOrgTZxlLH+Yhzt6b8AsZBPPcnbY+cP/UPO04sjiLqVTlE9ZfNQ5/RLMMCkuvq25Y0vK6p8zYYuI1DK4OgfwEiF23NPlZsbchOpqfo79pB7JCwgT77OCEByKVznVhwILZuYFtIitGLPKiMctIAJ6SCa69JGKZoQPTIGKiEXCEOGJ2vAYTU29M0Qnja1+3u/Jgy6IywLEIU7nTx5xxwN5hbR/v2Nxwh6rKT9/qvFWx6AW8aWAIMJmPSXlBcLgwdihIDsR90/BjVnwG989d+FYaomZ/xvgYgPR+mgAfZbwZNw3mXpiUZMMTPeCPHbokuZIEjWWyw5yYh4n7+q42g+A/me47vk7/OeB92xh1T5Jaikxt9uZIo/k6E0Yk0egxXtG3IxnuWgp13fnywbUsaOMC/+Qg8RY8XT/2GjsQZ2BQ9XfKEsERstr4nNjpliT0QhAgfqeckNBLlK3NKAwB5TD1iTlWuKqEhQwlT7bYs8oujiCi5th8U+wY3RIy9Y/5yUuo8wyRFaCxj7Y2kE7e9zptn7zvQXkZKveMWOmFvg+LyZKdNZSwFFcmlzydsWqpxnhKdvIBGXp67YyehlMi4zqKtzokClUIOjjBPOdxEth6SiB9gGhwYg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR05MB6080231E8EB0DFA1F18AC2D1BE580MN2PR05MB6080namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6080.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 94ec8d5d-8dbe-491d-e85e-08d84649580a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2020 03:13:29.4842 (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-CrossTenant-userprincipalname: Ezr3369Wxw+k+sHl9Lkny43rRmWPYM56YcePpDhL4DGzDdHdcbrkmJDjjyYWiCvGP86Ys4TAQiIdC5qt0KEagA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6030 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-22_01:2020-08-21, 2020-08-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 impostorscore=0 phishscore=0 mlxlogscore=749 mlxscore=0 malwarescore=0 adultscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008220029 Archived-At: Subject: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 03:13:42 -0000 --_000_MN2PR05MB6080231E8EB0DFA1F18AC2D1BE580MN2PR05MB6080namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 5. = BGP based L3 service over SRv6 When the egress PE sets the next-hop to a value that is not covered by the = SRv6 Locator from which the SRv6 Service SID is allocated, then the ingress PE SHOULD perform reachability check for the SRv6 Service = SID in addition to the BGP next-hop reachability procedures. I think we should mention, few points for egress side a) Recommended to set the bgp nexthop based upon locator. b) All the service SIDs across vrfs(DT4,DT6...) must be derived from the sa= me locator (this is independent of setting bgp nexthop) Juniper Business Use Only --_000_MN2PR05MB6080231E8EB0DFA1F18AC2D1BE580MN2PR05MB6080namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    5.  BGP based L3 service over SRv6

    When the egress PE sets the next-hop to a value that= is not covered by the SRv6 Locator from which the SRv6 Service SID is allo= cated,

    then the ingress PE SHOULD perform reachability chec= k for the SRv6 Service SID in addition to the BGP next-hop reachability pro= cedures.

     

     

    I think we should mention, few points for egress side=

    a) Recommended to set the bgp nexthop based upon locator.<= o:p>

    b) All the service SIDs across vrfs(DT4,DT6...) must be de= rived from the same locator (this is independent of setting bgp nexthop)


    Juniper Business= Use Only

    --_000_MN2PR05MB6080231E8EB0DFA1F18AC2D1BE580MN2PR05MB6080namp_-- From nobody Sun Aug 23 19:08:29 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49323A0945; Sun, 23 Aug 2020 19:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 pWSD7MPxsp7b; Sun, 23 Aug 2020 19:08:16 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690090.outbound.protection.outlook.com [40.107.69.90]) (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 892C03A093C; Sun, 23 Aug 2020 19:08:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gjNk2/61S7S3I8bagZs8jRFlGEKUEbGU4CTnszzyaQxdc7Qwdo1onKcxnwgWxuzwxdnAVsUimO5/vDF7vC35yQWnfYDcDvc4EDMtmG4zyJA0LpK1NK3rvHBXmr3N8jUdQB5oTU/K0inu8etIpSfrG0+NMcoDoG0oWz4nsgwZck93GZ9MokCmPL+UEK0VsoOVLDg6BPkWyYOFim1xc/sx/pI8TNRQRLzCSDEzBH24K+30FU21ybSx3fZ0eDvsC9N/GpEfdW478H+qOoB+0tRfbYUusWQa0NVYtu0ibGg/lUkBtzCjpmnpJLsnEvjTDgFiXsGp1rzn5tkvm0zE4LzmDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mGjvNXYkBk+WevUUNhJ9vE57NDmSCoezAbYOKJlr7zg=; b=nQPbRmWaSlKDqcWP+otp38Swyw2n06cWU4o64BNgFxr3GeIbSv73X9bxCwSBSdD/OHy6AT7Q7+3lwtfHeDCnWpgbmVJkcyQKCWYBfIjrfFdvRSKz4gJFEbye+mmNwZE1FVTo0Ijm3FMA1BM34SMDrJcddCeb03ZLxt1obx1ra+APx/JZzZvvBi7O6Z0uKHeCeTnsw9yMizVJAiBPlG3JTi+0ksATw5Sj0cu6vfPfaLXSMQ7WgXG99dMtOwDKFeOIRFX13taExT5DnE9qToRf5KSZ1JK1RyxU7VO1xE3I42rJlzA0IK+2n4T/dn5b+K2xwOuru2VozTxa9QMSAwbzFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mGjvNXYkBk+WevUUNhJ9vE57NDmSCoezAbYOKJlr7zg=; b=R5GaVaAjQ84VBkwtBhz4GM3XQa6t07dtetdndeeBhzOXxC56flEW8x3rCZJUNqbxd7EsiobF5+WNBMeomVyoVzC8S60FrqpIfYjcoj2getxUAEG4AFUozby3MNJ9mmQ2TgF3QTPB/b7t8YCxOMTpYhqlW66ZqYEO4q5Pq+fEzJs= Received: from BYAPR08MB5493.namprd08.prod.outlook.com (2603:10b6:a03:cc::31) by BYAPR08MB5783.namprd08.prod.outlook.com (2603:10b6:a03:11a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Mon, 24 Aug 2020 02:08:11 +0000 Received: from BYAPR08MB5493.namprd08.prod.outlook.com ([fe80::856f:d650:2695:2a4e]) by BYAPR08MB5493.namprd08.prod.outlook.com ([fe80::856f:d650:2695:2a4e%6]) with mapi id 15.20.3305.024; Mon, 24 Aug 2020 02:08:11 +0000 From: "Fomin, Sergey (Nokia - US/Mountain View)" To: "Ketan Talaulikar (ketant)" , "Thomas.Graf@swisscom.com" CC: "lsr@ietf.org" , "spring@ietf.org" , "opsawg@ietf.org" Thread-Topic: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thread-Index: AdZktQw6qX35tZ6KQpiaZtLipXAiTwAxTF+AAHUFTIACvTCesAAduZCAAAG4RsAAAinugABlpowAAD/GjoAAAsKqkAEUSZTg Date: Mon, 24 Aug 2020 02:08:11 +0000 Message-ID: References: <1307140725.3423419.1595923900561@ss002890> <44EA00AA-E9D9-4173-9F34-219752DACA5D@gredler.at> <1419364510.2875.1596208917648@ss002890> <2022615026.3001869.1597464620979@ss002889> <696872714.3003081.1597471334092@ss002889> <731376225.102325.1597755492826@ss007564> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [73.252.153.127] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a5acb3f1-5d11-446b-4de8-08d847d28d78 x-ms-traffictypediagnostic: BYAPR08MB5783: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DvrW+WRS3vjNoBB9SDvT2dldySXhc+kAp2qOx0nbQnOYkong7hT03nnFlu7SW5yqK5ZdfJFtqsdaOKdlExIOUOls63QSqyBQEUj7zJSSNUBM6U0sTRGrx1f9vskmhl5B4rSH/q/GPsAGruo37L9I5cxg+k86WQkiV419ko2s3RifekhblBYmIz3XGDy4CdqFAyCGsaNHGj8BlOWKayGX9O6U/3bLyh7nXZ0iLjq67MVXMwtUA1hoLEjgypEGeJ51jMm+ZUECH7FU0noRaReq0aK9USKGL6Cz0eDqX2Hk3stdUnW1jVrazF0EGfLTRvQCdTzi5hWf+CFotLzxNNdvX+N0i5i5FS7EBW8U3wwGkR169U/iokIVzU+NazXM9M1p0x0fwNmYkh603MSocqDTSg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR08MB5493.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(366004)(396003)(136003)(376002)(346002)(316002)(110136005)(966005)(5660300002)(76116006)(86362001)(52536014)(19627235002)(55016002)(9686003)(7696005)(71200400001)(54906003)(8936002)(66446008)(4326008)(66946007)(8676002)(30864003)(186003)(66476007)(33656002)(26005)(478600001)(2906002)(66574015)(166002)(6506007)(64756008)(53546011)(66556008)(83380400001)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: sPQDblUl98a06GtfQ/7X2eKEvwxmhXF4cKazGKOnWK6uBxyAAm7mALavrFliF5jCQH73Ff7DqrcWiQD8OUzd2eZLcuhg93Qo6+KRrt2Q6T8CeIm0vB4cY6hpUcRi94oQDeS4J7nneWYN8cXnF9LWDKjnOcCDYs5BgDIWzBp0ttTea2CO7FHHzgWsChA3uRLzN/E+tJFUECGl00ehfNLUt0XU3niL6GsOhuRYwFcAuetwBuEAjF6+j0yqdf6U8L4AQDV4EH2WPR/AhFoKoL5cMpzDCPynqso9BLUOdFYw+xuIn419/gQz+SNzF8OB99CQxpveMwG6G0WGHqzcnYlwc9Gok9kQ511Ehlzhj1j6vwvChacKdL2ylss8MyviC/TICtgHcCcXQCeQ70bCKRS6jlv4SCWVN52wbpSGv8a8K4TA0AhFlaHh7r46VsEqTb/j2ohjOMgg0JZBxDu9t5Pw2cGVOR4XQyrzw50j/Y95/0nijdw4pLGDjZVxsopc5E+ubAWjVAVnjLrsOXVWhSnms8v8HBV9+5QbfuR6k6nsozUzEmmJp9czHS0V9MPlwexH6WdmqicxxD4KXyemdy8FjNm9gjp6zuWyJS6OWd6pyb9pDXTAnHOJ5WddLvNjjQj/dCKNoFYpq78vzjdJydd6Iw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR08MB54935D8454329096A4567E2D85560BYAPR08MB5493namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR08MB5493.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5acb3f1-5d11-446b-4de8-08d847d28d78 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2020 02:08:11.3991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ag6fmGzFy+byMwdGP+/SPDUVZq1arXX6SFujc6JAZBuNW/YHFovu2X2YozwgRpVv5fzPJwPiD3zR0KpigAJicw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB5783 Archived-At: Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 02:08:20 -0000 --_000_BYAPR08MB54935D8454329096A4567E2D85560BYAPR08MB5493namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, Ketan, all, While I tend to agree with Ketan that, in principle, specific control plane= protocol name might not be the most useful bit of info, I would argue that= it still makes more sense to keep IE46 in this format instead of replacing= it with srsidtype. I.e. treat IE46 as in 'control plane protocol that is t= he source/owner of a particular label in LIB/LFIB'. Maybe we should conside= r adding a generic type 'Segment Routing' w/o extra details if this might b= ecome an implementation challenge? I'm in favor of keeping SrSidType as a separate entity -> this seems to be = significantly more complex to implement and arguably IPFIX may not be the b= est way to collect this info. -- Sergey From: spring On Behalf Of Ketan Talaulikar (ketan= t) Sent: Tuesday, August 18, 2020 7:23 AM To: Thomas.Graf@swisscom.com; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, Thanks for your response. Let us also wait for inputs from others in the WG= s. One small bit. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? Thomas> "admin distance" is one reason why one path is considered over anot= her from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an = examples, it is "sr-prefer" configuration option. KT2> The proposal to extend IE46 will cover the "sr-prefer" scenario and in= dicate whether the forwarding is happening with SR or LDP label. IMHO OSPF = SR vs ISIS SR is perhaps not as useful? Also, from an operational perspective (looking holistically), we have LSP p= ing/trace tools specified for MPLS (including SR segments/labels) to verify= /validate consistency between forwarding and control plane to determine whi= ch protocol/label is being used and lot's more details. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 18 August 2020 18:28 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the feedback. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR= Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment ty= pes from RFC8402)? It's a simpler change to an existing element/field that = makes it easier for routers, collectors and analysers? Thomas> I am open to this approach to change IE46 to include segment types = for RFC8402. I understand your concern to add additional fields. I would ap= preciate feedback from the wg if that is the path we like to go. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? Thomas> "admin distance" is one reason why one path is considered over anot= her from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an = examples, it is "sr-prefer" configuration option. [KT] From the document, I believe we are still talking only about the top o= f the stack label ... Thomas> Correct [KT] My point is why do we need to introduce another ElementID and why not = use the existing Type 46 as suggested above? Thomas> See feedback above. [KT] To be clear, I am not talking from the POV of a specific implementatio= n. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nu= ances into IPFIX since they require all that additional context/information= to be made available at the "layer" (or component) from where IPFIX picks = this info (traditionally from the "FIB"). This added information should hav= e a strong enough justification of benefit - e.g. How does difference betwe= en Adj SID and LAN Adj SID matter? How relevant it is to determine if the = SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount= and sufficient information that is necessary for flow analysis. We need to= note that there may be many more/other sources for "off-box enrichment" of= flow information collected and perhaps not everything needs to be determin= ed and reported by routers. Thomas> Absolutely. I fully agree on your feedback. We need to have the min= imum possible in order to have a clear view about the MPL-SR forwarding. Si= nce IPFIX using UDP for transport, without the possibility of fragmentation= , we need to be careful as well not to add many more dimension's/fields. Best Wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Monday, August 17, 2020 8:51 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, Please check inline below. From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 11:31 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, * This helps identification of specific SR-MPLS segment types as well a= s differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from = LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR= Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment ty= pes from RFC8402)? It's a simpler change to an existing element/field that = makes it easier for routers, collectors and analysers? * What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? It is important to distinguish between intend and result. [KT] By giving different types for OSPF and ISIS, is the intention to troub= leshoot routing preference selection (done based on "admin distance" betwee= n protocol selection in RIB)? If you migrate from one label distribution protocol to another, a network o= perator want's to understand if the data plane is still forwarding packets = with the label distribution protocol which needs to be removed or not. IE46= enables that by looking at the result of the forwarded traffic and not at = the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section= -3, describes the context. [KT] Sure, so adding the SR Segments to IE46, one can check whether the tra= ffic forwarding is happening using LDP or SR labels at any link in the netw= ork.. * What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing para= digm". Means that not the routing protocol does all the forwarding decision= s, the node can change the forwarding by pushing additional labels.. [KT] From the document, I believe we are still talking only about the top o= f the stack label ... With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling= to analyze the result of this decision. The example with " Adjacency SID o= r a LAN Adjacency SID" is not very useful because the difference of the two= is the topology among the adjacency. If you compare " Adjacency SID with P= refix SID", that makes much more sense. Since it describes that a particula= r adjacency is chosen to forward the packet instead of a prefix. If IE 89, = ForwardingStatus is drop, we understand that result of that decision lead t= o the drop and this enables to narrow down forwarding issues in segment rou= ting networks more efficiently and quickly. [KT] My point is why do we need to introduce another ElementID and why not = use the existing Type 46 as suggested above? * am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed w= hat you mean with implementation complexities. I would like to have a bette= r understanding where your fear is coming from. I would appreciate if you c= ould differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= . [KT] To be clear, I am not talking from the POV of a specific implementatio= n. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nu= ances into IPFIX since they require all that additional context/information= to be made available at the "layer" (or component) from where IPFIX picks = this info (traditionally from the "FIB"). This added information should hav= e a strong enough justification of benefit - e.g. How does difference betwe= en Adj SID and LAN Adj SID matter? How relevant it is to determine if the = SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount= and sufficient information that is necessary for flow analysis. We need to= note that there may be many more/other sources for "off-box enrichment" of= flow information collected and perhaps not everything needs to be determin= ed and reported by routers. Thanks, Ketan Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label typ= e identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as diff= erentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was be= ing signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID o= r a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads w= ith the proposed details of SR-MPLS segments in IPFIX against the benefit (= if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: Thomas.Graf@swisscom.com > Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) >; = hannes@gredler.at Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Ketan, Thank you very much for the review and feedback. * What or how much value be there on determining whether a SR Prefix SI= D was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters = and is more important is that it is a Prefix SID. Hardly any deployments wo= uld be running multiple protocols and learning the same prefix from differe= nt IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in = networks when migrations are ongoing. Usually in a life cycle. Migrating fr= om LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom = when we first discovered this shortcoming in vendor implementations. The ke= y point here, with these additional IPFIX MPLS Label Type identifiers we en= able the possibility to verify the label protocol migration without taking = the label value into the consideration. * IPFIX may be picking this information from a FIB in some implementati= on where the protocol does not matter and this information is not available= therein. I am not sure if you have seen the presentation in IETF 108 at OPSAWG and S= PRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpl= s-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label T= ype identifier. There is an open ddts where vendor feasibility has been cla= rified. Ping me off the list when you like to have more details. I do understand your point that not all the vendors are capable to implemen= t IE 46. But that's not the point about the IPFIX IE registry. The IE regis= try enables that an IPFIX implementation can refer to the right code point.= With RFC 5102 the decision has been made that MPLS Label Type identifier m= ake sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just= extends the IE 46 registry with the Segment Routing label protocol code po= ints so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the= IPFIX implementation can point to the right code point. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP= - what would we use/show? In this case the IE 46 shows the label protocol which was used to program t= he FIB. * For that table proposal, it is very difficult and in some cases not p= ossible to different between Prefix and Node and Anycast SID. Many of these= types are control plane elements and we can be sure more get added. I fully agree. As a network operator its still hard to understand the archi= tecture and constraints within a router. When monitoring capabilities are d= iscussed at IETF, this is the usual topic. What is possible, what make sens= e. By purpose, all available SID types are listed in the draft. This with t= he aim to start the discussion in the working groups what is possible what = makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit = of visibility in the FIB by showing where Adj-SID was used. This should be = a simple example why it make sense not only to look at which label protocol= was used to forward a particular packet, but also which SID type to furthe= r understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF >; hannes@gredler.at Cc: lsr@ietf.org; SPRING WG > Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < also copying Spring WG for their review/inputs > Hi Thomas/All, I have reviewed the draft and would like to share a different perspective. What or how much value be there on determining whether a SR Prefix SID was = signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is= more important is that it is a Prefix SID. Hardly any deployments would be= running multiple protocols and learning the same prefix from different IGP= s. IPFIX may be picking this information from a FIB in some implementation = where the protocol does not matter and this information is not available th= erein. On some nodes, the same Prefix SID may be learnt via both BGP and IGP - wha= t would we use/show? I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR= BGP Peering SID and so on ... for the MPLS Label Type. This also takes away the need for the second table that is being proposed t= o a large extent. For that table proposal, it is very difficult and in some= cases not possible to different between Prefix and Node and Anycast SID. M= any of these types are control plane elements and we can be sure more get a= dded. Is there really much value in differentiation between say an Adjacenc= y SID and LAN Adjacency SID? Could we evaluate the implementation overhead and complexity of this level = of categorization/information in IPFIX against their value in flow analysis= to perhaps consider a middle ground? Thanks, Ketan From: Lsr > On Behalf Of = Thomas.Graf@swisscom.com Sent: 31 July 2020 20:52 To: hannes@gredler.at Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Hannes, Thanks a lot for the feedback. Yes, makes completely sense. Will take it fo= r the next update... Best Wishes Thomas From: Hannes Gredler > Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF > Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Thomas, I have one comment/suggestion to Paragraph 4 (IANA Considerations). Please add also a code point for BGP Prefix-SID - it's quite popular in DC = deployments. https://tools.ietf.org/html/rfc8669 thanks, /hannes On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote: Dear lsr, I presented the following draft Export of MPLS Segment Routing Label Type Information in IP Flow Informatio= n Export (IPFIX) https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 at the spring working group at IETF 108 yesterday https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-infor= mation-export-ipfix-00.pdf and today at OPSAWG where I call for adoption. This draft adds additional segment routing code points for in the IANA IPFI= X registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to g= ain further insights into the MPLS-SR forwarding-plane. I have been asked to not only gather feedback from spring and opsawg but al= so from lsr and mpls working groups since these code points are related to = link state routing protocols and mpls data plane. I am looking forward to your feedback and input. Best Wishes Thomas Graf _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_BYAPR08MB54935D8454329096A4567E2D85560BYAPR08MB5493namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Thomas, Ketan, all,

     

    While I tend to agree with Ketan that, in principle,= specific control plane protocol name might not be the most useful bit of i= nfo, I would argue that it still makes more sense to keep IE46 in this form= at instead of replacing it with srsidtype. I.e. treat IE46 as in ‘control plane protocol that is the source/own= er of a particular label in LIB/LFIB’. Maybe we should consider addin= g a generic type 'Segment Routing' w/o extra details if this might become a= n implementation challenge?

     

    I'm in favor of keeping SrSidType as a separate enti= ty -> this seems to be significantly more complex to implement and argua= bly IPFIX may not be the best way to collect this info.

     

    --=

    Sergey

    From: spring <spring-bounces@ietf.org> = On Behalf Of Ketan Talaulikar (ketant)
    Sent: Tuesday, August 18, 2020 7:23 AM
    To: Thomas.Graf@swisscom.com; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org
    Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas,

     

    Thanks for your response. Let u= s also wait for inputs from others in the WGs.

     

    One small bit.

     

    [KT] By giving different types for OSPF and IS= IS, is the intention to troubleshoot routing preference selection (done bas= ed on “admin distance” between protocol selection in RIB)?<= /b>

    Thomas> "admin distance&= quot; is one reason why one path is considered over another from two differ= ent protocols. In case of LDP vs IS-IS, in IOS-XR as an examples, it is "sr-prefer" configuration option.

    KT2> The proposal to extend = IE46 will cover the “sr-prefer” scenario and indicate whether t= he forwarding is happening with SR or LDP label. IMHO OSPF SR vs ISIS SR is= perhaps not as useful?

     

    Also, from an operational persp= ective (looking holistically), we have LSP ping/trace tools specified for M= PLS (including SR segments/labels) to verify/validate consistency between f= orwarding and control plane to determine which protocol/label is being used and lot’s more details.

     

    Thanks,

    Ketan

     

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 18 August 2020 18:28
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    Thank you very much for the feed= back.

     

    [KT] Why not extend the e= xisting IPFIX MPLS Label Type (value 46) to add SR Prefix SID, SR Adjacency= SID, SR Binding SID … (basically the segment types from RFC8402)? It= ’s a simpler change to an existing element/field that makes it easier for routers, collectors and analysers?=

    Thomas> I am o= pen to this approach to change IE46 to include segment types for RFC8402. I= understand your concern to add additional fields. I would appreciate feedback from the wg if that is the path we like to go.=

     =

    [KT] By giving different types for OSPF and IS= IS, is the intention to troubleshoot routing preference selection (done bas= ed on “admin distance” between protocol selection in RIB)?<= /b>

    Thomas> "admin distance&= quot; is one reason why one path is considered over another from two differ= ent protocols. In case of LDP vs IS-IS, in IOS-XR as an examples, it is "sr-prefer" configuration option.

     

    [KT] From the document, I believe we are still= talking only about the top of the stack label …=

    Thomas> Correct

     

    [KT] My point is why do we need to introduce a= nother ElementID and why not use the existing Type 46 as suggested above?

    Thomas> See feedback above.

     

     

    [KT] To be clear, I am not talking from the PO= V of a specific implementation. Let me summarize my feedback and perspectiv= e:

    • Carefully consider the addition of more control plane elements = and nuances into IPFIX since they require all that additional context/infor= mation to be made available at the “layer” (or component) from where IPFIX picks this info (traditionally from the &#= 8220;FIB”). This added information should have a strong enough justif= ication of benefit – e.g. How does difference between Adj SID and LAN= Adj SID matter?  How relevant it is to determine if the SR signaling protocol is OSPF or ISIS?
    • Try to add/extend existing elements/fields with just the right amoun= t and sufficient information that is necessary for flow analysis. We need t= o note that there may be many more/other sources for “off-box enrichment” of flow information collected= and perhaps not everything needs to be determined and reported by routers.=

     

    Thomas> Absolutely. I fully a= gree on your feedback. We need to have the minimum possible in order to hav= e a clear view about the MPL-SR forwarding. Since IPFIX using UDP for transport, without the possibility of fragmentation, w= e need to be careful as well not to add many more dimension's/fields.<= /o:p>

     

    Best Wishes

    Thomas

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Monday, August 17, 2020 8:51 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas,

     

    Please check inline below.=

     

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 11:31
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    • This helps identification of specific SR-MPLS se= gment types as well as differentiating them from LDP, RSVP-TE, etc.

     

    To be precise, the existing MPLS= Label Type identifier differentiates from LDP, RSVP-TE. Not the new SrSidT= ype IPFIX IE being proposed.

    [KT] Why not extend the e= xisting IPFIX MPLS Label Type (value 46) to add SR Prefix SID, SR Adjacency= SID, SR Binding SID … (basically the segment types from RFC8402)? It= ’s a simpler change to an existing element/field that makes it easier for routers, collectors and analysers?=

     

    • What value is provided for IPFIX analysis if the= SR Prefix SID was being signalled via OSPF or ISIS?

     

    It is important to distinguish b= etween intend and result.

    [KT] By giving different types for OSPF and IS= IS, is the intention to troubleshoot routing preference selection (done bas= ed on “admin distance” between protocol selection in RIB)?<= /b>

     

    If you migrate from one label di= stribution protocol to another, a network operator want's to understand if = the data plane is still forwarding packets with the label distribution protocol which needs to be removed or not. IE46 ena= bles that by looking at the result of the forwarded traffic and not at the = intend. RFC 8661 section 3, https:/= /tools.ietf.org/html/rfc8661#section-3, describes the context.

    [KT] Sure, so adding the = SR Segments to IE46, one can check whether the traffic forwarding is happen= ing using LDP or SR labels at any link in the network..

     =

    • What value is provided for IPFIX analysis if it = was a Adjacency SID or a LAN Adjacency SID?

     

    Quote from RFC8402. "Segmen= t Routing (SR) leverages the source routing paradigm". Means that not = the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels.. <= span style=3D"font-size:10.0pt;font-family:"Trebuchet MS",sans-se= rif">

    [KT] From the document, I believe we are still= talking only about the top of the stack label …=

     

    With IPFIX SrSidType we are able= to cover this dimension in IPFIX. Enabling to analyze the result of this d= ecision. The example with " Adjacency SID or a LAN Adjacency SID" is not very useful because the difference of the t= wo is the topology among the adjacency. If you compare " Adjacency SID= with Prefix SID", that makes much more sense. Since it describes that= a particular adjacency is chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we underst= and that result of that decision lead to the drop and this enables to narro= w down forwarding issues in segment routing networks more efficiently and q= uickly.

    [KT] My point is why do we need to introduce a= nother ElementID and why not use the existing Type 46 as suggested above?

     

    • am asking for WG to weigh t= he implementation complexities

     

    For the WG and me, I would be im= portant if you can describe more detailed what you mean with implementation complexities. I would like to ha= ve a better understanding where your fear is coming from. I would appreciat= e if you could differentiate between MPLS Label Type identifier, IE46, from which lab= el protocol the label was coming from and SrSidType which SID type was used= .

    [KT] To be clear, I am not talking from the PO= V of a specific implementation. Let me summarize my feedback and perspectiv= e:

    • Carefully consider the addition of more control plane elements = and nuances into IPFIX since they require all that additional context/infor= mation to be made available at the “layer” (or component) from where IPFIX picks this info (traditionally from the &#= 8220;FIB”). This added information should have a strong enough justif= ication of benefit – e.g. How does difference between Adj SID and LAN= Adj SID matter?  How relevant it is to determine if the SR signaling protocol is OSPF or ISIS?
    • Try to add/extend existing elements/fields with just the right amoun= t and sufficient information that is necessary for flow analysis. We need t= o note that there may be many more/other sources for “off-box enrichment” of flow information collected= and perhaps not everything needs to be determined and reported by routers.=

     

    Thanks,

    Ketan

     

    Best wishes

    Thomas

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Saturday, August 15, 2020 7:09 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas,

     

    I should have been more clear i= n my email.

     

    The proposal/suggestion is to a= dd the following to the IPFIX MPLS Label type identifier registry:

    • SR Prefix SID
    • SR Adjacency SID
    • SR Binding SID
    • SR BG= P Peering SID
    • … and = so on

     

    This helps identification of sp= ecific SR-MPLS segment types as well as differentiating them from LDP, RSVP= -TE, etc.

     

    And my questions were:

    1. What value is provided for IPFIX analysis if the= SR Prefix SID was being signalled via OSPF or ISIS?
    2. What value is provided fo= r IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID?

     

    I am asking for WG to weigh the= implementation complexities and overheads with the proposed details of SR-= MPLS segments in IPFIX against the benefit (if any) that they provide for t= he flow analysis and monitoring.

     

    Thanks,

    Ketan

     

    From: Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
    Sent: 15 August 2020 09:40
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; hannes@gredler.at
    Cc: lsr@ietf.org; spring@ietf.org; opsawg@ietf.org=
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Ketan,

     =

    Thank you very much for the revi= ew and feedback.

     

    • What or how much value be there on determining w= hether a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3= /ISIS – what matters and is more important is that it is a Prefix SID. Hardly any deployments would be running multip= le protocols and learning the same prefix from different IGPs.

     

    As Jeff already p= ointed out. Multiple IGP labelling protocols are used  in networks whe= n migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swissc= om when we first discovered this shortcoming in vendor implementations. The= key point here, with these additional IPFIX MPLS Label Type identifiers we= enable the possibility to verify the label protocol migration without taking the label value into the consi= deration.

     

    • IPFIX may be picking this information from a FIB= in some implementation where the protocol does not matter and this informa= tion is not available therein.

     

    I am not sure if = you have seen the presentation in IETF 108 at OPSAWG and SPRING.=

    https://www.ietf.org/proceedings/108/slides/slides= -108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf

     

    Slide 2 shows Cis= co as example vendor which implemented IE 46, MPLS Label Type identifier. T= here is an open ddts where vendor feasibility has been clarified. Ping me off the list when you like to have more details.

     =

    I do understand your point that = not all the vendors are capable to implement IE 46. But that’s not th= e point about the IPFIX IE registry. The IE registry enables that an I= PFIX implementation can refer to the right code point. With RFC 5102 the de= cision has been made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type ju= st extends the IE 46 registry with the Segment Routing label protocol code = points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, t= he IPFIX implementation can point to the right code point.

     

    • On some nodes, the same Prefix SID may be learnt= via both BGP and IGP – what would we use/show?

     =

    In this case the = IE 46 shows the label protocol which was used to program the FIB.

     =

    • For that table proposal, it= is very difficult and in some cases not possible to different between Pref= ix and Node and Anycast SID. Many of these types are control plane elements= and we can be sure more get added.<= /span>

     

    I fully agree. As a network oper= ator its still hard to understand the architecture and constraints within a= router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what make sense. By pu= rpose, all available SID types are listed in the draft. This with the aim t= o start the discussion in the working groups what is possible what makes se= nse. I would be interested to get your and also Jeff's feedback.

     

    In above mentioned slides I desc= ribed how TI-LFA application would benefit of visibility in the FIB by show= ing where Adj-SID was used. This should be a simple example why it make sense not only to look at which label protocol was use= d to forward a particular packet, but also which SID type to further unders= tand the intend why this label is being pushed.

     

    I hope this makes all sense. Loo= king forward for reply.

     =

    Best wishes<= /o:p>

    Thomas=

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020 7:35 PM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>; hannes@gredler.at
    Cc: lsr@ietf.org; SPRING WG <= spring@ietf.org>
    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    < also copying Spring WG for= their review/inputs >

     

    Hi Thomas/All,

     

    I have reviewed the draft and w= ould like to share a different perspective.

     

    What or how much value be there= on determining whether a SR Prefix SID was signalled/programmed on a node = via OSPFv2/OSPFv3/ISIS – what matters and is more important is that i= t is a Prefix SID. Hardly any deployments would be running multiple protocols and learning the same prefix from diff= erent IGPs. IPFIX may be picking this information from a FIB in some implem= entation where the protocol does not matter and this information is not ava= ilable therein.

     

    On some nodes, the same Prefix = SID may be learnt via both BGP and IGP – what would we use/show?=

     

    I would recommend using SR Pref= ix SID, SR Adjacency SID, SR Binding SID, SR BGP Peering SID and so on R= 30; for the MPLS Label Type.

     

    This also takes away the need f= or the second table that is being proposed to a large extent. For that tabl= e proposal, it is very difficult and in some cases not possible to differen= t between Prefix and Node and Anycast SID. Many of these types are control plane elements and we can be sure mor= e get added. Is there really much value in differentiation between say an A= djacency SID and LAN Adjacency SID?

     

    Could we evaluate the implement= ation overhead and complexity of this level of categorization/information i= n IPFIX against their value in flow analysis to perhaps consider a middle g= round?

     

    Thanks,

    Ketan

     

    From: Lsr <lsr-bounces@ietf.org> On Behalf Of Thomas.Graf= @swisscom.com
    Sent: 31 July 2020 20:52
    To: hannes@gredler.at
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Hannes,

     =

    Thanks a lot for the feedback. Y= es, makes completely sense. Will take it for the next update...<= /span>

     

    Best Wishes

    Thomas

     

     =

    From: Hannes Gredler <hannes@gredler.at>
    Sent: Wednesday, July 29, 2020 9:31 AM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
    Cc: lsr@ietf.org
    Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Thomas,

     

    I have one comment/suggestion t= o Paragraph 4 (IANA Considerations).

     

    Please add also a code point fo= r BGP Prefix-SID - it’s quite popular in DC deployments.

     

    thanks,

     

    /hannes

    =  

    On 28.07.2020, at 10:11, Thomas.Graf@swisscom.com wrote:

     

    Dear lsr,

     

    I presented the following draft

     <= /span>

    Export of MPLS Segment Routing Label Type Info= rmation in IP Flow Information Export (IPFIX)

     

    at the spring working group at IETF 108 yester= day

     <= /span>

    and today at OPSAWG where I call for adoption.=

     <= /span>

    This draft adds additional segment routing cod= e points for in the IANA IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and s= egment routing SID types to gain further insights into the MPLS-SR forwarding-plane.<= /span>

     <= /span>

    I have been asked to not only gather feedback = from spring and opsawg but also from lsr and mpls working groups since thes= e code points are related to link state routing protocols and mpls data plane.

     <= /span>

    I am looking forward to your feedback and inpu= t.

     <= /span>

    Best Wishes

    Thomas Graf

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

     

    --_000_BYAPR08MB54935D8454329096A4567E2D85560BYAPR08MB5493namp_-- From nobody Mon Aug 24 05:51:42 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 722DF3A0D88; Mon, 24 Aug 2020 05:51:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ladislav Lhotka via Datatracker To: Cc: spring@ietf.org, draft-ietf-spring-sr-yang.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159827349041.30993.687894019314723215@ietfa.amsl.com> Reply-To: Ladislav Lhotka Date: Mon, 24 Aug 2020 05:51:30 -0700 Archived-At: Subject: [spring] Yangdoctors last call review of draft-ietf-spring-sr-yang-20 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 12:51:31 -0000 Reviewer: Ladislav Lhotka Review result: Ready with Nits I also did an early YANG Doctors review [1]. My comments regarding YANG module revisions and normative references are addressed in the current revision. The suggested naming changes were either accepted or, I assume, addressed in the WG and rejected (which is OK). Compared to the previously reviewed revision -09, the current revision contains one additional YANG module: ietf-segment-routing-mpls. This module adheres to the same high standards as the previous two, and I discovered no issues with all of them. [1] https://datatracker.ietf.org/doc/review-ietf-spring-sr-yang-09-yangdoctors-early-lhotka-2018-10-24/ Comments ------------ - The title of Section 6 (States) still looks weird to me. My suggestion is to use "State Data" instead. - The title of Section 8 should use plural "YANG Modules" because it contains three modules. It would also be helpful to introduce a subsection for each module. - Due to the RFC line length limit, the example in Appendix A uses a line break inside a URI of a XML namespace declaration, which makes the XML invalid. This can be probably avoided by including the XML namespace declaration for "sr-cmn" in the top-level element, i.e. If not, it would be better to use conventions of RFC 8792. - Assuming that the example is intended for human readers, it might be better to provide it in the JSON representation per RFC 7951. From nobody Tue Aug 25 13:11:14 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6946B3A0B70; Tue, 25 Aug 2020 13:11:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <159838627336.16980.13050103033926469641@ietfa.amsl.com> Date: Tue, 25 Aug 2020 13:11:13 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-21.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 20:11:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-21.txt Pages : 35 Date : 2020-08-25 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-21 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 25 13:16:23 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0203A0B70; Tue, 25 Aug 2020 13:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 mdbG0JafG7m4; Tue, 25 Aug 2020 13:16:19 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2117.outbound.protection.outlook.com [40.107.94.117]) (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 4237F3A0B81; Tue, 25 Aug 2020 13:16:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dOtKevZBrdydI4y+kikF4Q3fl1atdO0bC+z4nT0q/Q+bOX9v8RLKRzt4DV+WWIOZMWQNx6mlNzKLtlzrVNwT3AyYqi/VQAalmhkGOq6V3t9AVGJmDROL453FrUd2H/ck0Im7B/0t6IlY4gK14l3rtFehHenfr1MAqXP9r6IuoiNKOnGDihdeln4AKbbVxe6GtfQjjRG4RWnp8L1hJ3membeyRtiG5+baBF0kevKGwVJbbM7uEXbuUv3L+nqnLYgTDSTLlR1aIWAcewuh4cLu5iBk2SIQy6nkn1GBEq4/cPByPO5tip3Yo0t5LMHyaIhukv791uw7KItwJyzYp/I5HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HVA6vnM7BOOWftCoGdhPEQJohYXIE5ckg5o4VSFuww4=; b=SVzuavQgFWsM57TRX/pAZ+aQ4xmRdjGD0uh8Z3HYn1grOLotN0oKaKpQ3pi8+tAwcgGYtrx6dyAolcHB5SRTgtHDCLpDNfpkBi6BbqNi3ras6ZBm4a5Lre8zQ3FIZwhyPVqgn3Qp+tbM8ywNSvQcoWfVnsm9L24t0v3l6UL9J3FVSVl8sB8WL7XPSTocHELYx4velSBZO9V9uNG6f9VUD3lhufxBTDU0BLuGn/l3sJR+CKnOD/dDLHsGY5kUL93RJHoTwwnnJC/6+JmUWhVXzcn7jgxzjvjzwJ2HM19kaYUDniD8hRQmhHJ1UsHQEwOl1I0hcFghcgHPCdSZHlxqBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HVA6vnM7BOOWftCoGdhPEQJohYXIE5ckg5o4VSFuww4=; b=L73wLVSXq14bsIVkovh1kGU5ij+EuppudRF4gxTPDST/N3IaXZFfz30Gr8zs9ZeaLEv6Lsbz+8//QM1f++cDBH4zn16K/J1c8xd62B9oCxbY1GaKHkcK7fNPDOJ4yZ+aEZyaYv+En9kW/oTEWpeoKKw85LlpY2kl/qlK4+Q26Dg= Received: from BY5PR13MB3048.namprd13.prod.outlook.com (2603:10b6:a03:188::21) by BY5PR13MB3554.namprd13.prod.outlook.com (2603:10b6:a03:1ad::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Tue, 25 Aug 2020 20:16:12 +0000 Received: from BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034]) by BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034%5]) with mapi id 15.20.3326.018; Tue, 25 Aug 2020 20:16:12 +0000 From: Yingzhen Qu To: Ladislav Lhotka , "yang-doctors@ietf.org" CC: "spring@ietf.org" , "draft-ietf-spring-sr-yang.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-spring-sr-yang-20 Thread-Index: AQHWehVL6ibBl740LkCSVJAG2mn0IalIz6KA Date: Tue, 25 Aug 2020 20:16:12 +0000 Message-ID: References: <159827349041.30993.687894019314723215@ietfa.amsl.com> In-Reply-To: <159827349041.30993.687894019314723215@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:646:9500:c900:916a:535b:e402:d6a3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: daad27b8-0221-4772-4d16-08d84933b663 x-ms-traffictypediagnostic: BY5PR13MB3554: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b5r1ei3LWocicOMrR9zOCVE8P6KXPqkXNf4iDrakt4qLbvXHg/53qHShJ8kHCDTwWYKn3PNAcWWThax20k6/PwhgRQHXCwkmSOPnoYlqhYW4K1ejAD5lYPwoibmrhF83/8ucZIwvoF/tt0MRMDvVoO0ojNauzOBkQY7A+0L7k4GyEPeqsv6RrK8hZYhHndKYK3LfWX3dZVS0bw9/etBcyTbcsPdvQ/A3YxgcdYs5a15xbl7tHhgfUGdwPPemsT7T68vdATGCqpmzw2cMHKtB0LQqk4hJRW3MekRwBk9ATxL77nGYFnCBKskF4Hp8f9+orlncR6Z6nZNaiG+9hOO6z5cBsgNz2J4ZHpFaKnrpdAEdCni9nJ4b4jZIqal39fwgJaQIzur9/W88sjEyMJTDvQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3048.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39840400004)(396003)(366004)(346002)(136003)(86362001)(4326008)(33656002)(83380400001)(66446008)(66556008)(66946007)(66476007)(8676002)(76116006)(64756008)(186003)(2906002)(8936002)(71200400001)(2616005)(45080400002)(110136005)(6512007)(36756003)(54906003)(6486002)(478600001)(316002)(4001150100001)(44832011)(5660300002)(6506007)(966005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2RZcT2eHv9q/vNs6DpuUnV2QxaYBTrBtdcN3HiixAFGWbw8CXzsVa8ZOmq7jvLrxXXJZFNRV9mXgraZ+6s/gOElbsjXiMdGX0w5ShlEyWttWDRhM8ofkyLo4Ugm8ihhvSZZyAhDeJ4ciaByDkbWaGTpqQSMNlkrOCOQOvBDKlr9fxInFZBzYy9LxJ8drcSb/zEfvMDUg9FuO3VCbrQyLWdT7x2u2FaRC1mxtDG5FSR2ajFzT/RrsoilYip1zffJr0M6LFA6BvpFkIxOWjmgUbVfj+BN0XbHEg6M0fQ/oLTFrE4d3UzsT58L3lsow5W/vtTeA0gp8r+t6Uxqq0Uat7O7Y/Y35NUD5bzjVjg/9fMaDvjKtypL+JVqwbbdAlJA8QVSVPi9M07A72G83y4TK4pYyutfBBFIQSLjkEXpjwRBMxyiXcJO7+l7bPM6VLD2deBxae8LlPgc1HmnKnt7qDeqkIRM4JzhHXIGbvGv11GMkYsGJ28nX+BGmOF61XqE4EFgH+YJs3CHSA4ehUjrdenXPoiNnk0xUM4JV324rBkj/q1UkbaTa1jd3TD+FjKz3uBe7R2yuO891dkz4Mc2FRq2fmVY73KXR75aHQ0yDrYXSR6Fdef0JxvdvswWrorvX/rezESYvud4XhDFJTgM2dyTsXrUINj9eEsuL4rbwzPROafcft6ZdUxuPwj39mIhqVovEbmVOtCZMgswpuBITKQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <32BE278A88398242860E9FFFE79B3F19@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3048.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: daad27b8-0221-4772-4d16-08d84933b663 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2020 20:16:12.2977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rPw+Ce0zu786sgSDfF6ml3SsoUNM2D+YOOZv82AmbWXSAUpFX8+diJZLQrsNJbDUYia1boAfI+n6lF3wqvecXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3554 Archived-At: Subject: Re: [spring] Yangdoctors last call review of draft-ietf-spring-sr-yang-20 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 20:16:21 -0000 SGkgTGFkYSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldywgcmVhbGx5IGFwcHJlY2lhdGUu IA0KDQpJJ3ZlIHVwbG9hZGVkIHZlcnNpb24gLTIxIHRvIGFkZHJlc3MgeW91ciBjb21tZW50cyBh bmQgcGxlYXNlIHNlZSBkZXRhaWxlZCBhbnN3ZXJzIGJlbG93IGlubGluZSBzdGFydGluZyB3aXRo IFtZUV0uDQoNClRoYW5rcywNCllpbmd6aGVuDQoNCu+7v09uIDgvMjQvMjAsIDU6NTEgQU0sICJM YWRpc2xhdiBMaG90a2EgdmlhIERhdGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6 DQoNCiAgICBSZXZpZXdlcjogTGFkaXNsYXYgTGhvdGthDQogICAgUmV2aWV3IHJlc3VsdDogUmVh ZHkgd2l0aCBOaXRzDQoNCiAgICBJIGFsc28gZGlkIGFuIGVhcmx5IFlBTkcgRG9jdG9ycyByZXZp ZXcgWzFdLiBNeSBjb21tZW50cyByZWdhcmRpbmcgWUFORyBtb2R1bGUNCiAgICByZXZpc2lvbnMg YW5kIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGFyZSBhZGRyZXNzZWQgaW4gdGhlIGN1cnJlbnQgcmV2 aXNpb24uIFRoZQ0KICAgIHN1Z2dlc3RlZCBuYW1pbmcgY2hhbmdlcyB3ZXJlIGVpdGhlciBhY2Nl cHRlZCBvciwgSSBhc3N1bWUsIGFkZHJlc3NlZCBpbiB0aGUgV0cNCiAgICBhbmQgcmVqZWN0ZWQg KHdoaWNoIGlzIE9LKS4NCg0KICAgIENvbXBhcmVkIHRvIHRoZSBwcmV2aW91c2x5IHJldmlld2Vk IHJldmlzaW9uIC0wOSwgdGhlIGN1cnJlbnQgcmV2aXNpb24gY29udGFpbnMNCiAgICBvbmUgYWRk aXRpb25hbCBZQU5HIG1vZHVsZTogaWV0Zi1zZWdtZW50LXJvdXRpbmctbXBscy4gVGhpcyBtb2R1 bGUgYWRoZXJlcyB0bw0KICAgIHRoZSBzYW1lIGhpZ2ggc3RhbmRhcmRzIGFzIHRoZSBwcmV2aW91 cyB0d28sIGFuZCBJIGRpc2NvdmVyZWQgbm8gaXNzdWVzIHdpdGgNCiAgICBhbGwgb2YgdGhlbS4N Cg0KICAgIFsxXSBodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRnJldmlldy1p ZXRmLXNwcmluZy1zci15YW5nLTA5LXlhbmdkb2N0b3JzLWVhcmx5LWxob3RrYS0yMDE4LTEwLTI0 JTJGJmFtcDtkYXRhPTAyJTdDMDElN0N5aW5nemhlbi5xdSU0MGZ1dHVyZXdlaS5jb20lN0NiNjE3 MWRiNTc5ZmY0ZGYyYzAyZTA4ZDg0ODJjNmNkZSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1 OTFmZWRjJTdDMSU3QzAlN0M2MzczMzg3MDI5MjQ0MDQ3MjcmYW1wO3NkYXRhPSUyQkNWY044UlFR JTJCMmFEUCUyQkZIWTJHaUN1a1BFenBmMUdjSkF0UTBMRGJCaDQlM0QmYW1wO3Jlc2VydmVkPTAN Cg0KICAgICBDb21tZW50cw0KICAgIC0tLS0tLS0tLS0tLQ0KDQogICAgLSBUaGUgdGl0bGUgb2Yg U2VjdGlvbiA2IChTdGF0ZXMpIHN0aWxsIGxvb2tzIHdlaXJkIHRvIG1lLiBNeSBzdWdnZXN0aW9u IGlzIHRvDQogICAgdXNlICJTdGF0ZSBEYXRhIiBpbnN0ZWFkLg0KW1lRXTogbW9kaWZpZWQgYXMg eW91IHN1Z2dlc3RlZC4NCg0KICAgIC0gVGhlIHRpdGxlIG9mIFNlY3Rpb24gOCBzaG91bGQgdXNl IHBsdXJhbCAiWUFORyBNb2R1bGVzIiBiZWNhdXNlIGl0IGNvbnRhaW5zDQogICAgdGhyZWUgbW9k dWxlcy4gSXQgd291bGQgYWxzbyBiZSBoZWxwZnVsIHRvIGludHJvZHVjZSBhIHN1YnNlY3Rpb24g Zm9yIGVhY2gNCiAgICBtb2R1bGUuDQpbWVFdOiBjaGFuZ2VkIHRoZSB0aXRsZSBhbmQgYWRkZWQg YW4gaW50cm9kdWN0aW9uIG9mIGVhY2ggbW9kdWxlLg0KDQogICAgLSBEdWUgdG8gdGhlIFJGQyBs aW5lIGxlbmd0aCBsaW1pdCwgdGhlIGV4YW1wbGUgaW4gQXBwZW5kaXggQSB1c2VzIGEgbGluZSBi cmVhaw0KICAgIGluc2lkZSBhIFVSSSBvZiBhIFhNTCBuYW1lc3BhY2UgZGVjbGFyYXRpb24sIHdo aWNoIG1ha2VzIHRoZSBYTUwgaW52YWxpZC4gVGhpcw0KICAgIGNhbiBiZSBwcm9iYWJseSBhdm9p ZGVkIGJ5IGluY2x1ZGluZyB0aGUgWE1MIG5hbWVzcGFjZSBkZWNsYXJhdGlvbiBmb3IgInNyLWNt biINCiAgICBpbiB0aGUgdG9wLWxldmVsIGVsZW1lbnQsIGkuZS4NCg0KICAgICAgPHJvdXRpbmcN CiAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXJvdXRpbmci DQogICAgICAgIHhtbG5zOnNyLWNtbj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYt c2VnbWVudC1yb3V0aW5nLWNvbW1vbiI+DQoNCiAgICAgIElmIG5vdCwgaXQgd291bGQgYmUgYmV0 dGVyIHRvIHVzZSBjb252ZW50aW9ucyBvZiBSRkMgODc5Mi4NCg0KW1lRXTogSSB0cmllZCB0aGUg Zm9ybWF0IGFzIHlvdXIgc3VnZ2VzdGVkLCBidXQgc29tZWhvdyBJIGNvdWxkIGdldCBpdCBwYXNz IHlhbmdsaW50LCBzbyBhZGRlZCAiXCIgcGVyIFJGQyA4NzkyLg0KIA0KICAgIC0gQXNzdW1pbmcg dGhhdCB0aGUgZXhhbXBsZSBpcyBpbnRlbmRlZCBmb3IgaHVtYW4gcmVhZGVycywgaXQgbWlnaHQg YmUgYmV0dGVyDQogICAgdG8gcHJvdmlkZSBpdCBpbiB0aGUgSlNPTiByZXByZXNlbnRhdGlvbiBw ZXIgUkZDIDc5NTEuDQoNCltZUV06IEFkZGVkIEpTT04gZm9ybWF0Lg0KDQoNCg== From nobody Tue Aug 25 15:31:35 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F243A053F; Tue, 25 Aug 2020 15:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 KHowCUbtX1s7; Tue, 25 Aug 2020 15:31:32 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 BD4E93A052C; Tue, 25 Aug 2020 15:31:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4BbkHS48plz1nvMs; Tue, 25 Aug 2020 15:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1598394692; bh=xK7/R+3D2zm5T8DJ8dZB7ewteTGziV5TSh+rjEpPBDc=; h=Subject:References:To:From:Date:In-Reply-To:From; b=fo8o8KO/D6RZdRIZl1LN1BHFVF8TTzvDAEUI2Z0X9X/mJEr37sA2Bwzsa8d3YmkzI nV+bP5w0sMrGq2tVfTZiDVT+qMg92Dx8VgFNNHM2p1va+ykuVHXFnFkxr0o36t1k9f uW6jJ/829LXXk0q1Vkv+Vpse0EPWSCds7RX/CwE0= X-Quarantine-ID: <0DJV0U0wotxH> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4BbkHS016vz1ntQh; Tue, 25 Aug 2020 15:31:31 -0700 (PDT) References: <159839313932.2001.15256610356742310223@ietfa.amsl.com> To: "lisp@ietf.org" , "sfc@ietf.org" , "spring@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: <159839313932.2001.15256610356742310223@ietfa.amsl.com> Message-ID: <9d852e5f-6166-d5a4-8c8c-a569d4a196ef@joelhalpern.com> Date: Tue, 25 Aug 2020 18:31:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <159839313932.2001.15256610356742310223@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] Fwd: NomCom 2020: Call for nominations X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 22:31:34 -0000 Please nominate those people you think would be good to have serving in any of the positions the current nomcom is evaluating. Also, consider this a heads up that when the comment period opens, the nomcom will need your comments. PLEASE plan to provide comments. Thank you, Joel -------- Forwarded Message -------- Subject: NomCom 2020: Call for nominations Date: Tue, 25 Aug 2020 15:05:39 -0700 From: NomCom Chair 2020 To: IETF Announcement List CC: ietf@ietf.org The 2020-21 IETF Nominating Committee (NomCom) is seeking nominations from now until October 6, 2020. The open positions being considered by this year's NomCom can be found at the end of this email and also on this year's NomCom website: https://datatracker.ietf.org/nomcom/2020/ Nominations may be made by selecting the Nominate link at the top of the NomCom 2020 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2020/nominate/ Note: Nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ If you are unable to use the web form, nominations may instead be made by email to nomcom-20 at ietf dot org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The questionnaires will be available no later than September 1, 2020 and have a submission deadline of October 13, 2019. Most are already posted. NomCom 2020-21 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 8713: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way, e.g., anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP 10 remain in effect. All feedback and all NomCom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the NomCom to tell the nominee that you were the one who made the nomination. This defaults to “no†- so if you don't mark the field we won’t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before October 6, 2020. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. The NomCom appoints individuals to fill open slots on the IAB, IESG, the IETF Trust and the LLC Board. The list of people and posts whose terms end with the March 2021 IETF meeting, and thus the positions for which this NomCom is responsible, follows: LLC Board - Maja Andjelkovic IETF Trust - Joel Halpern IAB - Jari Arkko - Jeff Tantsura - Mark Nottingham * - Stephen Farrell - Wes Hardaker - Zhenbin Li IESG - Alissa Cooper, IETF Chair/GEN AD * - Alvaro Retana, RTG AD - Deborah Brungard, RTG AD - Magnus Westerlund, TSV AD - Roman Danyliw, SEC AD - Warren Kumari, OPS AD * - have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2020/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, in individual tabs at: https://datatracker.ietf.org/nomcom/2020/requirements/ In addition to nominations, the NomCom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions’ responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-20 at ietf dot org. Thank you for your help in identifying qualified nominees! Thanks, Barbara IETF NomCom Chair 2020-2021 Barbara Stark nomcom-chair-2020 at ietf dot org From nobody Wed Aug 26 13:19:42 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC8B3A0B3E; Wed, 26 Aug 2020 13:19:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <159847318005.28091.3212458145380647674@ietfa.amsl.com> Date: Wed, 26 Aug 2020 13:19:40 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-22.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 20:19:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-22.txt Pages : 35 Date : 2020-08-26 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-22 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-22 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 Aug 26 13:24:53 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0922C3A0B53; Wed, 26 Aug 2020 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 aA-oAW3yTGT0; Wed, 26 Aug 2020 13:24:49 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2124.outbound.protection.outlook.com [40.107.243.124]) (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 869713A095E; Wed, 26 Aug 2020 13:24:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UWLz/vovhQKss9lkskqr4t24zU8Tmze+o6/lRdVuWUUwQpD3tXr/4gh5XGQTn3AqxTCbGmsT+PhsXoUFbG9JqhZ73FF0x14d+G/WNeA0FsUMYTysn6r/wSWict3zNG9kqQ1IUU2RvYnitLG/2c/Tia12FIrBhipqqzhq6pzx3AjywYkEZlNdR7rsJzRmxmPkI9IEc4uB8tJsMCdE36WdkGJxdyUE3oHfCO/7HHkGVr+BEJ2QfOFV0hMSzntWnM1H4NG6Mln1yMwpXCeWd80lO7n/i0LnqhrXytSdaZozAHhvj8KQtWp+DLOeKR8CuqohWKQZjgLGq+lDnyCekeF9cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CintKYAVn7l7d2t1bZzWx1gnx3E6mxinzxA2qeEwSnI=; b=nTPHSwZLIIJK5u83e74YsUmxQRqxuLz+su1jOsQ+J53yM94RQhVdnPctM7hNnqUU4k0pQJK/zvGpcIXaEDUTeF4lhTXEX3uu40Ue/e/p+mP4wpOp3Qg/0X0ocq1ZOOGkQhTtXfJd1yViGJR8I3Hz5IE/6ROxfvms1SlCKAWTdJ65RnnUarBqhfDc9er1gPzeJHguVmm7bdEHyqWwKvaDzac5My1GP1uI0Ix/CDSm7NW176B81e76fq/U7Vu4Pjsi0qwz+vhbtvXrUmyG6FI9zP3yqmru4c9Sprl4Y9LQjLiPhYdSItA5D8HEf7I9L2vdJe0D3KrxA5kqNeQQnJ0bqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CintKYAVn7l7d2t1bZzWx1gnx3E6mxinzxA2qeEwSnI=; b=mxluSzVHje8qwkKgL1Lqz1l2g0z9iI3G1mu/JxTmiEquU9SDMo/c5HlAdN2dDIsR42ackz/nRxJFpXKFZI9Z4oMEOgEF1YTgMqBo1aT11UslQPlQLcxUWRjgzCjOSxOINPNN/k4ela98k8kfQUis/QTJICIv+8P5tNj1JQ3vGkQ= Received: from BY5PR13MB3048.namprd13.prod.outlook.com (2603:10b6:a03:188::21) by BY5PR13MB3729.namprd13.prod.outlook.com (2603:10b6:a03:218::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Wed, 26 Aug 2020 20:24:45 +0000 Received: from BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034]) by BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034%5]) with mapi id 15.20.3326.019; Wed, 26 Aug 2020 20:24:45 +0000 From: Yingzhen Qu To: Ladislav Lhotka , "yang-doctors@ietf.org" CC: "spring@ietf.org" , "draft-ietf-spring-sr-yang.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-spring-sr-yang-20 Thread-Index: AQHWehVL6ibBl740LkCSVJAG2mn0IalIz6KAgAFKrYCAAEoMAA== Date: Wed, 26 Aug 2020 20:24:45 +0000 Message-ID: References: <159827349041.30993.687894019314723215@ietfa.amsl.com> <87h7sphjeo.fsf@nic.cz> In-Reply-To: <87h7sphjeo.fsf@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:646:9500:c900:916a:535b:e402:d6a3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10ef4118-3633-48ee-2887-08d849fe127a x-ms-traffictypediagnostic: BY5PR13MB3729: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8+v378LpB/6+Uxnw4X4vD2fFXeAx+3bzkfDdCsciMw52OeKejulh/Ma9s3Thex8bhFuDh2XAU7mKpmoFOE7Qi1lM+NQy7y+8dCyQD+i6q3w1Z8Vu9Gvv18AJTFc6CBeDoOGhc/UUIzxIiVwOqXykEn/aTynXBg+vhees2mgi6xNulTTk/G9Vo4gYsC/AbiRyYbsDdaZzxenvOq2nFISGO1/69zJ1mnmfaiwBwlLQVM/jIUkDk3flH3mtI9nhFSasUf5n2YEtk9+A0rGyU4BMgsFPzp6vO+3v6JixStuHIo9QPKBnW9ynVr2O6uO/wphlziAayEsTv5iRvsE47ElqLw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3048.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(39850400004)(136003)(366004)(53546011)(2616005)(2906002)(44832011)(83380400001)(8936002)(6512007)(8676002)(54906003)(66446008)(4326008)(110136005)(76116006)(5660300002)(64756008)(66946007)(66556008)(66476007)(478600001)(316002)(6506007)(186003)(86362001)(33656002)(36756003)(6486002)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JtuNazKxMu6Cg51cmBvIKChbjhUgfwhKqq+WI0GeFg7C2F6arI5824mco/rL9HC1zXbcYS7Yev8I6WL3yQF9ruR2Tlh/AYDXHCyjcBI0CYFQ7TrrDbRNLFi9FY9wYdizKmW5YlvaW9L31rmKwP7l1+NxBSbkCFBd2mH/FhaR56z92+zbfDrWkq4V5Unm9LvFZgt58ba62yC2uYR1BvlYMczFdDpxD9NbI8AJng/RxD3gJUxf3vqMC2jR2d7+NcU4D0DrzmVAMKQR5i2DUQdCRyUfIpJla6c19exFLFetOYeQU1var7lz/wQ8zX6Auuq/jBqj8fmKPJpyso74FdKBKwRnC38vhhqeMvQFCJ1P9PiCXhwOYxJD1KJ7XhK+7IOsHCaJKCEYO3xThSEN6+tX11YNFiJdO7JYU1Q7hcd4PR+LtFKRtJHT6ma/zTwE+CyzHq/T+Wi/vaJsohDmBPBfx231XLnT4xvYEFV10riHhU3XbaXv5k1O4xABx5PVVudCfEoD3ASJGQI8jpctOhB5LeFPsTDPFTusvSimNTeyc6eLb6WLP/ypCGGk6QsjskaI7e/4T0uIJxfLgfdR+r/WeYX/whc/syBOksWdTu02HdSpJTOlUGlmChJg6LKKfi1D2iKnxgCFwt98X20P/8N+YubWxoRi4aUQMcQ9sXUp4s8efqURp9n1Ej1Xr22NP5TySI4cODlBD/Q4Lt1aP8ZhrA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5608933B93744A46A8CA12FB74A0F7DF@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3048.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10ef4118-3633-48ee-2887-08d849fe127a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 20:24:45.1532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9pu0At3bgO4FhWR2QOozJR+h485RnL5W2EkSLvE4hS/cwl8AN+wdNaN56IX3Cyun9KwXJt6TmE1mj1mFPZ5uAw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3729 Archived-At: Subject: Re: [spring] Yangdoctors last call review of draft-ietf-spring-sr-yang-20 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 20:24:51 -0000 SGkgTGFkYSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgSSd2ZSB1cGxvYWRlZCB2ZXJzaW9u IC0yMiB0byBhZGRyZXNzIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgYW5zd2VycyBpbmxp bmUgZm9yIGRldGFpbHMuDQoNClRoYW5rcywNCllpbmd6aGVuDQoNCu+7v09uIDgvMjYvMjAsIDE6 NTkgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCg0KICAgIEhp IFlpbmd6aGVuLA0KDQogICAgcGxlYXNlIHNlZSBteSByZXNwb25zZXMgaW5saW5lLg0KDQogICAg WWluZ3poZW4gUXUgPHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+IHdyaXRlczoNCg0KICAgID4g SGkgTGFkYSwNCiAgICA+DQogICAgPiBUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LCByZWFsbHkg YXBwcmVjaWF0ZS4gDQogICAgPg0KICAgID4gSSd2ZSB1cGxvYWRlZCB2ZXJzaW9uIC0yMSB0byBh ZGRyZXNzIHlvdXIgY29tbWVudHMgYW5kIHBsZWFzZSBzZWUgZGV0YWlsZWQgYW5zd2VycyBiZWxv dyBpbmxpbmUgc3RhcnRpbmcgd2l0aCBbWVFdLg0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+ IFlpbmd6aGVuDQogICAgPg0KICAgID4gT24gOC8yNC8yMCwgNTo1MSBBTSwgIkxhZGlzbGF2IExo b3RrYSB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCiAgICA+DQog ICAgPiAgICAgUmV2aWV3ZXI6IExhZGlzbGF2IExob3RrYQ0KICAgID4gICAgIFJldmlldyByZXN1 bHQ6IFJlYWR5IHdpdGggTml0cw0KICAgID4NCg0KICAgIC4uLg0KDQogICAgPg0KICAgID4gICAg IC0gVGhlIHRpdGxlIG9mIFNlY3Rpb24gOCBzaG91bGQgdXNlIHBsdXJhbCAiWUFORyBNb2R1bGVz IiBiZWNhdXNlIGl0IGNvbnRhaW5zDQogICAgPiAgICAgdGhyZWUgbW9kdWxlcy4gSXQgd291bGQg YWxzbyBiZSBoZWxwZnVsIHRvIGludHJvZHVjZSBhIHN1YnNlY3Rpb24gZm9yIGVhY2gNCiAgICA+ ICAgICBtb2R1bGUuDQogICAgPiBbWVFdOiBjaGFuZ2VkIHRoZSB0aXRsZSBhbmQgYWRkZWQgYW4g aW50cm9kdWN0aW9uIG9mIGVhY2ggbW9kdWxlLg0KDQogICAgSSBtZWFudCB0byBhZGQgYSBzdWJz ZWN0aW9uIG9mIHNlYy4gOCBmb3IgZWFjaCBtb2R1bGUgc28gdGhhdCB0aGV5IGFyZSBjbGVhcmx5 IHNlcGFyYXRlZCBhbmQgZWFjaCBvZiB0aGVtIGVhc2lseSBhY2Nlc3NpYmxlIGZyb20gdGhlIHRh YmxlIG9mIGNvbnRlbnRzLg0KDQpbWVFdOiBzb3JyeSBmb3IgdGhlIG1pc3VuZGVyc3RhbmRpbmcu IEkndmUgYWRkZWQgYSBzdWJzZWN0aW9uIGZvciBlYWNoIG1vZHVsZSwgYW5kIGl0IGRvZXMgbG9v ayBiZXR0ZXIgbm93Lg0KICAgID4NCiAgICA+ICAgICAtIER1ZSB0byB0aGUgUkZDIGxpbmUgbGVu Z3RoIGxpbWl0LCB0aGUgZXhhbXBsZSBpbiBBcHBlbmRpeCBBIHVzZXMgYSBsaW5lIGJyZWFrDQog ICAgPiAgICAgaW5zaWRlIGEgVVJJIG9mIGEgWE1MIG5hbWVzcGFjZSBkZWNsYXJhdGlvbiwgd2hp Y2ggbWFrZXMgdGhlIFhNTCBpbnZhbGlkLiBUaGlzDQogICAgPiAgICAgY2FuIGJlIHByb2JhYmx5 IGF2b2lkZWQgYnkgaW5jbHVkaW5nIHRoZSBYTUwgbmFtZXNwYWNlIGRlY2xhcmF0aW9uIGZvciAi c3ItY21uIg0KICAgID4gICAgIGluIHRoZSB0b3AtbGV2ZWwgZWxlbWVudCwgaS5lLg0KICAgID4N CiAgICA+ICAgICAgIDxyb3V0aW5nDQogICAgPiAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnlhbmc6aWV0Zi1yb3V0aW5nIg0KICAgID4gICAgICAgICB4bWxuczpzci1jbW49 InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXNlZ21lbnQtcm91dGluZy1jb21tb24i Pg0KICAgID4NCiAgICA+ICAgICAgIElmIG5vdCwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHVzZSBj b252ZW50aW9ucyBvZiBSRkMgODc5Mi4NCiAgICA+DQogICAgPiBbWVFdOiBJIHRyaWVkIHRoZSBm b3JtYXQgYXMgeW91ciBzdWdnZXN0ZWQsIGJ1dCBzb21laG93IEkgY291bGQgZ2V0IGl0IHBhc3Mg eWFuZ2xpbnQsIHNvIGFkZGVkICJcIiBwZXIgUkZDIDg3OTIuDQoNCiAgICBPSy4NCg0KICAgID4g IA0KICAgID4gICAgIC0gQXNzdW1pbmcgdGhhdCB0aGUgZXhhbXBsZSBpcyBpbnRlbmRlZCBmb3Ig aHVtYW4gcmVhZGVycywgaXQgbWlnaHQgYmUgYmV0dGVyDQogICAgPiAgICAgdG8gcHJvdmlkZSBp dCBpbiB0aGUgSlNPTiByZXByZXNlbnRhdGlvbiBwZXIgUkZDIDc5NTEuDQogICAgPg0KICAgID4g W1lRXTogQWRkZWQgSlNPTiBmb3JtYXQuDQoNCiAgICBMb29rcyBnb29kLCBtYXliZSBvbmx5IHRo ZSBmaXJzdCBicmFjZSBjYW4gYmUgbW92ZWQgdG8gdGhlIGxlZnQuDQpbWVFdOiBmaXhlZC4NCg0K ICAgIFRoYW5rcywgTGFkYQ0KDQogICAgPg0KICAgID4NCg0KICAgIC0tIA0KICAgIExhZGlzbGF2 IExob3RrYSANCiAgICBIZWFkLCBDWi5OSUMgTGFicw0KICAgIFBHUCBLZXkgSUQ6IDB4QjhGOTJC MDhBOUY3NkM2Nw0KDQo= From nobody Wed Aug 26 20:14:22 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D91233A0CA7; Wed, 26 Aug 2020 20:14:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Brian Weis via Datatracker To: Cc: draft-ietf-spring-srv6-network-programming.all@ietf.org, spring@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159849805983.7699.460089427690333419@ietfa.amsl.com> Reply-To: Brian Weis Date: Wed, 26 Aug 2020 20:14:19 -0700 Archived-At: Subject: [spring] Secdir last call review of draft-ietf-spring-srv6-network-programming-17 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 03:14:20 -0000 Reviewer: Brian Weis Review result: Has Nits This document is titled “SRv6 Network Programmingâ€, which is attention grabbing. It fleshes out how Segment Routing routes IPv6 packets by Segment ID (SID), as well as defining the format of a SID for IPv6. The Introduction states, “An ingress node steers a packet through an ordered list of instructions, called segments.†When one considers this statement along with the document title, it’s apparent that network devices are indeed being given “instructions†in the programming sense, where each “instruction†is encoded in an IPv6 address. An “instruction†(i.e., SRv6 SID) comprises a locator (which is used to route to a particular network device), and also directs the network device acting as the locator how to process the IPv6 packet. With the help of an IPv6 Segment Routing Header (SRH) header, a series of “instructions†can source route a packet through the network, where each network device acting as a locator learns how to handle the packet before possibly sending it on to the next SID (if any). The encoding of an IPv6 address as an SRv6 SID includes a locator, a code indicating a certain function, and optionally arguments to that function. An initial set of codes (and their associated algorithms) is defined in this document. Most of the codes describe how the egress router should decapsulate the packet, with might include defining which routing table the receiving router should look up after decapsulation. The Security Considerations section points to the Security Considerations of the architecture document and the SRH document. Both documents focus on the fact that SRv6 is intended to be used within a single domain (e.g., provider network) and discuss routing mitigations such as filtering external traffic appropriately. They seem to assume that the boundaries of the domain itself are inviolate such that the domain boundary devices are not subverted, and that there are no bad actors within the domain. These are common assumptions for service provider networks where Segment Routing is intended to be deployed. However, it cannot be certain that all networks deploying Service Routing to be free of bad actors, and there will certainly be some benefit to a bad actor changing “instructions†encoded in IPv6 addresses. Perhaps there is opportunity for mischief in changing the routing table argument in an End.DT46, for example. Also, as other SRv6 functions are defined (e.g., packet inspection functions), it would be important to ensure that those SIDs are not modified to avoid or decrease the quality of those inspection functions. The SRH document does describe an HMAC TLV that is intended to mitigate these kinds of attacks. Since neither of the referenced documents Security Considerations mention it, it would be a good idea to describe here that there are threats to changing SIDs, and point out how to mitigate them with the HMAC TLV. Also, if I’m not mistaken, when there is just one SID then it is placed in the IPv6 DA and there is no SRH header or HMAC TLV. This is a general problem with ensuring that the DA on packets are not changed in transit, and one could use IPsec to mitigate that issue. It’s probably worthwhile mentioning something like that. From nobody Wed Aug 26 22:10:44 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4601C3A0CE6; Wed, 26 Aug 2020 22:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Trvgpi6W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DBJp5V58 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 7vSEQRdyd4wY; Wed, 26 Aug 2020 22:10:36 -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 15CAC3A0CE4; Wed, 26 Aug 2020 22:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5468; q=dns/txt; s=iport; t=1598505036; x=1599714636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yCg6Nm5/DG5ElFeyim5NtCB6zRJq7n0jhAenOrzbhSU=; b=Trvgpi6WpXd1TsTcmL6XipTQ4FzI4PQnO5dhHpO/vnZPWPJiErnwi7UN 9/SCA93Cur6kvS8zrxGbzphpRiVd1dYUgtgzFQPd7rGy8ReoFr6NnWmQ0 7fj1a6ywRgahwbGcifNBHM+eTKbONJTOnCPZ7ZomMjg+cP47CJvjYP2YP M=; IronPort-PHdr: =?us-ascii?q?9a23=3Aq2Vpdx9vjg/Cov9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRCN6vBkjVuPVoLeuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorH6+OElRXs35Yg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAADHP0df/4UNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTYHAQELAYFRUQdwWC8sCodzA4RYiRGKC45mgS6BJQNVCwE?= =?us-ascii?q?BAQwBARgNCAIEAQGETAKCOAIkNAkOAgMBAQsBAQUBAQECAQYEbYVcDIVyAQE?= =?us-ascii?q?BAwEBARAoBgEBLAsBBAcEAgEIEQQBAQEeBQshBgsdCAIEAQ0FCBqDBYJLAw4?= =?us-ascii?q?gAQMLpzkCgTmIYXSBNIMBAQEFgTMBE0GDJg0Lgg4DBoE4AYJwijMbgUE/gRF?= =?us-ascii?q?Dgk0+ghpCAQECAQGBXQWDQ4Itj3gCglijMVEKgmOIZoZOhXWFJIMGiWeTUpJ?= =?us-ascii?q?JikqCZpIaAgQCBAUCDgEBBYFUOoFXcBU7gjUBATJQFwINjh8MFxSDOoUUhUJ?= =?us-ascii?q?0AgE0AgYKAQEDCXyOeQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,358,1592870400"; d="scan'208";a="819337950" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 05:10:34 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07R5AYIg004503 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2020 05:10:34 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 00:10:34 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 00:10:33 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 27 Aug 2020 00:10:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aoNyy25BXj0Xns+9VGgN1E2ClIQGhbbT4ha3Ii3IcIr+CYPQPonPTQCbaW1ApaPXFAQRnV0V4kyJfxlNv+q1F/AFvd95GPT9l1yI9SphY9CbhC029f0F1LuU4YPNvCSwCGb2vB3TKKNIT4JCtD4Xfla28TX/8z9e3dmuvw4k1PTPJLjh5UhD+xfd8Il6lKHTcPT3zvrE4EpQTVmaAZXfy1ikLYNupMz3AaHiTHi7twOLzOH4ijDAm8517nUGackpzDgd8uErZjqJYz4Dx3/WqUegFpfF6H7fHt4lg/OsOqvBGDBcLzBCg3ijUtQ/m+czBUcUUtnlG2lE8ci+CANrMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ho3Vg33WPFKh3SU3BrABgewbq6k77gEuRPmUw0Q7hUU=; b=dKjJ2STE9KHPP8MikY/VemW3aoQq9LkiTbBeMibarpIRlZYbZvHzTzH1k2+O85hGoDyCnFmuVV0qXj8Qk0l0LdtRBR5EOEea7V1ALeEv7/rWxsNSJ7bysG7wClXpl6LeKdZKz5sSdp4fyuYDRXz4JBB4nR9ZcDLDY++ewDnzqd5wCbaD3Riaeb7sdTfk4DNOcWlAuPoURgkCvLUHc7sXyPvN7kU5yBh1BQ7ip1s0yL7CGig6G3t33bEMa/xHP7mCR3aDqh67c1xXoSjeScWvvtONEheyFo3k1PZmtl9x3MBglwYPGeyW7v3nnaR3VFm5sVkAc8JHW3JAAlH7ASXrog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ho3Vg33WPFKh3SU3BrABgewbq6k77gEuRPmUw0Q7hUU=; b=DBJp5V581dw1xGNQPeGpNBgY3IjUwt5RuKHdGL379lIGWF2j61t2Ap3OxbgmkFgQ9VkmincOsojOuZg+pnOsEaKowBPD7isVmgljt+UW13JoqCemmN7JfNvyUmw/dL2vo2XyYIjz4dVZaFiS3BkaE1iisjfNv9Vf1vkJoZxh9XU= Received: from MWHPR11MB1374.namprd11.prod.outlook.com (2603:10b6:300:24::8) by MWHPR1101MB2144.namprd11.prod.outlook.com (2603:10b6:301:51::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Thu, 27 Aug 2020 05:10:31 +0000 Received: from MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e]) by MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e%12]) with mapi id 15.20.3326.021; Thu, 27 Aug 2020 05:10:31 +0000 From: "Pablo Camarillo (pcamaril)" To: Brian E Carpenter , "last-call@ietf.org" CC: "spring@ietf.org" , "spring-chairs@ietf.org" , Bruno Decraene , "jmh@joelhalpern.com" , "draft-ietf-spring-srv6-network-programming@ietf.org" Thread-Topic: Last Call: (SRv6 Network Programming) to Proposed Standard Thread-Index: AQHWcKf0zDZZDEhyN0ektmn5dymw76lBmuYAgAiIPDA= Date: Thu, 27 Aug 2020 05:10:31 +0000 Message-ID: References: <159723694970.27067.9766029100632402951@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [88.14.54.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a4eae2fc-bb1e-4afa-5595-08d84a478588 x-ms-traffictypediagnostic: MWHPR1101MB2144: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oo4i87ODJUKlgXru+lfjJdrEMnZANMCG5oozicGUWA3mLQfhOhNz24Rwd2szggBi1ll02CA2wFCPlBt4CckKA/mD6cBEPNkOfHCQMlqHEdVDQjPbEP1VkB4BJ1DhS+fkkqz2d1JTdu90gfioVN0EJqQW1P06IvqPJXzpYp87S/Y9+ywndUI34yA3jrF82hn5j2vaplxGBV1q3a83Us/PCuf2EZdx7T6auB7geDh7rsJXIXCvTmYkTbCN2hsFs2JuUuipf3y2gfcgNvSjhIEaCn6B+XwnI7+NRvcxTl/NNhKoNeldh3gERnM2iGRWNE3fjPYmZDYu8AnVteHIP+SnSQ3vItFrifrB/l8VSaD6MVUgP4LxajRl8i+yV5Au5uzm9UwjVJQHQWmG9KSaAOncwQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1374.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(396003)(376002)(39860400002)(8676002)(26005)(966005)(186003)(83380400001)(6506007)(478600001)(7696005)(53546011)(52536014)(54906003)(110136005)(316002)(86362001)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007)(5660300002)(8936002)(9686003)(4326008)(33656002)(2906002)(71200400001)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YTzPQkrajtD+TfnKjFUB+E2BwXlp0GIJQgurI5kMmpmROnJqW9O7H3D53q0hm/5dM0Gqq4GSN2cbvuk44/zjHA8p4dHrsY1T6MjH9SbtSDcvmX67o5Rn61gmh394uMHFcYg5FzJ7L/8xcixEIkJQq9GkGv4HpLl3acuwbZ7fC4ZTxY1WZ40rYAGQAEbluOWk2XxoPlrNAtsDBzwyAjPLe8SMi183YlaSlA3HhiXLUdr3jVHX1w9TFNCd6AO6tDIZRjasRwWQSZAJvaeh7g5AIooFjN/L0kn1Cf75dmbpfZ1gAB2ze2LExrkskfDg0UqxQI9t5m+X7ASYTyjyxxPEdUr+eApLwOok9NF7rqvUMQjqEfttNf3eDa2KHRsTQivf0xo8XZjsZGo4zVqBVawZw6CarKFvrQ8MNPdTYuFk9g//2EYZB/77V7uSQSycHfWLVY0pOYNILfEwPiVHcN+XVOguO41LolEXk8udri0ByBK0iMpib9A03Hf7xaVb+RMXEGAATqAUEEPRHcsyOEIWf6InMe5g2upGCBwjQDYFs6dd6dd8SM//JaTLqukwzv9buSc89tkhIE2puAEsM9M2q14Hy/FbKVP+Mg6sp9RlUaxwS6wH4hLjFZY4SkFSBkZgmquBFpT4jHpzWlxZ69blWQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1374.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4eae2fc-bb1e-4afa-5595-08d84a478588 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 05:10:31.3444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ssHOa0am1WlsY0M+C2+kzK9EhihlbuVKgPk8Tkodm+NepeiSApCMPqZrLlPUNQVO/9JwJ3GmyHo7ksAaaLumug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2144 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [spring] Last Call: (SRv6 Network Programming) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 05:10:38 -0000 Hi Brian, The PSP behavior is only applied to received packets when (Segments Left = =3D1 & Destination Address =3D PSP SID). The PSP behavior pseudocode describes the local processing of this packet, = and the check for Segments Left =3D=3D 0 is an intermediate step of that lo= cal processing. This local processing might be implemented in different way= s as long as the externally observable wire protocol is preserved. In order to clarify this, we propose the diff below. Thank you, Pablo. =20 The following sub-sections detail the behaviors, introduced in this document, that a node (N) binds to a SID (S). =20 Section 4.16 defines flavors of some of these behaviors. =20 4.1. End: Endpoint The following sub-sections detail the behaviors, introduced in this document, that a node (N) binds to a SID (S). The pseudocode describing these behaviors detail local processing at a= =20 node. An implementation of the pseudocode is compliant as long as the e= xternally=20 observable wire protocol is as described by the pseudocode. =20 Section 4.16 defines flavors of some of these behaviors.=20 =20 4.1. End: Endpoint =20 This behavior does not contravene Section 4 of [RFC8200] because the current destination address of the incoming packet is the address of the node executing the PSP behavior. =20 The End, End.X and End.T behaviors with PSP do not contravene=20 Section 4 of [RFC8200] because the destination address of the incomin= g packet is the=20 address of the node executing the behavior. -----Original Message----- From: Brian E Carpenter =20 Sent: viernes, 21 de agosto de 2020 0:06 To: last-call@ietf.org Cc: spring@ietf.org; spring-chairs@ietf.org; Bruno Decraene ; jmh@joelhalpern.com; draft-ietf-spring-srv6-network-programmi= ng@ietf.org Subject: Re: Last Call: = (SRv6 Network Programming) to Proposed Standard IMHO there is still a logical defect in the description of the PSP flavor a= t https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-17= #section-4.16.1 The description of the PSP flavor considers the packet to have (Segments L= eft =3D=3D 0 and Destination Address =3D=3D the PSP node's address). In fact that is *never* the state of the packet on the wire, which is eithe= r (Segments Left =3D=3D 1 and Destination Address =3D=3D the PSP node's ad= dress) when the packet arrives, or (Segments Left =3D=3D 0 and Destination= Address =3D=3D the final node's address) when the packet departs. So the text does not refer a packet on the wire, whereas RFC8200 only refer= s to packets on the wire. Thus the test "S14.1. If (Segments Left =3D=3D 0) {" in section 4.16.1 is= confusing because it's applied to a packet that is half way through proces= sing of the routing header inside the node (Segments Left has been updated,= but Destination Address has not been updated). This makes it unclear how t= he spec is claiming to interpret RFC 8200. (This was pointed out a long time ago: https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/ ) The text: > This behavior does not contravene Section 4 of [RFC8200] because the > current destination address of the incoming packet is the address of > the node executing the PSP behavior. is being applied to a packet that never exists on the wire, but only inside= the PSP node. Regards Brian Carpenter On 13-Aug-20 00:55, The IESG wrote: >=20 > The IESG has received a request from the Source Packet Routing in=20 > Networking WG (spring) to consider the following document: - 'SRv6 Networ= k Programming' > as Proposed=20 > Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits=20 > final comments on this action. Please send substantive comments to the=20 > last-call@ietf.org mailing lists by 2020-08-26. Exceptionally,=20 > comments may be sent to iesg@ietf.org instead. In either case, please=20 > retain the beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The SRv6 Network Programming framework enables a network operator or > an application to specify a packet processing program by encoding a > sequence of instructions in the IPv6 packet header. >=20 > Each instruction is implemented on one or several nodes in the > network and identified by an SRv6 Segment Identifier in the packet. >=20 > This document defines the SRv6 Network Programming concept and > specifies the base set of SRv6 behaviors that enables the creation of > interoperable overlays with underlay optimization (Service Level > Agreements). >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-progra > mming/ >=20 >=20 > The following IPR Declarations may be related to this I-D: >=20 > https://datatracker.ietf.org/ipr/3464/ >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From nobody Wed Aug 26 23:29:35 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D923A0D47; Wed, 26 Aug 2020 23:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vo6eAxBXKZd; Wed, 26 Aug 2020 23:29:27 -0700 (PDT) Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 AEC533A0D4E; Wed, 26 Aug 2020 23:29:27 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id n3so2157101pjq.1; Wed, 26 Aug 2020 23:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LKIGB+lyCan0jP2K5m2Yzo8r5a6x63uEC0qteWVPISM=; b=Bsv7HuYDEeYOb/tNxNqmbo3oPZslEHmMjNNYq9s+ye7n5VQnmpD2bobvV2J2R+0M9s k0X8ToShn2GzLK20OW440Ld1ejJAAM8AYKiPrUSflVbrwpLKcpvTJWP9Q0rTH1Lx/knU CfrfrIVjAoEwc0QFLlZ+ZIrcAnwYnFMVgIcW8dpf2iIxkLWbbjS1ImeVdo77x4O3NhAl U3f1O2AfukaHwCqm7EKrDmQbR7PN4DDxfm/YDT58sZZVQKnJi/IJl4ICN2J1neVQAhHv QKvRBsKw9+j3hRx6656s63OO19mgi4VNrQbnFNCi0TEMtWNvM2E9v1qxaCtlFQFmuAxD upFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LKIGB+lyCan0jP2K5m2Yzo8r5a6x63uEC0qteWVPISM=; b=fOjC28VZQOIWnxVFAzQObvZ4INJeQItwD44pvNbsUtFPWXqrIDxnTLS4Wc4Re6C0XU zwgL+XoJgPyOnoesqI4D54t2pMUN/3Vq/D8RJ+Yo9wNZ5evAKhcqgAg2jNxXVm0J+wG2 YpSHR9ISJpxSsi0hglIG7ojJitsVmo98d3YElvgFnLfARJ8R8xLmjDv01M5ox3AnHz5Z +eqTVNubgyZTMBQ2Hor0mcId5uSfRRVH6leFL3P8pQpuffPR388Q25RoP7LW3Bkptms6 Wn8EiynKRqXC12cUzDJzGoZKTCg+Nb1cR2mMVPIXLS7hqEOp+SFSo1/3IrKjjEkv9TPa BnNg== X-Gm-Message-State: AOAM532Xok9TIIzIWmY9md0Huxo27CrKvD6+RDESqiZW1LQXFpsef8eW xlJMzZYBThWFC0Gzf4ws0NW/+gXtI5Qhxg== X-Google-Smtp-Source: ABdhPJxL/Hgx5K0y0l2FTJF890TbHr1v0eOfmJ+vWFOkZlOR9PTD26FGuTerK0uq6xiofW+DLmoSOw== X-Received: by 2002:a17:90a:6a05:: with SMTP id t5mr8903310pjj.26.1598509766812; Wed, 26 Aug 2020 23:29:26 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id s64sm1363360pfs.111.2020.08.26.23.29.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 23:29:26 -0700 (PDT) To: "Pablo Camarillo (pcamaril)" , "last-call@ietf.org" Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , Bruno Decraene , "jmh@joelhalpern.com" , "draft-ietf-spring-srv6-network-programming@ietf.org" References: <159723694970.27067.9766029100632402951@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <521aafe7-6d05-a245-1b21-e047c0904e08@gmail.com> Date: Thu, 27 Aug 2020 18:29:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] Last Call: (SRv6 Network Programming) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 06:29:30 -0000 Thanks Pablo, that clarifies the point for me. Regards Brian Carpenter On 27-Aug-20 17:10, Pablo Camarillo (pcamaril) wrote: > Hi Brian, > > The PSP behavior is only applied to received packets when (Segments Left =1 & Destination Address = PSP SID). > The PSP behavior pseudocode describes the local processing of this packet, and the check for Segments Left == 0 is an intermediate step of that local processing. This local processing might be implemented in different ways as long as the externally observable wire protocol is preserved. > > In order to clarify this, we propose the diff below. > > Thank you, > Pablo. > > > > The following sub-sections detail the behaviors, introduced in this > document, that a node (N) binds to a SID (S). > > Section 4.16 defines flavors of some of these behaviors. > > 4.1. End: Endpoint > > > The following sub-sections detail the behaviors, introduced in this > document, that a node (N) binds to a SID (S). > > The pseudocode describing these behaviors detail local processing at a > node. An implementation of the pseudocode is compliant as long as the externally > observable wire protocol is as described by the pseudocode. > > Section 4.16 defines flavors of some of these behaviors. > > 4.1. End: Endpoint > > > > This behavior does not contravene Section 4 of [RFC8200] because the > current destination address of the incoming packet is the address of > the node executing the PSP behavior. > > > > The End, End.X and End.T behaviors with PSP do not contravene > Section 4 of [RFC8200] because the destination address of the incoming packet is the > address of the node executing the behavior. > > > > -----Original Message----- > From: Brian E Carpenter > Sent: viernes, 21 de agosto de 2020 0:06 > To: last-call@ietf.org > Cc: spring@ietf.org; spring-chairs@ietf.org; Bruno Decraene ; jmh@joelhalpern.com; draft-ietf-spring-srv6-network-programming@ietf.org > Subject: Re: Last Call: (SRv6 Network Programming) to Proposed Standard > > IMHO there is still a logical defect in the description of the PSP flavor at https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-17#section-4.16.1 > > The description of the PSP flavor considers the packet to have (Segments Left == 0 and Destination Address == the PSP node's address). > In fact that is *never* the state of the packet on the wire, which is either (Segments Left == 1 and Destination Address == the PSP node's address) when the packet arrives, or (Segments Left == 0 and Destination Address == the final node's address) when the packet departs. > > So the text does not refer a packet on the wire, whereas RFC8200 only refers to packets on the wire. > > Thus the test "S14.1. If (Segments Left == 0) {" in section 4.16.1 is confusing because it's applied to a packet that is half way through processing of the routing header inside the node (Segments Left has been updated, but Destination Address has not been updated). This makes it unclear how the spec is claiming to interpret RFC 8200. > > (This was pointed out a long time ago: > https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/ ) > > The text: > >> This behavior does not contravene Section 4 of [RFC8200] because the >> current destination address of the incoming packet is the address of >> the node executing the PSP behavior. > > is being applied to a packet that never exists on the wire, but only inside the PSP node. > > Regards > Brian Carpenter > > On 13-Aug-20 00:55, The IESG wrote: >> >> The IESG has received a request from the Source Packet Routing in >> Networking WG (spring) to consider the following document: - 'SRv6 Network Programming' >> as Proposed >> Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2020-08-26. Exceptionally, >> comments may be sent to iesg@ietf.org instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The SRv6 Network Programming framework enables a network operator or >> an application to specify a packet processing program by encoding a >> sequence of instructions in the IPv6 packet header. >> >> Each instruction is implemented on one or several nodes in the >> network and identified by an SRv6 Segment Identifier in the packet. >> >> This document defines the SRv6 Network Programming concept and >> specifies the base set of SRv6 behaviors that enables the creation of >> interoperable overlays with underlay optimization (Service Level >> Agreements). >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-progra >> mming/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> https://datatracker.ietf.org/ipr/3464/ >> >> >> >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > From nobody Wed Aug 26 23:56:06 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3953A0D9C for ; Wed, 26 Aug 2020 23:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=YMzZcRuI; dkim=pass (1024-bit key) header.d=juniper.net header.b=Jf+KDy0Q 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 v2hQ2WHEgM_P for ; Wed, 26 Aug 2020 23:56:02 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 3DC993A0D9D for ; Wed, 26 Aug 2020 23:56:02 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07R6pXBW025272; Wed, 26 Aug 2020 23:55:50 -0700 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 : mime-version; s=PPS1017; bh=tDp6WBkanLGL14IxK2vlySngqOqdKbhc7aro/YQupxM=; b=YMzZcRuI288iIOkcs7M6mAp6lYMwF+xUZIy+h0oJ63zeCB7lkh4hxvB2vgE2wvuuoR0O 423mmMRE/3pY64bMLO7lKieBVOlOIsGe1VvwAlhaVab2ToKaCS3CMixCU6hgjUjiOkuK FN9OVkuykW119ruNrpWtAHb3g+rLowEmiSOKnXeyaCVH+aT8GWYudVsj+J4HUeUCxE1O avXPH/RbS4476MlgUy1DoP47QUBDjNctJeo07C0fYB6kfyWVPGsGMb5q2p/NKzYwmzdV HHTiDCDqD/2kOhS7IZXMkYTn+9tdLOi0yvStXMcpHSLzGw7dIqnenqFIIVbT6BmofIvz mg== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173]) by mx0b-00273201.pphosted.com with ESMTP id 3332fy7vx3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Aug 2020 23:55:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CYPmuBsh36/bhAARt8ZXcNX+TKtTO9Pemy1q0dU9Ir87c0OpMKjg+1ibjwUbfO3G8NMQYREq3Yl6gYlB0bS+aDZIbiLRxzWnHxUSDGJRlLTApe29G9K9klpcQIZuwNvlAdR5cZI4Du+kw9Ps4cNh34nIHhJIjA/YT2TtjiUWipzv4BQJ6xsM3eRdX3LnEff9Ecn/9MdIQTA8Y2Ab49Yfj/Hyp9CUMEsRi34ZlCg+vmGD/eM+VrkoXFgdsNXUd5c4rxsWaK5OBAloX30MKLz7DXyiVMtDwpsZ+QprVEnBs+ZeAjXLuTq4VPG8G/ht6NxAOer7oT/z3stuojlyDg7jyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tDp6WBkanLGL14IxK2vlySngqOqdKbhc7aro/YQupxM=; b=RVA0QCMRsz9GrCaXFfQiW4ewfH/EskBey8WSJyHsWCa2s6vBB3jr3io10kxCFGZ053f3X20lueRutXTVBaT7Oi0LptWi74d+bV4hFPKZFww8297h0vORNYgU1QNReHHV9fpxrkRvqpcnBAwAQgtIw0zDtPGsw0nVCj7PSinvocp5UkiC0MTrcXvROhu9KRx98Hl8QpcWgkhE8+X2zSgWjAK3DjQxfXAHgtwNrruppFHFMnfuN4NplpZqWogVnjIxN4T4/RzNqwwHHodbcYYqYtuBlv6d9SmVAiXjuIyQfxSZ+U7OCK8PniJzd5kIzjw/8pN/WVRLFo5NuGSPC2mqNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tDp6WBkanLGL14IxK2vlySngqOqdKbhc7aro/YQupxM=; b=Jf+KDy0QrWBNl6dpuXA96GEXMl/DRszSZ8ReD5PHm4T3EejMkYkwWYWopM1pEm8VnsnL9mrQrVfAN7YaLqiFtdDnsaZCHsmWVMByVwx5md36oIPM/qvmCtBvR4ngUxKbgc5gB/7YD3bBJoA5P+Rw7md+JeKYhGwZ9PIOpcA2blg= Received: from MN2PR05MB6080.namprd05.prod.outlook.com (2603:10b6:208:c4::21) by MN2PR05MB6144.namprd05.prod.outlook.com (2603:10b6:208:d1::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Thu, 27 Aug 2020 06:55:48 +0000 Received: from MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::409:6521:1e51:f8f5]) by MN2PR05MB6080.namprd05.prod.outlook.com ([fe80::409:6521:1e51:f8f5%4]) with mapi id 15.20.3326.019; Thu, 27 Aug 2020 06:55:48 +0000 From: Rajesh M To: "gdawra.ietf@gmail.com" , "cfilsfil@cisco.com" , "robert@raszuk.net" , "bruno.decraene@orange.com" , "zhuangshunwan@huawei.com" , "jorge.rabadan@nokia.com" CC: "spring@ietf.org" Thread-Topic: https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 Thread-Index: AdZ4MNW2XqUqDnZ6QwCVe2fsN6tJPwEDhcRQ Date: Thu, 27 Aug 2020 06:55:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-22T03:13:26Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=558e4b75-cfc5-4de3-87d0-5beb9c66ec74; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [106.201.60.119] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8c12b5ef-0e69-4225-0c17-08d84a563a85 x-ms-traffictypediagnostic: MN2PR05MB6144: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sKIErEPsIPIsij5SUQvVbApGnqQRYDPQQa7kW8DkFRR+2Q8lSjn7UVw7ZiqlFkAJ5PEdYBVlJZx3AhojxT5uhoOxwxafnNzfCyXlZXTNThMqGjPQnbP9xinTqAqyu53NgCiQ2VUfX14mf00JIRmih1yrH6v/ZInQRKR5AcdxThUz2JfsYwdkqr6hj4OQUWxuYgS50EtlIGkolZedJDVWdP6VYKaoybx1DFkYtYTv+YSUAaeziZf9wGjPIvIWEbl6fo4WYa0uml2IxnCOZYVP1IqARqKlF5Y+ccDrqSob2WK1FfRucjb1oPezpzRyY7GS74b61zylOutsF2WGrEGfi9v/0Edj4H8FWuPDtBrt3rjV8Y3Y86ULZYTEHOIrQruJbxYg8Q+mO9WhcfUZ5eks3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6080.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(396003)(366004)(376002)(39860400002)(64756008)(52536014)(4326008)(478600001)(71200400001)(4744005)(5660300002)(9686003)(76116006)(66476007)(86362001)(966005)(66946007)(2906002)(66446008)(33656002)(66556008)(8676002)(166002)(6506007)(26005)(8936002)(110136005)(55016002)(7696005)(316002)(55236004)(53546011)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: WGkHQt7lMcDwS66n4bMsNqa1ML7O+ssusslNijPHEFLxPu8M+6jsDew5QV+/GGAyHVZVfWaJ+3maW8FdKNc4zRkyp7hEsvAYjMV8krhjrmcLbqDKfaFUMjE1u0yuY09RquUeLqoxTaVnsb/K+8CU9eUq18ZS8eyVcA8IUQ1zWoghuJnsnDRk5Dvj2rTUYKn5jO1yhxp3pye5OGDiiWicLthc1c1LE/uXTtDBqgHhDdaK8Nnn0fwrymbAMKQkk2Ee/Bcsc28ylS1W1XVX+ZcEdWbTCPbgjVMVi1r2uUMf/+EKiYVbq/kZ82RdCFhtSieU5mfWpm6cmLOnYLuCaesT3ceSRWBo8HTkiIrzcQa3jijr+UPrOoNpS0eX7ckPR7FQxgYaFCQOYox/+g5VSbmvNmCHwI7oXNlfSzGjLJV4TEoTX+v8/qP/JeDzl8wViYwuE4GdLtsf4abUAoYY6AbCn8h9AYKeIWCvrhJkrqH7+oYdfLXqQaFRc7SYUCDYpu5MwekgKkUPu6WWlkqfED9ewRURNigRJiv8u6/NaHcjBwdy9cLMaNFTjuxGZCbYOq82Uw0Pe+Y4a1pnH6xcg7LF+RyXFGWezVcGTG4uGq2dCP1a55QtjFeRyYvFPSXhCEjvu9YZioEF9a8ZHuXphSDnpQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR05MB6080D843FBEC506FEE4CAFC6BE550MN2PR05MB6080namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6080.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c12b5ef-0e69-4225-0c17-08d84a563a85 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 06:55:48.1556 (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-CrossTenant-userprincipalname: edoURyuu5BhnJDmk1nUGMNBUZYp3at3udZJS9/QqFo4iwn7QGQ251yekqrAnYljjwwGfgcuGsEPuKkzBmkV7LA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_02:2020-08-27, 2020-08-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 malwarescore=0 adultscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 spamscore=0 clxscore=1015 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008270053 Archived-At: Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 06:56:04 -0000 --_000_MN2PR05MB6080D843FBEC506FEE4CAFC6BE550MN2PR05MB6080namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sending it again. Juniper Business Use Only From: spring On Behalf Of Rajesh M Sent: Saturday, August 22, 2020 8:43 AM To: gdawra.ietf@gmail.com; cfilsfil@cisco.com; robert@raszuk.net; bruno.dec= raene@orange.com; zhuangshunwan@huawei.com; jorge.rabadan@nokia.com Cc: spring@ietf.org Subject: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services= -04 [External Email. Be cautious of content] 5. BGP based L3 service over SRv6 When the egress PE sets the next-hop to a value that is not covered by the = SRv6 Locator from which the SRv6 Service SID is allocated, then the ingress PE SHOULD perform reachability check for the SRv6 Service = SID in addition to the BGP next-hop reachability procedures. I think we should mention, few points for egress side a) Recommended to set the bgp nexthop based upon locator. b) All the service SIDs across vrfs(DT4,DT6...) must be derived from the sa= me locator (this is independent of setting bgp nexthop) Juniper Business Use Only --_000_MN2PR05MB6080D843FBEC506FEE4CAFC6BE550MN2PR05MB6080namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Sending it again.

     

     

    Juniper Business Use Only

    From: spring <spring-bounces@ietf.org> = On Behalf Of Rajesh M
    Sent: Saturday, August 22, 2020 8:43 AM
    To: gdawra.ietf@gmail.com; cfilsfil@cisco.com; robert@raszuk.net; br= uno.decraene@orange.com; zhuangshunwan@huawei.com; jorge.rabadan@nokia.com<= br> Cc: spring@ietf.org
    Subject: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-s= ervices-04

     

    <= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

     

    5.  BGP based L3 service over SRv6

    When the egress PE sets the next-hop to a value that= is not covered by the SRv6 Locator from which the SRv6 Service SID is allo= cated,

    then the ingress PE SHOULD perform reachability chec= k for the SRv6 Service SID in addition to the BGP next-hop reachability pro= cedures.

     

     

    I think we should mention, few points for egress side=

    a) Recommended to set the bgp nexthop based upon locator.<= o:p>

    b) All the service SIDs across vrfs(DT4,DT6...) must be de= rived from the same locator (this is independent of setting bgp nexthop)

     

    Juniper Business Use Only

    --_000_MN2PR05MB6080D843FBEC506FEE4CAFC6BE550MN2PR05MB6080namp_-- From nobody Thu Aug 27 00:06:36 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30383A0DDB for ; Thu, 27 Aug 2020 00:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WWZQl5ZK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pHYEqsR6 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 6tYEFneLp7Ug for ; Thu, 27 Aug 2020 00:06:31 -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 C8BAD3A0DCA for ; Thu, 27 Aug 2020 00:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11405; q=dns/txt; s=iport; t=1598511990; x=1599721590; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PfyzmFPk8xez6LC/E7fVJP4pv+R0B9mD9nUZrRL2OP4=; b=WWZQl5ZKVUuNPj0d2QNOqGe0CvDR3qBPVlFbW1LyWbKE5GpHuRA15Rcm 8doZ/MVzNfynrNPNTGZZY5P3vKuB4TMTixBF5bznGKGdU4Bv27Y3vRX3i GbbhfW/GI6IAzQD6kmx7Jvw0RxnkbJ97bdzEORErfI3RkNW+by0xajdpc g=; IronPort-PHdr: =?us-ascii?q?9a23=3Ab6ufpR0kGTJO50R5smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFuadhiVbTVsPa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXyYlTIqTuz4CIcXB?= =?us-ascii?q?LlOlk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAABnWkdf/4QNJK1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTgFAQELAYEiLyMuB3AOSi8sCodzA41oiguJeIRugS4UgRE?= =?us-ascii?q?DVQsBAQEMAQEeDwIEAQGETAKCOAIkNgcOAgMBAQsBAQUBAQECAQYEbYVcDIV?= =?us-ascii?q?yAQEBBBIbEwEBNwEPAgEIEQQBASgHIREUCQgBAQQBDQUIGoMFgX5NAy0BAQ6?= =?us-ascii?q?nDgKBOYhhdIE0gwEBAQWBNwKDaA0LghADBoE4AYJwhGeFTRuBQT+BVIJNPoI?= =?us-ascii?q?aQgEBA4EnARIBIysJgxSCLY94gRSIa4tlkClRCoJjiGaMRIUkgweJZ5Eugii?= =?us-ascii?q?Fc4xYikqCZpIaAgQCBAUCDgEBBYFbDSZncHAVgyQJRxcCDY4fDBcsgyKFFIU?= =?us-ascii?q?JATh0AjUCBgoBAQMJfI8cAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,358,1592870400"; d="scan'208,217";a="532504326" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 07:06:28 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 07R76SFn004411 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2020 07:06:28 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 02:06:28 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 03:06:27 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 27 Aug 2020 02:06:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MhfLDq7cCN+SnHaDLTjsQsTtGcPgRHxVdsIH0XsSBaWCw9rSlzt9RK2IfoJXx1rkaRnxvxoFuBAaNzYN0R+dFWg1SXNk1/kSBI/s8b+gi44XtK45IYy4C2EyBPXy5wwkzVp5FIBo0aLeuaNaq5Ik/3GJ0/9g6nZYuYVNqt2GvlY/qnEvdqsbX48TSDUe56PpvfUMlgPchyS8SmCT/qP0UzNRAZTGAGHFD09nKg3gPofiE46584GWPgh4+tfhUc+76+haM1l9dRpzeePyNBU53gRsbVWWdnx20oZaaE3uxGv15CCoLMNmkzT75ljjjKrNMw23XubkYFHEXpbehwYbyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3MvbLW5gO3nFhG5TdQ/c8Utom0u6ILqtNCxJ69XEf/g=; b=JunCksUuiRgxuJ3NLuRIBTUoYZrtqlbYkQ5oH29cSDxe9XREshHjfcxJjvMOZG+S17No+OzSnKha6ptZ71aYcXrbhQdJOmUD+FT4KuX+92UH5kYWBmiahK/XWgeBv+OThTy5OjLiXYPdpO1G6FUSLfVIWicIaK2pA+Q3VJoOyc5J8ptmCK9BU2qYanS3NaU4OfVVHONx1plwKEJCaGeU1cKM4lUKA7wuGHAkzbKcHJkfE3k5NUHjmePUuwVW4sLqhtYU83oLJgmhsbEQr4+PLB21kEElYZOOp7NX5q0eZC1Vs+nThWZRfq1c807xD5Bq67fCDRzMYW6Hg/CzZZUhgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3MvbLW5gO3nFhG5TdQ/c8Utom0u6ILqtNCxJ69XEf/g=; b=pHYEqsR6OVjs6x78YaIH3s39K+TMyyZu6zIwsSZ6SvHjJE71eP8Df1Ghq4xZizezhn+Ygr4ehBuUEtf0vbpDU/mCWVzc/O2qJynWJLwkJTDbNFD35RxpVCQI37tEeqnJyBRVTUfDdkLD312EQlO2yOooOGUoL7foUgn+KLtvV/M= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4715.namprd11.prod.outlook.com (2603:10b6:303:57::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Thu, 27 Aug 2020 07:06:26 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135%8]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 07:06:26 +0000 From: "Ketan Talaulikar (ketant)" To: Rajesh M , "gdawra.ietf@gmail.com" , "Clarence Filsfils (cfilsfil)" , "robert@raszuk.net" , "bruno.decraene@orange.com" , "zhuangshunwan@huawei.com" , "jorge.rabadan@nokia.com" CC: "spring@ietf.org" Thread-Topic: https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 Thread-Index: AdZ4MNW2XqUqDnZ6QwCVe2fsN6tJPwEDhcRQAAA2K+A= Date: Thu, 27 Aug 2020 07:06:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-22T03:13:26Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=558e4b75-cfc5-4de3-87d0-5beb9c66ec74; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [49.36.37.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 165b05a5-182f-4a70-de1a-08d84a57b6e8 x-ms-traffictypediagnostic: MW3PR11MB4715: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aaLhAqiLAWmLvxVrbTcYM/NiAEEN1hp9/IpQY8SeXP0UXl4a16ezlahRcSsusZXkXCSLK9q0AokctKQNT8SaYqttcBgOr3vmQugbx1KFEQufW49ASqW/szUi27yWXp3xzSQQR+AOPiP9cvihHWbpZexRgedf687Me9qNAUzj16uDpFqmur3RrIyY4659uj06KAVOR+jZ+6nw5ozASlk3Co5MYsa+igNkhrxSkXBJPSS7w0Tfg5w4T+atMPxcbNQKSewK7XL8Ssl6veagJodYhWRgV+hob7+3uWycEfZZr7GgiLrCYa664hlZW/NhTSCaLKUOuwuGr1jIfJkhvN9y7b8xtGCz7ArDkIY1erP4dzf8LpgoAyAw1lxU8hDOtVi0G8T8WYpOtrkCMx4KqJW6sg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(346002)(39860400002)(366004)(9326002)(316002)(186003)(71200400001)(8676002)(53546011)(8936002)(26005)(33656002)(7696005)(83380400001)(2906002)(166002)(966005)(66556008)(64756008)(66446008)(66946007)(76116006)(66476007)(86362001)(110136005)(478600001)(55016002)(5660300002)(52536014)(9686003)(6506007)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: pwS7fm9bGhsq++Fcx/+X+HKuUOBAZRIpX9V7iKCWYkc/Wbil8qSwwO6NlgfmcBSFNW2Hq5a410Os7BqE5wS8JewKJytPgdUofzBUv25tOhOxn7p+p4eShtQ6TKDyXUCjMhfrjUYA2Ax2SjTfryMNkdABwsXYJ1NvfN7JIfHmvoMO3x0G/d4pjOxD4vDKhMDxWtpaC/svAhXTmDiCYWcjLCQc5Huq51s3umluZpaKawOqxdHuqr7zo0GZP2W8rklIUB+MRD/RfdOG4Q07gk4g0gJ61gaRNl0Xhyjh3DFC6nD5Og2vbFQzI6LCH9h+Ne9BXd7/r5oSDhOvJMNeWa0MruEr9qm1/rIfdnFTeaoh3oaIXGLrbPKRv9EUGc4SJb4ldEKZq6PcE+nx019uaKFRV/5q1x4PcR0329C2yNZodKvgtcQpER99y+Q1aHDZ6iBtiWRdSRFIo2SYctWGJPxyaMiYtf8VI3FDXQXJJ5fkTODFVJGm0/H+P0/q7w01iu3SXuG8og9jCNzUowWrEwczlH/QFAr9739aHXZfu/Z2v/6FHi1Ecp7FrVsgnC/qWgftpx9URMR3L/D+GGdr20WgUDgNLUg6iFTk19/6sHewIO8TIJmSX8J8rZq06hHbLNz8DFjLzUn3d9Kbj7cjis4eFw== Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570898FAD75110DAD5C46F6C1550MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 165b05a5-182f-4a70-de1a-08d84a57b6e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 07:06:26.2806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 31hp93JWVPuEYj1otyzRJ8qsMajv/oyvuPnBjcX6iEv5bMIiUy7QjNzqGX2hnEeu0XoVivOEU2qWmmA0/tUD/w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4715 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 07:06:35 -0000 --_000_MW3PR11MB4570898FAD75110DAD5C46F6C1550MW3PR11MB4570namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rajesh, Please check inline below. From: spring On Behalf Of Rajesh M Sent: 27 August 2020 12:26 To: gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) ; robert@raszuk.net; bruno.decraene@orange.com; zhuangshunwan@huawei.com; = jorge.rabadan@nokia.com Cc: spring@ietf.org Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-serv= ices-04 Sending it again. Juniper Business Use Only From: spring > On B= ehalf Of Rajesh M Sent: Saturday, August 22, 2020 8:43 AM To: gdawra.ietf@gmail.com; cfilsfil@cisco.com= ; robert@raszuk.net; b= runo.decraene@orange.com; zhuangshunwan@h= uawei.com; jorge.rabadan@nokia.com Cc: spring@ietf.org Subject: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services= -04 [External Email. Be cautious of content] 5. BGP based L3 service over SRv6 When the egress PE sets the next-hop to a value that is not covered by the = SRv6 Locator from which the SRv6 Service SID is allocated, then the ingress PE SHOULD perform reachability check for the SRv6 Service = SID in addition to the BGP next-hop reachability procedures. I think we should mention, few points for egress side a) Recommended to set the bgp nexthop based upon locator. [KT] I would think that it is difficult to normatively recommend such a thi= ng in the spec. There would be implementation and deployment design aspects= to be considered. b) All the service SIDs across vrfs(DT4,DT6...) must be derived from the sa= me locator (this is independent of setting bgp nexthop) [KT] I am not sure such a restriction is required and in fact would be seve= rely limiting in nature. Consider that some service may wish to leverage a = FlexAlgo based on delay metric computation to get from the ingress to egres= s PE. In such cases, the egress PE can allocate the SRv6 SID for that servi= ce from its FlexAlgo specific locator. Thanks, Ketan Juniper Business Use Only --_000_MW3PR11MB4570898FAD75110DAD5C46F6C1550MW3PR11MB4570namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Rajesh= ,

    &nbs= p;

    Please ch= eck inline below.

    &nbs= p;

    From: spring <spring-bounces@ietf.org> On Behalf Of Rajesh M
    Sent: 27 August 2020 12:26
    To: gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <cfilsfil= @cisco.com>; robert@raszuk.net; bruno.decraene@orange.com; zhuangshunwan= @huawei.com; jorge.rabadan@nokia.com
    Cc: spring@ietf.org
    Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-sr= v6-services-04

     

    Sending it again.

     

     

    Juniper Business= Use Only

     

    <= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Lato;color:black"= >[External Email. Be cautious of content]

     

    5.  BGP based L3 service over SRv6

    When the egress PE sets the nex= t-hop to a value that is not covered by the SRv6 Locator from which the SRv= 6 Service SID is allocated,

    then the ingress PE SHOULD perf= orm reachability check for the SRv6 Service SID in addition to the BGP next= -hop reachability procedures.

     

     

    I think we shou= ld mention, few points for egress side

    a) Recommended to set the bgp nexthop based= upon locator.

     

    [KT] I would think that i= t is difficult to normatively recommend such a thing in the spec. There wou= ld be implementation and deployment design aspects to be considered.

     

    b) All the service SIDs across vrfs(DT4,DT6= ...) must be derived from the same locator (this is independent of setting = bgp nexthop)

    [KT] I am not sure such a= restriction is required and in fact would be severely limiting in nature. = Consider that some service may wish to leverage a FlexAlgo based on delay m= etric computation to get from the ingress to egress PE. In such cases, the egress PE can allocate the SRv6 SID for t= hat service from its FlexAlgo specific locator.

     <= /i>

    Thanks,=

    Ketan

     

    Juniper Business= Use Only

    --_000_MW3PR11MB4570898FAD75110DAD5C46F6C1550MW3PR11MB4570namp_-- From nobody Thu Aug 27 00:49:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF9F3A0E2C for ; Thu, 27 Aug 2020 00:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 IVNA2jW6JKZo for ; Thu, 27 Aug 2020 00:49:24 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2131.outbound.protection.outlook.com [40.107.223.131]) (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 6A1173A0E2E for ; Thu, 27 Aug 2020 00:49:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DGLZBWLsqws9ZmbZJkV9klNdpHjYw93FWLEw5j/nuplrl8ln7g8lRAzzS2R2rrREfHuRHLdlnuSfFQpqgSjbFk8bAyS7MZKk26PZEzdrkDrGT2FtVDkomEjEf5Q0ixs7FQc2m8TIMpBHazBuxZ9TDLBPE3m3t8Drc8YZYtLuWUh1JjMDdNCXSKJF4ZizWeQ/vogZVo1E9J30tvcMFPsg0uMHxs47yhfE4zQNCIdFsvVzURafoVuilm3HRLTFuDWGfjShe+3UCISvu35PTamRFMOwMYOK2c6zUKtBdebi+25NEOs4daPRhh9yMMbyAzWruaYqR8of28E/k4qEHipc0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D8CnLnUtWaKtx2MaiB4WkU68ea3jfRHjWW7xfS7l9IA=; b=AYBaSZQbqd82dvyfHnRnaAW4XfvxjQv9Goq9ug6WxefUMpP3a+k0N/oz4zU48tyvQiZF7CT2+7UwELUsEtOuwlg0T9AMO0X5aWCfHVI9OysHiyvnye5o/SkjXbeaA8bDLEZhOzQvagVGDy4ZFkjnWg5FQARGt6H/O56gRdvM0V2AuCT1beCA2jS9SkeuOdvOXllyTHHq3p9c45kQ/hd6jo8EZkqlpUP9vkrYq1Sg9TPzeCFpbAIpyL/HYYijeHxze2c7vPoIswJbPt6oUjgrBFZDPohDhi3VEqKk6qixVuJzrayWa3cCmYD8gMzcdDgm1f9nEnQ025f4yHmXZBwMtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D8CnLnUtWaKtx2MaiB4WkU68ea3jfRHjWW7xfS7l9IA=; b=vbif2DxE3Jf1VkpsYbYW3Hpt2bDILfqJIMz3ywLY9dZHvRDwwg5fBdpvbgVLy2UlwbC29Ey4sjPdfEy8aR+FRapHM3Ikm5ILu4zKpEiV+UKfkFzSHGIbxuaJRIJEv7Lhy7d80aLKALfvArur9LmXHYiXH1wUJrlQVlzpk/IUSUw= Received: from MWHPR08MB3520.namprd08.prod.outlook.com (2603:10b6:301:61::15) by MWHPR08MB2798.namprd08.prod.outlook.com (2603:10b6:300:cc::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25; Thu, 27 Aug 2020 07:49:21 +0000 Received: from MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::19d8:bf7f:5bfa:e391]) by MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::19d8:bf7f:5bfa:e391%4]) with mapi id 15.20.3305.024; Thu, 27 Aug 2020 07:49:21 +0000 From: "Rabadan, Jorge (Nokia - US/Mountain View)" To: "Ketan Talaulikar (ketant)" , Rajesh M , "gdawra.ietf@gmail.com" , "Clarence Filsfils (cfilsfil)" , "robert@raszuk.net" , "bruno.decraene@orange.com" , "zhuangshunwan@huawei.com" CC: "spring@ietf.org" Thread-Topic: https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 Thread-Index: AdZ4MNW2XqUqDnZ6QwCVe2fsN6tJPwEDhcRQAAA2K+AAAHbN6A== Date: Thu, 27 Aug 2020 07:49:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-22T03:13:26.0000000Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.5] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0f2d95f0-7631-4733-4977-08d84a5db5ee x-ms-traffictypediagnostic: MWHPR08MB2798: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SJW0czTitb3+pV7N3slKgDk/VQ4fnJCFSXPo8H/9Gk69z6YkjjImt24QYycJEMO7X+Lbh0IxDn9inbZ+g3Uzwsk96jaPYqYahbpQWFTIuycZtvh0JsPAYIaKVsIqM3adaftJQVs1f+n34XFCiV2ywAAk042RTr0B5YLRVU+G4UN20i2qlK48X+/mtee64WUaWZl0CsyrlJmUnVCvR7TZU8EF0nUR7ilIn8Xx1xHgEuyBYvwe0c3LX3aRG9XkohWMdkMgWoEWc9Rf6rPJfVsAJbtJvU+t9vcuWSQ0+ALrDvDe7bCd+/odPqhRYim17goRu49INh65+H2bo7JmUfl8MrQI3vw2bqZFnNmrDlKkUoXn+uZANhdKA0JDb1e6nlJNcK2HnlOkW/fnmpUHBIpc9w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR08MB3520.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(39860400002)(376002)(346002)(66476007)(7696005)(9686003)(166002)(8676002)(86362001)(186003)(110136005)(71200400001)(8936002)(55016002)(64756008)(6506007)(83380400001)(316002)(33656002)(66446008)(478600001)(66556008)(52536014)(2906002)(76116006)(4326008)(966005)(66574015)(9326002)(5660300002)(26005)(53546011)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2C0IDRBveHM00x6kxDrH9GWLOL5LLxL+IWlzWhMGaICjSDa72MJODrQz/O1cTcwK+6XJv8UFIpsuuqanPxeKL2M1cpQrX7lJcZAE47Zi/K5brYpjD3eZvui4018xTjOeb3w4/7QrxQKaj6Xd6Iy3ISiimc/1nFfcvPz1FonKeZbgpXyrlmfYq/0V5X8A5PPBVZPRnZ+Viu8VykhwOnX8qQNykAx/SrlOrogOoO5cYuGBiOHXuQ2/7rcppQnoTuIsE3995SUCsGov7fARj4c1tX4xPiSbKTKUhtE2el1MRSbHyvYjBLqgA25CRPbMxjZ//nzQfh8yxQcpXHYpndVlC9sFiyMnLelXrlU4j/6wWdUa+WcpefNjdVTi/rAkOxUApcED6KQH/5YLWGEHwt5tATzmB2vttoaCGMsRsEZsMpyL8kgtZGUlTqlTYerTYzcuoZIGbPikxXPjHZdTai4cGMBuihBy/cqgtltfs5dd4zjzegYybi0F/562rcmcGH09IOhEzk6WPMHm68sNi31FRUjSts/ZOP906n/W7BM2xhd4p9AumNd4fxnPFhAMiuP/26OSVo7lUEnix2CLqpvAI/NyAE+BrXb2CxeqlY1CrHhHnUydRBQdFV5u3ZkATfbebNkDwNDztqyAlwYSzqrGBQ== Content-Type: multipart/alternative; boundary="_000_MWHPR08MB35202A36EBB5D7A3E6CE8E08F7550MWHPR08MB3520namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR08MB3520.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f2d95f0-7631-4733-4977-08d84a5db5ee X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 07:49:21.5392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7NAqWjHZXDauaW7a8VzlBxXS9wfro9bKq6vtQP1yGWi3HVzMAJipaEnI1afpbyU5bQurqPoBK/2VsTYtlgX2+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2798 Archived-At: Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 07:49:26 -0000 --_000_MWHPR08MB35202A36EBB5D7A3E6CE8E08F7550MWHPR08MB3520namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I fully agree with Ketan. For (a), it is obvious that if the next-hop and locator belong to the same = prefix, we minimize the prefixes to be advertised, hence we=92ll have small= er route tables. But it is up to the user to decide that. The spec should s= upport both. Similar for (b). There may be multiple locators on the same router. Thanks. Jorge From: Ketan Talaulikar (ketant) Date: Thursday, August 27, 2020 at 9:06 AM To: Rajesh M , gdawra.ietf@gmail.co= m , Clarence Filsfils (cfilsfil) , robert@raszuk.net , bruno.decraene@orange.com , zhuangshunwan@huawei.com , = Rabadan, Jorge (Nokia - US/Mountain View) Cc: spring@ietf.org Subject: RE: https://tools.ietf.org/html/draft-ietf-bess-srv6-services-04 Hi Rajesh, Please check inline below. From: spring On Behalf Of Rajesh M Sent: 27 August 2020 12:26 To: gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) ; robert@raszuk.net; bruno.decraene@orange.com; zhuangshunwan@huawei.com; = jorge.rabadan@nokia.com Cc: spring@ietf.org Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-serv= ices-04 Sending it again. Juniper Business Use Only From: spring > On B= ehalf Of Rajesh M Sent: Saturday, August 22, 2020 8:43 AM To: gdawra.ietf@gmail.com; cfilsfil@cisco.com= ; robert@raszuk.net; b= runo.decraene@orange.com; zhuangshunwan@h= uawei.com; jorge.rabadan@nokia.com Cc: spring@ietf.org Subject: [spring] https://tools.ietf.org/html/draft-ietf-bess-srv6-services= -04 [External Email. Be cautious of content] 5. BGP based L3 service over SRv6 When the egress PE sets the next-hop to a value that is not covered by the = SRv6 Locator from which the SRv6 Service SID is allocated, then the ingress PE SHOULD perform reachability check for the SRv6 Service = SID in addition to the BGP next-hop reachability procedures. I think we should mention, few points for egress side a) Recommended to set the bgp nexthop based upon locator. [KT] I would think that it is difficult to normatively recommend such a thi= ng in the spec. There would be implementation and deployment design aspects= to be considered. b) All the service SIDs across vrfs(DT4,DT6...) must be derived from the sa= me locator (this is independent of setting bgp nexthop) [KT] I am not sure such a restriction is required and in fact would be seve= rely limiting in nature. Consider that some service may wish to leverage a = FlexAlgo based on delay metric computation to get from the ingress to egres= s PE. In such cases, the egress PE can allocate the SRv6 SID for that servi= ce from its FlexAlgo specific locator. Thanks, Ketan Juniper Business Use Only --_000_MWHPR08MB35202A36EBB5D7A3E6CE8E08F7550MWHPR08MB3520namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi,

     

    I fully agree with Ketan.

    For (a), it is obvious that if the next-hop and locator belong to the sam= e prefix, we minimize the prefixes to be advertised, hence we=92ll have sma= ller route tables. But it is up to the user to decide that. The spec should support both.

     

    Similar for (b). There may be multiple locators on the same router.<= /o:p>

     

    Thanks.

    Jorge

     

    From: Ketan Talaulikar (ketant) <ketant@cis= co.com>
    Date: Thursday, August 27, 2020 at 9:06 AM
    To: Rajesh M <mrajesh=3D40juniper.net@dmarc.ietf.org>, gdawra.= ietf@gmail.com <gdawra.ietf@gmail.com>, Clarence Filsfils (cfilsfil) = <cfilsfil@cisco.com>, robert@raszuk.net <robert@raszuk.net>, br= uno.decraene@orange.com <bruno.decraene@orange.com>, zhuangshunwan@hu= awei.com <zhuangshunwan@huawei.com>, Rabadan, Jorge (Nokia - US/Mountain View= ) <jorge.rabadan@nokia.com>
    Cc: spring@ietf.org <spring@ietf.org>
    Subject: RE: https://tools.ietf.org/html/draft-ietf-bess-srv6-servic= es-04

    Hi Rajesh,

     

    Please check inline bel= ow.

     

    From: spring <= ;spring-bounces@ietf.org> On Behalf Of Rajesh M
    Sent: 27 August 2020 12:26
    To: gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <cfilsfil= @cisco.com>; robert@raszuk.net; bruno.decraene@orange.com; zhuangshunwan= @huawei.com; jorge.rabadan@nokia.com
    Cc: spring@ietf.org
    Subject: Re: [spring] https://tools.ietf.org/html/draft-ietf-bess-sr= v6-services-04

     

    Sending it again.<= /o:p>

     

     

    Juniper Business Use Only

     

    [External = Email. Be cautious of content]

     

    5.&nb= sp; BGP based L3 service over SRv6

    When the egress PE sets= the next-hop to a value that is not covered by the SRv6 Locator from which= the SRv6 Service SID is allocated,

    then the ingress PE SHO= ULD perform reachability check for the SRv6 Service SID in addition to the = BGP next-hop reachability procedures.

     

     

    I think we should mention, few points for egress side

    a) Recommended to set the bgp= nexthop based upon locator.

     

    [KT] I would thin= k that it is difficult to normatively recommend such a thing in the spec. T= here would be implementation and deployment design aspects to be considered= .

     

    b) All the service SIDs acros= s vrfs(DT4,DT6...) must be derived from the same locator (this is independe= nt of setting bgp nexthop)

    [KT] I am not sur= e such a restriction is required and in fact would be severely limiting in = nature. Consider that some service may wish to leverage a FlexAlgo based on= delay metric computation to get from the ingress to egress PE. In such cases, the egress PE can allocate the SR= v6 SID for that service from its FlexAlgo specific locator.

     

    Thanks,

    Ketan

     

    Juniper Business Use Only

    --_000_MWHPR08MB35202A36EBB5D7A3E6CE8E08F7550MWHPR08MB3520namp_-- From nobody Thu Aug 27 03:35:04 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2B43A0B3C for ; Thu, 27 Aug 2020 03:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=lab.dtag.de 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 yRSwHj52W4xx for ; Thu, 27 Aug 2020 03:34:59 -0700 (PDT) Received: from OldBailey.lab.dtag.de (OldBailey.lab.DTAG.DE [194.25.1.220]) (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 CC2F03A0AB2 for ; Thu, 27 Aug 2020 03:34:58 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id E7418C12DD for ; Thu, 27 Aug 2020 12:34:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1598524481; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=tjjyU15Lh0wO45M6o9aFhUmjfg4GCNlzCL6qXAGd5M4=; b=nLGbEJqdUvHddkW+8omOeHhAJfVRkfImsTPnDQzRByKfcM+eGEhdQRlY0F6kDaNImC0n7F t//sInuBuxpIgd7LIJ0AKqP6CHuBapVpIoSoJJ7jVr3DZaTKWNqdVVmV58eYTAIysjxEV5 jHbxDrkzZJSxOsbq1k5jrVuHCNXKlwwmx3tkN+H1gRbuA9vGZF97DWAc+z5Y6DFnWJ3/cL p2YTNS/0vmy0WCM4rrFiJLWd59cTxS1kEhQ1M+/K7C2zyknc7xZPnP595LYguaZqetw4IS /pmtLllNwor0HPWmGvBSuHp7kcp+RsDP3LQxbyE6/TygTtUywgt7O/EaUwY5EQ== To: spring@ietf.org References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> From: Martin Horneffer Message-ID: <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> Date: Thu, 27 Aug 2020 12:34:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 Archived-At: Subject: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 10:35:03 -0000 Hello everyone, may I come back the the question below? Or rather let me update it a little: In case an SR-MPLS path is broken, should a node rather drop the packet, or forward it? This can happen whenever the IGP points to a certain next hop, but that neither supplies a valid SID, nor allows LDP-stitching for whatever reason. For PUSH as well as for CONTINUE. We have been using MPLS transport and a BGP free core since about two decades now, using LDP. In the analog case, LDP creates "unlabelled" entries in the LFIB, does the equivalent of a POP operation and forwards the packet to the next-hop as chosen by the IGP. This behavior obviously breaks any traffic that relies on a service label, but it can protect some traffic. In our case a huge percentage of all traffic still is public IPv4. This needs MPLS only for a transport label, be it LDP or SR-MPLS. If this traffic gets forwarded unlabelled, it follows an IGP default route to a central device, where it is 1) redirected to the correct destination and 2) counted in a way that operators can quickly see whether and where this kind of failure occurs at some point in the network. After more operational experience and several internal discussions we agreed that we want packets to be forwarded unlabelled rather than dropped. Anyone to share, or oppose this position? Best regards, Martin Am 31.01.20 um 16:50 schrieb Martin Horneffer: > Hello everyone, > > again it seems the interesting questions only show up when applying > something to the live network... > > We ran into something that poses a question related to RFC8660: What > is the exact meaning of section 2.10.1, "Forwarding for PUSH and > CONTINUE of Global SIDs", when the chosen neighbor doesn't provide a > valid MPLS path? > > The relevant sections reads: > >       -  Else, if there are other usable next hops, use them to forward >          the incoming packet.  The method by which the router "R0" >          decides on the possibility of using other next hops is beyond >          the scope of this document.  For example, the MCC on "R0" may >          chose the send an IPv4 packet without pushing any label to >          another next hop. > > Does the part "send an IPv4 packet without pushing any label" apply to > PUSH and CONTINUE, or just to PUSH? > Does R0 have to validate that neighbor N can correctly process to > packet? Or can it forward the packet regardless? > > The reason for asking is that we are now seeing issues similar to ones > we had when starting with LDP based MPLS about two decades ago: > traffic being black holed even though a path to the destination > exists, because the MPLS path is interrupted somewhere in the middle. > > With LDP we know the case of LFIBentries called "unlabelled". While > this does break connectivity for many kinds of service, e.g. those > relying on an additional service labels, it still works for plain > IP(v4) traffic. In our cases, this works perfectly fine for all > internal routing and control traffic. And even for IPv4 traffic that > gets collected by a central router that injects a default route. > > However, depending on the exact interpretation of the above paragraph, > an implementor might feel obliged to chose the next paragraph: > >       -  Otherwise, drop the packet. > > Which is, at least in our case, very unfortunate... > > Any advice or opinion appreciated! > > > Best regards, Martin > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Aug 27 04:10:38 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EA03A0BA0 for ; Thu, 27 Aug 2020 04:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ULw3o6eR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZL4bc/u+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHOOx324ulBr for ; Thu, 27 Aug 2020 04:10:35 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624693A0B9C for ; Thu, 27 Aug 2020 04:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5650; q=dns/txt; s=iport; t=1598526635; x=1599736235; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8M5AXYFve5PKPkQO8P1iN0Z1kMAj/OLOh+Kq5S1hp9c=; b=ULw3o6eRjc3SwfzJTUT9sRQJjlqh7rTx/1g6ycLhGpJwHz1eVRKDi6bc 79KuLTqtBgG3TSrKvuLdAJkj3bY7RpTp6eOw9tUDiJyYLrzL6SQElf8RY wXhdWcmcN+B+f+Js2kAmPWEaY5ZGt6y0vAKAJGig7eqTHpr2O/K7egPYu M=; IronPort-PHdr: =?us-ascii?q?9a23=3Am7n1ox0woOthoBI/smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGtadphVWPUZnS5LRIhrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtREcy4a0HbrTu+4G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVGgBblEdf/4kNJK1gHAEBATwBAQQ?= =?us-ascii?q?EAQECAQEHAQEVgUoCgTwCEikoB3BYLywKhC2DRgONaphxgS6BJQNVCwEBAQw?= =?us-ascii?q?BARgLCgIEAQGECEQCF4IrAiQ1CA4CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQE?= =?us-ascii?q?EAQEQEREMAQEsDAsEAgEGAg4DBAEBAwImAgICJQsVCAgCBAESCBqDBYJLAy0?= =?us-ascii?q?BAQ6WVpBoAoE5iGF2gTKDAQEBBYU3GIIQAwaBDigCAQGCb4JXS0OGTxuBQT+?= =?us-ascii?q?BEUOCTT6BBIFYAQGBYYMVM4Itj3qDF5JRj3KBCAqCY5pOgwedPpJMgW2ZNoQ?= =?us-ascii?q?oAgQCBAUCDgEBBYFWAjaBV3AVO4JpUBcCDY4rF4ECAQmCQoUUhUJ0NwIGAQk?= =?us-ascii?q?BAQMJfI0hLYEGAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,359,1592870400"; d="scan'208";a="565531482" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 11:10:34 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07RBAY0B014355 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2020 11:10:34 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 06:10:34 -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.1497.2; Thu, 27 Aug 2020 06:10:33 -0500 Received: from NAM11-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.1497.2 via Frontend Transport; Thu, 27 Aug 2020 07:10:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RpEVnzCv0iNU4wJKGMLpXM4QLaWv4Jjs1yACPMxkFP/pRjvlVjczFUJiqLUi3x08SZ0YlqdoCp9AmLDkvN+t67OywzmB9WhLigB9H7Cp3CtiNO9LL8h7342424RyJaN/Go4tgi4xeST9GPlb46s9drUZWXhDFzRHEYkzHjQmCDURnQavflKUGK9Y4KmlImhSEm+GS9Lw7yp3x2iVYP63b9vqOYgAZL1ximJKUlgN5fXRWrR8gFm6Xe46zaQgv8Q3TNynB983w9CLJVVSZSOVSRIs1kqaI6JF4CxVwqnt2R0lbh0keOaDvukE8V+nLhlS9PQVYs3lxstW8gqSb91gnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8M5AXYFve5PKPkQO8P1iN0Z1kMAj/OLOh+Kq5S1hp9c=; b=Oy3EDNfyYnG+wCZj/ueEGeUvcOEAtenkdNb7NfcNEV0mQOnEaYfYNj9MC5T6VS6im+Ak4mm394cCRfKm1xg7IGtbrULjlM2QXWLQwWUVVEBXmlG4xaQFUnKKeD1con5JarqNWFIk7dWoTIaAy1pOYrHncg2mdYIckG/PhC2/N9ZuE8k6GZQRZqTqtnyxl48OvimOI5SGAGIphLisuHXJcqRzjNFxLbxaoJlkhGqtkSunFDP0qkU5iLkChB1uGqE9OmTuyAl9uNFPAn+jUkuTKcnlIAsVnYqFXyupHktK8KeVRnDyh1T7OKT209EdjQOYkaHpRoQDCalv2V7Zlp4KfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8M5AXYFve5PKPkQO8P1iN0Z1kMAj/OLOh+Kq5S1hp9c=; b=ZL4bc/u+RyhJv2DWJWaxs+FbTjCdrVPK8rhyLk1H+bfQ78IgiDpcp7yLke84Cn6BdpoqpZHLucNmIu862s/8zAfa31jP6hi3a05DgY/fHFh2bU19qGAlQM+FIBSOpeq2v58GKVUvu7imU2gmu6i5RQNn49VeETJjQ3Kg2MEKQgc= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1838.namprd11.prod.outlook.com (2603:10b6:300:10c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 27 Aug 2020 11:10:31 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135%8]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 11:10:31 +0000 From: "Ketan Talaulikar (ketant)" To: Martin Horneffer , "spring@ietf.org" Thread-Topic: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) Thread-Index: AQHWfF3PJHPbhBOyy0eQumMBLyDp0qlLyxJA Date: Thu, 27 Aug 2020 11:10:31 +0000 Message-ID: References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> In-Reply-To: <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lab.dtag.de; dkim=none (message not signed) header.d=none;lab.dtag.de; dmarc=none action=none header.from=cisco.com; x-originating-ip: [49.36.37.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c2f7450-5d35-40aa-7c9c-08d84a79d044 x-ms-traffictypediagnostic: MWHPR11MB1838: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EGxA0+3CmkAJW+n7Vorab+dbmPILe6Hux4t4XKb9muDGYlpgTI+jAqlsNZLOY5XDQ0rhP35zBLHNy6m+nFiPUiOA4hV2w3W2CWrasXCe2IK8RPtrwbXe2yNVXbCJEVBH4gASEveE94TerEaCr3Jq2uPK8ad1LiMKCQhNAc/jbpKldKZH6Yk7Lj2jAfOC+P3eOC46Ipl5Kmk4uNq13x/NrWPNmoviSK5kQxNfSZufW3siCMZFxVU3TzNp6uqF0wQPTamGs1tBODiEwB7SVKGWok5sTu0VaIWimluEwApZouFc3n+HWPuWVaEIqrgQnaenx3rFwCBdtHdz88mLD+532YgvwlHFZN9quDgfUxkgCuwe99aD9Miq878Kpoko//Ss2V38nwDVmM580uU4OAbMUQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(346002)(39860400002)(396003)(186003)(33656002)(6506007)(53546011)(110136005)(7696005)(478600001)(316002)(966005)(8936002)(8676002)(55016002)(52536014)(5660300002)(9686003)(2906002)(66574015)(86362001)(26005)(83380400001)(66476007)(71200400001)(64756008)(76116006)(66556008)(66946007)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: SV4J01Y8sI0xgvbgPIqU79+6ZonYZsz9lIIvVN4NCTIueqppmT33dsphObqBk5WEzL9C8Q3Z8Y0/yifVFSP/htl0vnwcMav2hFNrmww7u7LtAyr+1V+kQZPrML9c/prckV6QsBaL7q1+iBgjCYV5PWRiBsQy5GIWIWgxWmxeZSvWOuP82yYmlSOdwIvlrc31FvtRcFsCkiyO7XML+LvGE/UfX8s9OdyGw1zGxW+O57uQUQYNBrua2kXW7QtrqnlIb0Khp/UMxNZbn/oyYVWuTFsU0eUWuvJeO93UTQzdTgIqUpxF7/PkCnJAiKhAQHHo1Dwn1/WApff71WR4j86VfQUqnYwgyQWAWn17IFnHDrrbSfb96rAcpEXOpSCcFBzxRoOlY7HWltwEBFH71PmOAiiH7jsUbNl3gwgcDYgotxX025F4vgnSFCaEiI57N+3f1lSbG1NO1cJqFPT+P+GaVXH8rB83mc7drXLR1wv9hVfp+JYTC5CJJVHtnwdB9ZTGmev3CpiatG1Aiglt3E5aOtMzD/S0IpzulM3Og73UsQqREEdRpWai2dv4pGz/xYJ2nT4x5Rz3CpAnHANDkWu58VrbKfLvjZUxea5/byoEy8oTiDE3MiBSszdjsvVh+oSg3dsFE2YTjI/Zp+/P1YG9XQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c2f7450-5d35-40aa-7c9c-08d84a79d044 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 11:10:31.5237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EAUmw+Jc0Lon/XDN2pExIfGxPxGMdtxH+cTf3RLihD3PgvH0tIgQzaw1y2wYJjZiD73O4Y5Kx/GP2e+Kz9SBjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1838 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 11:10:37 -0000 SGkgTWFydGluLA0KDQpJIHNoYXJlIHlvdXIgcG9zaXRpb24uDQoNClRoYW5rcywNCktldGFuDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGluIEhvcm5lZmZlcg0KU2VudDogMjcgQXVndXN0 IDIwMjAgMTY6MDUNClRvOiBzcHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFtzcHJpbmddIHRvIGRy b3Agb3IgdG8gZm9yd2FyZCB1bmxhYmVsbGVkIChSZTogUXVlc3Rpb24gb24gUkZDODY2MCkNCg0K SGVsbG8gZXZlcnlvbmUsDQoNCm1heSBJIGNvbWUgYmFjayB0aGUgdGhlIHF1ZXN0aW9uIGJlbG93 PyBPciByYXRoZXIgbGV0IG1lIHVwZGF0ZSBpdCBhIGxpdHRsZToNCg0KSW4gY2FzZSBhbiBTUi1N UExTIHBhdGggaXMgYnJva2VuLCBzaG91bGQgYSBub2RlIHJhdGhlciBkcm9wIHRoZSBwYWNrZXQs IG9yIGZvcndhcmQgaXQ/DQpUaGlzIGNhbiBoYXBwZW4gd2hlbmV2ZXIgdGhlIElHUCBwb2ludHMg dG8gYSBjZXJ0YWluIG5leHQgaG9wLCBidXQgdGhhdCBuZWl0aGVyIHN1cHBsaWVzIGEgdmFsaWQg U0lELCBub3IgYWxsb3dzIExEUC1zdGl0Y2hpbmcgZm9yIHdoYXRldmVyIHJlYXNvbi4gRm9yIFBV U0ggYXMgd2VsbCBhcyBmb3IgQ09OVElOVUUuDQoNCldlIGhhdmUgYmVlbiB1c2luZyBNUExTIHRy YW5zcG9ydCBhbmQgYSBCR1AgZnJlZSBjb3JlIHNpbmNlIGFib3V0IHR3byBkZWNhZGVzIG5vdywg dXNpbmcgTERQLiBJbiB0aGUgYW5hbG9nIGNhc2UsIExEUCBjcmVhdGVzICJ1bmxhYmVsbGVkIiAN CmVudHJpZXMgaW4gdGhlIExGSUIsIGRvZXMgdGhlIGVxdWl2YWxlbnQgb2YgYSBQT1Agb3BlcmF0 aW9uIGFuZCBmb3J3YXJkcyB0aGUgcGFja2V0IHRvIHRoZSBuZXh0LWhvcCBhcyBjaG9zZW4gYnkg dGhlIElHUC4NCg0KVGhpcyBiZWhhdmlvciBvYnZpb3VzbHkgYnJlYWtzIGFueSB0cmFmZmljIHRo YXQgcmVsaWVzIG9uIGEgc2VydmljZSBsYWJlbCwgYnV0IGl0IGNhbiBwcm90ZWN0IHNvbWUgdHJh ZmZpYy4NCkluIG91ciBjYXNlIGEgaHVnZSBwZXJjZW50YWdlIG9mIGFsbCB0cmFmZmljIHN0aWxs IGlzIHB1YmxpYyBJUHY0LiBUaGlzIG5lZWRzIE1QTFMgb25seSBmb3IgYSB0cmFuc3BvcnQgbGFi ZWwsIGJlIGl0IExEUCBvciBTUi1NUExTLiBJZiB0aGlzIHRyYWZmaWMgZ2V0cyBmb3J3YXJkZWQg dW5sYWJlbGxlZCwgaXQgZm9sbG93cyBhbiBJR1AgZGVmYXVsdCByb3V0ZSB0byBhIGNlbnRyYWwg ZGV2aWNlLCB3aGVyZSBpdCBpcyAxKSByZWRpcmVjdGVkIHRvIHRoZSBjb3JyZWN0IGRlc3RpbmF0 aW9uIGFuZA0KMikgY291bnRlZCBpbiBhIHdheSB0aGF0IG9wZXJhdG9ycyBjYW4gcXVpY2tseSBz ZWUgd2hldGhlciBhbmQgd2hlcmUgdGhpcyBraW5kIG9mIGZhaWx1cmUgb2NjdXJzIGF0IHNvbWUg cG9pbnQgaW4gdGhlIG5ldHdvcmsuDQoNCkFmdGVyIG1vcmUgb3BlcmF0aW9uYWwgZXhwZXJpZW5j ZSBhbmQgc2V2ZXJhbCBpbnRlcm5hbCBkaXNjdXNzaW9ucyB3ZSBhZ3JlZWQgdGhhdCB3ZSB3YW50 IHBhY2tldHMgdG8gYmUgZm9yd2FyZGVkIHVubGFiZWxsZWQgcmF0aGVyIHRoYW4gZHJvcHBlZC4g QW55b25lIHRvIHNoYXJlLCBvciBvcHBvc2UgdGhpcyBwb3NpdGlvbj8NCg0KQmVzdCByZWdhcmRz LCBNYXJ0aW4NCg0KDQpBbSAzMS4wMS4yMCB1bSAxNjo1MCBzY2hyaWViIE1hcnRpbiBIb3JuZWZm ZXI6DQo+IEhlbGxvIGV2ZXJ5b25lLA0KPg0KPiBhZ2FpbiBpdCBzZWVtcyB0aGUgaW50ZXJlc3Rp bmcgcXVlc3Rpb25zIG9ubHkgc2hvdyB1cCB3aGVuIGFwcGx5aW5nIA0KPiBzb21ldGhpbmcgdG8g dGhlIGxpdmUgbmV0d29yay4uLg0KPg0KPiBXZSByYW4gaW50byBzb21ldGhpbmcgdGhhdCBwb3Nl cyBhIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gUkZDODY2MDogV2hhdCANCj4gaXMgdGhlIGV4YWN0IG1l YW5pbmcgb2Ygc2VjdGlvbiAyLjEwLjEsICJGb3J3YXJkaW5nIGZvciBQVVNIIGFuZCANCj4gQ09O VElOVUUgb2YgR2xvYmFsIFNJRHMiLCB3aGVuIHRoZSBjaG9zZW4gbmVpZ2hib3IgZG9lc24ndCBw cm92aWRlIGEgDQo+IHZhbGlkIE1QTFMgcGF0aD8NCj4NCj4gVGhlIHJlbGV2YW50IHNlY3Rpb25z IHJlYWRzOg0KPg0KPiDCoMKgwqDCoMKgIC3CoCBFbHNlLCBpZiB0aGVyZSBhcmUgb3RoZXIgdXNh YmxlIG5leHQgaG9wcywgdXNlIHRoZW0gdG8gDQo+IGZvcndhcmQNCj4gwqDCoMKgwqDCoMKgwqDC oCB0aGUgaW5jb21pbmcgcGFja2V0LsKgIFRoZSBtZXRob2QgYnkgd2hpY2ggdGhlIHJvdXRlciAi UjAiDQo+IMKgwqDCoMKgwqDCoMKgwqAgZGVjaWRlcyBvbiB0aGUgcG9zc2liaWxpdHkgb2YgdXNp bmcgb3RoZXIgbmV4dCBob3BzIGlzIGJleW9uZA0KPiDCoMKgwqDCoMKgwqDCoMKgIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50LsKgIEZvciBleGFtcGxlLCB0aGUgTUNDIG9uICJSMCIgbWF5DQo+ IMKgwqDCoMKgwqDCoMKgwqAgY2hvc2UgdGhlIHNlbmQgYW4gSVB2NCBwYWNrZXQgd2l0aG91dCBw dXNoaW5nIGFueSBsYWJlbCB0bw0KPiDCoMKgwqDCoMKgwqDCoMKgIGFub3RoZXIgbmV4dCBob3Au DQo+DQo+IERvZXMgdGhlIHBhcnQgInNlbmQgYW4gSVB2NCBwYWNrZXQgd2l0aG91dCBwdXNoaW5n IGFueSBsYWJlbCIgYXBwbHkgdG8gDQo+IFBVU0ggYW5kIENPTlRJTlVFLCBvciBqdXN0IHRvIFBV U0g/DQo+IERvZXMgUjAgaGF2ZSB0byB2YWxpZGF0ZSB0aGF0IG5laWdoYm9yIE4gY2FuIGNvcnJl Y3RseSBwcm9jZXNzIHRvIA0KPiBwYWNrZXQ/IE9yIGNhbiBpdCBmb3J3YXJkIHRoZSBwYWNrZXQg cmVnYXJkbGVzcz8NCj4NCj4gVGhlIHJlYXNvbiBmb3IgYXNraW5nIGlzIHRoYXQgd2UgYXJlIG5v dyBzZWVpbmcgaXNzdWVzIHNpbWlsYXIgdG8gb25lcyANCj4gd2UgaGFkIHdoZW4gc3RhcnRpbmcg d2l0aCBMRFAgYmFzZWQgTVBMUyBhYm91dCB0d28gZGVjYWRlcyBhZ286DQo+IHRyYWZmaWMgYmVp bmcgYmxhY2sgaG9sZWQgZXZlbiB0aG91Z2ggYSBwYXRoIHRvIHRoZSBkZXN0aW5hdGlvbiANCj4g ZXhpc3RzLCBiZWNhdXNlIHRoZSBNUExTIHBhdGggaXMgaW50ZXJydXB0ZWQgc29tZXdoZXJlIGlu IHRoZSBtaWRkbGUuDQo+DQo+IFdpdGggTERQIHdlIGtub3cgdGhlIGNhc2Ugb2YgTEZJQmVudHJp ZXMgY2FsbGVkICJ1bmxhYmVsbGVkIi4gV2hpbGUgDQo+IHRoaXMgZG9lcyBicmVhayBjb25uZWN0 aXZpdHkgZm9yIG1hbnkga2luZHMgb2Ygc2VydmljZSwgZS5nLiB0aG9zZSANCj4gcmVseWluZyBv biBhbiBhZGRpdGlvbmFsIHNlcnZpY2UgbGFiZWxzLCBpdCBzdGlsbCB3b3JrcyBmb3IgcGxhaW4N Cj4gSVAodjQpIHRyYWZmaWMuIEluIG91ciBjYXNlcywgdGhpcyB3b3JrcyBwZXJmZWN0bHkgZmlu ZSBmb3IgYWxsIA0KPiBpbnRlcm5hbCByb3V0aW5nIGFuZCBjb250cm9sIHRyYWZmaWMuIEFuZCBl dmVuIGZvciBJUHY0IHRyYWZmaWMgdGhhdCANCj4gZ2V0cyBjb2xsZWN0ZWQgYnkgYSBjZW50cmFs IHJvdXRlciB0aGF0IGluamVjdHMgYSBkZWZhdWx0IHJvdXRlLg0KPg0KPiBIb3dldmVyLCBkZXBl bmRpbmcgb24gdGhlIGV4YWN0IGludGVycHJldGF0aW9uIG9mIHRoZSBhYm92ZSBwYXJhZ3JhcGgs IA0KPiBhbiBpbXBsZW1lbnRvciBtaWdodCBmZWVsIG9ibGlnZWQgdG8gY2hvc2UgdGhlIG5leHQg cGFyYWdyYXBoOg0KPg0KPiDCoMKgwqDCoMKgIC3CoCBPdGhlcndpc2UsIGRyb3AgdGhlIHBhY2tl dC4NCj4NCj4gV2hpY2ggaXMsIGF0IGxlYXN0IGluIG91ciBjYXNlLCB2ZXJ5IHVuZm9ydHVuYXRl Li4uDQo+DQo+IEFueSBhZHZpY2Ugb3Igb3BpbmlvbiBhcHByZWNpYXRlZCENCj4NCj4NCj4gQmVz dCByZWdhcmRzLCBNYXJ0aW4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiBzcHJpbmdA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmlu ZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Thu Aug 27 05:45:55 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321B93A0CCD for ; Thu, 27 Aug 2020 05:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mzq34ZJEMzKz for ; Thu, 27 Aug 2020 05:45:51 -0700 (PDT) Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) (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 B64213A0CB4 for ; Thu, 27 Aug 2020 05:45:50 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id si26so7425585ejb.12 for ; Thu, 27 Aug 2020 05:45:50 -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=/e6/AqEVXGIQqspcsC0b8wFnLpL20iX+xJPWOxlVlHQ=; b=OEjgYNMYuKSEz2gkRaqh5H/mGXmBwUa1UDfdenQPIlMwrZn3O9zCrKcbWQTiDsu/yz BvHNqmwHy86RgZUoaFwMdeMyTd1Edd8peXMAXgfstnar0pC6MkT0kR+gRHjbdaTImJrt F/GnxvPIl7wuOaXwOJWb0PcN2gHtMJ13Ug6Le0Vqxd+L47pvaTSzeqLFL/8fAqP63bYA ach67IHn8ZWSHkJ11bGMsCtJdqufYHGBP4LdqAlETrRqoXikAupPQ4WI2PAiyrDwEvYe gq1Yhx2iqhR1iDt0MxhLxq7/7MwvwB4mC2HRJdox+v1e5p//kkgPBybXt54WW5ZB7USF cyWQ== 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=/e6/AqEVXGIQqspcsC0b8wFnLpL20iX+xJPWOxlVlHQ=; b=XCaMY8nMEzELm/Xtm44Xogj8bJTCW3MyGl+srDnMjZfFRaym2wbQRtjHOBg/BMHS0O 8xLWn4CU22DSgHd1zw1taFjNimBzFZ3wrQ3fbPvcwVsDZ2NvDuy69yflp18cSL49xhwR E7QZ0Cdj7aONR5YvYUyhG69X3wefGKzsxHOf1OF42NvWqc9QQD4iG6pKY9h+ME8rxMh3 CTvQkeiETNwIVTQ/DzJDMg0UwBy3PmhskqzMAm1DT3UAKx/FpgVvNZF0i5ixAmuMVhyS zpRS0anP+Sw4tkrPDcBb7uTZ+vzpg1T2+Opz/qooS5CyzfxMHR+hUMcwXI6iWT6aH27E AaoA== X-Gm-Message-State: AOAM531sDQ6swh/G9WbmtJvh0gKgHgyJ2wyzVrywyaInn3pBLFdfTuww zA3uDxVcE+DsSzobJAPh3Pg1folMR3XSrtAX0jOxBd2XwPJNlg== X-Google-Smtp-Source: ABdhPJwzrjrfZEG0wGO/3rqXnPlnbbgG6wYGmXjkEsLMH02U+H3oxYW5HcWWyxNpCZSQfpKIRj1zlt4dM/ckM5jUQQ8= X-Received: by 2002:a17:906:22d6:: with SMTP id q22mr12895361eja.242.1598532348984; Thu, 27 Aug 2020 05:45:48 -0700 (PDT) MIME-Version: 1.0 References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> In-Reply-To: <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> From: Robert Raszuk Date: Thu, 27 Aug 2020 14:45:39 +0200 Message-ID: To: Martin Horneffer Cc: SPRING WG Content-Type: multipart/alternative; boundary="000000000000d2d79405addb50b2" Archived-At: Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 12:45:53 -0000 --000000000000d2d79405addb50b2 Content-Type: text/plain; charset="UTF-8" Martin, > it follows an IGP default route to a central device, So putting aside that such default must point domian wide to the same address (could be anycast if you are careful) once this "central device" receives a packet and does a BGP full table lookup it will again try to encapsulate it in MPLS towards exit. What if the path is again via a device which breaks LDP LSP or SR path and the packet will again go back to central device creating a very nice loop ? Sure central device could give up on MPLS all together and IP encap to egress via your BGP free core - but you are not mentioning that. Bottom line if you would not have BGP free core (or Internet route free core) I would say sure good idea to continue. But since you do I think this is a lot of hidden traps number of networks may fall into by doing it. So at least it should not be a default behaviour. Thx, R. On Thu, Aug 27, 2020 at 12:35 PM Martin Horneffer wrote: > Hello everyone, > > may I come back the the question below? Or rather let me update it a > little: > > In case an SR-MPLS path is broken, should a node rather drop the packet, > or forward it? > This can happen whenever the IGP points to a certain next hop, but that > neither supplies a valid SID, nor allows LDP-stitching for whatever > reason. For PUSH as well as for CONTINUE. > > We have been using MPLS transport and a BGP free core since about two > decades now, using LDP. In the analog case, LDP creates "unlabelled" > entries in the LFIB, does the equivalent of a POP operation and forwards > the packet to the next-hop as chosen by the IGP. > > This behavior obviously breaks any traffic that relies on a service > label, but it can protect some traffic. > In our case a huge percentage of all traffic still is public IPv4. This > needs MPLS only for a transport label, be it LDP or SR-MPLS. If this > traffic gets forwarded unlabelled, it follows an IGP default route to a > central device, where it is 1) redirected to the correct destination and > 2) counted in a way that operators can quickly see whether and where > this kind of failure occurs at some point in the network. > > After more operational experience and several internal discussions we > agreed that we want packets to be forwarded unlabelled rather than > dropped. Anyone to share, or oppose this position? > > Best regards, Martin > > > Am 31.01.20 um 16:50 schrieb Martin Horneffer: > > Hello everyone, > > > > again it seems the interesting questions only show up when applying > > something to the live network... > > > > We ran into something that poses a question related to RFC8660: What > > is the exact meaning of section 2.10.1, "Forwarding for PUSH and > > CONTINUE of Global SIDs", when the chosen neighbor doesn't provide a > > valid MPLS path? > > > > The relevant sections reads: > > > > - Else, if there are other usable next hops, use them to forward > > the incoming packet. The method by which the router "R0" > > decides on the possibility of using other next hops is beyond > > the scope of this document. For example, the MCC on "R0" may > > chose the send an IPv4 packet without pushing any label to > > another next hop. > > > > Does the part "send an IPv4 packet without pushing any label" apply to > > PUSH and CONTINUE, or just to PUSH? > > Does R0 have to validate that neighbor N can correctly process to > > packet? Or can it forward the packet regardless? > > > > The reason for asking is that we are now seeing issues similar to ones > > we had when starting with LDP based MPLS about two decades ago: > > traffic being black holed even though a path to the destination > > exists, because the MPLS path is interrupted somewhere in the middle. > > > > With LDP we know the case of LFIBentries called "unlabelled". While > > this does break connectivity for many kinds of service, e.g. those > > relying on an additional service labels, it still works for plain > > IP(v4) traffic. In our cases, this works perfectly fine for all > > internal routing and control traffic. And even for IPv4 traffic that > > gets collected by a central router that injects a default route. > > > > However, depending on the exact interpretation of the above paragraph, > > an implementor might feel obliged to chose the next paragraph: > > > > - Otherwise, drop the packet. > > > > Which is, at least in our case, very unfortunate... > > > > Any advice or opinion appreciated! > > > > > > Best regards, Martin > > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000d2d79405addb50b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Martin,

    > it follows an IGP default = route to a=C2=A0central device,=C2=A0=C2=A0

    So= putting aside that such default=C2=A0must point domian wide to the same ad= dress (could be anycast if you=C2=A0are careful) once this "central de= vice" receives a packet and does a BGP full table lookup it will again= try to encapsulate it in MPLS towards exit.=C2=A0

    What if the path is again via a device which breaks LDP LSP or SR path=C2= =A0and the packet will again go back to central device creating a very nice= loop ?=C2=A0

    Sure central device could give up on= MPLS all together and IP encap to egress via your BGP free core - but you = are not mentioning that.=C2=A0

    Bottom line if you= =C2=A0would not have BGP free core (or Internet route free core) I would sa= y sure good idea to continue. But since you do I think this is a lot of hid= den traps number of networks may fall into by doing it. So at least it shou= ld not be a default behaviour.=C2=A0

    Thx,
    R.

    Hi Gyan,

     =

    Thank you very mu= ch. Perfect we are in line. All ack on your comments.

     =

    • With MPLS we are label swapping however with SR= you are label stacking.  So let’s say you have an SR-TE path in= stantiated and using the strict ERO path with adjacency SIDs defined,  would just the active label being used in the forwardi= ng plane be the one that IPFIX would be monitoring versus the entire stack = of labels.

     =

    Correct. IE46 is = only referencing the top label. We do not know these additional dimensions = for the other labels in the label stack. Same as all other IE below, just as reference.

     =

    46  &nb= sp;     mplsTopLabelType

    47  &nb= sp;     mplsTopLabelIPv4Address

    70  &nb= sp;     mplsTopLabelStackSection

    91  &nb= sp;     mplsTopLabelPrefixLength

    140  &n= bsp;    mplsTopLabelIPv6Address

    200  &n= bsp;    mplsTopLabelTTL

    203  &n= bsp;    mplsTopLabelExp

     =

    • What about IPFIX  SRv6 support?=

     =

    Good point. draft= -patki-srv6-ipfix-00 (https://tools.ietf.org/html/draft-patki-srv6-ipfix-00= ) is covering the IPv6 data plane in IPFIX. SrSidType in draft-tgraf-ipfix-mpls-sr-label-type relates to MPLS-SR and SRv6, IE46 = only to MPLS-SR.

     =

    Best Wishes<= /o:p>

    Thomas=

     

    From: Gyan Mishra <hayabusagsm@gmail.com>
    Sent: Sunday, August 16, 2020 10:40 PM
    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>
    Cc: hannes@gredler.at; ketant@cisco.com; lsr@ietf.org; opsawg@ietf.o= rg; spring@ietf.org
    Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

    Hi Thomas 

     

    Sorry for any misunderstanding.  I am well awar= e of the origins and history behind IPFIX and Neflow and use with BGP monit= oring.  

     

    I was not aware of IE 46 and how that was being leve= raged to support SR IGP extensions sid types.

     

    After  reviewing your IPFIX slides related to I= E 46 registry for mplsTopLabelType and this drafts solution to extend the I= E 46 registry with SR and now requiring new IGP codepoints to be allocated.=  

     

    You had given an example in the LDP interworking exa= mple or others that with this new IGP codepoint in case of multiple control= planes present such as both LDP and SR that with IPFIX and with the new IG= P codepoint allocations for each IGP type that you can see the forwarding resulting FIB entry.  I can see = that as a benefit for monitoring telemetry 

     

    In-line  below addresses complexity of extendin= g IE46 for SR support.

     

    On Sun, Aug 16, 2020 at 3:13 AM <Thomas.Graf@swisscom.com> wrote:












     

     

    Hi Gyan,

     

     

     

    Gyan> IPFIX has been traditionally been us= ed for flow analysis and to that end all that was required is support of th= e data plane encapsulation.  With your proposed SR support idea you are really transforming the IPFIX

    to be used for not just flow monitoring at that level solely, but now also = to analyze and troubleshoot data plane forwarding.  That is a consider= able departure I think from what IPFIX was intended.  I am not su= re we want to add that layer of complexity into

    IPFIX.

     

     

     

    Thomas> I have seen your feedback to Tarek and w= as puzzled about your remark about data plane encapsulation and IPFIX. I th= ink you have a limited picture for what IPFIX has been intended and being used. I do not want

    to lecture, but it might be useful to go back to the origins of Netflow and= IPFIX. At the beginning, the main reason for was to account traffic for BG= P control-plane dimensions. Such as BGP peer AS, src and dst prefix attribu= te. These helped to account traffic

    in shared enviroments. Later also for datacenters. These was and is always = in conjunction with the encapsulated header metrics of forwarded traffic an= d device dimensions such as ingress interface, egress interface, vrf id and= vrf name. In order to have a proper

    picture about the forwarding plane, and to enable data correlation, key fie= lds from other perspectives (control-plane, forwarding-plane, device) are n= ecessary to enable data correlation with other protocols such as BMP and YA= NG.

     

     

     

    Thomas> Going back to the initial conversa= tion. Section 7.2 of RFC 5102

     

    https://tools.ietf.org/html/rfc5102#section-7.2=

     

     

     

       For ensuring extensibility of this informati= on, IANA has created a

     

       new registry for MPLS label types and filled= it with the initial list

     

       from the description Information Element #46= , mplsTopLabelType.

     

     

     

    Thomas> When IPFIX was specified, it has b= een defined in mind that other MPLS label protocols will be developed in th= e future. Which is the case with RFC 8665, 8666, 8667 and 8669. All adding TLV's to carry segment routing

    SID's. In the presentation I gave, I showed one of many vendors implemented= IE46 and showing the wrong value. Event though the label protocol was IS-I= S SR TLV, the value shown was LDP. This is not acceptable. When new protoco= ls are developed, we at IETF must

    ensure that they can be properly monitored. With IPFIX we have the proper p= rotocol to do that. Even without modifications as section 4 in draft-ali-sp= ring-sr-traffic-accounting mentioned:



    https://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#secti= on-4

     

     

     

    Thomas> You have been referring to complex= ity. One of the key objectives of SR-MPLS was that it does not much change = in the MPLS data plane. You need to explain on this WG how SR differs from other MPLS label protocols

    in terms of RIB/FIB. And then from there why an implementation would= be difficult. That’s the discussion I am looking forward to.    <= o:p>

     

    Gyan> SR-MPLS reuses the MPLS data plane s= o from that  perspective is the same but how it differs is with SR ste= ering and MSD SID depth with SR-TE especially when strict ERO is defined with adjacency SID the label stack is expanded.=  

     

        With MPLS we are label swapping howeve= r with SR you are label stacking.  So let’s say you have an SR-T= E path instantiated and using the strict ERO path with adjacency SIDs defin= ed,  would just the active label being used in the forwarding plane be the one that IPFIX would be monitoring versus the entire stack of= labels.

    In theory it appears that the IPFIX machinery= is in place with IE 46 to support SR as what you have proposed in the draf= t.  

     

        As far as vendor compatibility as long= as they         support IE 46 they should support SR-M= PLS.

     

    I don’t see any issues now as far as complexit= ies to support as the we are using existing machinery IPFIX IE 46 to extend= for SR support.  

     

    I think getting feedback from LSR is critical on the= ir thoughts on complexity and caveats with getting the codepoints assigned.=

     

    What about IPFIX  SRv6 support?

     

    Comment on Section 2

     

     &nbs=
p; A typical use case scenario is to monitor MPLS control plane
     &n=
bsp; migrations from LDP to IS-IS or OSPF.  By looking at the MPLS lab=
el
       value itself, it is not always clear as to which label p=
rotocol it
       belongs, since they could potentially share the =
same label allocation
       range.  This is the case for IGP=
-Adjacency SID's and LDP as an
       example.
    SR SRGB la=
bel range is different then LDP label range.

          

     

    Best wishes

     

    Thomas

     

     

     

    From: Gyan= Mishra <haya= busagsm@gmail.com>




    Sent: Saturday, August 15, 2020 9:26 PM


    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>


    Cc: hannes@gr= edler.at; ketant@cisco.com;= lsr@ietf.org; opsa= wg@ietf.org; spring@ietf.org

    Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

     

     

     

     

     

     

     

     

     

    Hi Thomas 

     

     

     

     

     

     

     

    Responses in-line 

     

     

     

     

     

     

     

     

    On Sat, Aug 15, 2020 at 2:02 AM <Thomas.Graf@swisscom.com> wrote:

     

     

     

     

     

































     

     

     

     

     

     

     

     

     

     

    Hi Ketan,

     

     

     

     

     

     

     



     

     

     



    • This helps identification of specific SR-MPLS segment = types as well as differentiating them from LDP, RSVP-TE, etc.

     

     

     

     

     

     

     

    To be precise, the existing MPL= S Label Type identifier differentiates from LDP, RSVP-TE.

    Not the new SrSidType IPFIX IE being proposed.

     

     

     

     

     

     

     



     

     

     



    • What value is provided for IPFIX analysis if the SR Pr= efix SID was being signalled via OSPF or ISIS?

     

     

     

     

     

     

     

    It is important to distinguish = between intend and result.

     

     

     

     

     

     

     

    If you migrate from one label d= istribution protocol to another, a network operator

    want's to understand if the data plane is still forwarding





    packets with the label distribution protocol which needs to be removed or n= ot. IE46 enables that by looking at the result of the forwarded traffic and= not at the intend. RFC 8661 section 3,





    https://tools.ietf.org/html/rfc8661#section-3,





    describes the context.

     

     

     

     

     

     

    Gyan> IPFIX has been traditionally been used for flow analysis = and to that end all that was required is support of the data plane encapsul= ation.  With your proposed SR support idea you are really transforming the IPFIX to be used for not

    just flow monitoring at that level solely, but now also to analyze and trou= bleshoot data plane forwarding.  That is a considerable departure I th= ink from what IPFIX was intended.  

     

     

     

     

     

     

     

    I am not sure we want to add that layer of complexity into IPFIX.<= o:p>

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     



     

     

     



    • What value is provided for IPFIX analysis if it was a = Adjacency SID or a LAN Adjacency SID?

     

     

     

     

     

     

     

    Quote from RFC8402. "Segme= nt Routing (SR) leverages the source routing paradigm".

    Means that not the routing protocol does all the forwarding





    decisions, the node can change the forwarding by pushing additional labels.= . With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabli= ng to analyze the result of this decision. The example with " Adjacenc= y SID or a LAN Adjacency SID" is not





    very useful because the difference of the two is the topology among the adj= acency. If you compare " Adjacency SID with Prefix SID", that mak= es much more sense. Since it describes that a particular adjacency is chose= n to forward the packet instead of a prefix.





    If IE 89, ForwardingStatus is drop, we understand that result of that decis= ion lead to the drop and this enables to narrow down forwarding issues in s= egment routing networks more efficiently and quickly.

     

     

     

     

     

     

     

    Ø 





    am asking for WG to weigh the implementation co= mplexities

     

     

     

     

     

     

     

    For the WG and me, I would be importa= nt if you can describe more detailed what you mean

    with





    implementation complexities. I would like to ha= ve a better understanding where your fear is coming from. I would appreciat= e if you could differentiate between





    MPLS Label Type identifier, IE46,= from which label protocol the label was coming from and SrSidType which SI= D type was used.

     

     

     

     

     

     

     

     

     

     

     

    Best wishes

     

     

     

    Thomas

     

     

     

     

     

     

     

     

     

     

     

     

     

    From: Keta= n Talaulikar (ketant) <ketant@cisco.com>














    Sent: Saturday, August 15, 2020 7:09 AM








    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;

    hannes@gredler.at








    Cc:     lsr@ietf.org;

    spring@ietf.org    ; o= psawg@ietf.org








    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type    <= /o:p>

     

     

     

     

     

     

     

     

     

     

     

     

     

    Hi Thomas,

     

     

     

     

     

     

     

    I should have been more clear in my email.

     

     

     

     

     

     

     

    The proposal/suggestion is to add the followi= ng to the IPFIX MPLS Label type identifier registry:

     

     

     



     

     

     



    • SR Prefix SID


    • SR Adjacency SID


    • SR Binding SID


    • SR BGP Peering SID


    • … and so on

     

     

     

     

     

     

     

    This helps identification of specific SR-MPLS= segment types as well as differentiating them from LDP, RSVP-TE, etc.

     

     

     

     

     

     

     

    And my questions were:

     

     

     



     

     

     



    1. What value is provided for IPFIX analysis if the SR Pr= efix SID was being signalled via OSPF or ISIS?


    2. What value is provided for IPFIX analysis if it was a = Adjacency SID or a LAN Adjacency SID?

     

     

     

     

     

     

     

    I am asking for WG to weigh the implementatio= n complexities and overheads with the proposed details of SR-MPLS segments = in IPFIX against the benefit (if any)

    that they provide for the





    flow analysis and monitoring.

     

     

     

     

     

     

     

    Thanks,

     

     

     

    Ketan

     

     

     

     

     

     

     

     

     

     

     

     

     

    From:







    Thomas.Graf@swisscom.com     <Thomas.Graf@swisscom.com>














    Sent: 15 August 2020 09:40








    To: Ketan Talaulikar (ketant) <ketant@cisco.com>;





    hannes@gredler.at








    Cc:     lsr@ietf.org;







    spring@ietf.org    ; o= psawg@ietf.org








    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type    <= /o:p>

     

     

     

     

     

     

     

     

     

     

     

     

     

    Hi Ketan,

     

     

     

     

     

     

     

    Thank you very much for the rev= iew and feedback.

     

     

     

     

     

     

     



     

     

     



    • What or how much value be there on determining whether= a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS<= br>




      – what matters and is more important is that it is a Prefix SID. Hard= ly any deployments would be running multiple protocols and learning the sam= e prefix from different IGPs.

     

     

     

     

     

     

     

    As Jeff already pointed out. Multiple IGP labe= lling protocols are used  in networks when migrations

    are ongoing. Usually in a life cycle. Migrating from





    LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom whe= n we first discovered this shortcoming in vendor implementations. The key p= oint here, with these additional IPFIX MPLS Label Type identifiers we enabl= e the possibility to verify the





    label protocol migration without taking the label value into the considerat= ion.

     

     

     

     

     

     

     



     

     

     



    • IPFIX may be picking this information from a FIB in so= me implementation where the protocol does not matter and this information




      is not available therein.

     

     

     

     

     

     

     

    I am not sure if you have seen the presentatio= n in IETF 108 at OPSAWG and SPRING.

     

     

     

    https://www.ietf.org/proceedings/108/slides/slides-= 108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf

     

     

     

     

     

     

     

    Slide 2 shows Cisco as example vendor which im= plemented IE 46, MPLS Label Type identifier. There

    is an open ddts where vendor feasibility has been clarified.





    Ping me off the list when you like to have more details.    <= /p>

     

     

     

     

     

     

     

    I do understand your point that= not all the vendors are capable to implement IE 46.

    But that’s not the point about the IPFIX IE registry.





    The IE registry enables that an IPFIX implementa= tion can refer to the right code point. With RFC 5102 the decision has been= made that MPLS Label Type identifier make sense





    and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends t= he IE 46 registry with the Segment Routing label protocol code points so wh= en OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX imp= lementation can point to the right





    code point.

     

     

     

     

     

     

     



     

     

     



    • On some nodes, the same Prefix SID may be learnt via b= oth BGP and IGP – what would we use/show?

     

     

     

     

     

     

     

    In this case the IE 46 shows the labe= l protocol which was used to program the FIB.

     

     

     

     

     

     

     



     

     

     









    • For that table proposal, it= is very difficult and in some cases not possible to different between Pref= ix and Node and Anycast SID. Many of these types are control plane elements= and we can





      be sure more get added.

     

     

     

     

     

     

     

    I fully agree. As a network ope= rator its still hard to understand the architecture

    and constraints within a router. When monitoring capabilities





    are discussed at IETF, this is the usual topic. What is possible, what make= sense. By purpose, all available SID types are listed in the draft. This w= ith the aim to start the discussion in the working groups what is possible = what makes sense. I would be interested





    to get your and also Jeff's feedback.

     

     

     

     

     

     

     

    In above mentioned slides I described= how TI-LFA application would benefit of visibility

    in the FIB by showing where Adj-SID was used. This





    should be a simple example why it make sense not only to look at which labe= l protocol was used to forward a particular packet, but also which SID type= to further understand the intend why this label is being pushed.

     

     

     

     

     

     

     

    I hope this makes all sense. Lo= oking forward for reply.

     

     

     

     

     

     

     

    Best wishes

     

     

     

    Thomas

     

     

     

     

     

     

     

     

     

     

     

     

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>














    Sent: Friday, August 14, 2020 7:35 PM








    To: Graf Thomas, INI-NET-DCF <Thomas.Graf@swisscom.com>;





    hannes@gredler.at








    Cc:     lsr@ietf.org; SPRING WG <spri= ng@ietf.org>








    Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

     

     

     

     

     

     

     

     

     

     

     

     

     

    < also copying Spring WG for their review/= inputs >

     

     

     

     

     

     

     

    Hi Thomas/All,

     

     

     

     

     

     

     

    I have reviewed the draft and would like to s= hare a different perspective.

     

     

     

     

     

     

     

    What or how much value be there on determinin= g whether a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSP= Fv3/ISIS – what matters and is more important

    is that it is a





    Prefix SID. Hardly any deployments would be running multiple protocols and = learning the same prefix from different IGPs. IPFIX may be picking this inf= ormation from a FIB in some implementation where the protocol does not matt= er and this information is not





    available therein.

     

     

     

     

     

     

     

    On some nodes, the same Prefix SID may be lea= rnt via both BGP and IGP – what would we use/show?<= /p>

     

     

     

     

     

     

     

    I would recommend using SR Prefix SID, SR Adj= acency SID, SR Binding SID, SR BGP Peering SID and so on … for the MP= LS Label Type.

     

     

     

     

     

     

     

    This also takes away the need for the second = table that is being proposed to a large extent. For that table proposal, it= is very difficult and in some cases not

    possible to different





    between Prefix and Node and Anycast SID. Many of these types are control pl= ane elements and we can be sure more get added. Is there really much value = in differentiation between say an Adjacency SID and LAN Adjacency SID?

     

     

     

     

     

     

     

    Could we evaluate the implementation overhead= and complexity of this level of categorization/information in IPFIX agains= t their value in flow analysis to perhaps

    consider a middle ground?

     

     

     

     

     

     

     

    Thanks,

     

     

     

    Ketan

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Hi Hannes,

     

     

     

     

     

     

     

    Thanks a lot for the feedback. = Yes, makes completely sense. Will take it for the

    next update...

     

     

     

     

     

     

     

    Best Wishes

     

     

     

    Thomas

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Thomas,

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    I have one comment/suggestion to Paragraph 4 (IANA Considerations)= .

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Please add also a code point for BGP Prefix-SID - it’s quite= popular in DC deployments.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    thanks,

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    /hannes

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    On 28.07.2020, at 10:11,







    Thomas.Graf@swisscom.com     wrote:

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Dear lsr,

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    I presented the following draft

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Export of MPLS Segment Routing Label Type Inf= ormation in IP Flow Information Export (IPFIX)

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    at the spring working group at IETF 108 yeste= rday

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    and today at OPSAWG where I call for adoption= .

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    This draft adds additional segment routing co= de points for in the IANA IPFIX registry for IS-IS,

    OPSFv2 and OPSF v3 and segment routing SID types to gain





    further insights into the MPLS-SR forwarding-plane.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    I have been asked to not only gather feedback= from spring and opsawg but also from lsr and mpls

    working groups since these code points are related to link





    state routing protocols and mpls data plane.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    I am looking forward to your feedback and inp= ut.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    Best Wishes

     

     

     

     

     

     

     

     

     

    Thomas Graf

     

     

     

     

     

     

    _______________________________________________








    Lsr mailing list








    Ls= r@ietf.org








    https://www.ietf.org/mailman/listinfo/lsr

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     













    _______________________________________________





    OPSAWG mailing list





    OPSAWG@ietf.org




    https://www= .ietf.org/mailman/listinfo/opsawg

     

     

     

     

     

     

     

    --

     

     

     

     

     

     

     

     

     

     

     

    Gyan Mishra

     

    Network Solutions Architect 

     

    M 301 502-1347


    13101 Columbia Pike 


    Silver Spring, MD

     



     

     

     

     

     

     

     

     

     

     

     

     

     




    --

    <= span style=3D"color:#1155CC;text-decoration:none">

    Gyan = Mishra

    Network = Solutions Architect 

    M 301 50= 2-1347
    13101 Columbia Pike 
    Silver Spring, MD<= /p>

     






    On Th= u, Aug 27, 2020 at 12:35 PM Martin Horneffer <maho@lab.dtag.de> wrote:
    Hello everyone,

    may I come back the the question below? Or rather let me update it a little= :

    In case an SR-MPLS path is broken, should a node rather drop the packet, or forward it?
    This can happen whenever the IGP points to a certain next hop, but that neither supplies a valid SID, nor allows LDP-stitching for whatever
    reason. For PUSH as well as for CONTINUE.

    We have been using MPLS transport and a BGP free core since about two
    decades now, using LDP. In the analog case, LDP creates "unlabelled&qu= ot;
    entries in the LFIB, does the equivalent of a POP operation and forwards the packet to the next-hop as chosen by the IGP.

    This behavior obviously breaks any traffic that relies on a service
    label, but it can protect some traffic.
    In our case a huge percentage of all traffic still is public IPv4. This needs MPLS only for a transport label, be it LDP or SR-MPLS. If this
    traffic gets forwarded unlabelled, it follows an IGP default route to a central device, where it is 1) redirected to the correct destination and 2) counted in a way that operators can quickly see whether and where
    this kind of failure occurs at some point in the network.

    After more operational experience and several internal discussions we
    agreed that we want packets to be forwarded unlabelled rather than
    dropped. Anyone to share, or oppose this position?

    Best regards, Martin


    Am 31.01.20 um 16:50 schrieb Martin Horneffer:
    > Hello everyone,
    >
    > again it seems the interesting questions only show up when applying > something to the live network...
    >
    > We ran into something that poses a question related to RFC8660: What <= br> > is the exact meaning of section 2.10.1, "Forwarding for PUSH and =
    > CONTINUE of Global SIDs", when the chosen neighbor doesn't pr= ovide a
    > valid MPLS path?
    >
    > The relevant sections reads:
    >
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 Else, if there are other usable= next hops, use them to forward
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the incoming packet.= =C2=A0 The method by which the router "R0"
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 decides on the possib= ility of using other next hops is beyond
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the scope of this doc= ument.=C2=A0 For example, the MCC on "R0" may
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 chose the send an IPv= 4 packet without pushing any label to
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 another next hop.
    >
    > Does the part "send an IPv4 packet without pushing any label"= ; apply to
    > PUSH and CONTINUE, or just to PUSH?
    > Does R0 have to validate that neighbor N can correctly process to
    > packet? Or can it forward the packet regardless?
    >
    > The reason for asking is that we are now seeing issues similar to ones=
    > we had when starting with LDP based MPLS about two decades ago:
    > traffic being black holed even though a path to the destination
    > exists, because the MPLS path is interrupted somewhere in the middle.<= br> >
    > With LDP we know the case of LFIBentries called "unlabelled"= . While
    > this does break connectivity for many kinds of service, e.g. those > relying on an additional service labels, it still works for plain
    > IP(v4) traffic. In our cases, this works perfectly fine for all
    > internal routing and control traffic. And even for IPv4 traffic that <= br> > gets collected by a central router that injects a default route.
    >
    > However, depending on the exact interpretation of the above paragraph,=
    > an implementor might feel obliged to chose the next paragraph:
    >
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 Otherwise, drop the packet.
    >
    > Which is, at least in our case, very unfortunate...
    >
    > Any advice or opinion appreciated!
    >
    >
    > Best regards, Martin
    >
    >
    >
    >
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    >     https://www.ietf.org/mailman/listinfo/spring
    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --000000000000d2d79405addb50b2-- From nobody Thu Aug 27 06:20:14 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FF53A08A6; Thu, 27 Aug 2020 06:20:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <159853441163.2949.14549837077207318829@ietfa.amsl.com> Date: Thu, 27 Aug 2020 06:20:11 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-18.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 13:20:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : SRv6 Network Programming Authors : Clarence Filsfils Pablo Camarillo Garvia John Leddy Daniel Voyer Satoru Matsushima Zhenbin Li Filename : draft-ietf-spring-srv6-network-programming-18.txt Pages : 42 Date : 2020-08-27 Abstract: The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization (Service Level Agreements). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-18 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-18 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 Aug 27 06:34:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C23A097E; Thu, 27 Aug 2020 06:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bj6dFNEu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=njV3yLQh 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 CesrOXbNKfsb; Thu, 27 Aug 2020 06:34:39 -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 B93923A097C; Thu, 27 Aug 2020 06:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1598535278; x=1599744878; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8JmyuLjv4nkhu8P4dBXb/C1erjse1kyXYtQvhLe9Vmc=; b=bj6dFNEu78fagRCpSZghLtd33YEXeBMsxqOOX74GCaIXX8ipWI3JOTio ZA/GOZynsQ08IjzjvYj+ZkilO2TFhau9ck+uZUJJlqpWtHONm43veUc0d QimVAXWQvW5NAo4lC/DGGhn5q6J39H0D5Sg2N2kP9inaOpXpbopvdofja A=; IronPort-PHdr: =?us-ascii?q?9a23=3AcA6GbhWo+8myanLx2z8PuY+C1i/V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqBgD/tEdf/4cNJK1gHgEBCxIMQIE?= =?us-ascii?q?/C4FSUQdwWC8sCoQtg0YDjW2YcYEugSUDVQsBAQEMAQEnBgIEAQGETAIXgjE?= =?us-ascii?q?CJDQJDgIDAQELAQEFAQEBAgEGBG2FXAELhXIBAQEDARIREQwBASwLAQ8CAQg?= =?us-ascii?q?YAgIfBwICAjAVEAIEDgUIGoMFgksDDiABAwunZQKBOYhhdoEygwEBAQWBMwE?= =?us-ascii?q?DAgENQYMlGIIQAwaBDiqCcYNlhk8bgUE/gRFDgk0+glwBAQIBARWBSBWDADO?= =?us-ascii?q?CLY96gxeHD5w8CoJjiGaRaIMHiWiTVpJMikuVAAIEAgQFAg4BAQWBVDqBQg4?= =?us-ascii?q?HcBUaglYBATJQFwINjh83gzqFFIVCdAI1AgYBCQEBAwl8jlQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.76,359,1592870400"; d="scan'208";a="819538374" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 13:34:37 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 07RDYbie014227 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2020 13:34:37 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 08:34:37 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 09:34:36 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 27 Aug 2020 08:34:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TK9mGGLssVKsMWkaGsB7ptOhTKnzvHzyOwd5vg0e+BnSVGgmy+IiK41PhU/myU8/WXz6D+pCxF5EbTqSP3CHqu/PKmBGfrJIRfRShNdppeYsF7juMVkesqT9dHqhdPGAb7gD2cNfmtsFMTmBtZVHjrNg2kRocEKWroZvbetE5CahnQCmZakzWAWbDSiqOiM8tlxE0vYX5Y4fQX2H5ZUAxufy6vlRi1FCUIUxJNeMYscHv741x5whMmqnvzDrlKdBLTUSX+jVcy50lemJTjLkBOi9RlyoJP6ZK98XVj598UuP0C9ELaJvHbNrcz1ITDLdZBG+Ol0Zj2kiirXUf25pVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8JmyuLjv4nkhu8P4dBXb/C1erjse1kyXYtQvhLe9Vmc=; b=NbilDOKjJTwRRVwZQd1Cj/9EUw950hZdm3XLvSesvYzyKZ0wkudkgxPlRODFoXsmxSc7Pkw9VD5QlbSfdqSc9Cqmqm+MBOiaVtNkfSZGLNle8dcQcU9qu8bvCKxMIp3103tE9RdrtRZFGshD4tKnClcN9XSSY2b8JzV4Y/s3eBvBFAOq2vOqEKGvj7CM0225ekmSUaGaCr8VonGiqcs4my1kQDLp53BdTpdDnfeL5Q7xhTwDs2OnDc355xSzuTniwszWGgP/SAb7NQmPWO/P/eAFjzSaW6jvQRDX3Zn9IspzeppTbiEvLLAJgfka7i2R2vD3T4qu/5GdBRNdMqPW3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8JmyuLjv4nkhu8P4dBXb/C1erjse1kyXYtQvhLe9Vmc=; b=njV3yLQh9/HPDhxbFS74bhx5/ZBJNvBiwg5ydxbo6o93DXJWbS2Q8jYeeLoOdvHGM8aJ5Uku2xe7+UX7hMkxss0fr3ZDj9ZKdNKPAlWTQAHmEvv9Sra9HiWqHThe4XK85uZX/+l7reE2aH94zEPVfy1DpiZl3K3Sj0/PSBrvMsg= Received: from MWHPR11MB1374.namprd11.prod.outlook.com (2603:10b6:300:24::8) by MWHPR11MB1903.namprd11.prod.outlook.com (2603:10b6:300:10e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25; Thu, 27 Aug 2020 13:34:34 +0000 Received: from MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e]) by MWHPR11MB1374.namprd11.prod.outlook.com ([fe80::c0dd:2d6e:c8ef:261e%12]) with mapi id 15.20.3326.021; Thu, 27 Aug 2020 13:34:34 +0000 From: "Pablo Camarillo (pcamaril)" To: "last-call@ietf.org" CC: "spring@ietf.org" , "draft-ietf-spring-srv6-network-programming@ietf.org" , "iesg@ietf.org" Thread-Topic: Last Call: (SRv6 Network Programming) to Proposed Standard Thread-Index: AQHWcKf0zDZZDEhyN0ektmn5dymw76lBmuYAgAiIPDCAAXJYAIAAc2XQ Date: Thu, 27 Aug 2020 13:34:33 +0000 Message-ID: References: <159723694970.27067.9766029100632402951@ietfa.amsl.com> <521aafe7-6d05-a245-1b21-e047c0904e08@gmail.com> In-Reply-To: <521aafe7-6d05-a245-1b21-e047c0904e08@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [88.14.54.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ef37a14-c9ed-426c-b7ab-08d84a8def88 x-ms-traffictypediagnostic: MWHPR11MB1903: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZZk3CLjB4qykc5JADrt0AdOjKqw0+2+QoXynbDCFgRl0T2izZ4Ioscfvw98cn1+SwRLKkeESMTX8laWeXIvCy1jhA+MGsZxUYTUQ1jt5zb/PCiGycSwo3cZ1aaeyGXzZUDkWqANwtRlWDLpp2NAAqIcHHKa2T8hd9Nu96550woAB/rixsX8BWieHjByeXUoRdOF/BQjw4d8KCe3pHZ0NX9HQTVkbGKAqjbcDoBu7MMr/ZsXX4PuQ47Y4M3e3j3FNnH5AT2cm8zPpfYMFeO8/EnYvyx5V33KhnNiHjT5u8lq8g3YlxvNT5clFkhFhN5AX9Ne7i+OOh7oinysY6TU1PX6ncDfPrgbf+JaJ3i0A3r+1aoU3FuoFfLdhLQZMKAzM6gV+8IknJE7pmtRIJUbeIQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1374.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(396003)(136003)(39860400002)(33656002)(186003)(6506007)(26005)(7696005)(2906002)(86362001)(66574015)(71200400001)(83380400001)(52536014)(8676002)(9686003)(55016002)(316002)(4326008)(76116006)(64756008)(966005)(66446008)(54906003)(66556008)(6916009)(53546011)(478600001)(5660300002)(8936002)(66946007)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: oYsZwxonG3af+uWEKahJG1gFfkCPylcHKZEptnjLi6LAp/j+49gRJCIC/V7nJPpr+xY1KrnqSNOmR5dR8nGBDMa32wjvAhjtSL60DCnGkN82nD47t1vTeWVlukS+90dU4oNcYKrn9JnRwAxp9nOk/sWGVCIki6A/wo9Z+H3+BVe8TtB+5S+mPZOLU1Lpb1gLOm7k1IaF2ZdTMoeE6yTGHnHWUgyhWmmRpoeLWD+Jt9+0n3aYIr+o45iYop2z2LkIDIKcG7YztcYb5rK2MZvhTodpftbrbSDZoQRMtMtHzYOIeSKjpLpxXC24RGooB8si6LzobnBloDyTVVyvCoVvlvTSFPtt8oG0R0j3oIIRSV6MQRxeUCLxSj8DKlauCyNBeao5Bg7WWfSx8CwRZPG679wodUjCLLcv3TDQV1gdt3ahHDzd69L2AXG6GkYKerM8IISfGHd8BdbWq98R+uJ+O1vZ641EVbKZYRt1eJDyviMou2ioAthBT3EOthWTa5L/S27cmqYgzp98UiynTErrJA7syV1Eb73vlM6HydWa3GYws31KxyRlRllp7l7Y+wLAXWOG/u2akLtkD7/cZTrftM9dftDLM3cAAbV+ErjqdQWQuwnPsVCRwA6jo2aBSToZM7hDNX17seXINPUzef9LDg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1374.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ef37a14-c9ed-426c-b7ab-08d84a8def88 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 13:34:34.0314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Co/ntbbr6kCMe3ecKlK0Hs/hq+vURehYs+OzhXU40v4ULZ+zfs17J/trn2NwKC/kV1fQe2ReQC7B4RmyEpuVuQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1903 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [spring] Last Call: (SRv6 Network Programming) to Proposed Standard X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 13:34:41 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIGp1c3QgcG9zdGVkIHJldmlzaW9uIDE4IG9mIGRyYWZ0LWlldGYt c3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy4NClRoaXMgcmV2aXNpb24gYWRkcmVzc2Vz IHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIE1pcmphIEvDvGhsZXdpbmQgKFRTVkFSVCByZXZp ZXcpIFsxXSwgRGFuIFJvbWFzY2FudSAoT1BTRElSIHJldmlldykgWzIsIDNdIGFuZCBCcmlhbiBD YXJwZW50ZXIgWzQsIDVdLg0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXdzIGFuZCBjb21tZW50 cy4NCg0KUmVnYXJkcywNClBhYmxvLg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvcmV2aWV3LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy0xNy10c3Zh cnQtbGMta3VlaGxld2luZC0yMDIwLTA4LTE4Lw0KWzJdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL3Jldmlldy1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMTct b3BzZGlyLWxjLXJvbWFzY2FudS0yMDIwLTA4LTIwLTIvDQpbM10gaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvajdJVHNiVVJnZzNmTWpPWll6X0JTRUpIQXNVLw0K WzRdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2Q1dUI2WEs4 QzRjeGYwam4zNVJ3QXROeDQ2SS8NCls1XSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3NwcmluZy9mTHo5QVB3V1lPc05VRC12SXI1ZmtqWnFKUFUvDQoNCg0KTmFtZToJCWRy YWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZw0KUmV2aXNpb246CTE4DQpU aXRsZToJCVNSdjYgTmV0d29yayBQcm9ncmFtbWluZw0KRG9jdW1lbnQgZGF0ZToJMjAyMC0wOC0y Nw0KR3JvdXA6CQlzcHJpbmcNClBhZ2VzOgkJNDINClVSTDogICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3Jr LXByb2dyYW1taW5nLTE4LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy8N Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1z cHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTE4DQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5l dHdvcmstcHJvZ3JhbW1pbmcNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTE4 DQoNCg0KPiANCj4gT24gMTMtQXVnLTIwIDAwOjU1LCBUaGUgSUVTRyB3cm90ZToNCj4+DQo+PiBU aGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIFNvdXJjZSBQYWNrZXQgUm91 dGluZyBpbiANCj4+IE5ldHdvcmtpbmcgV0cgKHNwcmluZykgdG8gY29uc2lkZXIgdGhlIGZvbGxv d2luZyBkb2N1bWVudDogLSAnU1J2NiBOZXR3b3JrIFByb2dyYW1taW5nJw0KPj4gICA8ZHJhZnQt aWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTE3LnR4dD4gYXMgUHJvcG9zZWQg DQo+PiBTdGFuZGFyZA0KPj4NCj4+IFRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBp biB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cyANCj4+IGZpbmFsIGNvbW1lbnRzIG9u IHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byANCj4+IHRo ZSBsYXN0LWNhbGxAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDIwLTA4LTI2LiBFeGNlcHRp b25hbGx5LCANCj4+IGNvbW1lbnRzIG1heSBiZSBzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVh ZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSANCj4+IHJldGFpbiB0aGUgYmVnaW5uaW5nIG9mIHRo ZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQo+Pg0KPj4gQWJzdHJh Y3QNCj4+DQo+Pg0KPj4gICAgVGhlIFNSdjYgTmV0d29yayBQcm9ncmFtbWluZyBmcmFtZXdvcmsg ZW5hYmxlcyBhIG5ldHdvcmsgb3BlcmF0b3Igb3INCj4+ICAgIGFuIGFwcGxpY2F0aW9uIHRvIHNw ZWNpZnkgYSBwYWNrZXQgcHJvY2Vzc2luZyBwcm9ncmFtIGJ5IGVuY29kaW5nIGENCj4+ICAgIHNl cXVlbmNlIG9mIGluc3RydWN0aW9ucyBpbiB0aGUgSVB2NiBwYWNrZXQgaGVhZGVyLg0KPj4NCj4+ ICAgIEVhY2ggaW5zdHJ1Y3Rpb24gaXMgaW1wbGVtZW50ZWQgb24gb25lIG9yIHNldmVyYWwgbm9k ZXMgaW4gdGhlDQo+PiAgICBuZXR3b3JrIGFuZCBpZGVudGlmaWVkIGJ5IGFuIFNSdjYgU2VnbWVu dCBJZGVudGlmaWVyIGluIHRoZSBwYWNrZXQuDQo+Pg0KPj4gICAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIHRoZSBTUnY2IE5ldHdvcmsgUHJvZ3JhbW1pbmcgY29uY2VwdCBhbmQNCj4+ICAgIHNwZWNp ZmllcyB0aGUgYmFzZSBzZXQgb2YgU1J2NiBiZWhhdmlvcnMgdGhhdCBlbmFibGVzIHRoZSBjcmVh dGlvbiBvZg0KPj4gICAgaW50ZXJvcGVyYWJsZSBvdmVybGF5cyB3aXRoIHVuZGVybGF5IG9wdGlt aXphdGlvbiAoU2VydmljZSBMZXZlbA0KPj4gICAgQWdyZWVtZW50cykuDQo+Pg0KPj4NCj4+DQo+ Pg0KPj4gVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyDQo+PiBh DQo+PiBtbWluZy8NCj4+DQo+Pg0KPj4gVGhlIGZvbGxvd2luZyBJUFIgRGVjbGFyYXRpb25zIG1h eSBiZSByZWxhdGVkIHRvIHRoaXMgSS1EOg0KPj4NCj4+ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvaXByLzM0NjQvDQo+Pg0KPj4NCg== From nobody Thu Aug 27 20:32:09 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FBC3A1584 for ; Thu, 27 Aug 2020 20:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGIhad93DuNt for ; Thu, 27 Aug 2020 20:31:59 -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 5E7323A1569 for ; Thu, 27 Aug 2020 20:31:56 -0700 (PDT) Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 7C4C1C5D9A1F5FA742E8 for ; Fri, 28 Aug 2020 11:31:53 +0800 (CST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 5E29ECBEE6DA1914E876; Fri, 28 Aug 2020 11:31:53 +0800 (CST) Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl1.zte.com.cn with SMTP id 07S3Vcj1082884; Fri, 28 Aug 2020 11:31:38 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Fri, 28 Aug 2020 11:31:38 +0800 (CST) Date: Fri, 28 Aug 2020 11:31:38 +0800 (CST) X-Zmail-TransId: 2af95f487a9a8b675b4d X-Mailer: Zmail v1.0 Message-ID: <202008281131380547490@zte.com.cn> In-Reply-To: <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> References: 15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de, 52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 07S3Vcj1082884 Archived-At: Subject: Re: [spring] =?utf-8?q?to_drop_or_to_forward_unlabelled_=28Re=3A_Que?= =?utf-8?q?stion_on_RFC8660=29?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 03:32:07 -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 SGkgTWFydGluLA0KDQoNCg0KDQoNCg0KRm9yIHRoZSBtYXRjaGVkIExGSUIgZW50cnkgd2l0aCB1 bmxhYmVsZWQgb3V0Z29pbmcgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiwgSSBhZ3JlZSB5b3VyIG9w aW5pb24gdGhhdCBwdWJsaWMgdHJhZmZpYyBuZWVkIHRvIGJlIGZvcndhcmRlZC4gDQoNCg0KSSB0 aGluayB0aGUgYWJvdmUgTEZJQiBlbnRyeSBjYW4gZWFzaWVseSBkcm9wIFZQTiB0cmFmZmljIGFj Y29yZGluZyB0byBubyBib3R0b20gZmxhZyBvZiBpbmNvbW1pbmcgTERQL1NSIGxhYmVsLg0KDQoN Cg0KDQoNCg0KUmVnYXJkcywNCg0KDQpQU0YNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7tuS6uu+8mk1hcnRpbkhvcm5lZmZlciA8bWFo b0BsYWIuZHRhZy5kZT4NCuaUtuS7tuS6uu+8mnNwcmluZ0BpZXRmLm9yZyA8c3ByaW5nQGlldGYu b3JnPjsNCuaXpSDmnJ8g77yaMjAyMOW5tDA45pyIMjfml6UgMTg6MzUNCuS4uyDpopgg77yaW3Nw cmluZ10gdG8gZHJvcCBvciB0byBmb3J3YXJkIHVubGFiZWxsZWQgKFJlOiBRdWVzdGlvbiBvbiBS RkM4NjYwKQ0KDQoNCg0KDQpIZWxsbyBldmVyeW9uZSwNCg0KbWF5IEkgY29tZSBiYWNrIHRoZSB0 aGUgcXVlc3Rpb24gYmVsb3c/IE9yIHJhdGhlciBsZXQgbWUgdXBkYXRlIGl0IGEgbGl0dGxlOg0K DQpJbiBjYXNlIGFuIFNSLU1QTFMgcGF0aCBpcyBicm9rZW4sIHNob3VsZCBhIG5vZGUgcmF0aGVy IGRyb3AgdGhlIHBhY2tldCwgDQpvciBmb3J3YXJkIGl0Pw0KVGhpcyBjYW4gaGFwcGVuIHdoZW5l dmVyIHRoZSBJR1AgcG9pbnRzIHRvIGEgY2VydGFpbiBuZXh0IGhvcCwgYnV0IHRoYXQgDQpuZWl0 aGVyIHN1cHBsaWVzIGEgdmFsaWQgU0lELCBub3IgYWxsb3dzIExEUC1zdGl0Y2hpbmcgZm9yIHdo YXRldmVyIA0KcmVhc29uLiBGb3IgUFVTSCBhcyB3ZWxsIGFzIGZvciBDT05USU5VRS4NCg0KV2Ug aGF2ZSBiZWVuIHVzaW5nIE1QTFMgdHJhbnNwb3J0IGFuZCBhIEJHUCBmcmVlIGNvcmUgc2luY2Ug YWJvdXQgdHdvIA0KZGVjYWRlcyBub3csIHVzaW5nIExEUC4gSW4gdGhlIGFuYWxvZyBjYXNlLCBM RFAgY3JlYXRlcyAidW5sYWJlbGxlZCIgDQplbnRyaWVzIGluIHRoZSBMRklCLCBkb2VzIHRoZSBl cXVpdmFsZW50IG9mIGEgUE9QIG9wZXJhdGlvbiBhbmQgZm9yd2FyZHMgDQp0aGUgcGFja2V0IHRv IHRoZSBuZXh0LWhvcCBhcyBjaG9zZW4gYnkgdGhlIElHUC4NCg0KVGhpcyBiZWhhdmlvciBvYnZp b3VzbHkgYnJlYWtzIGFueSB0cmFmZmljIHRoYXQgcmVsaWVzIG9uIGEgc2VydmljZSANCmxhYmVs LCBidXQgaXQgY2FuIHByb3RlY3Qgc29tZSB0cmFmZmljLg0KSW4gb3VyIGNhc2UgYSBodWdlIHBl cmNlbnRhZ2Ugb2YgYWxsIHRyYWZmaWMgc3RpbGwgaXMgcHVibGljIElQdjQuIFRoaXMgDQpuZWVk cyBNUExTIG9ubHkgZm9yIGEgdHJhbnNwb3J0IGxhYmVsLCBiZSBpdCBMRFAgb3IgU1ItTVBMUy4g SWYgdGhpcyANCnRyYWZmaWMgZ2V0cyBmb3J3YXJkZWQgdW5sYWJlbGxlZCwgaXQgZm9sbG93cyBh biBJR1AgZGVmYXVsdCByb3V0ZSB0byBhIA0KY2VudHJhbCBkZXZpY2UsIHdoZXJlIGl0IGlzIDEp IHJlZGlyZWN0ZWQgdG8gdGhlIGNvcnJlY3QgZGVzdGluYXRpb24gYW5kIA0KMikgY291bnRlZCBp biBhIHdheSB0aGF0IG9wZXJhdG9ycyBjYW4gcXVpY2tseSBzZWUgd2hldGhlciBhbmQgd2hlcmUg DQp0aGlzIGtpbmQgb2YgZmFpbHVyZSBvY2N1cnMgYXQgc29tZSBwb2ludCBpbiB0aGUgbmV0d29y ay4NCg0KQWZ0ZXIgbW9yZSBvcGVyYXRpb25hbCBleHBlcmllbmNlIGFuZCBzZXZlcmFsIGludGVy bmFsIGRpc2N1c3Npb25zIHdlIA0KYWdyZWVkIHRoYXQgd2Ugd2FudCBwYWNrZXRzIHRvIGJlIGZv cndhcmRlZCB1bmxhYmVsbGVkIHJhdGhlciB0aGFuIA0KZHJvcHBlZC4gQW55b25lIHRvIHNoYXJl LCBvciBvcHBvc2UgdGhpcyBwb3NpdGlvbj8NCg0KQmVzdCByZWdhcmRzLCBNYXJ0aW4NCg0KDQpB bSAzMS4wMS4yMCB1bSAxNjo1MCBzY2hyaWViIE1hcnRpbiBIb3JuZWZmZXI6DQo+IEhlbGxvIGV2 ZXJ5b25lLA0KPg0KPiBhZ2FpbiBpdCBzZWVtcyB0aGUgaW50ZXJlc3RpbmcgcXVlc3Rpb25zIG9u bHkgc2hvdyB1cCB3aGVuIGFwcGx5aW5nIA0KPiBzb21ldGhpbmcgdG8gdGhlIGxpdmUgbmV0d29y ay4uLg0KPg0KPiBXZSByYW4gaW50byBzb21ldGhpbmcgdGhhdCBwb3NlcyBhIHF1ZXN0aW9uIHJl bGF0ZWQgdG8gUkZDODY2MDogV2hhdCANCj4gaXMgdGhlIGV4YWN0IG1lYW5pbmcgb2Ygc2VjdGlv biAyLjEwLjEsICJGb3J3YXJkaW5nIGZvciBQVVNIIGFuZCANCj4gQ09OVElOVUUgb2YgR2xvYmFs IFNJRHMiLCB3aGVuIHRoZSBjaG9zZW4gbmVpZ2hib3IgZG9lc24ndCBwcm92aWRlIGEgDQo+IHZh bGlkIE1QTFMgcGF0aD8NCj4NCj4gVGhlIHJlbGV2YW50IHNlY3Rpb25zIHJlYWRzOg0KPg0KPiAg ICAgICAtICBFbHNlLCBpZiB0aGVyZSBhcmUgb3RoZXIgdXNhYmxlIG5leHQgaG9wcywgdXNlIHRo ZW0gdG8gZm9yd2FyZA0KPiAgICAgICAgICB0aGUgaW5jb21pbmcgcGFja2V0LiAgVGhlIG1ldGhv ZCBieSB3aGljaCB0aGUgcm91dGVyICJSMCINCj4gICAgICAgICAgZGVjaWRlcyBvbiB0aGUgcG9z c2liaWxpdHkgb2YgdXNpbmcgb3RoZXIgbmV4dCBob3BzIGlzIGJleW9uZA0KPiAgICAgICAgICB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEZvciBleGFtcGxlLCB0aGUgTUNDIG9uICJSMCIg bWF5DQo+ICAgICAgICAgIGNob3NlIHRoZSBzZW5kIGFuIElQdjQgcGFja2V0IHdpdGhvdXQgcHVz aGluZyBhbnkgbGFiZWwgdG8NCj4gICAgICAgICAgYW5vdGhlciBuZXh0IGhvcC4NCj4NCj4gRG9l cyB0aGUgcGFydCAic2VuZCBhbiBJUHY0IHBhY2tldCB3aXRob3V0IHB1c2hpbmcgYW55IGxhYmVs IiBhcHBseSB0byANCj4gUFVTSCBhbmQgQ09OVElOVUUsIG9yIGp1c3QgdG8gUFVTSD8NCj4gRG9l cyBSMCBoYXZlIHRvIHZhbGlkYXRlIHRoYXQgbmVpZ2hib3IgTiBjYW4gY29ycmVjdGx5IHByb2Nl c3MgdG8gDQo+IHBhY2tldD8gT3IgY2FuIGl0IGZvcndhcmQgdGhlIHBhY2tldCByZWdhcmRsZXNz Pw0KPg0KPiBUaGUgcmVhc29uIGZvciBhc2tpbmcgaXMgdGhhdCB3ZSBhcmUgbm93IHNlZWluZyBp c3N1ZXMgc2ltaWxhciB0byBvbmVzIA0KPiB3ZSBoYWQgd2hlbiBzdGFydGluZyB3aXRoIExEUCBi YXNlZCBNUExTIGFib3V0IHR3byBkZWNhZGVzIGFnbzogDQo+IHRyYWZmaWMgYmVpbmcgYmxhY2sg aG9sZWQgZXZlbiB0aG91Z2ggYSBwYXRoIHRvIHRoZSBkZXN0aW5hdGlvbiANCj4gZXhpc3RzLCBi ZWNhdXNlIHRoZSBNUExTIHBhdGggaXMgaW50ZXJydXB0ZWQgc29tZXdoZXJlIGluIHRoZSBtaWRk bGUuDQo+DQo+IFdpdGggTERQIHdlIGtub3cgdGhlIGNhc2Ugb2YgTEZJQmVudHJpZXMgY2FsbGVk ICJ1bmxhYmVsbGVkIi4gV2hpbGUgDQo+IHRoaXMgZG9lcyBicmVhayBjb25uZWN0aXZpdHkgZm9y IG1hbnkga2luZHMgb2Ygc2VydmljZSwgZS5nLiB0aG9zZSANCj4gcmVseWluZyBvbiBhbiBhZGRp dGlvbmFsIHNlcnZpY2UgbGFiZWxzLCBpdCBzdGlsbCB3b3JrcyBmb3IgcGxhaW4gDQo+IElQKHY0 KSB0cmFmZmljLiBJbiBvdXIgY2FzZXMsIHRoaXMgd29ya3MgcGVyZmVjdGx5IGZpbmUgZm9yIGFs bCANCj4gaW50ZXJuYWwgcm91dGluZyBhbmQgY29udHJvbCB0cmFmZmljLiBBbmQgZXZlbiBmb3Ig SVB2NCB0cmFmZmljIHRoYXQgDQo+IGdldHMgY29sbGVjdGVkIGJ5IGEgY2VudHJhbCByb3V0ZXIg dGhhdCBpbmplY3RzIGEgZGVmYXVsdCByb3V0ZS4NCj4NCj4gSG93ZXZlciwgZGVwZW5kaW5nIG9u IHRoZSBleGFjdCBpbnRlcnByZXRhdGlvbiBvZiB0aGUgYWJvdmUgcGFyYWdyYXBoLCANCj4gYW4g aW1wbGVtZW50b3IgbWlnaHQgZmVlbCBvYmxpZ2VkIHRvIGNob3NlIHRoZSBuZXh0IHBhcmFncmFw aDoNCj4NCj4gICAgICAgLSAgT3RoZXJ3aXNlLCBkcm9wIHRoZSBwYWNrZXQuDQo+DQo+IFdoaWNo IGlzLCBhdCBsZWFzdCBpbiBvdXIgY2FzZSwgdmVyeSB1bmZvcnR1bmF0ZS4uLg0KPg0KPiBBbnkg YWR2aWNlIG9yIG9waW5pb24gYXBwcmVjaWF0ZWQhDQo+DQo+DQo+IEJlc3QgcmVnYXJkcywgTWFy dGluDQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gc3ByaW5nQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0 DQpzcHJpbmdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5n --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MThweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxOHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+SGkgTWFydGluLDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE4cHg7Zm9udC1mYW1p bHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MThweDtmb250LWZhbWlseTph cmlhbDsiPkZvciB0aGUgbWF0Y2hlZCBMRklCIGVudHJ5IHdpdGggdW5sYWJlbGVkIG91dGdvaW5n IGZvcndhcmRpbmcgaW5mb3JtYXRpb24sIEkgYWdyZWUgeW91ciBvcGluaW9uIHRoYXQgcHVibGlj IHRyYWZmaWMgbmVlZCB0byBiZSBmb3J3YXJkZWQuJm5ic3A7PC9wPjxwIHN0eWxlPSJmb250LXNp emU6MThweDtmb250LWZhbWlseTphcmlhbDsiPkkgdGhpbmsgdGhlIGFib3ZlIExGSUIgZW50cnkg Y2FuIGVhc2llbHkgZHJvcCBWUE4gdHJhZmZpYyBhY2NvcmRpbmcgdG8gbm8gYm90dG9tIGZsYWcg b2YgaW5jb21taW5nIExEUC9TUiBsYWJlbC48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxOHB4O2Zv bnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE4cHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij5SZWdhcmRzLDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE4cHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij5QU0Y8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxOHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+PGJyPjwvcD48ZGl2IGNsYXNzPSJ6TWFpbFNpZ24iIHVub25hbWVjaD0i5b2t5bCR 5a+MMTAwNTM4MTUiIHVub25hbWVlbj0icGVuZyBzaGFvZnUxMDA1MzgxNSI+PGRpdiBjbGFzcz0i ek1haWxTaWduQ29udGVudCI+PGRpdj48cD48YnI+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYg Y2xhc3M9InpNYWlsRnJvbSI+PC9kaXY+PGRpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5 bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9InpoaXN0b3J5RGVzIiBzdHlsZT0id2lkdGg6 IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6IDI4cHg7IGJhY2tncm91bmQtY29sb3I6 ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFsaWduOiBjZW50ZXI7IiBsYW5ndWFnZS1k YXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8L2Rpdj48ZGl2IGlkPSJ6d3JpdGVIaXN0 b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9sLWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxk aXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0icGFkZGluZzogOHB4OyBiYWNrZ3JvdW5k LWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTZW5k ZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIj5N YXJ0aW5Ib3JuZWZmZXIgJmx0O21haG9AbGFiLmR0YWcuZGUmZ3Q7PC9zcGFuPjwvZGl2PjxkaXY+ PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQiPuaUtuS7tuS6uu+8mjwvc3Ryb25n PjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+c3By aW5nQGlldGYub3JnICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2Pjxz dHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+ PHNwYW4gY2xhc3M9IiI+MjAyMOW5tDA45pyIMjfml6UgMTg6MzU8L3NwYW4+PC9kaXY+PGRpdj48 c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ry b25nPjxzcGFuIGNsYXNzPSJ6cmVhZFRpdGxlIj48c3Ryb25nPltzcHJpbmddIHRvIGRyb3Agb3Ig dG8gZm9yd2FyZCB1bmxhYmVsbGVkIChSZTogUXVlc3Rpb24gb24gUkZDODY2MCk8L3N0cm9uZz48 L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiB6bWFpbGJ1c2luZXNzPSJidXNpbmVzc0V4dGVybmFsIj48 L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRlbnQiPjxkaXY+SGVsbG8mbmJzcDtldmVyeW9u ZSw8YnI+PGJyPm1heSZuYnNwO0kmbmJzcDtjb21lJm5ic3A7YmFjayZuYnNwO3RoZSZuYnNwO3Ro ZSZuYnNwO3F1ZXN0aW9uJm5ic3A7YmVsb3c/Jm5ic3A7T3ImbmJzcDtyYXRoZXImbmJzcDtsZXQm bmJzcDttZSZuYnNwO3VwZGF0ZSZuYnNwO2l0Jm5ic3A7YSZuYnNwO2xpdHRsZTo8YnI+PGJyPklu Jm5ic3A7Y2FzZSZuYnNwO2FuJm5ic3A7U1ItTVBMUyZuYnNwO3BhdGgmbmJzcDtpcyZuYnNwO2Jy b2tlbiwmbmJzcDtzaG91bGQmbmJzcDthJm5ic3A7bm9kZSZuYnNwO3JhdGhlciZuYnNwO2Ryb3Am bmJzcDt0aGUmbmJzcDtwYWNrZXQsJm5ic3A7PGJyPm9yJm5ic3A7Zm9yd2FyZCZuYnNwO2l0Pzxi cj5UaGlzJm5ic3A7Y2FuJm5ic3A7aGFwcGVuJm5ic3A7d2hlbmV2ZXImbmJzcDt0aGUmbmJzcDtJ R1AmbmJzcDtwb2ludHMmbmJzcDt0byZuYnNwO2EmbmJzcDtjZXJ0YWluJm5ic3A7bmV4dCZuYnNw O2hvcCwmbmJzcDtidXQmbmJzcDt0aGF0Jm5ic3A7PGJyPm5laXRoZXImbmJzcDtzdXBwbGllcyZu YnNwO2EmbmJzcDt2YWxpZCZuYnNwO1NJRCwmbmJzcDtub3ImbmJzcDthbGxvd3MmbmJzcDtMRFAt c3RpdGNoaW5nJm5ic3A7Zm9yJm5ic3A7d2hhdGV2ZXImbmJzcDs8YnI+cmVhc29uLiZuYnNwO0Zv ciZuYnNwO1BVU0gmbmJzcDthcyZuYnNwO3dlbGwmbmJzcDthcyZuYnNwO2ZvciZuYnNwO0NPTlRJ TlVFLjxicj48YnI+V2UmbmJzcDtoYXZlJm5ic3A7YmVlbiZuYnNwO3VzaW5nJm5ic3A7TVBMUyZu YnNwO3RyYW5zcG9ydCZuYnNwO2FuZCZuYnNwO2EmbmJzcDtCR1AmbmJzcDtmcmVlJm5ic3A7Y29y ZSZuYnNwO3NpbmNlJm5ic3A7YWJvdXQmbmJzcDt0d28mbmJzcDs8YnI+ZGVjYWRlcyZuYnNwO25v dywmbmJzcDt1c2luZyZuYnNwO0xEUC4mbmJzcDtJbiZuYnNwO3RoZSZuYnNwO2FuYWxvZyZuYnNw O2Nhc2UsJm5ic3A7TERQJm5ic3A7Y3JlYXRlcyZuYnNwOyJ1bmxhYmVsbGVkIiZuYnNwOzxicj5l bnRyaWVzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtMRklCLCZuYnNwO2RvZXMmbmJzcDt0aGUmbmJz cDtlcXVpdmFsZW50Jm5ic3A7b2YmbmJzcDthJm5ic3A7UE9QJm5ic3A7b3BlcmF0aW9uJm5ic3A7 YW5kJm5ic3A7Zm9yd2FyZHMmbmJzcDs8YnI+dGhlJm5ic3A7cGFja2V0Jm5ic3A7dG8mbmJzcDt0 aGUmbmJzcDtuZXh0LWhvcCZuYnNwO2FzJm5ic3A7Y2hvc2VuJm5ic3A7YnkmbmJzcDt0aGUmbmJz cDtJR1AuPGJyPjxicj5UaGlzJm5ic3A7YmVoYXZpb3ImbmJzcDtvYnZpb3VzbHkmbmJzcDticmVh a3MmbmJzcDthbnkmbmJzcDt0cmFmZmljJm5ic3A7dGhhdCZuYnNwO3JlbGllcyZuYnNwO29uJm5i c3A7YSZuYnNwO3NlcnZpY2UmbmJzcDs8YnI+bGFiZWwsJm5ic3A7YnV0Jm5ic3A7aXQmbmJzcDtj YW4mbmJzcDtwcm90ZWN0Jm5ic3A7c29tZSZuYnNwO3RyYWZmaWMuPGJyPkluJm5ic3A7b3VyJm5i c3A7Y2FzZSZuYnNwO2EmbmJzcDtodWdlJm5ic3A7cGVyY2VudGFnZSZuYnNwO29mJm5ic3A7YWxs Jm5ic3A7dHJhZmZpYyZuYnNwO3N0aWxsJm5ic3A7aXMmbmJzcDtwdWJsaWMmbmJzcDtJUHY0LiZu YnNwO1RoaXMmbmJzcDs8YnI+bmVlZHMmbmJzcDtNUExTJm5ic3A7b25seSZuYnNwO2ZvciZuYnNw O2EmbmJzcDt0cmFuc3BvcnQmbmJzcDtsYWJlbCwmbmJzcDtiZSZuYnNwO2l0Jm5ic3A7TERQJm5i c3A7b3ImbmJzcDtTUi1NUExTLiZuYnNwO0lmJm5ic3A7dGhpcyZuYnNwOzxicj50cmFmZmljJm5i c3A7Z2V0cyZuYnNwO2ZvcndhcmRlZCZuYnNwO3VubGFiZWxsZWQsJm5ic3A7aXQmbmJzcDtmb2xs b3dzJm5ic3A7YW4mbmJzcDtJR1AmbmJzcDtkZWZhdWx0Jm5ic3A7cm91dGUmbmJzcDt0byZuYnNw O2EmbmJzcDs8YnI+Y2VudHJhbCZuYnNwO2RldmljZSwmbmJzcDt3aGVyZSZuYnNwO2l0Jm5ic3A7 aXMmbmJzcDsxKSZuYnNwO3JlZGlyZWN0ZWQmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2NvcnJlY3Qm bmJzcDtkZXN0aW5hdGlvbiZuYnNwO2FuZCZuYnNwOzxicj4yKSZuYnNwO2NvdW50ZWQmbmJzcDtp biZuYnNwO2EmbmJzcDt3YXkmbmJzcDt0aGF0Jm5ic3A7b3BlcmF0b3JzJm5ic3A7Y2FuJm5ic3A7 cXVpY2tseSZuYnNwO3NlZSZuYnNwO3doZXRoZXImbmJzcDthbmQmbmJzcDt3aGVyZSZuYnNwOzxi cj50aGlzJm5ic3A7a2luZCZuYnNwO29mJm5ic3A7ZmFpbHVyZSZuYnNwO29jY3VycyZuYnNwO2F0 Jm5ic3A7c29tZSZuYnNwO3BvaW50Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtuZXR3b3JrLjxicj48 YnI+QWZ0ZXImbmJzcDttb3JlJm5ic3A7b3BlcmF0aW9uYWwmbmJzcDtleHBlcmllbmNlJm5ic3A7 YW5kJm5ic3A7c2V2ZXJhbCZuYnNwO2ludGVybmFsJm5ic3A7ZGlzY3Vzc2lvbnMmbmJzcDt3ZSZu YnNwOzxicj5hZ3JlZWQmbmJzcDt0aGF0Jm5ic3A7d2UmbmJzcDt3YW50Jm5ic3A7cGFja2V0cyZu YnNwO3RvJm5ic3A7YmUmbmJzcDtmb3J3YXJkZWQmbmJzcDt1bmxhYmVsbGVkJm5ic3A7cmF0aGVy Jm5ic3A7dGhhbiZuYnNwOzxicj5kcm9wcGVkLiZuYnNwO0FueW9uZSZuYnNwO3RvJm5ic3A7c2hh cmUsJm5ic3A7b3ImbmJzcDtvcHBvc2UmbmJzcDt0aGlzJm5ic3A7cG9zaXRpb24/PGJyPjxicj5C ZXN0Jm5ic3A7cmVnYXJkcywmbmJzcDtNYXJ0aW48YnI+PGJyPjxicj5BbSZuYnNwOzMxLjAxLjIw Jm5ic3A7dW0mbmJzcDsxNjo1MCZuYnNwO3NjaHJpZWImbmJzcDtNYXJ0aW4mbmJzcDtIb3JuZWZm ZXI6PGJyPiZndDsmbmJzcDtIZWxsbyZuYnNwO2V2ZXJ5b25lLDxicj4mZ3Q7PGJyPiZndDsmbmJz cDthZ2FpbiZuYnNwO2l0Jm5ic3A7c2VlbXMmbmJzcDt0aGUmbmJzcDtpbnRlcmVzdGluZyZuYnNw O3F1ZXN0aW9ucyZuYnNwO29ubHkmbmJzcDtzaG93Jm5ic3A7dXAmbmJzcDt3aGVuJm5ic3A7YXBw bHlpbmcmbmJzcDs8YnI+Jmd0OyZuYnNwO3NvbWV0aGluZyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7 bGl2ZSZuYnNwO25ldHdvcmsuLi48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7V2UmbmJzcDtyYW4mbmJz cDtpbnRvJm5ic3A7c29tZXRoaW5nJm5ic3A7dGhhdCZuYnNwO3Bvc2VzJm5ic3A7YSZuYnNwO3F1 ZXN0aW9uJm5ic3A7cmVsYXRlZCZuYnNwO3RvJm5ic3A7UkZDODY2MDombmJzcDtXaGF0Jm5ic3A7 PGJyPiZndDsmbmJzcDtpcyZuYnNwO3RoZSZuYnNwO2V4YWN0Jm5ic3A7bWVhbmluZyZuYnNwO29m Jm5ic3A7c2VjdGlvbiZuYnNwOzIuMTAuMSwmbmJzcDsiRm9yd2FyZGluZyZuYnNwO2ZvciZuYnNw O1BVU0gmbmJzcDthbmQmbmJzcDs8YnI+Jmd0OyZuYnNwO0NPTlRJTlVFJm5ic3A7b2YmbmJzcDtH bG9iYWwmbmJzcDtTSURzIiwmbmJzcDt3aGVuJm5ic3A7dGhlJm5ic3A7Y2hvc2VuJm5ic3A7bmVp Z2hib3ImbmJzcDtkb2Vzbid0Jm5ic3A7cHJvdmlkZSZuYnNwO2EmbmJzcDs8YnI+Jmd0OyZuYnNw O3ZhbGlkJm5ic3A7TVBMUyZuYnNwO3BhdGg/PGJyPiZndDs8YnI+Jmd0OyZuYnNwO1RoZSZuYnNw O3JlbGV2YW50Jm5ic3A7c2VjdGlvbnMmbmJzcDtyZWFkczo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwOyZuYnNwO0Vsc2UsJm5i c3A7aWYmbmJzcDt0aGVyZSZuYnNwO2FyZSZuYnNwO290aGVyJm5ic3A7dXNhYmxlJm5ic3A7bmV4 dCZuYnNwO2hvcHMsJm5ic3A7dXNlJm5ic3A7dGhlbSZuYnNwO3RvJm5ic3A7Zm9yd2FyZDxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlJm5ic3A7aW5jb21pbmcmbmJzcDtwYWNrZXQuJm5ic3A7Jm5ic3A7VGhlJm5ic3A7 bWV0aG9kJm5ic3A7YnkmbmJzcDt3aGljaCZuYnNwO3RoZSZuYnNwO3JvdXRlciZuYnNwOyJSMCI8 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2RlY2lkZXMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO3Bvc3NpYmlsaXR5Jm5ic3A7 b2YmbmJzcDt1c2luZyZuYnNwO290aGVyJm5ic3A7bmV4dCZuYnNwO2hvcHMmbmJzcDtpcyZuYnNw O2JleW9uZDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlJm5ic3A7c2NvcGUmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtk b2N1bWVudC4mbmJzcDsmbmJzcDtGb3ImbmJzcDtleGFtcGxlLCZuYnNwO3RoZSZuYnNwO01DQyZu YnNwO29uJm5ic3A7IlIwIiZuYnNwO21heTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2hvc2UmbmJzcDt0aGUmbmJzcDtz ZW5kJm5ic3A7YW4mbmJzcDtJUHY0Jm5ic3A7cGFja2V0Jm5ic3A7d2l0aG91dCZuYnNwO3B1c2hp bmcmbmJzcDthbnkmbmJzcDtsYWJlbCZuYnNwO3RvPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthbm90aGVyJm5ic3A7bmV4 dCZuYnNwO2hvcC48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7RG9lcyZuYnNwO3RoZSZuYnNwO3BhcnQm bmJzcDsic2VuZCZuYnNwO2FuJm5ic3A7SVB2NCZuYnNwO3BhY2tldCZuYnNwO3dpdGhvdXQmbmJz cDtwdXNoaW5nJm5ic3A7YW55Jm5ic3A7bGFiZWwiJm5ic3A7YXBwbHkmbmJzcDt0byZuYnNwOzxi cj4mZ3Q7Jm5ic3A7UFVTSCZuYnNwO2FuZCZuYnNwO0NPTlRJTlVFLCZuYnNwO29yJm5ic3A7anVz dCZuYnNwO3RvJm5ic3A7UFVTSD88YnI+Jmd0OyZuYnNwO0RvZXMmbmJzcDtSMCZuYnNwO2hhdmUm bmJzcDt0byZuYnNwO3ZhbGlkYXRlJm5ic3A7dGhhdCZuYnNwO25laWdoYm9yJm5ic3A7TiZuYnNw O2NhbiZuYnNwO2NvcnJlY3RseSZuYnNwO3Byb2Nlc3MmbmJzcDt0byZuYnNwOzxicj4mZ3Q7Jm5i c3A7cGFja2V0PyZuYnNwO09yJm5ic3A7Y2FuJm5ic3A7aXQmbmJzcDtmb3J3YXJkJm5ic3A7dGhl Jm5ic3A7cGFja2V0Jm5ic3A7cmVnYXJkbGVzcz88YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7VGhlJm5i c3A7cmVhc29uJm5ic3A7Zm9yJm5ic3A7YXNraW5nJm5ic3A7aXMmbmJzcDt0aGF0Jm5ic3A7d2Um bmJzcDthcmUmbmJzcDtub3cmbmJzcDtzZWVpbmcmbmJzcDtpc3N1ZXMmbmJzcDtzaW1pbGFyJm5i c3A7dG8mbmJzcDtvbmVzJm5ic3A7PGJyPiZndDsmbmJzcDt3ZSZuYnNwO2hhZCZuYnNwO3doZW4m bmJzcDtzdGFydGluZyZuYnNwO3dpdGgmbmJzcDtMRFAmbmJzcDtiYXNlZCZuYnNwO01QTFMmbmJz cDthYm91dCZuYnNwO3R3byZuYnNwO2RlY2FkZXMmbmJzcDthZ286Jm5ic3A7PGJyPiZndDsmbmJz cDt0cmFmZmljJm5ic3A7YmVpbmcmbmJzcDtibGFjayZuYnNwO2hvbGVkJm5ic3A7ZXZlbiZuYnNw O3Rob3VnaCZuYnNwO2EmbmJzcDtwYXRoJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtkZXN0aW5hdGlv biZuYnNwOzxicj4mZ3Q7Jm5ic3A7ZXhpc3RzLCZuYnNwO2JlY2F1c2UmbmJzcDt0aGUmbmJzcDtN UExTJm5ic3A7cGF0aCZuYnNwO2lzJm5ic3A7aW50ZXJydXB0ZWQmbmJzcDtzb21ld2hlcmUmbmJz cDtpbiZuYnNwO3RoZSZuYnNwO21pZGRsZS48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7V2l0aCZuYnNw O0xEUCZuYnNwO3dlJm5ic3A7a25vdyZuYnNwO3RoZSZuYnNwO2Nhc2UmbmJzcDtvZiZuYnNwO0xG SUJlbnRyaWVzJm5ic3A7Y2FsbGVkJm5ic3A7InVubGFiZWxsZWQiLiZuYnNwO1doaWxlJm5ic3A7 PGJyPiZndDsmbmJzcDt0aGlzJm5ic3A7ZG9lcyZuYnNwO2JyZWFrJm5ic3A7Y29ubmVjdGl2aXR5 Jm5ic3A7Zm9yJm5ic3A7bWFueSZuYnNwO2tpbmRzJm5ic3A7b2YmbmJzcDtzZXJ2aWNlLCZuYnNw O2UuZy4mbmJzcDt0aG9zZSZuYnNwOzxicj4mZ3Q7Jm5ic3A7cmVseWluZyZuYnNwO29uJm5ic3A7 YW4mbmJzcDthZGRpdGlvbmFsJm5ic3A7c2VydmljZSZuYnNwO2xhYmVscywmbmJzcDtpdCZuYnNw O3N0aWxsJm5ic3A7d29ya3MmbmJzcDtmb3ImbmJzcDtwbGFpbiZuYnNwOzxicj4mZ3Q7Jm5ic3A7 SVAodjQpJm5ic3A7dHJhZmZpYy4mbmJzcDtJbiZuYnNwO291ciZuYnNwO2Nhc2VzLCZuYnNwO3Ro aXMmbmJzcDt3b3JrcyZuYnNwO3BlcmZlY3RseSZuYnNwO2ZpbmUmbmJzcDtmb3ImbmJzcDthbGwm bmJzcDs8YnI+Jmd0OyZuYnNwO2ludGVybmFsJm5ic3A7cm91dGluZyZuYnNwO2FuZCZuYnNwO2Nv bnRyb2wmbmJzcDt0cmFmZmljLiZuYnNwO0FuZCZuYnNwO2V2ZW4mbmJzcDtmb3ImbmJzcDtJUHY0 Jm5ic3A7dHJhZmZpYyZuYnNwO3RoYXQmbmJzcDs8YnI+Jmd0OyZuYnNwO2dldHMmbmJzcDtjb2xs ZWN0ZWQmbmJzcDtieSZuYnNwO2EmbmJzcDtjZW50cmFsJm5ic3A7cm91dGVyJm5ic3A7dGhhdCZu YnNwO2luamVjdHMmbmJzcDthJm5ic3A7ZGVmYXVsdCZuYnNwO3JvdXRlLjxicj4mZ3Q7PGJyPiZn dDsmbmJzcDtIb3dldmVyLCZuYnNwO2RlcGVuZGluZyZuYnNwO29uJm5ic3A7dGhlJm5ic3A7ZXhh Y3QmbmJzcDtpbnRlcnByZXRhdGlvbiZuYnNwO29mJm5ic3A7dGhlJm5ic3A7YWJvdmUmbmJzcDtw YXJhZ3JhcGgsJm5ic3A7PGJyPiZndDsmbmJzcDthbiZuYnNwO2ltcGxlbWVudG9yJm5ic3A7bWln aHQmbmJzcDtmZWVsJm5ic3A7b2JsaWdlZCZuYnNwO3RvJm5ic3A7Y2hvc2UmbmJzcDt0aGUmbmJz cDtuZXh0Jm5ic3A7cGFyYWdyYXBoOjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7Jm5ic3A7T3RoZXJ3aXNlLCZuYnNwO2Ryb3Am bmJzcDt0aGUmbmJzcDtwYWNrZXQuPGJyPiZndDs8YnI+Jmd0OyZuYnNwO1doaWNoJm5ic3A7aXMs Jm5ic3A7YXQmbmJzcDtsZWFzdCZuYnNwO2luJm5ic3A7b3VyJm5ic3A7Y2FzZSwmbmJzcDt2ZXJ5 Jm5ic3A7dW5mb3J0dW5hdGUuLi48YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7QW55Jm5ic3A7YWR2aWNl Jm5ic3A7b3ImbmJzcDtvcGluaW9uJm5ic3A7YXBwcmVjaWF0ZWQhPGJyPiZndDs8YnI+Jmd0Ozxi cj4mZ3Q7Jm5ic3A7QmVzdCZuYnNwO3JlZ2FyZHMsJm5ic3A7TWFydGluPGJyPiZndDs8YnI+Jmd0 Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmbmJzcDtzcHJpbmcmbmJzcDttYWlsaW5nJm5i c3A7bGlzdDxicj4mZ3Q7Jm5ic3A7c3ByaW5nQGlldGYub3JnPGJyPiZndDsmbmJzcDtodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxicj48YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+c3ByaW5nJm5ic3A7bWFpbGlu ZyZuYnNwO2xpc3Q8YnI+c3ByaW5nQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3ByaW5nPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjxwPjxicj48L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Thu Aug 27 23:25:56 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40693A0D52 for ; Thu, 27 Aug 2020 23:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.499, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r8pz7wQjaoKV for ; Thu, 27 Aug 2020 23:25:49 -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 75C253A159B for ; Thu, 27 Aug 2020 23:25:48 -0700 (PDT) Received: from lhreml729-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 702C07E6396F6F0CF0F6 for ; Fri, 28 Aug 2020 07:25:46 +0100 (IST) Received: from lhreml748-chm.china.huawei.com (10.201.108.198) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 28 Aug 2020 07:25:46 +0100 Received: from lhreml748-chm.china.huawei.com (10.201.108.198) by lhreml748-chm.china.huawei.com (10.201.108.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 28 Aug 2020 07:25:44 +0100 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml748-chm.china.huawei.com (10.201.108.198) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 28 Aug 2020 07:25:43 +0100 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.60]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Fri, 28 Aug 2020 14:25:41 +0800 From: "Chengli (Cheng Li)" To: "Ketan Talaulikar (ketant)" , "Robert Raszuk" CC: Alexander Vainshtein , "spring@ietf.org" , "Joel M. Halpern" , Shraddha Hegde , "EXT-Andrew.Alston@liquidtelecom.com" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfMxHlh+yzcCkewTBiyswjXMaklNGAAgAA0D4CAAMHVAIAABZ6AgAABgICAADUsgIAAC1WAgAAdJ4CAAGzfgIAAFLcAgAB1eACAD4ZiAIAADy+AgAAIGQCAABlPgIAACqaAgAAC7QCAAAmcgIAAFWuAgAADZQCAFcaKoA== Date: Fri, 28 Aug 2020 06:25:41 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4229284b-9a73-612b-306d-2818f37dd5b3@joelhalpern.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.130] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4B2dggeml509mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 06:25:55 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4B2dggeml509mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2V0YW4gYW5kIFJvYmVydCwNCg0KSSB0aGluayB3ZSBuZWVkIHRvIHNpZ25hbCBieXBhc3Mt YWJsZSBpbmRpY2F0aW9uIGZvciBwcmVmaXggU0lEcyBpbiBJR1AsIGFuZCBJIHRoaW5rIHRoaXMg aGFzIGJlZW4gd3JpdHRlbiBpbiBbMV0uIEJ1dCBpbiB0aGlzIGRyYWZ0LCB3ZSBhbHNvIGFkZCBO by1ieXBhc3MgZmxhZyBmb3IgYWRqLVNJRCBhcyB3ZWxsLiBXZSBtYXkgbmVlZCB0byBkaXNjdXNz IHRoYXQgZG8gd2UgbmVlZCBpdCBvciBub3Qgc2luY2UgQiBmbGFnIGlzIHRoZXJlIGFscmVhZHku DQoNCkFsc28sIG9wZXJhdG9yc+KAmSBQT1ZzIGFyZSBhbHdheXMgaW1wb3J0YW50LCB3ZSBjYW4g cmVhY2ggb3V0IHRvIHNvbWUgb3BlcmF0b3JzIEFTQVAuDQoNClRoYW5rcywNCkNoZW5nDQoNCg0K WzFdLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktcnRnd2ctZW5oYW5jZWQt dGktbGZhLTAyDQoNCg0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkNClNlbnQ6IFNhdHVy ZGF5LCBBdWd1c3QgMTUsIDIwMjAgMTo0NiBBTQ0KVG86IFJvYmVydCBSYXN6dWsgPHJvYmVydEBy YXN6dWsubmV0Pg0KQ2M6IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVp bkByYmJuLmNvbT47IHNwcmluZ0BpZXRmLm9yZzsgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhh bHBlcm4uY29tPjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PjsgRVhULUFu ZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb20+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1p bmluZyBhcHBsaWNhYmlsaXR5DQoNCkhpIFJvYmVydCwNCg0KV2UgZG8gbm90IGhhdmUgYSBzaWdu YWxsaW5nIG1lY2hhbmlzbSBpbiBJR1BzIHRvZGF5IHRvIGluZGljYXRlIGEg4oCcYnlwYXNzLWFi bGXigJ0gaW5kaWNhdGlvbiBmb3IgUHJlZml4IFNJRHMuIElmIHRoZXJlIHdhcyBhIGRlc2lyZSBm b3IgaXQsIGFuIElHUCBleHRlbnNpb24gd291bGQgYmUgcmVxdWlyZWQgKHRoZXJlIGlzIG5vbmUg aW4gcHJvZ3Jlc3MgQUZBSUspLiBOb3RlIHRoYXQgdGhpcyByZXN1bHRzIGluIGRvdWJsaW5nIHRo ZSBwcmVmaXggU0lEIHNjYWxlIChnbG9iYWwgbGFiZWxzKSBpbiB0aGUgbmV0d29yay4gU28gSSB3 b3VsZCBub3QgZ28gYWJvdXQgdGhpcyB0cml2aWFsbHkuDQoNCkkgdGhpbmsgaXQgaGVscHMgdG8g Z2V0IG1vcmUgaW5wdXRzIGFuZCBwZXJzcGVjdGl2ZXMgZnJvbSBvcGVyYXRvcnMgb24gdGhlaXIg dmlld3MgZm9yIGRvaW5nIGEgYnlwYXNzIHZpYSBsb2NhbCBwcm90ZWN0aW9uIGZvciBzZWdtZW50 cyBpbiBhbiBTUiBQb2xpY3kuIFRoZXJlIG1heSBiZSB0aG9zZSB0aGF0IHByZWZlciBlbmQtdG8t ZW5kIHBhdGggcHJvdGVjdGlvbiB1c2luZyBhIGZhbGxiYWNrIHBhdGggdGhhdCBpcyBzYXkgZGlz am9pbnQgd2l0aCB0aGUgcHJpbWFyeSBidXQgcHJvdmlkZXMgYW4gYXBwcm9wcmlhdGUgU0xBL2lu dGVudD8NCg0KVGhhbmtzLA0KS2V0YW4NCg0KRnJvbTogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJh c3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NClNlbnQ6IDE0IEF1Z3VzdCAyMDIw IDIzOjA0DQpUbzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbTxt YWlsdG86a2V0YW50QGNpc2NvLmNvbT4+DQpDYzogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhh bmRlci5WYWluc2h0ZWluQHJiYm4uY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJu LmNvbT4+OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBq b2VsaGFscGVybi5jb20+PjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PG1h aWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldD4+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+IDxBbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPj47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGlj YWJpbGl0eQ0KDQpLZXRhbiwNCg0KTG9va3MgbGlrZSB3ZSBhcmUgcHJldHR5IG11Y2ggaW4gc3lu YyBoZXJlLg0KDQpCdXQgbGV0IG1lIGp1c3Qgb2JzZXJ2ZSB0aGF0IEkgcHVycG9zZWx5IGRpZCBu b3QgbWVudGlvbiBhYm91dCBTUiBwb2xpY2llcyBhcyB3ZSBhcmUgbm90IGFibGUgdG8gc2lnbmFs IHRoZSBpbnRlbnQgd2l0aCB0aGUgcGFja2V0cyBpdHNlbGYuDQoNClNvIGFsbCB3ZSBoYXZlIHRo ZXJlIGlzIFNJRHMuIEJTSURzIG9yIHByZWZpeCBTSURzIG5lZWQgdG8gYmUgZmxvb2RlZCB3aXRo IGluZm9ybWF0aW9uIGlmIHBvbGljaWVzIGJ1aWxkIHdpdGggdXNpbmcgdGhlbSBhcmUgYnlwYXNz IGVsaWdpYmxlIG9yIG5vdC4NCg0KSSB3YXMgYWN0dWFsbHkgdW5kZXIgdGhlIGltcHJlc3Npb24g dGhhdCB0aGlzIGlzIGFscmVhZHkgdGhlcmUgYW5kIEkgYW0ganVzdCBub3QgYXdhcmUsIGJ1dCBs b29raW5nIGRlZXBlciBpbmRlZWQgSSBkbyBub3Qgc2VlIHRoaXMgbWFya2luZyBuZWl0aGVyIGlu IElTSVMgbm9yIE9TUEYgZm9yIHByZWZpeCBTSURzLg0KDQpJcyB0aGVyZSBzb21lIHdvcmsgaW4g cHJvZ3Jlc3MgdG8gYWRkIGl0IHRvIHRob3NlIHByb3RvY29scyBvciBoYXZlIHdlIGp1c3QgZG9j dW1lbnRlZCBuZWVkIGZvciBhIHNob3J0IExTUiBkcmFmdCAgPw0KDQpUaHgsDQpSLg0KDQoNCk9u IEZyaSwgQXVnIDE0LCAyMDIwIGF0IDY6MTcgUE0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8 a2V0YW50QGNpc2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgUm9i ZXJ0LA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBSb2JlcnQgUmFzenVr IDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KU2VudDogMTQg QXVndXN0IDIwMjAgMjE6MTMNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRA Y2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lzY28uY29tPj4NCkNjOiBBbGV4YW5kZXIgVmFpbnNo dGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQHJiYm4uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFAanVu aXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj47IEVYVC1BbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20+Pjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1p bmluZyBhcHBsaWNhYmlsaXR5DQoNCkhpIEtldGFuLA0KDQpXaGlsZSBJIGNvbXBsZXRlbHkgYWdy ZWUgd2l0aCB5b3VyIG5vdGUgdGhlIGNvbnNlcXVlbmNlcyBvZiBpdCBhcmUgcHJldHR5IHNldnJl Lg0KW0tUXSBJIHVuZGVyc3RhbmQuIFdlIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiBpbXBsaWNhdGlv bnMgb2YgcHJvdGVjdGlvbiBzY2hlbWVzIGZvciB0aGUgU0xBcy9pbnRlbnQgb2YgU1IgUG9saWNp ZXMuDQoNClVubGVzcyB3ZSBzaWduYWwgd2hpY2ggcHJlZml4IFNJRCBpcyBwcm90ZWN0aW9uIGVs aWdpYmxlIGFuZCB3aGljaCBpcyBub3QgaG93IHdvdWxkIG90aGVyIG5vZGVzIGtub3cgaWYgdGhl eSBjYW4gcHJvdGVjdCBpdCBvciBub3QgPw0KW0tUXSBDb3JyZWN0LiBUbyBiZSBtb3JlIGFjY3Vy YXRlLCB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoaXMgbW9yZSBpbiB0aGUgY29udGV4dCBvZiBTTEEg b3Ig4oCcaW50ZW504oCdIG9mIFNSIFBvbGljaWVzIGFuZCB3aGljaCBzZWdtZW50cyBtYXkgYmUg 4oCcYnlwYXNzLWFibGXigJ0gZm9yIGxvY2FsIHByb3RlY3Rpb24gZm9yIHNvbWUgb2YgdGhvc2Ug U1IgUG9saWNpZXMuIFdlIGFsc28gaGF2ZSBwYXRoLXByb3RlY3Rpb24gbWVjaGFuaXNtcy4NCg0K SXQgc2VlbXMgdGhhdCB0b2RheSdzIHNhZmUgdGhpbmcgaXMgbm90IHRvIGFwcGx5IGFueSBub2Rl IHByb3RlY3Rpb24gb24gU1IgZmxvd3MgYXQgdGhlIFBMUnMgdGhlbi4NCg0KQW5kIGxpbmsgcHJv dGVjdGlvbiBNVVNUIGFzc3VyZSB0aGF0IHBhY2tldHMgd2lsbCBhcnJpdmUgYXQgdGhlIG5laWdo Ym9yIG5vZGUgdmlhIHNvbWUgb3RoZXIgbGluayByZWdhcmRsZXNzIG9mIGZ1cnRoZXIgcGF0aCB0 b3dhcmRzIGRlc3RpbmF0aW9uLg0KW0tUXSBZZXMuIFdlIGhhdmUgYSBtZWNoYW5pc20gdG8gaW5k aWNhdGUgd2hpY2ggYWRqLVNJRHMgaGF2ZSBwcm90ZWN0aW9uICh0aGF0IG1lY2hhbmlzbSBvbmx5 IHByb3ZpZGVzIGxpbmsgcHJvdGVjdGlvbiB0byBnZXQgdG8gdGhlIG5laWdoYm9yIG5vZGUpIHNv IHRoZSBTUiBQb2xpY3kgY29tcHV0YXRpb24gaXMgYWJsZSB0byBpbmRpY2F0ZSB3aGV0aGVyIHRo YXQgc3BlY2lmaWMgbGluayBpcyDigJxieXBhc3MtYWJsZeKAnSBvciBub3QgYnkgaXRzIGNob2lj ZSBvZiBwcm90ZWN0ZWQgb3IgdW5wcm90ZWN0ZWQgYWRqLVNJRHMgcmVzcGVjdGl2ZWx5Lg0KDQpU aGFua3MsDQpLZXRhbg0KDQpJcyBpdCBjb3JyZWN0ID8NCg0KVGh4DQpSDQoNCk9uIEZyaSwgQXVn IDE0LCAyMDIwIGF0IDU6MzIgUE0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNp c2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgU2FzaGEsDQoNClRo ZSBzZXJ2aWNlIG5vZGUgYWR2ZXJ0aXNlcyBpdHMgb3duIFByZWZpeCBTSUQuIFRoZSBzZXJ2aWNl IGZ1bmN0aW9uIHRoYXQgdGhpcyBzZXJ2aWNlIG5vZGUgaW1wbGVtZW50cyBkb2VzIG5vdCByZXF1 aXJlIGFueSBjb250ZXh0IChpLmUuIGFsbCBwYWNrZXRzIGFycml2aW5nIGF0IHRoZSBub2RlIGFy ZSBzdWJqZWN0ZWQgdG8gdGhhdCBzZXJ2aWNlKS4gVGhlcmVmb3JlIHRoZSBzZXJ2aWNlIG5vZGUg ZG9lcyBub3QgbmVlZCB0byByZWNlaXZlIGEgcGFja2V0IHdpdGggaXTigJlzIG93biBQcmVmaXgg U0lELg0KDQpUaHVzLCB3ZSBjYW5ub3QgYXNzdW1lIHRoYXQgd2hlbiBQSFAgaXMgdXNlZCwgdGhl biB0aGUgU0lEIGlzIG9ubHkgYXNzb2NpYXRlZCB3aXRoIGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rp b24uDQoNCkhvcGUgdGhhdCBjbGFyaWZpZXM/DQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IEFs ZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbTxtYWlsdG86 QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+Pg0KU2VudDogMTQgQXVndXN0IDIwMjAgMjA6 MjQNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0 bzprZXRhbnRAY2lzY28uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNv bTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFA anVuaXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj47IEVYVC1BbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlv biAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KS2V0YW4sIGFuZCBhbGwsDQpJIGhhdmUg c3RhdGVkIHRoYXQsIElNSE8gYW5kIEZXSVcsIGJvdGggQWRqLVNJRHMgYW5kIFByZWZpeCBTSURz IHRoYXQgYXJlIGFkdmVydGlzZWQgd2l0aCBQSFAgY2FuICBPTkxZIHJlcHJlc2VudCB0b3BvbG9n aWNhbCBpbnN0cnVjdGlvbnMgaW4gU1ItTVBMUyAtIGJlY2F1c2UgdGhlIGFkdmVydGlzaW5nIG5v ZGUgd2lsbCBub3QgcmVjZWl2ZSB0aGVtIGFuZCB0aGVyZWZvcmUgY2FuIGhhcmRseSBiZSBleHBl Y3RlZCB0byBhc3NvY2lhdGUgYW55IHNlcnZpY2UgZnVuY3Rpb24gd2l0aCB0aGVtLg0KDQpUaGlz IGlzIGNvbXBsZW1lbnRhcnkgdG8gd2hhdCB5b3UgaGF2ZSBzYWlkLg0KDQpIb3BlIHRoaXMgY2xh cmlmaWVzIG15IHBvc2l0aW9uLg0KV2hhdCwgaWYgYW55dGhpbmcsIGRpZCBJIG1pc3M/DQoNClJl Z2FyZHMsDQpTYXNoYQ0KDQpHZXQgT3V0bG9vayBmb3IgQW5kcm9pZDxodHRwczovL2FrYS5tcy9n aGVpMzY+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBLZXRhbiBU YWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRAY2lzY28u Y29tPj4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNjoyMw0KVG86IEFsZXhhbmRl ciBWYWluc2h0ZWluOyBKb2VsIE0uIEhhbHBlcm47IFNocmFkZGhhIEhlZ2RlOyBFWFQtQW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb20+OyBSb2JlcnQgUmFzenVrDQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24g LSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpOT1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwg c2VuZGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpIaSBTYXNoYSwNCg0K SWYgdGhlIHNlcnZpY2UgZG9lcyBub3QgbmVlZCBhbnkgYWRkaXRpb25hbCBjb250ZXh0IChlLmcu IGEgZmlyZXdhbGwgdGhhdCBqdXN0IGFwcGxpZXMgbG9jYWxseSBjb25maWd1cmVkIGRlZmF1bHQg cnVsZXMgb24gaXQpLCB0aGVuIEkgZG9u4oCZdCBzZWUgd2h5IFBIUCBjb3VsZCBub3QgYmUgZG9u ZSBmb3IgYSBQcmVmaXggU0lEIGFzc29jaWF0ZWQgd2l0aCBhIHNlcnZpY2Ugbm9kZS4NCg0KQWxz bywgSSBkaWRu4oCZdCBmb2xsb3cgdGhlIHBvaW50IHRoYXQgeW91IHdlcmUgdHJ5aW5nIHRvIG1h a2UgYWJvdXQgQWRqLVNJRHMuDQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IEFsZXhhbmRlciBW YWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbTxtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AcmJibi5jb20+Pg0KU2VudDogMTQgQXVndXN0IDIwMjAgMTg6MjQNClRvOiBL ZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRA Y2lzY28uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZh aW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPj47 IFNocmFkZGhhIEhlZ2RlIDxzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hyYWRkaGFAanVu aXBlci5uZXQ+PjsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkVY VC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0 ZWxlY29tLmNvbTxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+OyBSb2Jl cnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0K Q2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0K DQpIaSBhbGwsDQpSZWdhcmRpbmcgdGhlIHN0YXRlbWVudCAiUHJlZml4IFNJRCBjb3VsZCBiZSBq dXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVl ciB0aGUgZmxvdyB0byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9u IHRvIGl0IjoNCg0KDQpJIHRoaW5rIHRoYXQgaW4gU1ItTVBMUyBhIE5vZGUgU0lEIHRoYXQgaXMg YWR2ZXJ0aXNlZCB3aXRoIFBIUCBhY2l0b24gY2FuIGJlIHNhZmVseSBjb25zaWRlcmVkIGFzICJq dXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24iIGJ5IHRoZSBQTFIgYmVjYXVzZSB0aGUgb3Jp Z2luYXRpbmcgbm9kZSB3aWxsIG5vdCByZWNlaXZlIGl0Lg0KVGhlIHNhbWUgYXBwbGllcyB0byBB ZGotU0RJcy4NCg0KTXkgMmMuDQoNCkdldCBPdXRsb29rIGZvciBBbmRyb2lkPGh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zNzVjNVlZQmVFYmFFWndVY0hwQ1kxbTZIMj91PWh0dHBzJTNB JTJGJTJGYWthLm1zJTJGZ2hlaTM2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8 a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzprZXRhbnQ9NDBjaXNjby5j b21AZG1hcmMuaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTQsIDIwMjAsIDE1OjAw DQpUbzogSm9lbCBNLiBIYWxwZXJuOyBBbGV4YW5kZXIgVmFpbnNodGVpbjsgU2hyYWRkaGEgSGVn ZGU7IEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IFJvYmVydCBSYXN6dWsNCkNjOiBzcHJpbmdAaWV0 Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJp bmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KSGkgQWxsLA0KDQpJ IHdvdWxkIGxpa2UgdG8gc2hhcmUgYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUgb24gdGhpcy4NCg0K Rmlyc3QsIHRoYW5rcyB0byBKb2VsIGZvciBicmluZ2luZyB1cCB0aGUgZGlzY3Vzc2lvbi4gQ2xl YXJseSB3ZSBuZWVkIGEgd2VsbC1kZWZpbmVkIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGZvciBk ZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5IG9mIHByb3RlY3Rpb24gZm9yIHNlZ21lbnQgdXNlZCBp biBhbiBTUiBQb2xpY3kuIFNvbWUgb2YgdGhpcyBpcyBjYXB0dXJlZCBpbiBbMV0uDQoNClRoaXMg aXMgYWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkgbmF0dXJlLCB0aGUg UExSIGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICJzdHJpY3Qgb3Igbm90IiBpcyB0aGUg U0xBIHRoYXQgaXMgYmVpbmcgcHJvdmlkZWQgYnkgdGhlIFNSIFBvbGljeS4gQXdhcmVuZXNzIG9m IHRoYXQgbm90aW9uIGV4aXN0cyBhdCB0aGUgU1IgUG9saWN5IGhlYWRlbmQgYW5kL29yIGNvbXB1 dGF0aW9uLW5vZGUuDQoNCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0ZWQgdmFyaWFu dHMgb2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0byBwaWNrIG9y IHRoZSBvdGhlciBiYXNlZCBvbiB0aGUgInN0cmljdG5lc3MiIG9mIHRoZSBTTEEgcmVxdWlyZW1l bnQgZm9yIHBpY2tpbmcgdGhhdCBsaW5rLiBXZSBkbyBub3QgaGF2ZSBzdWNoIGEgbm90aW9uIGZv ciBQcmVmaXggU0lEcy4gT25lIGNhbiBzYXkgdGhhdCB3ZSBjb3VsZCBpbnRyb2R1Y2Ugc2lnbmFs bGluZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hldGhlciBhIFByZWZpeCBTSUQgY2Fu IGJlIGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHRo ZSBjb21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhlciBmbGF2b3IgZGVwZW5kaW5nIG9u IHRoZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBvbGljeS4NCg0KSSBoYXZlIGEgcHJv YmxlbSBhbmQgYSBjb25jZXJuIGluIHRoZSBhc3N1bXB0aW9uIHRoYXQgUExScyBjYW4gYXNzdW1l IHRoYXQgdGhlIGN1cnJlbnRseSBkZWZpbmVkIHZhcmlhbnQgb2YgUHJlZml4IFNJRHMgaW4gUkZD ODQwMiAoYW5kIElHUCBzcGVjcykgYXJlICJieXBhc3MtYWJsZSIuDQoNCkFzIEpvZWwgYW5kIG90 aGVycyBoYXZlIGJyb3VnaHQgb3V0LCB0aGUgUHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0IGEgdG9w b2xvZ2ljYWwgaW5zdHJ1Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0aGUgZmxv dyB0byBhIG5vZGUgd2hpY2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGl0LiBJ biBvcmRlciB0byBzdXBwb3J0IGEgbWl4IG9mIFNSIFBvbGljaWVzIG9mIGRpZmZlcmVudCBTTEFz IChzdHJpY3QgYW5kIG5vdC1zdHJpY3QpLCB3ZSBuZWVkIHRvIGVuYWJsZSB0aGUgY2hvaWNlIG9m IFNJRHMgdGhhdCBpbmRpY2F0ZXMgdG8gdGhlIFBMUiB3aGV0aGVyIHRoZXkgYXJlICJieXBhc3Mt YWJsZSIgb3Igbm90Lg0KDQpGb3IgdGhlIGNhc2VzLCB3aGVyZSB0aGUgU1IgUG9saWN5IGhhcyBh IHNwZWNpZmljIFNMQSwgaXQgaXMgcmVxdWlyZWQgZm9yIG5vZGVzIHRvIGRyb3AgdGhlIHBhY2tl dHMgbWVhbnQgZm9yIHRoZSAiYWN0aXZlIHNlZ21lbnQiIHRoYW4gdG8gYnlwYXNzIGl0LiBXaGVu IHRoaXMgbWVjaGFuaXNtIGlzIHVzZWQgYWxvbmcgc2lkZSBTUlRFIHBhdGggbW9uaXRvcmluZyBt ZWNoYW5pc21zLCBpdCBlbmFibGVzIHRoZSBoZWFkZW5kIHRvIGRldGVjdCB0aGUgZmFpbHVyZSBh bmQgZmFsbGJhY2sgdG8gYW4gYWx0ZXJuYXRlIHBhdGggdXNpbmcgdGhlIHBhdGggcHJvdGVjdGlv biBhcHByb2FjaC4gVGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyBkZXNjcmliZWQgYW5kIGluIHVz ZSBpbiBkZXBsb3ltZW50cyB0b2RheSBbMV0uLg0KDQpUaGFua3MsDQpLZXRhbg0KDQpbMV0gaHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1zNkgyP3U9 aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05DQpbMl0gaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzM2ZkNNcmdtRWV3QzRhNEFKUnJtbjdINkgyP3U9aHR0cHMlM0ElMkYl MkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctcG9saWN5LTA4JTIzc2VjdGlvbi05LjMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogMDQgQXVn dXN0IDIwMjAgMjA6MjUNClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5z aHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPj47IFNo cmFkZGhhIEhlZ2RlIDxzaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0 bzpzaHJhZGRoYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPj47IEVYVC1BbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5n IHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQoNClRoZXJlIGFyZSwgYXMg ZmFyIGFzIEkgY2FuIHRlbGwsIGEgbnVtYmVyIG9mIHdheXMgdG8gYWRkcmVzcyB0aGlzIGZhbWls eSBvZiByZWxhdGVkIHF1ZXN0aW9ucy4NCldoYXQgc3RydWNrIG1lLCBhbmQgcHJvbXB0ZWQgdGhl IHN0YXJ0aW5nIHF1ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2VyZSBzcGVsbGVkIG91 dC4gIEkgc2VlIGxvdHMgb2YgaW50ZXJlc3RpbmcgaWRlYXMgLyBwcm9wb3NhbHMuDQpTb21lIG9m IHRoZW0gYXJlIGNvbXBhdGlibGUgd2l0aCBvdGhlcnMuICAgU29tZSBhcmUgbm90Lg0KSXQgd291 bGQgYmUgZ29vZCBpZiB3ZSBjb3VsZCByZWFjaCBhZ3JlZW1lbnQgb24gaG93IHdlIHRob3VnaHQg aXQgc2hvdWxkIGJlIGhhbmRsZWQuDQoNClRoYW5rIHlvdSwNCkpvZWwNCg0KT24gOC80LzIwMjAg Mzo1NCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6DQo+IEhpIGFsbCwNCj4NCj4gSSBh bSBzdGlsbCBub3Qgc3VyZSB0aGF0IHRoZSBwcm9ibGVtIG9mIGJ5cGFzcyBnb2luZyB0aHJ1IHVu ZGVzaXJhYmxlDQo+IGxpbmtzL25vZGVzIGV4aXN0cyBpbiB0aGUgY2FzZSBvZiB0b3BvbG9naWNh bCBTSURzLg0KPg0KPiBBRkFJSywgRmFjaWxpdHkgUHJvdGVjdGlvbiBpbiBSU1ZQLVRFIEZSUiAo UkZDIDQwOTANCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTkya25FOVhKdWpy ZjhCazdvSnZzNkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM0 MDkwPikgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IGRlcGxveWVkDQo+IGZvciBtYW55IHllYXJzIGJl Zm9yZSBTUi1NUExTIGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTigJlzIG1vcmUsDQo+IHNpZ25h bGluZyBvZiBieXBhc3MgdHVubmVscyBoZSBQTFIgdXN1YWxseSBkaWQgbm90IGluY2x1ZGUgYW55 IG9mIHRoZQ0KPiBjb25zdHJhaW50cyB1c2VkIGZvciBjb21wdXRpbmcgb2YgYW55IHNwZWNpZmlj IExTUCB0aGF0IHRoZSBieXBhc3MgTFNQDQo+IHdvdWxkIHByb3RlY3Qg4oCTIGJlY2F1c2UgaW4g dGhlIEZhY2lsaXR5IFByb3RlY3Rpb24gbW9kZSB0aGUgc2FtZQ0KPiBieXBhc3MgTFNQIHdvdWxk IGJlIHVzZWQgdG8gcHJvdGVjdCBtdWx0aXBsZSBMU1BzIHBhc3NpbmcgdGhydSB0aGUNCj4gZmFp bGVkIGxpbmsvbm9kZS4NCj4NCj4gIEZyb20gbXkgUE9WIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0 d2VlbiB0aGlzIGJlaGF2aW9yIGFuZCB0aGF0DQo+IGludHJvZHVjZWQgYnkgdGhlIOKAnGJ5cGFz c2luZ+KAnSBkcmFmdHMgaW4gU1IgaXMgdGhhdCwgaW4gdGhlIGNhc2Ugb2YNCj4gUlNWUC1URSwg dGhlIG9wZXJhdG9yIHdvdWxkIGV4cGxpY2l0bHkgaW5kaWNhdGUsIGFzIHBhcnQgb2YgTFNQDQo+ IHNpZ25hbGluZywgd2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBub3QgdXNlIEZSUjsgTFNQcyB0 aGF0IHdvdWxkIG5vdA0KPiB1c2UgRlJSIHdvdWxkIHRoZW4gZHJvcCB0cmFmZmljIHJhdGhlciB0 aGFuIGRlbGl2ZXJpbmcgaXQgdGhlIHdyb25nIHdheS4NCj4NCj4gU3VjaCBhbiBvcHRpb24gaW5k ZWVkIGRvZXMgbm90IGV4aXN0IGluIFNSLVRFIHRvZGF5LCBidXQgd291bGQgYmUgZWFzeQ0KPiB0 byBwcm92aWRlIGlmIHNvIGRlc2lyZWQgSU1ITy4NCj4NCj4gRGlkIEkgbWlzcyBzb21ldGhpbmcg c3Vic3RhbnRpYWw/DQo+DQo+IFJlZ2FyZHMsIGFuZCBsb3RzIG9mIHRoYW5rcyBpbiBhZHZhbmNl LA0KPg0KPiBTYXNoYQ0KPg0KPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4NCj4gQ2VsbDogICAg ICArOTcyLTU0OTI2NjMwMg0KPg0KPiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+DQo+ICpG cm9tOiogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpTaHJhZGRoYSBIZWdkZQ0KPiAqU2VudDoqIFR1 ZXNkYXksIEF1Z3VzdCA0LCAyMDIwIDk6NDEgQU0NCj4gKlRvOiogRVhULUFuZHJldy5BbHN0b25A bGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20u Y29tPg0KPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86QW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+OyBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5l dDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqQ2M6KiBzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNv bTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6IFtzcHJpbmdd IFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPg0KPiBBbGws DQo+DQo+IFRoaXMgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIHRoYW5rcyB0 byBKb2VsIGZvciBzdGFydGluZw0KPiB0aGlzIGRpc2N1c3Npb24uIElNTywgd2hlbiB0aGVyZSBh cmUgc3RyaWN0IHJlcXVpcmVtZW50cyBvZiBhdm9pZGluZw0KPiBjZXJ0YWluIG5vZGVzL2xpbmtz IGl0IGNhbiBiZSByZWFsaXplZCAgZWl0aGVyIGJ5IGRlZmluaW5nIGEgZmxleC1hbGdvDQo+IGF2 b2lkaW5nIHRob3NlDQo+DQo+IE5vZGVzIGFuZCBsaW5rcyBvciBieSB1c2luZyBhIHN0YWNrIG9m IHVucHJvdGVjdGVkIGFkai1zaWRzIHRoYXQgYXZvaWQNCj4gcmVzdHJpY3RlZCBub2RlcyBhbmQg bGlua3MuIFdoZW4gYSBzdGFjayBvZiBhZGotc2lkcyBpcyB1c2VkIHRvDQo+IHJlYWxpemUgdGhl IHBhdGgsIHRoZSBoZWFkLWVuZCBiYXNlZCAoc0JGRCkgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGNh biBiZSBhcHBsaWVkLg0KPg0KPiBJZiBOb2RlLXNpZHMvcHJlZml4LXNpZC9hbnljYXN0LXNpZHMg YXJlIHVzZWQgdG8gYnVpbGQgdGhlIHN0YWNrLCB0aGUNCj4gZmFpbHVyZSBldmVudHMgbWF5IGNh dXNlIHRyYWZmaWMgdG8gZ28gdGhyb3VnaCByZXN0cmljdGVkIG5vZGVzIGFuZA0KPiBsaW5rcy4g VGhpcyB3b3VsZCBoYXBwZW4gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFueSBraW5kIG9mIHByb3Rl Y3Rpb24NCj4gaXMgaW4gdXNlIG9yIG5vdC4NCj4NCj4gUmdkcw0KPg0KPiBTaHJhZGRoYQ0KPg0K PiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+DQo+ICpGcm9tOiogc3ByaW5nIDxzcHJpbmct Ym91bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUyMCUwYj4+ IDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiAqT24gQmVoYWxmIE9mICpBbmRyZXcg QWxzdG9uDQo+ICpTZW50OiogVHVlc2RheSwgQXVndXN0IDQsIDIwMjAgNTo0MSBBTQ0KPiAqVG86 KiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5u ZXQ+IDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KPiAqQ2M6KiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBKb2VsIE0u IEhhbHBlcm4NCj4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+DQo+ICpTdWJqZWN0OiogUmU6IFtzcHJp bmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPg0KPiAq W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XSoNCj4NCj4gUm9iZXJ0IHRo aXMgaXMgYWN0dWFsbHkgZmFyIG1vcmUgZGlmZmljdWx0IHdoZW4g4oCTIGl0IGNhbiBiZSBhbiBl bnRpcmUNCj4gKGxvbmcpIHNlcmllcyBvZiBub2RlcyB0aGF0IG5lZWQgdG8gYmUgYXZvaWRlZC4N Cj4NCj4gSXQgY291bGQgcG90ZW50aWFsbHkgYmUgbWFkZSB0byB3b3JrIGJ1dCBJ4oCZZCB3b3Jy eSB0aGF0IHRvIGRvIHRoaXMg4oCTDQo+IHlvdeKAmWQgaGF2ZSB0byBzdGFjayAxMCDigJMgMjAg 4oCTIDMwIG5lZ2F0aXZlIGxhYmVscyDigJMgYW5kIHRoYXQgd291bGRu4oCZdA0KPiBiZSB2aWFi bGUuDQo+DQo+IEl04oCZcyBlYXNpZXIgdG8gdXNlIGFsZ29yaXRobXMgYW5kIGFkamFjZW5jeSBz aWRzIGFuZCBvdGhlciBzdWNoIHRoaW5ncw0KPiB0byBjYWxjdWxhdGUgcGF0aHMg4oCTIHRoZSBi aWdnZXN0IHRyaWNrIGlzIGFib3V0IHRoZSBzdGFjayBkZXB0aC4gIFdoZW4NCj4geW91IGhhdmUg dGhpcyBuZWVkIGZvciBub2RlIGF2b2lkYW5jZSDigJMgdGhlIG5lZWQgZm9yIDEwKyBsYWJlbCBk ZXB0aA0KPiBpcyBjcml0aWNhbCDigJMgdW5sZXNzIHlvdSB3YW5uYSBiZSBhcHBseWluZyBvbmUg aGVsbCBvZiBhIGxvdCBvZg0KPiBiaW5kaW5nIGxhYmVscyBhbG9uZyB0aGUgd2F5IHdoaWNoIGlz IGEgbmlnaHRtYXJlLg0KPg0KPiBCdXQgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGlzIHRoaXMg YSBjb21tb24gdXNlIGNhc2Ug4oCTIGl04oCZcyBhIHVzZQ0KPiBjYXNlIHRoYXQgbW9zdCBvZiB0 aGUgcGVvcGxlIEkgZGlzY3VzcyB0aGlzIHdpdGggY2VydGFpbiBoYXZlIOKAkyBJIGNhbnQNCj4g Y29tbWVudCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFueW9uZSBlbHNlLCBidXQgZXZlcnkg aW5kaWNhdGlvbiBJDQo+IGhhdmUgaXMgdGhhdCB5ZXMg4oCTIGl0cyBzb21ldGhpbmcgcGVvcGxl IG5lZWQsIGFuZCB3YW50DQo+DQo+IEFuZHJldw0KPg0KPiAqRnJvbToqIFJvYmVydCBSYXN6dWsg PHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4gPG1haWx0bzpyb2Jl cnRAcmFzenVrLm5ldD4+DQo+ICpTZW50OiogVHVlc2RheSwgNCBBdWd1c3QgMjAyMCAwMToyNw0K PiAqVG86KiBBbmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8 bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGI+PiA8bWFpbHRvOkFu ZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+Pg0KPiAqQ2M6KiBKb2VsIE0uIEhhbHBlcm4g PGptaEBqb2VsaGFscGVybi5jb20NCjxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYj4+ IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4NCj4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICpTdWJqZWN0Oiog UmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eQ0KPg0KPiBJcyB0aGlzIGEgY29tbW9uIHVzZSBjYXNlIGllLiAgImJ1dCByYXRoZXIg4oCTIHdo aWNoIG5vZGVzIC8gbmV0d29yaw0KPiBzZWdtZW50cyBpdCBjYW4gbmV2ZXIgdG91Y2ggb3IgZmxv dyB0aHJvdWdoLiINCj4NCj4gSWYgc28gcGVyaGFwcyBpdHMgdGltZSB0byBkZWZpbmUgbm90aW9u IG9mICpuZWdhdGl2ZS1TSUQqIGllLiBsaXN0IGluDQo+IHRoZSBwYWNrZXQgcmVzb3VyY2VzIHdo aWNoIGdpdmVuIHBhY2tldCBNVVNUIG5vdCBldmVyIHRyYXZlcnNlLg0KPg0KPiBQdXQgaW4gdGhl IHBhY2tldCBzZXQgb2Ygbm9kZXMgb3IgbGlua3Mgd2hpY2ggdGhlIHBhY2tldCBzaG91bGQgbmV2 ZXINCj4gdHJhdmVyc2UuDQo+DQo+IFRoYXQgZ29lcyBpbiBsaW5lIG9mIHJlY2VudCB3YXZlIG9m IG5lZ2F0aXZlIHJvdXRpbmcgaW1wbGVtZW50YXRpb25zDQo+IChSSUZUKSBvciBkaXNjdXNzaW9u cyAoTFNSKQ0KPg0KPiBCZXN0LA0KPiBSLg0KPg0KPiBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDEx OjQ2IFBNIEFuZHJldyBBbHN0b24NCj4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20N CjxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSUyMCUwYj4+IDxtYWlsdG86 QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+IHdyb3RlOg0KPg0KPiAgICAgU28g4oCT DQo+DQo+ICAgICBPbmUgb2YgdGhlIHVzZSBjYXNlcywgaW4gZmFjdCwgc29tZSB2ZXJ5IG1ham9y IHVzZSBjYXNlcyBpbiBhbnkNCj4gICAgIHNwcmluZyB0ZWNobm9sb2d5IGZvciB1cyByZXZvbHZl IGFyb3VuZCB0aGUgZm9sbG93aW5nDQo+DQo+ICAgICBhLlRoZSBleHBsaWNpdCBhdm9pZGFuY2Ug b2YgY2VydGFpbiBub2Rlcw0KPg0KPiAgICAgYi5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNl cnRhaW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdvcmsNCj4NCj4gICAgIEFueXRoaW5nIHRoYXQgY291 bGQgcmVzdWx0IGluIHRoYXQgZXhwbGljaXQgYXZvaWRhbmNlIGJlaW5nIHZpb2xhdGVkDQo+ICAg ICDigJMgd291bGQgY3JlYXRlLCBzaGFsbCB3ZSBzYXkgc2lnbmlmaWNhbnQgcHJvYmxlbXMuDQo+ DQo+ICAgICBNdWNoIG9mIHRoZSB1c2UgY2FzZSBpcyBub3QgYSBjYXNlIG9mIHdoaWNoIG5vZGVz IHRoZSBwYWNrZXRzIGZsb3cNCj4gICAgIHRocm91Z2gg4oCTIGJ1dCByYXRoZXIg4oCTIHdoaWNo IG5vZGVzIC8gbmV0d29yayBzZWdtZW50cyBpdCBjYW4gbmV2ZXINCj4gICAgIHRvdWNoIG9yIGZs b3cgdGhyb3VnaC4gIEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9neSB0bw0K PiAgICAgYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuDQo+DQo+ICAg ICBUaGlzIGlzIGFsc28gb25lIG9mIHRoZSByZWFzb25zIGZvciBuZWVkaW5nIHN1Y2ggZGVlcCBs YWJlbCBzdGFja3Mg4oCTDQo+ICAgICB0aGlzIGtpbmQgb2YgZGV0YWlsZWQgcGF0aCBwcm9ncmFt bWluZyB0ZW5kcyB0byBkZWVwZW4gdGhlIHN0YWNrDQo+ICAgICBiZWNhdXNlIHlvdSBzb21ldGlt ZXMgaGF2ZSB0byBiZSBwcmV0dHkgZXhwbGljaXQuDQo+DQo+ICAgICBJdCBpcyBhYnNvbHV0ZWx5 IGNyaXRpY2FsIHRvIHVzIHRoYXQgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIHRoZXJlIOKAkw0KPiAg ICAgYW5kIHRoYXQgd2UgY2FuIGF2b2lkIHNpdHVhdGlvbnMgd2hpY2ggY291bGQgY2F1c2UgdHJh ZmZpYyB0bw0KPiAgICAgYWNjaWRlbnRseSBoaXQgdGhpbmdzIGV4cGxpY2l0bHkgYXZvaWRlZC4N Cj4NCj4gICAgIEkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgdGhhbiB0aGlzLCBidXQg aXQgaXMgd2hhdCBpdCBpcy4NCj4NCj4gICAgIFRoYW5rcw0KPg0KPiAgICAgQW5kcmV3DQo+DQo+ ICAgICAqRnJvbToqIHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxtYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZz4+ICpPbiBCZWhhbGYgT2YgKkpvZWwgTS4gSGFscGVybg0KPiAgICAgKlNlbnQ6KiBNb25k YXksIDMgQXVndXN0IDIwMjAgMjE6MzYNCj4gICAgICpUbzoqIFJvYmVydCBSYXN6dWsgPHJvYmVy dEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4gPG1haWx0bzpyb2JlcnRAcmFz enVrLm5ldD4+DQo+ICAgICAqQ2M6KiBzcHJpbmdAaWV0Zi4ub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi4ub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtz cHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcNCj4gYXBwbGljYWJpbGl0eQ0K Pg0KPiAgICAgKFNpbmNlIHRoZSB0aHJlYWQgaGFzIGdvdHRlbiBsb25nIGVub3VnaCwgcmVpdGVy YXRpbmcgdGhhdCB0aGlzIGlzIGFzIGENCj4gICAgIHBhcnRpY2lwYW50LCBub3QgYSBXRyBjaGFp ci4pDQo+DQo+ICAgICBZZXMsIHdlIGFyZSB0YWxraW5nIElQIG5ldHdvcmtzLiBBbmQgeWVzLCBJ IGhhdmUgc2VlbiBJUCBuZXR3b3JrcyB0aGF0DQo+ICAgICBjaG9vc2UgdG8gZHJvcCBwYWNrZXRz LiBGb3IgYWxsIHNvcnRzIG9mIHJlYXNvbnMuDQo+ICAgICBJIHRoaW5rIHRoZXJlIGFyZSBsaWtl bHkgb3RoZXIgcmVhc29ucyB3aHkgb25lIG1heSBub3Qgd2FudCBhIHJhbmRvbQ0KPiAgICAgcGF0 aCByYXRoZXIgdGhhbiBhIGNob3NlbiBURSBwYXRoLiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB3 ZSBiZSBjbGVhcg0KPiAgICAgYWJvdXQgd2hhdCBjb25zdHJhaW50cyBtYXkgYmUgLyBhcmUgdmlv bGF0ZWQgd2hlbiB3ZSB0ZWxsIHBlb3BsZSB0aGV5DQo+ICAgICBoYXZlIHRoaXMgdG9vbCAocHJv dGVjdGl2ZSByZXJvdXRpbmcpIHRoYXQgaXMgaW50ZW5kZWQgdG8gcHJlc2VydmUgUW9TLg0KPg0K PiAgICAgTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlzIGlzIG5vdCBh IGdvb2QgaWRlYS4gSXQgaXMgYQ0KPiAgICAgZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJIGFtIHRy eWluZyB0byBmaWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2YNCj4gICAgIGFkZGl0aW9uYWwg bWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVyeW9uZQ0K PiAgICAgZ2V0dGluZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUg dGhlIGJlaGF2aW9yIHRoZXkNCj4gICAgIGRlc2lyZSwgYnV0IHNvbWV0aW1lcyBpcyB0aGUgYmVz dCB3ZSBjYW4gZG8uKQ0KPg0KPiAgICAgWW91cnMsDQo+ICAgICBKb2VsDQo+DQo+ICAgICBPbiA4 LzMvMjAyMCAyOjMwIFBNLCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KPiAgICAgID4gSm9lbCwNCj4g ICAgICA+DQo+ICAgICAgPiBBcmUgd2Ugc3RpbGwgdGFsa2luZyBhYm91dCBJUCBuZXR3b3JrcyBo ZXJlID8gT3IgcGVyaGFwcyBzb21lIGhhcmQNCj4gICAgICA+IHNsaWNpbmcgd2l0aCByZWFsIHJl c291cmNlIHJlc2VydmF0aW9ucyBvciBkZXRuZXRzID8NCj4gICAgICA+DQo+ICAgICAgPiBCZWNh dXNlIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtpbmcgSSBoYXZlIHR3bw0KPiAg ICAgb2JzZXJ2YXRpb25zOg0KPiAgICAgID4NCj4gICAgICA+IEEpIElmIHlvdSBuZWVkIHRvIHRy YXZlcnNlIHZpYSBhIHNwZWNpZmljIG5vZGUgKGllLiBmaXJld2FsbCkgeW91DQo+ICAgICBiZXR0 ZXINCj4gICAgICA+IGFwcGx5IElQIGVuY2Fwc3VsYXRpb24gdG8gdGhhdCBub2RlLi4gSSBkb24n dCB0aGluayBJUA0KPiAgICAgZW5jYXBzdWxhdGlvbiBjYW4NCj4gICAgICA+IGJlIGhpamFja2Vk IHRvZGF5IHN1Y2ggdGhhdCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgaXMNCj4g ICAgIGlnbm9yZWQuDQo+ICAgICAgPg0KPiAgICAgID4gQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAg bmV0d29yayB3aGVyZSB1cG9uIHRvcG9sb2d5IGNoYW5nZSAobGluaw0KPiAgICAgb3Igbm9kZQ0K PiAgICAgID4gZmFpbHVyZSkgeW91IHN1ZGRlbmx5IHN0YXJ0IGRyb3BwaW5nIGZsb3dzIGluIHNw aXRlIG9mIFNQVCBvZmZlcmluZw0KPiAgICAgID4gcGVyaGFwcyBmZXcgbXMgbG9uZ2VyIHBhdGgg d2l0aCAxMCBtcyBtb3JlIGppdHRlciA/DQo+ICAgICAgPg0KPiAgICAgID4gT3IgYXJlIHNvbWUg U1IgbWFya2V0aW5nIHNsaWRlcyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW4NCj4gICAg ICA+IHNvbWV0aGluZyBuZXcgPyBXb3JzZSAuLi4gZG8gdGhleSBtZW50aW9uIHBhdGggcXVhbGl0 eSBndWFyYW50ZWVzLA0KPiAgICAgID4gcmVzb3VyY2UgcmVzZXJ2YXRpb25zID8gSSBob3BlIG5v dC4NCj4gICAgICA+DQo+ICAgICAgPiBUaHgsDQo+ICAgICAgPiBSLg0KPiAgICAgID4NCj4gICAg ICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4g ICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4gT24gTW9uLCBBdWcgMywgMjAyMCBhdCA4OjEwIFBN IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tJTBiPj4gICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYj4+IDxt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KPiAgICAgID4NCj4gICAgICA+IFdl bGwgbGVzcyBzZXJpb3VzIGZvciBURSBTSURzLCBJIGFtIG5vdCBzdXJlIHRoZSBwcm9ibGVtIGlz DQo+ICAgICByZXN0cmljdGVkDQo+ICAgICAgPiB0byBqdXN0IHNlcnZpY2UgU0lEcy4NCj4gICAg ICA+DQo+ICAgICAgPiBTdXBwb3NlIHRoYXQgdGhlIFBDRSBoYXMgc3BlY2lmaWVkIHRoZSBwYXRo IHRvIG1lZXQgc29tZSBjb21wbGV4IHRlDQo+ICAgICAgPiBvYmplY3RpdmUuICBUaGUgYnlwYXNz IG5vZGUgaGFzIG5vIHdheSBvZiBrbm93aW5nIHdoYXQgdGhvc2UNCj4gICAgICA+IGNvbnN0cmFp bnRzDQo+ICAgICAgPiB3ZXJlLiAgQW5kIGZvciBzb21lIGtpbmRzIG9mIHRyYWZmaWMsIGl0IGlz IGJldHRlciB0byBkcm9wIHRoZSBwYWNrZXQNCj4gICAgICA+IHRoYW4gdG8gZGVsaXZlciBpdCBv dXRzaWRlIHRoZSBlbnZlbG9wLiAgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0DQo+ICAgICAgPiBh bnN3ZXINCj4gICAgICA+IHRvIHRoaXMgaXMgInRvbyBiYWQiLiAgSWYgc28sIGFzIHdpdGggdGhl IGRpc3RpbmN0aW9uIHJlZ2FyZGluZw0KPiAgICAgc2VydmljZQ0KPiAgICAgID4gbm9kZXMsIHdl IHNob3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT8NCj4gICAgICA+DQo+ICAgICAgPiBZb3VycywN Cj4gICAgICA+IEpvZWwNCj4gICAgICA+DQo+ICAgICAgPiBPbiA4LzMvMjAyMCAyOjM2IEFNLCBB bGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gICAgICA+ID4gTWFjaCwgSm9lbCBhbmQgYWxs LA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJIHRoaW5rIHRoYXQgaW4gbW9zdCBjYXNlczoNCj4g ICAgICA+ID4NCj4gICAgICA+ID4gMS5UaGVyZSBpcyBjbGVhciBkaWZmZXJlbnRpYXRpb24gYmV0 d2VlbiAidG9wb2xvZ2ljYWwiIGFuZA0KPiAgICAgInNlcnZpY2UiDQo+ICAgICAgPiA+IGluc3Ry dWN0aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46DQo+ICAgICAgPiA+DQo+ICAgICAg PiA+IG9JR1AgUHJlZml4IE5vZGUgU0lEcyBJR1AgQWRqLVNJRHMgKGlkZW50aWZpZWQgYXMgc3Vj aCBpbiB0aGUNCj4gICAgICA+ID4gY29ycmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMpIHJl cHJlc2VudCB0b3BvbG9naWNhbA0KPiAgICAgaW5zdHJ1Y3Rpb25zDQo+ICAgICAgPiA+DQo+ICAg ICAgPiA+IG9TZXJ2aWNlIFNJRHMgZm9yIFNSdjYgKHNlZSBTUnY2IEJHUC1CYXNlZCBPdmVybGF5 IFNlcnZpY2VzDQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zQ0NjeTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJG ZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYt c2VydmljZXMtMDQNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0NDY3k5bVk2Y01m Yms3UWZqaGlBM1I2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9j JTJGaHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0JTBiPj4gICAgIDxodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dDNWFmMnozSnpwaFpEa1BuY0hBUWk2SDI/dT1o dHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNr ZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMt MDRfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4 cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNFQtTDBubCUyND4+DQo+ICAgICAgPg0KPiAgICAg ID4gPiBkcmFmdCkgdW5zdXJwcmlzaW5nbHkgcmVwcmVzZW50IOKAnHNlcnZpY2XigJ0gaW5zdHJ1 Y3Rpb25zDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQg dG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCwNCj4gICAgICA+ID4gd2hp bGUgc2VnbWVudHMgdGhhdCByZXByZXNlbnQgc2VydmljZSBpbnN0cnVjdGlvbnMgcmVxdWlyZQ0K PiAgICAgID4gYWx0ZXJuYXRpdmUNCj4gICAgICA+ID4gcHJvdGVjdGlvbiBtZWNoYW5pc21zLg0K PiAgICAgID4gPg0KPiAgICAgID4gPiBUaGlzIHZpZXcgc2VlbXMgdG8gYmUgYWxpZ25lZCB3aXRo IFJGQyA4NDAyDQo+ICAgICAgPiA+IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzQ1 TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJG aHRtbCUyRnJmYzg0MDINCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzQ1TkxDQjZU eWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RnJmYzg0MDIlMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zN1B6VUtB RDgyY2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUy Rl9faHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4NDAyX18lM0IlMjElMjFO RXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJI T0d0OEFrVFJEdWlEbzBJNFlidG0lMjQ+Pg0KPiAgICAgdGhhdCBzYXlzIGluIFNlY3Rpb24gMToN Cj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIEluIHRoZSBjb250ZXh0IG9mIGFuIElHUC1iYXNl ZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28NCj4gICAgICA+ID4NCj4gICAgICA+ID4g dG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNlZ21l bnQgYW5kIHRoZQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSUdQLVByZWZpeCBzZWdtZW50 Lg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSW4gdGhlIGNvbnRleHQgb2YgYSBCR1AtYmFz ZWQgZGlzdHJpYnV0ZWQgY29udHJvbCBwbGFuZSwgdHdvDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVu dCBhbmQgdGhlDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBCR1AtUHJlZml4IHNlZ21lbnQu DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEluIHRoZSBjYXNlIG9mIFNSLU1QTFMgdGhpcyBkaWZm ZXJlbnRpYXRpb24gaXMgYXNzdW1lZCBpbiBTZWN0aW9uDQo+ICAgICAgPiAzLjQgb2YNCj4gICAg ICA+ID4gdGhlIE5vZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aA0KPiAgICAgID4gPg0KPiAg ICAgID4NCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0piU1dHeDVEQWZO UHNaZGhwRXh4eDk2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9j JTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNyLXRlLXBh dGhzLTA3JTIzc2VjdGlvbi0zLjQNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0pi U1dHeDVEQWZOUHNaZGhwRXh4eDk2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9y LXNyLXRlLXBhdGhzLTA3JTIzc2VjdGlvbi0zLjQlMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zQ3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJG dXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUy RmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10 ZS1wYXRocy0wNyUyQXNlY3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4 OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNz biUyND4+DQo+ICAgICAgPg0KPiAgICAgID4gPiBkcmFmdCB0aGF0IHNheXM6DQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+ICAgICBUaGUgbm9kZSBwcm90ZWN0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQg aW4gdGhlIHByZXZpb3VzDQo+ICAgICBzZWN0aW9ucw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAg ICAgZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBsYWJlbCBpbW1lZGlhdGVseSBi ZWxvdw0KPiAgICAgID4gdGhlIHRvcA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBsYWJlbCBpbiB0 aGUgbGFiZWwgc3RhY2sgaXMgdW5kZXJzdG9vZCBpbiB0aGUgSUdQIGRvbWFpbi4gIFdoZW4gdGhl DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBwcm92aWRlciBlZGdlIHJvdXRlcnMgZXhjaGFu Z2Ugc2VydmljZSBsYWJlbHMgdmlhIEJHUCBvciBzb21lDQo+ICAgICAgPiBvdGhlcg0KPiAgICAg ID4gPg0KPiAgICAgID4gPiAgICAgbm9uLUlHUCBtZWNoYW5pc20gdGhlIGJvdHRvbSBsYWJlbCBp cyBub3QgdW5kZXJzdG9vZCBpbiB0aGUgSUdQDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBk b21haW4uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBUaGUgZWdyZXNzIG5vZGUgcHJvdGVj dGlvbiBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQNCj4gICAgICA+ID4NCj4gICAg ICA+ID4gICAgIFtSRkM4Njc5IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0pmdnRC QW1hUVBOMWpBM3BNNlRkQ0U2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGaHRtbCUyRnJmYzg2NzkNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v M0pmdnRCQW1hUVBOMWpBM3BNNlRkQ0U2SDI/dT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGZG9jJTJGaHRtbCUyRnJmYzg2NzklMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zNmRNQWp1WVRRb3ZvOGpId21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJG dXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUy RmRvYyUyRmh0bWwlMkZyZmM4Njc5X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5F OEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQ+ Pl0NCj4gICAgIGlzDQo+ICAgICAgPiA+IGFwcGxpY2FibGUgdG8gdGhpcyB1c2UgY2FzZSBhbmQg bm8gYWRkaXRpb25hbCBjaGFuZ2VzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICB3aWxsIGJl IHJlcXVpcmVkIGZvciBTUiBiYXNlZCBuZXR3b3Jrcw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBU aGUgc2NlbmFyaW9zIGluIHdoaWNoICBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiDigJx0b3BvbG9n aWNhbOKAnSBhbmQNCj4gICAgICA+ID4g4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnMgaXMgYnJv a2VuIGFyZSBpbmRlZWQgcHJvYmxlbWF0aWMuIEUuZy4sDQo+ICAgICAgPiBjb25zaWRlcg0KPiAg ICAgID4gPiB0aGUgdXNlIGNhc2UgaW4gd2hpY2ggYSBOb2RlIFNJRCBpbiB0aGUgRVJPIG9mIGEg U1ItVEUgcGF0aA0KPiAgICAgID4gaWRlbnRpZmllcyBhDQo+ICAgICAgPiA+IG5vZGUgdGhhdCBh Y3RzIGFzIGEgZmlyZXdhbGwgZm9yIGFsbCBwYWNrZXRzIGl0IHJlY2VpdmVzLCBpLmUuLA0KPiAg ICAgID4gcHJvdmlkZXMNCj4gICAgICA+ID4gdGhlIGZpcmV3YWxsIHNlcnZpY2Ugd2l0aG91dCBh bnkgZGVkaWNhdGVkIHNlcnZpY2UgU0lEDQo+ICAgICAgPiBpZGVudGlmeWluZyBpdC4NCj4gICAg ICA+ID4gT25lIGNvdWxkIHNheSB0aGF0IHRoZSBOb2RlIFNJRCBvZiBzdWNoIGEgbm9kZSB3b3Vs ZCBjb21iaW5lDQo+ICAgICAgPiB0b3BvbG9naWNhbA0KPiAgICAgID4gPiBhbmQgc2VydmljZSBp bnN0cnVjdGlvbnMgdGh1cyBicmVha2luZyB0aGUgZGlmZmVyZW50aWF0aW9uDQo+ICAgICAgPiBi ZXR3ZWVuIHRoZSB0d28uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgYW0gbm90IHN1cmUgaWYg dXNhZ2Ugb2Ygc3VjaCDigJxjb21iaW5lZOKAnSBTSURzIGNvdWxkIGJlIHByZXZlbnRlZA0KPiAg ICAgID4gb3IgYXQNCj4gICAgICA+ID4gbGVhc3QgZGlzY291cmFnZWQuDQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+IElmIG5vdCwgcHJvdmlkaW5nIGFuIGFiaWxpdHkgdG8gaWRlbnRpZnkgc3VjaCBT SURzIGluIHRoZQ0KPiAgICAgID4gYWR2ZXJ0aXNlbWVudA0KPiAgICAgID4gPiBtZWNoYW5pc21z IHdvdWxkIGJlIHVzZWZ1bCBJTUhPLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBNeSAyYywNCj4g ICAgICA+ID4NCj4gICAgICA+ID4gU2FzaGENCj4gICAgICA+ID4NCj4gICAgICA+ID4gT2ZmaWNl OiArOTcyLTM5MjY2MzAyDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IENlbGw6ICAgICAgKzk3Mi01 NDkyNjYzMDINCj4gICAgICA+ID4NCj4gICAgICA+ID4gRW1haWw6IEFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4N Cj4gICAgIDxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICAg PiA8bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPiAgICAgID4gPg0K PiAgICAgID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgICAgID4gPiBGcm9tOiBz cHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnJTBiPj4gICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI+Pg0KPiAg ICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNYWNoIENo ZW4NCj4gICAgICA+ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAyMCA2OjMwIEFNDQo+ICAg ICAgPiA+IFRvOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20NCjxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSUwYj4+ICAgICA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20l MGI+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PjsNCj4gICAgIHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJp bmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCj4gICAgICA+ID4NCj4g ICAgICA+ID4gSGkgSm9lbCwNCj4gICAgICA+ID4NCj4gICAgICA+ID4gSSB0aGluayB0aGlzIGlz IGEgZ29vZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZQ0KPiAgICAgID4g cGFzdC4gQW5kDQo+ICAgICAgPiA+IEkgYWxzbyBkb24ndCB0aGluayB0aGVyZSBpcyBhICJjYW4g YmUgYnlwYXNzZWQiIGluZGljYXRpb24gaW4gdGhlDQo+ICAgICAgPiA+IHJvdXRpbmcgYWR2ZXJ0 aXNlbWVudCBmb3Igbm93Lg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJTUhPLCB0aGUgaW5mb3Jt YXRpb24gYWR2ZXJ0aXNlZCBieSByb3V0aW5nIGlzIG5ldXRyYWwsIHN1Y2gNCj4gICAgICA+IGlu Zm9ybWF0aW9uDQo+ICAgICAgPiA+IChjYW4gb3IgY2Fubm90IGJlIGJ5cGFzc2VkKSBpcyBtb3Jl IHBhdGggc3BlY2lmaWMsIHRodXMNCj4gICAgIG5vcm1hbGx5IHRoZQ0KPiAgICAgID4gPiBjb250 cm9sbGVyIHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgZGVjaWRpbmcgd2hldGhlci93aGljaCBT SUQNCj4gICAgICA+IGNhbiBiZQ0KPiAgICAgID4gPiBieXBhc3NlZC4NCj4gICAgICA+ID4NCj4g ICAgICA+ID4gQmVzdCByZWdhcmRzLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBNYWNoDQo+ICAg ICAgPiA+DQo+ICAgICAgPiA+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICAg PiA+DQo+ICAgICAgPiA+ICA+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgICA+IDxtYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnJTBiJTNlJTIwJTNjbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTNlPl0NCj4g ICAgIE9uIEJlaGFsZiBPZiBKb2VsIE0uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IEhhbHBl cm4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMywgMjAy MCA3OjUxIEFNDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFRvOiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+IDxtYWlsdG86c3ByaW5nQGlldGYub3Jn IDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21h aWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAl M2NtYWlsdG86c3ByaW5nQGlldGYub3JnPj4+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFN1 YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJp bGl0eQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAg PiAoV0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20gYSBzbGlnaHRs eQ0KPiAgICAgID4gY29uZnVzZWQgV0cNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gcGFydGlj aXBhbnQuKQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4g PiAgPiBJIGhhdmUgYmVlbiByZWFkaW5nIHRoZSB2YXJpb3VzIHJlcGFpciBkcmFmdHMsIGFuZCB0 aGUgdmFyaW91cw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBuZXR3b3JrcyBwcm9ncmFtbWlu ZyBhbmQgc2VydmljZSBwcm9ncmFtbWluZyBkcmFmdCwgYW5kIEkgYW0NCj4gICAgICA+IHRyeWlu ZyB0bw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBmaWd1cmUgb3V0IG9uZSBhc3BlY3Qgb2Yg dGhlIGNvbWJpbmF0aW9uLg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0K PiAgICAgID4gPiAgPiBIb3cgZG9lcyBhIG5vZGUgdGhhdCBpcyBkb2luZyBzb21lIGZvcm0gb2Yg YnlwYXNzIChzdXBwb3NlLCBmb3INCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gc2ltcGxpY2l0 eSwgaXQgaXMgTm9kZSBOMiBkZWNpZGluZyB0byBieXBhc3MgdGhlIG5leHQgU0lEIGZvcg0KPiAg ICAgID4gYSBmYWlsZWQNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gbm9kZSBOMykga25vdyB0 aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAg ICAgPiA+DQo+ICAgICAgPiA+ICA+IElmIHRoZSBwYXRoIHdhcyBqdXN0IGZvciBURSwgdGhlbiBp dCBpcyAic2FmZSIgaWYgdGhlIG5ldyBwYXRoDQo+ICAgICAgPiBtZWV0cw0KPiAgICAgID4gPg0K PiAgICAgID4gPiAgPiB0aGUgVEUgY3JpdGVyaWEuICBvciBtYXliZSBpdCBpcyBzYWZlIGlmIGl0 IGlzIGV2ZW4gY2xvc2UsIGFzDQo+ICAgICAgPiBsb25nIGFzDQo+ICAgICAgPiA+DQo+ICAgICAg PiA+ICA+IGl0IGlzIG5vdCB1c2VkIGZvciB0b28gbG9uZy4NCj4gICAgICA+ID4NCj4gICAgICA+ ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gQnV0IHdoYXQgaWYgdGhlIG5vZGUgd2Vy ZSBhIEZpcmV3YWxsLCBpbmNsdWRlZCB0byBtZWV0IGxlZ2FsDQo+ICAgICAgPiA+IHJlcXVpcmVt ZW50cz8NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNz YXJ5IHByb2dyYW1tYXRpYyB0cmFuc2Zvcm0gKHdpbmNlIHdlIGFyZQ0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgPiBkZWxpYmVyYXRlbHkgdmFndWUgYWJvdXQgd2hhdCBub2RlcyBjYW4gZG8gd2hl biBhc2tlZCBzdWl0YWJseS4pDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+ICA+IElzIHRoZXJlIHNvbWUgImNhbiBiZSBieXBhc3NlZCIgaW5kaWNhdGlv biBpbiB0aGUgcm91dGluZw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBhZHZlcnRpc2VtZW50 cyB0aGF0IEkgbWlzc2VkPw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAgICAgID4gPg0K PiAgICAgID4gPiAgPiBUaGFuayB5b3UsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IFlvdXJz LA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBKb2VsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IHNwcmluZyBt YWlsaW5nIGxpc3QNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gc3ByaW5nQGlldGYub3JnPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWls dG86c3ByaW5nQGlldGYub3JnJTBiPj4gICAgIDxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNj bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+Pg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPg0KPiAg ICAgID4gPg0KPiAgICAgID4NCj4gICAgIGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z NjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI8aHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyPg0K PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTd2WDJxV1NVZFdWYzg5Mlh1 WHkySDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0El MkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1 JTNEaHR0cHMlMkEzQSUyQTJfXyUzQkpTVSUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4 RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNkh3UExpbCUyND4N Cj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyDQo8aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMl M0ElMjUyJTBiPj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0E1QjhIMkZt MXJQbmFaM1N1cGp3cjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9f aHR0cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2 UDQ2SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTI1Ml9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFT MFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG96 b1FpQUhrJTI0Pj4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gRiUyRnd3dy5pZXRmLm9yZzxo dHRwOi8vMkZ3d3cuaWV0Zi5vcmc+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNl LmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5FdDZ5TWFP LWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtU UkR1aURvLXBQQ2p2UiUyND4NCj4gICAgICA+IDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vM0dXVDlmeWphRmkzRmN2SER2b29kdlM2SDI/dT1odHRwJTNBJTJGJTJGMkZ3d3cuaWV0Zi5v cmcNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dXVDlmeWphRmkzRmN2SER2b29k dlM2SDI/dT1odHRwJTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmclMGI+PiAgICAgPGh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYub3JnX18l M0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9a SGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQ+PiUyRm1haWxtYW4lMkZsaXN0aW5mbyUy RnNwcmluZw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgID4gPg0KPiAgICAgID4gPiBzcHJpbmcgbWFp bGluZyBsaXN0DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIDxtYWlsdG86 c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZw0KPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiA8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAg aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0Nkgy P3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJp bmcNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0JoeUV0eDRRN243NEJo aVJuZk1KdFQ2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBz JTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0Nkgy JTNGdSUzRGh0dHBzJTJBM0ElMkEyRiUyQTJGd3d3LmlldGYub3JnJTJBMkZtYWlsbWFuJTJBMkZs aXN0aW5mbyUyQTJGc3ByaW5nX18lM0JKU1VsSlNVbCUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4 OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLWhSM2dB RCUyND4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4g ICAgICA+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICA+ID4gTm90aWNlOiBUaGlzIGUt bWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0KPiAgICAgID4g PiBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZp ZGVudGlhbA0KPiAgICAgID4gYW5kL29yDQo+ICAgICAgPiA+IHByb3ByaWV0YXJ5IGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywNCj4gICAgICA+ ID4gZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3 YXJkaW5nDQo+ICAgICB3aXRob3V0DQo+ICAgICAgPiA+IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4gICAgICA+IGludGVuZGVk DQo+ICAgICAgPiA+IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGwNCj4gICAgICA+ID4gY29waWVzLCBpbmNsdWRpbmcgYW55 IGF0dGFjaG1lbnRzLg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiAgICAgID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAg PiA+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPiA+IGh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+ICAg ICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXEx NkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlN YU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhB a1RSRHVpRG81S2xQbmJqJTI0Pg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgICA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPiBzcHJp bmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3Jn Pg0KPiAgICAgID4gaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNL eVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzcHJpbmcNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05y RG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJG djMlMkZfX2h0dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3By aW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3 eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQ+DQo+ICAgICAgPg0KPg0KPiAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAg IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgIHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgIGh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQo+DQo+IDxodHRw czovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1o dHRwcyUzQSUNCjxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFH NzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyNSUwYj4+IDJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUy Rl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmc8aHR0cDovLzJGd3d3LmlldGYub3JnPiUyRm1haWxt YW4lMkZsaXN0aQ0KPiBuZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4 OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1DQo+IG9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVL bFBuYmolMjQ+DQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gTm90aWNlOiBUaGlz IGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbg0KPiBpbmZv cm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlh bCBhbmQvb3INCj4gcHJvcHJpZXRhcnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LiBBbnkgcmV2aWV3LA0KPiBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmli dXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dA0KPiBleHByZXNzIHBlcm1pc3Np b24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+ IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVu IGRlbGV0ZSBhbGwNCj4gY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IC0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16 TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUy Rmxpc3RpbmZvJTJGc3ByaW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lN ek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnNwcmluZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBj b250YWluIGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMg Y29uZmlkZW50aWFsIGFuZC9vciBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRp c3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0IGV4cHJlc3MgcGVybWlz c2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4g ZGVsZXRlIGFsbCBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4B2dggeml509mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBLZXRhbiBh bmQgUm9iZXJ0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSB0aGluayB3 ZSBuZWVkIHRvIHNpZ25hbCBieXBhc3MtYWJsZSBpbmRpY2F0aW9uIGZvciBwcmVmaXggU0lEcyBp biBJR1AsIGFuZCBJIHRoaW5rIHRoaXMgaGFzIGJlZW4gd3JpdHRlbiBpbiBbMV0uIEJ1dCBpbiB0 aGlzIGRyYWZ0LCB3ZSBhbHNvIGFkZCBOby1ieXBhc3MgZmxhZyBmb3IgYWRqLVNJRCBhcyB3ZWxs LiBXZSBtYXkgbmVlZCB0byBkaXNjdXNzIHRoYXQNCiBkbyB3ZSBuZWVkIGl0IG9yIG5vdCBzaW5j ZSBCIGZsYWcgaXMgdGhlcmUgYWxyZWFkeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkFsc28sIG9wZXJhdG9yc+KAmSBQT1ZzIGFyZSBhbHdheXMgaW1wb3J0YW50LCB3ZSBj YW4gcmVhY2ggb3V0IHRvIHNvbWUgb3BlcmF0b3JzIEFTQVAuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNoZW5nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WzFdLjwvc3Bh bj4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXJ0Z3dnLWVu aGFuY2VkLXRpLWxmYS0wMiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGkt cnRnd2ctZW5oYW5jZWQtdGktbGZhLTAyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPktldGFuIFRhbGF1bGlrYXIgKGtldGFu dCk8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEF1Z3VzdCAxNSwgMjAyMCAxOjQ2IEFNPGJy Pg0KPGI+VG86PC9iPiBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDs8YnI+ DQo8Yj5DYzo8L2I+IEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDtBbGV4YW5kZXIuVmFpbnNodGVp bkByYmJuLmNvbSZndDs7IHNwcmluZ0BpZXRmLm9yZzsgSm9lbCBNLiBIYWxwZXJuICZsdDtqbWhA am9lbGhhbHBlcm4uY29tJmd0OzsgU2hyYWRkaGEgSGVnZGUgJmx0O3NocmFkZGhhQGp1bmlwZXIu bmV0Jmd0OzsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20gJmx0O0FuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3By aW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5XZSBkbyBub3QgaGF2ZSBhIHNpZ25hbGxpbmcgbWVjaGFuaXNtIGlu IElHUHMgdG9kYXkgdG8gaW5kaWNhdGUgYSDigJxieXBhc3MtYWJsZeKAnSBpbmRpY2F0aW9uIGZv ciBQcmVmaXggU0lEcy4gSWYgdGhlcmUgd2FzIGEgZGVzaXJlIGZvciBpdCwgYW4gSUdQIGV4dGVu c2lvbiB3b3VsZCBiZSByZXF1aXJlZCAodGhlcmUgaXMNCiBub25lIGluIHByb2dyZXNzIEFGQUlL KS4gTm90ZSB0aGF0IHRoaXMgcmVzdWx0cyBpbiBkb3VibGluZyB0aGUgcHJlZml4IFNJRCBzY2Fs ZSAoZ2xvYmFsIGxhYmVscykgaW4gdGhlIG5ldHdvcmsuIFNvIEkgd291bGQgbm90IGdvIGFib3V0 IHRoaXMgdHJpdmlhbGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUlOIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsg aXQgaGVscHMgdG8gZ2V0IG1vcmUgaW5wdXRzIGFuZCBwZXJzcGVjdGl2ZXMgZnJvbSBvcGVyYXRv cnMgb24gdGhlaXIgdmlld3MgZm9yIGRvaW5nIGEgYnlwYXNzIHZpYSBsb2NhbCBwcm90ZWN0aW9u IGZvciBzZWdtZW50cyBpbiBhbiBTUiBQb2xpY3kuIFRoZXJlIG1heSBiZSB0aG9zZSB0aGF0IHBy ZWZlcg0KIGVuZC10by1lbmQgcGF0aCBwcm90ZWN0aW9uIHVzaW5nIGEgZmFsbGJhY2sgcGF0aCB0 aGF0IGlzIHNheSBkaXNqb2ludCB3aXRoIHRoZSBwcmltYXJ5IGJ1dCBwcm92aWRlcyBhbiBhcHBy b3ByaWF0ZSBTTEEvaW50ZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5r cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1JTiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5LZXRhbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PkZyb206PC9iPiBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1 ay5uZXQiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxNCBB dWd1c3QgMjAyMCAyMzowNDxicj4NCjxiPlRvOjwvYj4gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50 KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudEBjaXNjby5jb20iPmtldGFudEBjaXNjby5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbSI+QWxleGFuZGVyLlZhaW5zaHRl aW5AcmJibi5jb208L2E+Jmd0OzsgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7OyBTaHJhZGRo YSBIZWdkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Ij5zaHJhZGRo YUBqdW5pcGVyLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tIj5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIj5B bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxp dHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tSU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiI+S2V0YW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1JTiI+TG9va3MgbGlrZSB3ZSBhcmUgcHJldHR5IG11Y2ggaW4gc3lu YyBoZXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1JTiI+QnV0IGxldCBtZSBqdXN0IG9ic2VydmUgdGhhdCBJIHB1cnBvc2VseSZuYnNwO2RpZCBu b3QgbWVudGlvbiBhYm91dCBTUiBwb2xpY2llcyBhcyB3ZSBhcmUgbm90IGFibGUgdG8gc2lnbmFs IHRoZSBpbnRlbnQgd2l0aCB0aGUgcGFja2V0cyBpdHNlbGYuJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tSU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIj5TbyBhbGwgd2UgaGF2ZSB0aGVyZSBp cyBTSURzLiBCU0lEcyBvciBwcmVmaXggU0lEcyBuZWVkIHRvIGJlIGZsb29kZWQgd2l0aCBpbmZv cm1hdGlvbiBpZiBwb2xpY2llcyBidWlsZCB3aXRoIHVzaW5nIHRoZW0gYXJlIGJ5cGFzcyBlbGln aWJsZSBvciBub3QuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUlOIj5JIHdhcyBhY3R1YWxseSB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMg aXMgYWxyZWFkeSB0aGVyZSBhbmQgSSBhbSBqdXN0IG5vdCBhd2FyZSwgYnV0IGxvb2tpbmcgZGVl cGVyIGluZGVlZCBJIGRvIG5vdCBzZWUgdGhpcyBtYXJraW5nIG5laXRoZXIgaW4gSVNJUyBub3Ig T1NQRiBmb3IgcHJlZml4IFNJRHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUlOIj5JcyB0aGVyZSBzb21lIHdvcmsgaW4gcHJvZ3Jlc3MgdG8gYWRk IGl0IHRvIHRob3NlIHByb3RvY29scyBvciBoYXZlIHdlIGp1c3QgZG9jdW1lbnRlZCBuZWVkJm5i c3A7Zm9yIGEgc2hvcnQgTFNSIGRyYWZ0Jm5ic3A7ID8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1J TiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tSU4iPlRoeCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1JTiI+ Ui48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1JTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUlOIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUlOIj5PbiBGcmksIEF1ZyAxNCwgMjAyMCBhdCA2OjE3IFBNIEtl dGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28u Y29tIj5rZXRhbnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1J TiI+SGkgUm9iZXJ0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPlBsZWFzZSBjaGVjayBpbmxpbmUg YmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUm9iZXJ0 IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9i bGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE0IEF1 Z3VzdCAyMDIwIDIxOjEzPGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQp ICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtl dGFudEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRl aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPC9hPiZndDs7IEpvZWwg TS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdl dD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs7IFNocmFkZGhhIEhlZ2RlICZs dDs8YSBocmVmPSJtYWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5z aHJhZGRoYUBqdW5pcGVyLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcu QWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8 c3BhbiBsYW5nPSJFTi1JTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+ SGkgS2V0YW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPldo aWxlIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHlvdXIgbm90ZSB0aGUgY29uc2VxdWVuY2VzIG9m IGl0IGFyZSBwcmV0dHkgc2V2cmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1JTiI+W0tUXSBJIHVuZGVyc3Rh bmQuIFdlIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiBpbXBsaWNhdGlvbnMgb2YgcHJvdGVjdGlvbiBz Y2hlbWVzIGZvciB0aGUgU0xBcy9pbnRlbnQgb2YgU1IgUG9saWNpZXMuPC9zcGFuPjwvaT48L2I+ PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tSU4iPlVubGVzcyB3ZSBzaWduYWwgd2hpY2ggcHJlZml4IFNJRCBpcyBwcm90 ZWN0aW9uIGVsaWdpYmxlIGFuZCB3aGljaCBpcyBub3QgaG93IHdvdWxkIG90aGVyIG5vZGVzIGtu b3cgaWYgdGhleSBjYW4gcHJvdGVjdCBpdCBvciBub3QgPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tSU4iPltL VF0gQ29ycmVjdC4gVG8gYmUgbW9yZSBhY2N1cmF0ZSwgd2UgbmVlZCB0byBjb25zaWRlciB0aGlz IG1vcmUgaW4gdGhlIGNvbnRleHQgb2YgU0xBIG9yIOKAnGludGVudOKAnSBvZiBTUiBQb2xpY2ll cyBhbmQgd2hpY2ggc2VnbWVudHMgbWF5IGJlIOKAnGJ5cGFzcy1hYmxl4oCdDQogZm9yIGxvY2Fs IHByb3RlY3Rpb24gZm9yIHNvbWUgb2YgdGhvc2UgU1IgUG9saWNpZXMuIFdlIGFsc28gaGF2ZSBw YXRoLXByb3RlY3Rpb24gbWVjaGFuaXNtcy48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1J TiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+ SXQgc2VlbXMgdGhhdCB0b2RheSdzIHNhZmUgdGhpbmcgaXMgbm90IHRvIGFwcGx5IGFueSBub2Rl IHByb3RlY3Rpb24gb24gU1IgZmxvd3MgYXQgdGhlIFBMUnMgdGhlbi4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj5BbmQgbGluayBwcm90 ZWN0aW9uIE1VU1QgYXNzdXJlIHRoYXQgcGFja2V0cyB3aWxsIGFycml2ZSBhdCB0aGUgbmVpZ2hi b3Igbm9kZSB2aWEgc29tZSBvdGhlciBsaW5rIHJlZ2FyZGxlc3Mgb2YgZnVydGhlciBwYXRoIHRv d2FyZHMgZGVzdGluYXRpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1JTiI+W0tUXSBZZXMuIFdlIGhhdmUg YSBtZWNoYW5pc20gdG8gaW5kaWNhdGUgd2hpY2ggYWRqLVNJRHMgaGF2ZSBwcm90ZWN0aW9uICh0 aGF0IG1lY2hhbmlzbSBvbmx5IHByb3ZpZGVzIGxpbmsgcHJvdGVjdGlvbiB0byBnZXQgdG8gdGhl IG5laWdoYm9yIG5vZGUpIHNvIHRoZQ0KIFNSIFBvbGljeSBjb21wdXRhdGlvbiBpcyBhYmxlIHRv IGluZGljYXRlIHdoZXRoZXIgdGhhdCBzcGVjaWZpYyBsaW5rIGlzIOKAnGJ5cGFzcy1hYmxl4oCd IG9yIG5vdCBieSBpdHMgY2hvaWNlIG9mIHByb3RlY3RlZCBvciB1bnByb3RlY3RlZCBhZGotU0lE cyByZXNwZWN0aXZlbHkuPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0i RU4tSU4iPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUlOIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9IkVO LUlOIj5UaGFua3MsPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRU4t SU4iPktldGFuPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPklzIGl0IGNvcnJlY3QgPyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4i PlRoeDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPlI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj5PbiBGcmksIEF1ZyAxNCwgMjAyMCBhdCA1OjMyIFBN IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tSU4iPkhpIFNhc2hhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPlRo ZSBzZXJ2aWNlIG5vZGUgYWR2ZXJ0aXNlcyBpdHMgb3duIFByZWZpeCBTSUQuIFRoZSBzZXJ2aWNl IGZ1bmN0aW9uIHRoYXQgdGhpcyBzZXJ2aWNlIG5vZGUgaW1wbGVtZW50cyBkb2VzIG5vdCByZXF1 aXJlIGFueSBjb250ZXh0IChpLmUuIGFsbCBwYWNrZXRzIGFycml2aW5nDQogYXQgdGhlIG5vZGUg YXJlIHN1YmplY3RlZCB0byB0aGF0IHNlcnZpY2UpLiBUaGVyZWZvcmUgdGhlIHNlcnZpY2Ugbm9k ZSBkb2VzIG5vdCBuZWVkIHRvIHJlY2VpdmUgYSBwYWNrZXQgd2l0aCBpdOKAmXMgb3duIFByZWZp eCBTSUQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj5UaHVzLCB3ZSBjYW5ub3QgYXNzdW1lIHRo YXQgd2hlbiBQSFAgaXMgdXNlZCwgdGhlbiB0aGUgU0lEIGlzIG9ubHkgYXNzb2NpYXRlZCB3aXRo IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+SG9wZSB0 aGF0IGNsYXJpZmllcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj5UaGFua3MsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+S2V0 YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gQWxl eGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkByYmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29t PC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxNCBBdWd1c3QgMjAyMCAyMDoyNDxicj4NCjxi PlRvOjwvYj4gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtl dGFudEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5rZXRhbnRAY2lzY28uY29tPC9hPiZndDs7 IEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i IHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs7IFNocmFkZGhhIEhl Z2RlICZsdDs8YSBocmVmPSJtYWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQiIHRhcmdldD0iX2Js YW5rIj5zaHJhZGRoYUBqdW5pcGVyLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOkVYVC1B bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+RVhULUFuZHJl dy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJldy5BbHN0b25A bGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0OzsgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eTxzcGFuIGxhbmc9IkVOLUlOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5LZXRhbiwgYW5kIGFs bCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLUlOIiBz dHlsZT0iY29sb3I6IzIxMjEyMSI+SSBoYXZlIHN0YXRlZCB0aGF0LCBJTUhPIGFuZCBGV0lXLCBi b3RoIEFkai1TSURzIGFuZCBQcmVmaXggU0lEcyB0aGF0IGFyZSBhZHZlcnRpc2VkIHdpdGggUEhQ IGNhbiZuYnNwOyBPTkxZIHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgaW4gU1It TVBMUyAtIGJlY2F1c2UgdGhlIGFkdmVydGlzaW5nIG5vZGUgd2lsbCBub3QgcmVjZWl2ZSB0aGVt IGFuZCB0aGVyZWZvcmUNCiBjYW4gaGFyZGx5IGJlIGV4cGVjdGVkIHRvIGFzc29jaWF0ZSBhbnkg c2VydmljZSBmdW5jdGlvbiB3aXRoIHRoZW0uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUlOIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1JTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJj b2xvcjojMjEyMTIxIj5UaGlzIGlzIGNvbXBsZW1lbnRhcnkgdG8gd2hhdCB5b3UgaGF2ZSBzYWlk Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1JTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tSU4iIHN0 eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+SG9wZSB0aGlzIGNs YXJpZmllcyBteSBwb3NpdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+V2hhdCwgaWYgYW55dGhpbmcs IGRpZCBJIG1pc3M/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUlOIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5n PSJFTi1JTiIgc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1JTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5S ZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1JTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4t SU4iIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5TYXNoYTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1JTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0iZ21haWwtbV8tMTY5OTUyMjQxOTU0NjMw MDY0M2dtYWlsLW1fLTU3NTYwNjU0NTU4NDMyNTA5MG1zLW91dGxvb2stbW9iaWxlLXNpZ25hdHVy ZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUlOIj5HZXQNCjxhIGhyZWY9Imh0dHBzOi8vYWthLm1zL2doZWkzNiIg dGFyZ2V0PSJfYmxhbmsiPk91dGxvb2sgZm9yIEFuZHJvaWQ8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy0xNjk5NTIyNDE5NTQ2MzAwNjQzZ21haWwt bV8tNTc1NjA2NTQ1NTg0MzI1MDkwaWQtNzNlMTM5NmMtNjE2ZS00YzQ1LTk4ZDEtMjU2NzgwZDAx NTNmIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIiBz dHlsZT0iZm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLUlOIj4NCjxo ciBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxk aXYgaWQ9ImdtYWlsLW1fLTE2OTk1MjI0MTk1NDYzMDA2NDNnbWFpbC1tXy01NzU2MDY1NDU1ODQz MjUwOTBkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48c3Bh biBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gbGFuZz0iRU4tSU4iPiBLZXRhbiBU YWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50QGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2Vu dDo8L3NwYW4+PC9zdHJvbmc+IEZyaWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNjoyMzxicj4NCjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VG86PC9zcGFuPjwvc3Ryb25nPiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgSm9lbCBNLiBI YWxwZXJuOyBTaHJhZGRoYSBIZWdkZTsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxp cXVpZHRlbGVjb20uY29tPC9hPjsgUm9iZXJ0IFJhc3p1azxicj4NCjxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2M6PC9zcGFu Pjwvc3Ryb25nPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQpzcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0Ojwvc3Bhbj48L3N0 cm9uZz4gUkU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGlj YWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxz cGFuIGxhbmc9IkVOLUlOIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRl ciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUlOIj5OT1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwgc2Vu ZGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLUlOIj4NCjxo ciBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1JTiI+SGkgU2FzaGEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+SWYgdGhlIHNlcnZpY2UgZG9l cyBub3QgbmVlZCBhbnkgYWRkaXRpb25hbCBjb250ZXh0IChlLmcuIGEgZmlyZXdhbGwgdGhhdCBq dXN0IGFwcGxpZXMgbG9jYWxseSBjb25maWd1cmVkIGRlZmF1bHQgcnVsZXMgb24gaXQpLCB0aGVu IEkgZG9u4oCZdCBzZWUgd2h5IFBIUCBjb3VsZA0KIG5vdCBiZSBkb25lIGZvciBhIFByZWZpeCBT SUQgYXNzb2NpYXRlZCB3aXRoIGEgc2VydmljZSBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4i PkFsc28sIEkgZGlkbuKAmXQgZm9sbG93IHRoZSBwb2ludCB0aGF0IHlvdSB3ZXJlIHRyeWluZyB0 byBtYWtlIGFib3V0IEFkai1TSURzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUlOIj5LZXRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206 PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5W YWluc2h0ZWluQHJiYm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5A cmJibi5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE0IEF1Z3VzdCAyMDIwIDE4OjI0 PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDs8YSBocmVmPSJt YWlsdG86a2V0YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudEBjaXNjby5jb208 L2E+Jmd0OzsgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OzsgQWxl eGFuZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVp bkByYmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29t PC9hPiZndDs7DQogU2hyYWRkaGEgSGVnZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBq dW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNocmFkZGhhQGp1bmlwZXIubmV0PC9hPiZndDs7 DQo8YSBocmVmPSJtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRh cmdldD0iX2JsYW5rIj5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4gJmx0 OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9 Il9ibGFuayI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7OyBSb2JlcnQg UmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2Js YW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBk ZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImNvbG9y OiMyMTIxMjEiPkhpIGFsbCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IGxhbmc9IkVOLUlOIiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+UmVnYXJkaW5nIHRoZSBzdGF0ZW1l bnQgJnF1b3Q7UHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rp b24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0aGUgZmxvdyB0byBhIG5vZGUgd2hpY2gg aXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGl0JnF1b3Q7Ojwvc3Bhbj48c3BhbiBs YW5nPSJFTi1JTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJjb2xvcjojMjEy MTIxIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9 IkVOLUlOIiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUlOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImNvbG9yOiMyMTIxMjEiPkkg dGhpbmsgdGhhdCBpbiBTUi1NUExTIGEgTm9kZSBTSUQgdGhhdCBpcyBhZHZlcnRpc2VkIHdpdGgg UEhQIGFjaXRvbiBjYW4gYmUgc2FmZWx5IGNvbnNpZGVyZWQgYXMgJnF1b3Q7anVzdCBhIHRvcG9s b2dpY2FsIGluc3RydWN0aW9uJnF1b3Q7IGJ5IHRoZSBQTFIgYmVjYXVzZSB0aGUgb3JpZ2luYXRp bmcgbm9kZSB3aWxsIG5vdCByZWNlaXZlIGl0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1JTiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5UaGUgc2FtZSBh cHBsaWVzIHRvIEFkai1TRElzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1JTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iY29sb3I6IzIx MjEyMSI+TXkgMmMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUlOIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IGlkPSJnbWFpbC1tXy0xNjk5NTIyNDE5NTQ2MzAwNjQzZ21haWwtbV8tNTc1NjA2 NTQ1NTg0MzI1MDkwbXMtb3V0bG9vay1tb2JpbGUtc2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4i PkdldA0KPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM3NWM1WVlCZUVi YUVad1VjSHBDWTFtNkgyP3U9aHR0cHMlM0ElMkYlMkZha2EubXMlMkZnaGVpMzYiIHRhcmdldD0i X2JsYW5rIj4NCk91dGxvb2sgZm9yIEFuZHJvaWQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy0xNjk5NTIyNDE5NTQ2MzAwNjQzZ21haWwtbV8tNTc1 NjA2NTQ1NTg0MzI1MDkwaWQtNmJmNDRkNTEtMGU2MC00NDhiLWJkZGUtZGM0MTkyNDllZmEyIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0i Zm9udC1zaXplOjE0LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLUlOIj4NCjxociBzaXpl PSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9 ImdtYWlsLW1fLTE2OTk1MjI0MTk1NDYzMDA2NDNnbWFpbC1tXy01NzU2MDY1NDU1ODQzMjUwOTBk aXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48c3BhbiBsYW5n PSJFTi1JTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gbGFuZz0iRU4tSU4iPiBzcHJpbmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgS2V0YW4gVGFsYXVs aWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudD00MGNpc2NvLmNvbUBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW50Ojwvc3Bhbj48L3N0cm9uZz4gRnJpZGF5LCBB dWd1c3QgMTQsIDIwMjAsIDE1OjAwPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ubzo8L3NwYW4+PC9zdHJvbmc+IEpv ZWwgTS4gSGFscGVybjsgQWxleGFuZGVyIFZhaW5zaHRlaW47IFNocmFkZGhhIEhlZ2RlOw0KPGEg aHJlZj0ibWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9 Il9ibGFuayI+RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+OyBSb2JlcnQg UmFzenVrPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5DYzo8L3NwYW4+PC9zdHJvbmc+IDxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+ DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlN1YmplY3Q6PC9zcGFuPjwvc3Ryb25nPiBSZTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1JTiI+SGkgQWxsLDxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0byBzaGFyZSBhIGRp ZmZlcmVudCBwZXJzcGVjdGl2ZSBvbiB0aGlzLjxicj4NCjxicj4NCkZpcnN0LCB0aGFua3MgdG8g Sm9lbCBmb3IgYnJpbmdpbmcgdXAgdGhlIGRpc2N1c3Npb24uIENsZWFybHkgd2UgbmVlZCBhIHdl bGwtZGVmaW5lZCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBmb3IgZGV0ZXJtaW5pbmcgYXBwbGlj YWJpbGl0eSBvZiBwcm90ZWN0aW9uIGZvciBzZWdtZW50IHVzZWQgaW4gYW4gU1IgUG9saWN5LiBT b21lIG9mIHRoaXMgaXMgY2FwdHVyZWQgaW4gWzFdLjxicj4NCjxicj4NClRoaXMgaXMgYWJvdXQg bG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkgbmF0dXJlLCB0aGUgUExSIGRvZXMg bm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICZxdW90O3N0cmljdCBvciBub3QmcXVvdDsgaXMgdGhl IFNMQSB0aGF0IGlzIGJlaW5nIHByb3ZpZGVkIGJ5IHRoZSBTUiBQb2xpY3kuIEF3YXJlbmVzcyBv ZiB0aGF0IG5vdGlvbiBleGlzdHMgYXQgdGhlIFNSIFBvbGljeSBoZWFkZW5kIGFuZC9vciBjb21w dXRhdGlvbi1ub2RlLjxicj4NCjxicj4NCldlIGhhdmUgcHJvdGVjdGVkIGFuZCB1bi1wcm90ZWN0 ZWQgdmFyaWFudHMgb2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBjb21wdXRhdGlvbiB0 byBwaWNrIG9yIHRoZSBvdGhlciBiYXNlZCBvbiB0aGUgJnF1b3Q7c3RyaWN0bmVzcyZxdW90OyBv ZiB0aGUgU0xBIHJlcXVpcmVtZW50IGZvciBwaWNraW5nIHRoYXQgbGluay4gV2UgZG8gbm90IGhh dmUgc3VjaCBhIG5vdGlvbiBmb3IgUHJlZml4IFNJRHMuIE9uZSBjYW4gc2F5IHRoYXQgd2UgY291 bGQgaW50cm9kdWNlDQogc2lnbmFsbGluZyAoZS5nLiBhIEIgZmxhZykgdG8gaW5kaWNhdGUgd2hl dGhlciBhIFByZWZpeCBTSUQgY2FuIGJlIGJ5cGFzc2VkIG9yIG5vdC4gVGhpcyBwcm92aWRlcyB0 aGUgb3Bwb3J0dW5pdHkgZm9yIHRoZSBjb21wdXRhdGlvbiB0byB1c2Ugb25lIG9yIHRoZSBvdGhl ciBmbGF2b3IgZGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgdGhlIFNMQSBmb3IgdGhlIFNSIFBv bGljeS48YnI+DQo8YnI+DQpJIGhhdmUgYSBwcm9ibGVtIGFuZCBhIGNvbmNlcm4gaW4gdGhlIGFz c3VtcHRpb24gdGhhdCBQTFJzIGNhbiBhc3N1bWUgdGhhdCB0aGUgY3VycmVudGx5IGRlZmluZWQg dmFyaWFudCBvZiBQcmVmaXggU0lEcyBpbiBSRkM4NDAyIChhbmQgSUdQIHNwZWNzKSBhcmUgJnF1 b3Q7YnlwYXNzLWFibGUmcXVvdDsuPGJyPg0KPGJyPg0KQXMgSm9lbCBhbmQgb3RoZXJzIGhhdmUg YnJvdWdodCBvdXQsIHRoZSBQcmVmaXggU0lEIGNvdWxkIGJlIGp1c3QgYSB0b3BvbG9naWNhbCBp bnN0cnVjdGlvbiBvciBtYXkgYWxzbyBiZSB1c2VkIHRvIHN0ZWVyIHRoZSBmbG93IHRvIGEgbm9k ZSB3aGljaCBpcyBhcHBseWluZyBhIHNlcnZpY2UgZnVuY3Rpb24gdG8gaXQuIEluIG9yZGVyIHRv IHN1cHBvcnQgYSBtaXggb2YgU1IgUG9saWNpZXMgb2YgZGlmZmVyZW50IFNMQXMgKHN0cmljdCBh bmQgbm90LXN0cmljdCksDQogd2UgbmVlZCB0byBlbmFibGUgdGhlIGNob2ljZSBvZiBTSURzIHRo YXQgaW5kaWNhdGVzIHRvIHRoZSBQTFIgd2hldGhlciB0aGV5IGFyZSAmcXVvdDtieXBhc3MtYWJs ZSZxdW90OyBvciBub3QuPGJyPg0KPGJyPg0KRm9yIHRoZSBjYXNlcywgd2hlcmUgdGhlIFNSIFBv bGljeSBoYXMgYSBzcGVjaWZpYyBTTEEsIGl0IGlzIHJlcXVpcmVkIGZvciBub2RlcyB0byBkcm9w IHRoZSBwYWNrZXRzIG1lYW50IGZvciB0aGUgJnF1b3Q7YWN0aXZlIHNlZ21lbnQmcXVvdDsgdGhh biB0byBieXBhc3MgaXQuIFdoZW4gdGhpcyBtZWNoYW5pc20gaXMgdXNlZCBhbG9uZyBzaWRlIFNS VEUgcGF0aCBtb25pdG9yaW5nIG1lY2hhbmlzbXMsIGl0IGVuYWJsZXMgdGhlIGhlYWRlbmQgdG8g ZGV0ZWN0IHRoZQ0KIGZhaWx1cmUgYW5kIGZhbGxiYWNrIHRvIGFuIGFsdGVybmF0ZSBwYXRoIHVz aW5nIHRoZSBwYXRoIHByb3RlY3Rpb24gYXBwcm9hY2guIFRoaXMgaXMgc29tZXRoaW5nIHRoYXQg aXMgZGVzY3JpYmVkIGFuZCBpbiB1c2UgaW4gZGVwbG95bWVudHMgdG9kYXkgWzFdLi48YnI+DQo8 YnI+DQpUaGFua3MsPGJyPg0KS2V0YW48YnI+DQo8YnI+DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1zNkgyP3U9aHR0cHMl M0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1kzZld1TkZZQ2pNSlVpaUFpV3dVbXM2SDI/dT1odHRw cyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTk8L2E+PGJyPg0KWzJdIDxhIGhyZWY9Imh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmZDTXJnbUVld0M0YTRBSlJybW43SDZIMj91 PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmct c2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOCUyM3NlY3Rpb24tOS4zIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzZmQ01yZ21FZXdDNGE0QUpScm1uN0g2 SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTkuMzwvYT48YnI+DQo8YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHNwcmluZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuPGJy Pg0KU2VudDogMDQgQXVndXN0IDIwMjAgMjA6MjU8YnI+DQpUbzogQWxleGFuZGVyIFZhaW5zaHRl aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPC9hPiZndDs7IFNocmFk ZGhhIEhlZ2RlICZsdDs8YSBocmVmPSJtYWlsdG86c2hyYWRkaGE9NDBqdW5pcGVyLm5ldEBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNocmFkZGhhPTQwanVuaXBlci5uZXRAZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1 aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29t PC9hPiZndDs7IFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQpDYzog PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0Bp ZXRmLm9yZzwvYT47IEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8 YnI+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmlu ZyBhcHBsaWNhYmlsaXR5PGJyPg0KPGJyPg0KVGhlcmUgYXJlLCBhcyBmYXIgYXMgSSBjYW4gdGVs bCwgYSBudW1iZXIgb2Ygd2F5cyB0byBhZGRyZXNzIHRoaXMgZmFtaWx5IG9mIHJlbGF0ZWQgcXVl c3Rpb25zLjxicj4NCldoYXQgc3RydWNrIG1lLCBhbmQgcHJvbXB0ZWQgdGhlIHN0YXJ0aW5nIHF1 ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2VyZSBzcGVsbGVkIG91dC4mbmJzcDsgSSBz ZWUgbG90cyBvZiBpbnRlcmVzdGluZyBpZGVhcyAvIHByb3Bvc2Fscy48YnI+DQpTb21lIG9mIHRo ZW0gYXJlIGNvbXBhdGlibGUgd2l0aCBvdGhlcnMuJm5ic3A7Jm5ic3A7IFNvbWUgYXJlIG5vdC48 YnI+DQpJdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxkIHJlYWNoIGFncmVlbWVudCBvbiBob3cg d2UgdGhvdWdodCBpdCBzaG91bGQgYmUgaGFuZGxlZC48YnI+DQo8YnI+DQpUaGFuayB5b3UsPGJy Pg0KSm9lbDxicj4NCjxicj4NCk9uIDgvNC8yMDIwIDM6NTQgQU0sIEFsZXhhbmRlciBWYWluc2h0 ZWluIHdyb3RlOjxicj4NCiZndDsgSGkgYWxsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIHN0 aWxsIG5vdCBzdXJlIHRoYXQgdGhlIHByb2JsZW0gb2YgYnlwYXNzIGdvaW5nIHRocnUgdW5kZXNp cmFibGUgPGJyPg0KJmd0OyBsaW5rcy9ub2RlcyBleGlzdHMgaW4gdGhlIGNhc2Ugb2YgdG9wb2xv Z2ljYWwgU0lEcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgQUZBSUssIEZhY2lsaXR5IFByb3RlY3Rp b24gaW4gUlNWUC1URSBGUlIgKFJGQyA0MDkwPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNROTJrbkU5WEp1anJmOEJrN29KdnM2SDI/dT1odHRw cyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzQwOTAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1E5MmtuRTlYSnVqcmY4Qms3b0p2czZI Mj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZjNDA5MDwvYT4mZ3Q7 KSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkNCiBkZXBsb3llZCA8YnI+DQomZ3Q7IGZvciBtYW55IHll YXJzIGJlZm9yZSBTUi1NUExTIGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTigJlzIG1vcmUsIDxi cj4NCiZndDsgc2lnbmFsaW5nIG9mIGJ5cGFzcyB0dW5uZWxzIGhlIFBMUiB1c3VhbGx5IGRpZCBu b3QgaW5jbHVkZSBhbnkgb2YgdGhlIDxicj4NCiZndDsgY29uc3RyYWludHMgdXNlZCBmb3IgY29t cHV0aW5nIG9mIGFueSBzcGVjaWZpYyBMU1AgdGhhdCB0aGUgYnlwYXNzIExTUCA8YnI+DQomZ3Q7 IHdvdWxkIHByb3RlY3Qg4oCTIGJlY2F1c2UgaW4gdGhlIEZhY2lsaXR5IFByb3RlY3Rpb24gbW9k ZSB0aGUgc2FtZSA8YnI+DQomZ3Q7IGJ5cGFzcyBMU1Agd291bGQgYmUgdXNlZCB0byBwcm90ZWN0 IG11bHRpcGxlIExTUHMgcGFzc2luZyB0aHJ1IHRoZSA8YnI+DQomZ3Q7IGZhaWxlZCBsaW5rL25v ZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7IEZyb20gbXkgUE9WIHRoZSBvbmx5IGRpZmZl cmVuY2UgYmV0d2VlbiB0aGlzIGJlaGF2aW9yIGFuZCB0aGF0IDxicj4NCiZndDsgaW50cm9kdWNl ZCBieSB0aGUg4oCcYnlwYXNzaW5n4oCdIGRyYWZ0cyBpbiBTUiBpcyB0aGF0LCBpbiB0aGUgY2Fz ZSBvZiA8YnI+DQomZ3Q7IFJTVlAtVEUsIHRoZSBvcGVyYXRvciB3b3VsZCBleHBsaWNpdGx5IGlu ZGljYXRlLCBhcyBwYXJ0IG9mIExTUCA8YnI+DQomZ3Q7IHNpZ25hbGluZywgd2hldGhlciBpdCB3 b3VsZCBvciB3b3VsZCBub3QgdXNlIEZSUjsgTFNQcyB0aGF0IHdvdWxkIG5vdCA8YnI+DQomZ3Q7 IHVzZSBGUlIgd291bGQgdGhlbiBkcm9wIHRyYWZmaWMgcmF0aGVyIHRoYW4gZGVsaXZlcmluZyBp dCB0aGUgd3Jvbmcgd2F5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBTdWNoIGFuIG9wdGlvbiBpbmRl ZWQgZG9lcyBub3QgZXhpc3QgaW4gU1ItVEUgdG9kYXksIGJ1dCB3b3VsZCBiZSBlYXN5IDxicj4N CiZndDsgdG8gcHJvdmlkZSBpZiBzbyBkZXNpcmVkIElNSE8uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IERpZCBJIG1pc3Mgc29tZXRoaW5nIHN1YnN0YW50aWFsPzxicj4NCiZndDsgPGJyPg0KJmd0OyBS ZWdhcmRzLCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2YW5jZSw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgU2FzaGE8YnI+DQomZ3Q7IDxicj4NCiZndDsgT2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxi cj4NCiZndDsgPGJyPg0KJmd0OyBDZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOzk3Mi01NDkyNjYzMDI8YnI+DQomZ3Q7IDxicj4NCiZndDsgRW1haWw6Jm5ic3A7Jm5ic3A7 IDxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPjxicj4NCiZndDsg PGJyPg0KJmd0OyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyAqT24gQmVoYWxmIE9mICpTaHJhZGRoYSBIZWdkZTxicj4NCiZndDsgKlNlbnQ6KiBUdWVz ZGF5LCBBdWd1c3QgNCwgMjAyMCA5OjQxIEFNPGJyPg0KJmd0OyAqVG86KiA8YSBocmVmPSJtYWls dG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5F WFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT48YnI+DQomZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0OzsgUm9iZXJ0IFJhc3p1 ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+ cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgKkNjOiogPGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IEpv ZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRh cmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQomZ3Q7ICpTdWJq ZWN0OiogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGlj YWJpbGl0eTxicj4NCiZndDsgPGJyPg0KJmd0OyBBbGwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo aXMgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIHRoYW5rcyB0byBKb2VsIGZv ciBzdGFydGluZyA8YnI+DQomZ3Q7IHRoaXMgZGlzY3Vzc2lvbi4gSU1PLCB3aGVuIHRoZXJlIGFy ZSBzdHJpY3QgcmVxdWlyZW1lbnRzIG9mIGF2b2lkaW5nIDxicj4NCiZndDsgY2VydGFpbiBub2Rl cy9saW5rcyBpdCBjYW4gYmUgcmVhbGl6ZWQmbmJzcDsgZWl0aGVyIGJ5IGRlZmluaW5nIGEgZmxl eC1hbGdvIDxicj4NCiZndDsgYXZvaWRpbmcgdGhvc2U8YnI+DQomZ3Q7IDxicj4NCiZndDsgTm9k ZXMgYW5kIGxpbmtzIG9yIGJ5IHVzaW5nIGEgc3RhY2sgb2YgdW5wcm90ZWN0ZWQgYWRqLXNpZHMg dGhhdCBhdm9pZCA8YnI+DQomZ3Q7IHJlc3RyaWN0ZWQgbm9kZXMgYW5kIGxpbmtzLiBXaGVuIGEg c3RhY2sgb2YgYWRqLXNpZHMgaXMgdXNlZCB0byA8YnI+DQomZ3Q7IHJlYWxpemUgdGhlIHBhdGgs IHRoZSBoZWFkLWVuZCBiYXNlZCAoc0JGRCkgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGNhbiBiZSBh cHBsaWVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBOb2RlLXNpZHMvcHJlZml4LXNpZC9hbnlj YXN0LXNpZHMgYXJlIHVzZWQgdG8gYnVpbGQgdGhlIHN0YWNrLCB0aGUgPGJyPg0KJmd0OyBmYWls dXJlIGV2ZW50cyBtYXkgY2F1c2UgdHJhZmZpYyB0byBnbyB0aHJvdWdoIHJlc3RyaWN0ZWQgbm9k ZXMgYW5kIDxicj4NCiZndDsgbGlua3MuIFRoaXMgd291bGQgaGFwcGVuIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBhbnkga2luZCBvZiBwcm90ZWN0aW9uIDxicj4NCiZndDsgaXMgaW4gdXNlIG9yIG5v dC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmdkczxicj4NCiZndDsgPGJyPg0KJmd0OyBTaHJhZGRo YTxicj4NCiZndDsgPGJyPg0KJmd0OyBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7ICpGcm9tOiogc3ByaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmclMjAlMGIiIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRm Lm9yZw0KPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7Jmd0OyAqT24gQmVoYWxmIE9mICpBbmRyZXcgQWxzdG9uPGJyPg0KJmd0OyAqU2VudDoq IFR1ZXNkYXksIEF1Z3VzdCA0LCAyMDIwIDU6NDEgQU08YnI+DQomZ3Q7ICpUbzoqIFJvYmVydCBS YXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6 dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsm Z3Q7PGJyPg0KJmd0OyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0 OzsgSm9lbCBNLiBIYWxwZXJuDQo8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+ICZs dDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyAqU3ViamVjdDoq IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxp dHk8YnI+DQomZ3Q7IDxicj4NCiZndDsgKltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2Yg Y29udGVudF0qPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJvYmVydCB0aGlzIGlzIGFjdHVhbGx5IGZh ciBtb3JlIGRpZmZpY3VsdCB3aGVuIOKAkyBpdCBjYW4gYmUgYW4gZW50aXJlPGJyPg0KJmd0OyAo bG9uZykgc2VyaWVzIG9mIG5vZGVzIHRoYXQgbmVlZCB0byBiZSBhdm9pZGVkLjxicj4NCiZndDsg PGJyPg0KJmd0OyBJdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBtYWRlIHRvIHdvcmsgYnV0IEnigJlk IHdvcnJ5IHRoYXQgdG8gZG8gdGhpcyDigJMgPGJyPg0KJmd0OyB5b3XigJlkIGhhdmUgdG8gc3Rh Y2sgMTAg4oCTIDIwIOKAkyAzMCBuZWdhdGl2ZSBsYWJlbHMg4oCTIGFuZCB0aGF0IHdvdWxkbuKA mXQgPGJyPg0KJmd0OyBiZSB2aWFibGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl04oCZcyBlYXNp ZXIgdG8gdXNlIGFsZ29yaXRobXMgYW5kIGFkamFjZW5jeSBzaWRzIGFuZCBvdGhlciBzdWNoIHRo aW5ncyA8YnI+DQomZ3Q7IHRvIGNhbGN1bGF0ZSBwYXRocyDigJMgdGhlIGJpZ2dlc3QgdHJpY2sg aXMgYWJvdXQgdGhlIHN0YWNrIGRlcHRoLiZuYnNwOyBXaGVuIDxicj4NCiZndDsgeW91IGhhdmUg dGhpcyBuZWVkIGZvciBub2RlIGF2b2lkYW5jZSDigJMgdGhlIG5lZWQgZm9yIDEwJiM0MzsgbGFi ZWwgZGVwdGggPGJyPg0KJmd0OyBpcyBjcml0aWNhbCDigJMgdW5sZXNzIHlvdSB3YW5uYSBiZSBh cHBseWluZyBvbmUgaGVsbCBvZiBhIGxvdCBvZiA8YnI+DQomZ3Q7IGJpbmRpbmcgbGFiZWxzIGFs b25nIHRoZSB3YXkgd2hpY2ggaXMgYSBuaWdodG1hcmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ1 dCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaXMgdGhpcyBhIGNvbW1vbiB1c2UgY2FzZSDigJMg aXTigJlzIGEgdXNlIDxicj4NCiZndDsgY2FzZSB0aGF0IG1vc3Qgb2YgdGhlIHBlb3BsZSBJIGRp c2N1c3MgdGhpcyB3aXRoIGNlcnRhaW4gaGF2ZSDigJMgSSBjYW50IDxicj4NCiZndDsgY29tbWVu dCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFueW9uZSBlbHNlLCBidXQgZXZlcnkgaW5kaWNh dGlvbiBJIDxicj4NCiZndDsgaGF2ZSBpcyB0aGF0IHllcyDigJMgaXRzIHNvbWV0aGluZyBwZW9w bGUgbmVlZCwgYW5kIHdhbnQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgQW5kcmV3PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICpGcm9tOiogUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVy dEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+ICZsdDs8 YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICpTZW50OiogVHVlc2RheSwg NCBBdWd1c3QgMjAyMCAwMToyNzxicj4NCiZndDsgKlRvOiogQW5kcmV3IEFsc3RvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGIiIHRhcmdl dD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8YnI+DQo8L2E+Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4m Z3Q7Jmd0Ozxicj4NCiZndDsgKkNjOiogSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYiIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFs cGVybi5jb20NCjxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZn dDsmZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnNwcmluZ0BpZXRmLm9yZzwvYT4gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBk ZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElzIHRoaXMgYSBj b21tb24gdXNlIGNhc2UgaWUuJm5ic3A7ICZxdW90O2J1dCByYXRoZXIg4oCTIHdoaWNoIG5vZGVz IC8gbmV0d29yayA8YnI+DQomZ3Q7IHNlZ21lbnRzIGl0IGNhbiBuZXZlciB0b3VjaCBvciBmbG93 IHRocm91Z2guJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHNvIHBlcmhhcHMgaXRzIHRp bWUgdG8gZGVmaW5lIG5vdGlvbiBvZiAqbmVnYXRpdmUtU0lEKiBpZS4gbGlzdCBpbiA8YnI+DQom Z3Q7IHRoZSBwYWNrZXQgcmVzb3VyY2VzIHdoaWNoIGdpdmVuJm5ic3A7cGFja2V0IE1VU1Qgbm90 IGV2ZXIgdHJhdmVyc2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFB1dCBpbiB0aGUgcGFja2V0IHNl dCBvZiBub2RlcyBvciBsaW5rcyB3aGljaCB0aGUgcGFja2V0IHNob3VsZCBuZXZlciA8YnI+DQom Z3Q7IHRyYXZlcnNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IGdvZXMgaW4gbGluZSBvZiBy ZWNlbnQgd2F2ZSBvZiBuZWdhdGl2ZSByb3V0aW5nIGltcGxlbWVudGF0aW9uczxicj4NCiZndDsg KFJJRlQpIG9yIGRpc2N1c3Npb25zIChMU1IpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QsPGJy Pg0KJmd0OyBSLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDEx OjQ2IFBNIEFuZHJldyBBbHN0b24gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJl dy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGIiIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcu QWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU28g4oCTPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uZSBvZiB0aGUgdXNlIGNhc2Vz LCBpbiBmYWN0LCBzb21lIHZlcnkgbWFqb3IgdXNlIGNhc2VzIGluIGFueTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc3ByaW5nIHRlY2hub2xvZ3kgZm9yIHVzIHJldm9sdmUgYXJv dW5kIHRoZSBmb2xsb3dpbmc8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYS5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9kZXM8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYi5UaGUgZXhwbGljaXQgYXZvaWRh bmNlIG9mIGNlcnRhaW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdvcms8YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW55dGhpbmcgdGhhdCBjb3VsZCByZXN1bHQgaW4g dGhhdCBleHBsaWNpdCBhdm9pZGFuY2UgYmVpbmcgdmlvbGF0ZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IOKAkyB3b3VsZCBjcmVhdGUsIHNoYWxsIHdlIHNheSBzaWduaWZpY2Fu dCBwcm9ibGVtcy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TXVjaCBvZiB0aGUgdXNlIGNhc2UgaXMgbm90IGEgY2FzZSBvZiB3aGljaCBub2RlcyB0aGUgcGFj a2V0cyBmbG93PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aHJvdWdoIOKAkyBi dXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2VnbWVudHMgaXQgY2FuIG5ldmVy PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b3VjaCBvciBmbG93IHRocm91Z2gu Jm5ic3A7IEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9neSB0bzxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXZvaWQgY2VydGFpbiB0aGluZ3MgZm9yIHNwZWNp ZmljIHJlYXNvbnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIG5lZWRpbmcgc3VjaCBkZWVwIGxh YmVsIHN0YWNrcyDigJM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMga2lu ZCBvZiBkZXRhaWxlZCBwYXRoIHByb2dyYW1taW5nIHRlbmRzIHRvIGRlZXBlbiB0aGUgc3RhY2s8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlY2F1c2UgeW91IHNvbWV0aW1lcyBo YXZlIHRvIGJlIHByZXR0eSBleHBsaWNpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1cyB0aGF0IHRoaXMg ZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDigJM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFuZCB0aGF0IHdlIGNhbiBhdm9pZCBzaXR1YXRpb25zIHdoaWNoIGNvdWxkIGNhdXNlIHRy YWZmaWMgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFjY2lkZW50bHkgaGl0 IHRoaW5ncyBleHBsaWNpdGx5IGF2b2lkZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgdGhhbiB0aGlz LCBidXQgaXQgaXMgd2hhdCBpdCBpcy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhhbmtzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEFuZHJldzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQo8L2E+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnPC9hPiZndDsmZ3Q7ICpPbiBCZWhhbGYgT2YgKkpvZWwgTS4gSGFscGVybjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlNlbnQ6KiBNb25kYXksIDMgQXVndXN0IDIwMjAg MjE6MzY8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpUbzoqIFJvYmVydCBSYXN6 dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PnJvYmVydEByYXN6dWsubmV0PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsu bmV0IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLi5vcmc8L2E+ICZs dDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5n IDxicj4NCiZndDsgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAoU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCBy ZWl0ZXJhdGluZyB0aGF0IHRoaXMgaXMgYXMgYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcGFydGljaXBhbnQsIG5vdCBhIFdHIGNoYWlyLik8YnI+DQomZ3Q7IDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWVzLCB3ZSBhcmUgdGFsa2luZyBJUCBuZXR3b3Jrcy4g QW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29ya3MgdGhhdDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFsbCBzb3J0cyBvZiBy ZWFzb25zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayB0aGVyZSBh cmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9uZSBtYXkgbm90IHdhbnQgYSByYW5kb208YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGggcmF0aGVyIHRoYW4gYSBjaG9zZW4g VEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXI8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFib3V0IHdoYXQgY29uc3RyYWludHMgbWF5IGJlIC8gYXJl IHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUgdGhleTxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0aW5nKSB0aGF0IGlz IGludGVuZGVkIHRvIHByZXNlcnZlIFFvUy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3VpbmcgdGhhdCB0aGlz IGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQgaXMgYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJIGFtIHRyeWluZyB0byBmaWd1cmUgb3R1IHdo YXQgY29tYmluYXRpb24gb2Y8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZGl0 aW9uYWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwgbGVhZCB0byBldmVy eW9uZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ2V0dGluZyB0aGUgYmVoYXZp b3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJlaGF2aW9yIHRoZXk8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2lyZSwgYnV0IHNvbWV0aW1lcyBpcyB0aGUg YmVzdCB3ZSBjYW4gZG8uKTxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBZb3Vycyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpvZWw8YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gOC8zLzIwMjAgMjozMCBQ TSwgUm9iZXJ0IFJhc3p1ayB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgSm9lbCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQXJlIHdl IHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya3MmbmJzcDtoZXJlID8gT3IgcGVyaGFwcyBz b21lIGhhcmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc2xp Y2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5ldHMgPzxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBCZWNhdXNlJm5ic3A7aWYgd2UgYXJlIHRhbGtpbmcm bmJzcDthYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d288YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG9ic2VydmF0aW9uczo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgQSkgSWYgeW91IG5lZWQgdG8gdHJhdmVyc2UgdmlhIGEgc3BlY2lmaWMgbm9kZSAoaWUuIGZp cmV3YWxsKSB5b3U8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJldHRlcjxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhcHBseSBJUCBlbmNhcHN1 bGF0aW9uIHRvIHRoYXQgbm9kZS4uIEkgZG9uJ3QgdGhpbmsgSVA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGVuY2Fwc3VsYXRpb24mbmJzcDtjYW48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYmUgaGlqYWNrZWQgdG9kYXkgc3VjaCB0aGF0IGRl c3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpczxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaWdub3JlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQikg SGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3aGVyZSB1cG9uIHRvcG9sb2d5IGNoYW5nZSAo bGluazxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3Igbm9kZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBmYWlsdXJlKSB5b3Ugc3VkZGVubHkm bmJzcDtzdGFydCBkcm9wcGluZyZuYnNwO2Zsb3dzIGluIHNwaXRlIG9mIFNQVCBvZmZlcmluZzxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBwZXJoYXBzIGZldyBt cyBsb25nZXIgcGF0aCB3aXRoIDEwIG1zIG1vcmUgaml0dGVyID88YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNsaWRlcyBwcm9taXNlIHRv IHR1cm4gSVAgbmV0d29ya3MgaW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgc29tZXRoaW5nJm5ic3A7bmV3ID8gV29yc2UgLi4uIGRvIHRoZXkgbWVudGlvbiBw YXRoIHF1YWxpdHkgZ3VhcmFudGVlcyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgcmVzb3VyY2UgcmVzZXJ2YXRpb25zJm5ic3A7PyBJIGhvcGUgbm90Ljxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBUaHgsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFIuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgODoxMCBQTSBKb2VsIE0u IEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiIiB0YXJn ZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUw YiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTIwJTBiPC9hPiZn dDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBXZWxsIGxlc3Mgc2VyaW91cyBmb3IgVEUgU0lE cywgSSBhbSBub3Qgc3VyZSB0aGUgcHJvYmxlbSBpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcmVzdHJpY3RlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyB0byBqdXN0IHNlcnZpY2UgU0lEcy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0aGUgcGF0aCB0byBtZWV0 IHNvbWUgY29tcGxleCB0ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBvYmplY3RpdmUuJm5ic3A7IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dp bmcgd2hhdCB0aG9zZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBjb25zdHJhaW50czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyB3ZXJlLiZuYnNwOyBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywgaXQgaXMgYmV0dGVy IHRvIGRyb3AgdGhlIHBhY2tldDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lkZSB0aGUgZW52ZWxvcC4mbmJzcDsgSSBz dXNwZWN0IHRoYXQgdGhlIHJpZ2h0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IGFuc3dlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyB0byB0aGlzIGlzICZxdW90O3RvbyBiYWQmcXVvdDsuJm5ic3A7IElmIHNvLCBhcyB3aXRo IHRoZSBkaXN0aW5jdGlvbiByZWdhcmRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNlcnZpY2U8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg bm9kZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT88YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgWW91cnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgT24gOC8zLzIw MjAgMjozNiBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgTWFjaCwgSm9lbCBhbmQgYWxsLDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSB0aGluayB0aGF0IGluIG1v c3QgY2FzZXM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAxLlRo ZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuICZxdW90O3RvcG9sb2dpY2FsJnF1 b3Q7IGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7c2VydmljZSZx dW90Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGlu c3RydWN0aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBvSUdQIFByZWZpeCBOb2RlIFNJRHMgSUdQIEFkai1T SURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgY29ycmVzcG9uZGluZyBJR1AgYWR2ZXJ0aXNlbWVudHMp IHJlcHJlc2VudCB0b3BvbG9naWNhbDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBv U2VydmljZSBTSURzIGZvciBTUnY2IChzZWUgU1J2NiBCR1AtQmFzZWQgT3ZlcmxheSBTZXJ2aWNl czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzNDQ2N5OW1ZNmNNZmJrN1FmamhpQTNSNkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tl ci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNlcy0w NCUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ0Nj eTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5v cmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQ8YnI+DQo8 L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNHQzVhZjJ6M0p6cGhaRGtQbmNIQVFpNkgyP3U9aHR0cHMlM0El MkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYu b3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZpY2VzLTA0X18lM0Il MjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3 cDZ2cFJIT0d0OEFrVFJEdWlEbzRULUwwbmwlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Ns aWNrdGltZS5zeW1hbnRlYy5jb20vM0dDNWFmMnozSnpwaFpEa1BuY0hBUWk2SDI/dT1odHRwcyUz QSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0 Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDRfXyUz QiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pI Z3dwNnZwUkhPR3Q4QWtUUkR1aURvNFQtTDBubCUyNDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRyYWZ0KSB1bnN1cnByaXNpbmdseSByZXByZXNlbnQg 4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9wb2xvZ2ljYWwgaW5zdHJ1 Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2VudCBzZXJ2aWNlIGlu c3RydWN0aW9ucyByZXF1aXJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IGFsdGVybmF0aXZlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgcHJvdGVjdGlvbiBtZWNoYW5pc21zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsgVGhpcyB2aWV3IHNlZW1zIHRvIGJlIGFsaWduZWQgd2l0aCBS RkMgODQwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzQ1TkxDQjZUeWR4 dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJm Yzg0MDIlMGIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v MzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRnJmYzg0MDI8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM3UHpVS0FEODJjalN2 bVZjR3Zwa2hGNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRw cyUzQSUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDJfXyUzQiUyMSUyMU5FdDZ5TWFP LWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtU UkR1aURvMEk0WWJ0bSUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zN1B6VUtBRDgyY2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVm ZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZyZmM4 NDAyX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3 eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJNFlidG0lMjQ8L2E+Jmd0OyZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgc2F5cyBpbiBTZWN0aW9uIDE6PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsg SW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUs IHR3bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgdG9wb2xvZ2lj YWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNlZ21lbnQgYW5kIHRo ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 Jm5ic3A7IElHUC1QcmVmaXggc2VnbWVudC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBJbiB0aGUgY29udGV4dCBvZiBhIEJHUC1i YXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFyZSBkZWZpbmVkOiB0 aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBhbmQgdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgQkdQLVByZWZpeCBzZWdtZW50Ljxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSW4gdGhlIGNhc2Ugb2Yg U1ItTVBMUyB0aGlzIGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb248YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgMy40IG9mPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgdGhlIE5vZGUgUHJvdGVjdGlv biBmb3IgU1ItVEUgUGF0aDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFmTlBzWmRocEV4eHg5NkgyP3U9aHR0cHMlM0El MkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJp bmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rpb24tMy40JTBiIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFm TlBzWmRocEV4eHg5NkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1w YXRocy0wNyUyM3NlY3Rpb24tMy40PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ3JVZ0FSVzhz b21BYnc2VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9f aHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdk ZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyQXNlY3Rpb24tMy40 X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4 cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNzbiUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91 PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90 ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyQXNlY3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5 TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4 QWtUUkR1aURvOXdPLVNzbiUyNDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7IGRyYWZ0IHRoYXQgc2F5czo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgbm9kZSBwcm90ZWN0aW9uIG1l Y2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzZWN0aW9uczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGRlcGVuZHMgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0 aGUgbGFiZWwgaW1tZWRpYXRlbHkgYmVsb3c8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgdGhlIHRvcDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDsgbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rvb2QgaW4gdGhlIElH UCBkb21haW4uJm5ic3A7IFdoZW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgcHJvdmlkZXIgZWRnZSByb3V0ZXJzIGV4Y2hh bmdlIHNlcnZpY2UgbGFiZWxzIHZpYSBCR1Agb3Igc29tZTxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBvdGhlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IG5vbi1JR1AgbWVjaGFuaXNtIHRoZSBi b3R0b20gbGFiZWwgaXMgbm90IHVuZGVyc3Rvb2QgaW4gdGhlIElHUDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGRvbWFpbi48YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNw OyBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUg ZHJhZnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyZuYnNwOyBbUkZDODY3OSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzNKZnZ0QkFtYVFQTjFqQTNwTTZUZENFNkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5JTBiIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFqQTNwTTZUZENFNkgy P3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4 Njc5PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmRNQWp1WVRRb3ZvOGpId21tM2VKdzZIMj91 PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5X18lM0IlMjElMjFORXQ2eU1hTy1n ayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJE dWlEbzhNR2lwWGMlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vMzZkTUFqdVlUUW92bzhqSHdtbTNlSnc2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVu c2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZo dG1sJTJGcmZjODY3OV9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lR QXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG84TUdpcFhjJTI0PC9hPiZndDsm Z3Q7XTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXM8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBhcHBsaWNhYmxlIHRvIHRoaXMgdXNl IGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdlczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHdpbGwgYmUgcmVxdWlyZWQgZm9y IFNSIGJhc2VkIG5ldHdvcmtzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0OyBUaGUgc2NlbmFyaW9zIGluIHdoaWNoICZuYnNwO2RpZmZlcmVudGlhdGlvbiBiZXR3ZWVu IOKAnHRvcG9sb2dpY2Fs4oCdIGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zIGlzIGJyb2tlbiBhcmUg aW5kZWVkIHByb2JsZW1hdGljLiBFLmcuLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBjb25zaWRlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUgU0lEIGluIHRoZSBF Uk8gb2YgYSBTUi1URSBwYXRoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IGlkZW50aWZpZXMgYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7IG5vZGUgdGhhdCBhY3RzIGFzIGEgZmlyZXdhbGwgZm9yIGFsbCBwYWNrZXRz IGl0IHJlY2VpdmVzLCBpLmUuLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBwcm92aWRlczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IHRoZSBmaXJld2FsbCBzZXJ2aWNlIHdpdGhvdXQgYW55IGRlZGljYXRlZCBzZXJ2 aWNlIFNJRDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpZGVu dGlmeWluZyBpdC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0OyBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2ggYSBub2RlIHdvdWxk IGNvbWJpbmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG9w b2xvZ2ljYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyBhbmQgc2VydmljZSBpbnN0cnVjdGlvbnMgdGh1cyBicmVha2luZyB0aGUgZGlmZmVyZW50aWF0 aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGJldHdlZW4g dGhlIHR3by48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEkgYW0g bm90IHN1cmUgaWYgdXNhZ2Ugb2Ygc3VjaCDigJxjb21iaW5lZOKAnSBTSURzIGNvdWxkIGJlIHBy ZXZlbnRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBvciBh dDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGxlYXN0 IGRpc2NvdXJhZ2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsg SWYgbm90LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0byBpZGVudGlmeSBzdWNoIFNJRHMgaW4gdGhl PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFkdmVydGlzZW1l bnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBtZWNo YW5pc21zIHdvdWxkIGJlIHVzZWZ1bCBJTUhPLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsgTXkgMmMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBTYXNoYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsg T2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgQ2VsbDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzs5NzIt NTQ5MjY2MzAyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBFbWFp bDogPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+DQpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgRnJvbTogc3ByaW5nICZsdDs8YSBocmVmPSJt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2JsYW5rIj5zcHJpbmct Ym91bmNlc0BpZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2Js YW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI8L2E+Jmd0OyZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+Jmd0OyZndDsgT24gQmVoYWxmIE9mIE1hY2ggQ2hlbjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMs IDIwMjAgNjozMCBBTTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tJTBiIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwv YT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tJTBiPC9hPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5n QGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW3Nwcmlu Z10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBIaSBKb2VsLDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSB0aGluayB0aGlzIGlzIGEgZ29vZCBwb2lu dCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBwYXN0LiBBbmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSAm cXVvdDtjYW4gYmUgYnlwYXNzZWQmcXVvdDsgaW5kaWNhdGlvbiBpbiB0aGU8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyByb3V0aW5nIGFkdmVydGlzZW1l bnQgZm9yIG5vdy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IElN SE8sIHRoZSBpbmZvcm1hdGlvbiBhZHZlcnRpc2VkIGJ5IHJvdXRpbmcgaXMgbmV1dHJhbCwgc3Vj aDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpbmZvcm1hdGlv bjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IChjYW4g b3IgY2Fubm90IGJlIGJ5cGFzc2VkKSBpcyBtb3JlIHBhdGggc3BlY2lmaWMsIHRodXM8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vcm1hbGx5IHRoZTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGNvbnRyb2xsZXIgc2hvdWxkIGJlIHJl c3BvbnNpYmxlIGZvciBkZWNpZGluZyB3aGV0aGVyL3doaWNoIFNJRDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjYW4gYmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBieXBhc3NlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IE1hY2g8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgRnJvbTog c3ByaW5nIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUzY21haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZyUzZSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUzY21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y ZyUzZTwvYT4mZ3Q7XTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gQmVoYWxm IE9mIEpvZWwgTS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgSGFscGVybjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0OyBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDc6NTEgQU08YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgVG86IDxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5v cmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2JsYW5rIj5tYWls dG86c3ByaW5nQGlldGYub3JnICZsdDttYWlsdG86c3ByaW5nQGlldGYub3JnPGJyPg0KPC9hPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7 IFN1YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGlj YWJpbGl0eTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0 OyAoV0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZyb20gYSBzbGlnaHRs eTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjb25mdXNlZCBX Rzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBw YXJ0aWNpcGFudC4pPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNw OyAmZ3Q7IEkgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIHZhcmlvdXMgcmVwYWlyIGRyYWZ0cywgYW5k IHRoZSB2YXJpb3VzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmZ3Q7IG5ldHdvcmtzIHByb2dyYW1taW5nIGFuZCBzZXJ2aWNlIHByb2dyYW1taW5nIGRy YWZ0LCBhbmQgSSBhbTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyB0cnlpbmcgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgZmlndXJlIG91dCBvbmUgYXNwZWN0IG9mIHRoZSBjb21iaW5hdGlvbi48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSG93IGRvZXMgYSBu b2RlIHRoYXQgaXMgZG9pbmcgc29tZSBmb3JtIG9mIGJ5cGFzcyAoc3VwcG9zZSwgZm9yPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IHNpbXBsaWNp dHksIGl0IGlzIE5vZGUgTjIgZGVjaWRpbmcgdG8gYnlwYXNzIHRoZSBuZXh0IFNJRCBmb3I8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYSBmYWlsZWQ8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgbm9kZSBOMykg a25vdyB0aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IElmIHRoZSBwYXRoIHdhcyBqdXN0IGZvciBURSwgdGhl biBpdCBpcyAmcXVvdDtzYWZlJnF1b3Q7IGlmIHRoZSBuZXcgcGF0aDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBtZWV0czxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyB0aGUgVEUgY3JpdGVyaWEuJm5ic3A7IG9y IG1heWJlIGl0IGlzIHNhZmUgaWYgaXQgaXMgZXZlbiBjbG9zZSwgYXM8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbG9uZyBhczxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBpdCBpcyBub3QgdXNlZCBmb3IgdG9v IGxvbmcuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7 IEJ1dCB3aGF0IGlmIHRoZSBub2RlIHdlcmUgYSBGaXJld2FsbCwgaW5jbHVkZWQgdG8gbWVldCBs ZWdhbDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHJl cXVpcmVtZW50cz88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1tYXRpYyB0cmFuc2Zv cm0gKHdpbmNlIHdlIGFyZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0OyBkZWxpYmVyYXRlbHkgdmFndWUgYWJvdXQgd2hhdCBub2RlcyBjYW4gZG8g d2hlbiBhc2tlZCBzdWl0YWJseS4pPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0OyZuYnNwOyAmZ3Q7IElzIHRoZXJlIHNvbWUgJnF1b3Q7Y2FuIGJlIGJ5cGFzc2VkJnF1b3Q7 IGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgYWR2ZXJ0aXNlbWVudHMgdGhhdCBJIG1pc3NlZD88YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgVGhhbmsgeW91 LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBZ b3Vycyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgSm9lbDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBzcHJpbmcgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNw OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z cHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGIiIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnICZsdDttYWlsdG86c3ByaW5nQGlldGYub3Jn PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8 L2E+Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBzJTNBJTI1MiIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVr elc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1E3 dlgycVdTVWRXVmM4OTJYdVh5Mkg2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJG djMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5 dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyX18lM0JKU1UlMjElMjFORXQ2eU1hTy1n ayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJE dWlEbzZId1BMaWwlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vM1E3dlgycVdTVWRXVmM4OTJYdVh5Mkg2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVu c2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3Fo VTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyX18lM0JKU1UlMjElMjFO RXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJI T0d0OEFrVFJEdWlEbzZId1BMaWwlMjQ8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0 NkgyP3U9aHR0cHMlM0ElMjUyJTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUu c3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyPGJy Pg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQTVCOEgyRm0xclBuYVozU3VwandyNkgyP3U9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1h bnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJB MjUyX18lM0JKU1UlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEb3pvUWlBSGslMjQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0E1QjhIMkZtMXJQbmFaM1N1cGp3cjZI Mj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZjbGlj a3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0 cHMlMkEzQSUyQTI1Ml9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ix b2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG96b1FpQUhrJTI0PC9hPiZn dDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAm Z3Q7IEYlPGEgaHJlZj0iaHR0cDovLzJGd3d3LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+MkZ3 d3cuaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1 ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJG MkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9p UUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLXBQQ2p2UiUyNCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhH SjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUz QSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVf UjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQ8L2E+ Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHV1Q5ZnlqYUZpM0ZjdkhEdm9v ZHZTNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3LmlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHV1Q5ZnlqYUZpM0ZjdkhEdm9vZHZTNkgy P3U9aHR0cCUzQSUyRiUyRjJGd3d3LmlldGYub3JnPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z OU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20l MkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1hTy1nayUy MVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlE by1wUENqdlIlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5j b20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2Uu Y29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9yZ19fJTNCJTIxJTIxTkV0NnlNYU8t Z2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RS RHVpRG8tcFBDanZSJTI0PC9hPiZndDsmZ3Q7JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5n PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3Jn PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiIiB0YXJn ZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnJTBiIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUwYjwvYT4mZ3Q7Jmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpz cHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdD NGVBdlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNCaHlFdHg0UTduNzRCaGlSbmZN SnRUNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUy RmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUl M0RodHRwcyUyQTNBJTJBMkYlMkEyRnd3dy5pZXRmLm9yZyUyQTJGbWFpbG1hbiUyQTJGbGlzdGlu Zm8lMkEyRnNwcmluZ19fJTNCSlNVbEpTVWwlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5F OEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1oUjNnQUQlMjQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0JoeUV0eDRR N243NEJoaVJuZk1KdFQ2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZf X2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVB dlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyRiUyQTJGd3d3LmlldGYub3JnJTJBMkZtYWlsbWFu JTJBMkZsaXN0aW5mbyUyQTJGc3ByaW5nX18lM0JKU1VsSlNVbCUyMSUyMU5FdDZ5TWFPLWdrJTIx UzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURv LWhSM2dBRCUyNDwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IE5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBh bnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMg SW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBhbmQvb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQuIEFueSByZXZpZXcsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsgZGlzY2xvc3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5 IG90aGVycyBvciBmb3J3YXJkaW5nPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3 aXRob3V0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsg ZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90 IHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpbnRlbmRl ZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCB0aGVuIGRlbGV0 ZSBhbGw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBj b3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgPGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyA8YSBocmVm PSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2 SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNR MXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRu U1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYz JTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmlu Z19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hx Z3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9 aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2sl MjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVp RG81S2xQbmJqJTI0PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhx THE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUy RnNwcmluZzwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVm PSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2 SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1h Ty1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFr VFJEdWlEbzVLbFBuYmolMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1h bnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRl ZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFv aVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQ8L2E+Jmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0Bp ZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z UTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2Ns aWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzwvYT48YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91 PWh0dHBzJTNBJTI1JTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50 ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElPGJyPg0KPC9hPiZn dDsgMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSU8YSBocmVmPSJodHRwOi8v MkZ3d3cuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4yRnd3dy5pZXRmLm9yZzwvYT4lMkZtYWls bWFuJTJGbGlzdGk8YnI+DQomZ3Q7IG5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2sl MjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3U8YnI+DQomZ3Q7IG9aSGd3cDZ2cFJI T0d0OEFrVFJEdWlEbzVLbFBuYmolMjQmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTm90aWNl OiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiA8 YnI+DQomZ3Q7IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQg aXMgY29uZmlkZW50aWFsIGFuZC9vciA8YnI+DQomZ3Q7IHByb3ByaWV0YXJ5IGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgPGJyPg0KJmd0OyBk aXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRp bmcgd2l0aG91dCA8YnI+DQomZ3Q7IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgPGJyPg0KJmd0OyByZWNpcGllbnQs IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxs IDxicj4NCiZndDsgY29waWVzLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLjxicj4NCiZndDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCiZndDsgLS08YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpz cHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpD S3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1JTiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln bjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLUlOIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGhyIHNpemU9IjIiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Tm90aWNlOiBUaGlzIGUtbWFpbCB0b2dl dGhlciB3aXRoIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiBvZiBSaWJi b24gQ29tbXVuaWNhdGlvbnMgSW5jLg0KIHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vciBwcm9w cmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSBy ZXZpZXcsIGRpc2Nsb3N1cmUsIHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3Ig Zm9yd2FyZGluZyB3aXRob3V0IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 DQogdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsIGNvcGllcywgaW5j bHVkaW5nIGFueSBhdHRhY2htZW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tSU4iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFTi1JTiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBz aXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4B2dggeml509mbschi_-- From nobody Thu Aug 27 23:37:17 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425A73A159B for ; Thu, 27 Aug 2020 23:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.499, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cq6oOL_XoRcG for ; Thu, 27 Aug 2020 23:37:09 -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 27C633A0D62 for ; Thu, 27 Aug 2020 23:37:08 -0700 (PDT) Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8BE70F723A290C1C3A45; Fri, 28 Aug 2020 07:37:06 +0100 (IST) 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.1913.5; Fri, 28 Aug 2020 07:37:05 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) 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.1913.5 via Frontend Transport; Fri, 28 Aug 2020 07:37:04 +0100 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.60]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Fri, 28 Aug 2020 14:36:57 +0800 From: "Chengli (Cheng Li)" To: Alexander Vainshtein , Martin Horneffer CC: "spring@ietf.org" , Robert Raszuk , "EXT-Andrew.Alston@liquidtelecom.com" , Shraddha Hegde , "Ketan Talaulikar (ketant)" , "Joel M. Halpern" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfMxHlh+yzcCkewTBiyswjXMaklNGAAgAA0D4CAAMHVAIAABZ6AgAABgICAADUsgIAAC1WAgAAdJ4CAAGzfgIAAFLcAgAB1eACAD4ZiAIAADy+AgAAIGQCAABlPgIAACqaAgAAC7QCAAAmcgIAAFWuAgAADZQCABhhmgIAADwSAgA+hnYA= Date: Fri, 28 Aug 2020 06:36:55 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.130] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4CCdggeml509mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 06:37:16 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4CCdggeml509mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FzaGEgYW5kIE1hcnRpbiwNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgaW5wdXQuIEkgZnVs bHkgYWdyZWUgd2l0aCB5b3VyIHBvaW50IG9mIHdlIG5lZWQgdG8gY29uc2lkZXIgdG8gYWR2ZXJ0 aXNlIHRoZSBhYmlsaXR5IG9mIHRoZSBub2RlIHRvIGFkdmVydGlzZSBhIHNwZWNpZmljIFByZWZp eCBTSUQgaXQgb3JpZ2luYXRlcyBhcyDigJxub3QgZWxpZ2libGUgZm9yIGJ5cGFzcyBwcm90ZWN0 aW9u4oCdLg0KDQpBbHNvLCB0aGlzIGV4dGVuc2lvbiBzaG91bGQgYmUgd3JpdHRlbiBpbiBhIHBy b3RlY3Rpb24gZG9jdW1lbnQgbGlrZSBNYXJ0aW4gc2FpZC4gV2UgaGF2ZSBhIHN0cmF3bWFuIGRy YWZ0IHBvc2VkIDEgeWVhciBhZ28gWzFdLCBidXQgaXQgaGFzIG5vdCBiZWVuIGRpc2N1c3NlZCB5 ZXQuICBUaGUgbWFpbiBpZGVhIG9mIHRoZSBkcmFmdCBpcyB0byBhZGQgYSBuby1ieXBhc3MgZmxh ZyBpbnRvIFNJRChpbmNsdWRpbmcgUHJlZml4IFNJRCwgYW5kIGFkai1TSUQpLiBCdXQgd2UgYXJl IGRpc2N1c3Npbmcgd2l0aCBzb21lIGV4cGVydHMgdGhhdCBkbyB3ZSBuZWVkIHRoZSBOby1ieXBh c3MgZmxhZyBmb3IgQWRqLVNJRCBvciBub3QsIGl0IHNlZW1zIGxpa2Ugd2UgaGF2ZSBhIEIgZmxh ZyBhbHJlYWR5Lg0KDQpJdCBpcyBzbyBuaWNlIHRvIHNlZSB0aGlzIHBvaW50IGlzIHJhaXNlZCBh bmQgZGlzY3Vzc2VkLiBBbHNvLCB3ZWxjb21lIHRvIHJldmlldyB0aGUgZG9jdW1lbnQsIGFuZCBo b3BlIHRvIGhhdmUgeW91ciB2YWx1YWJsZSBjb21tZW50cy4NCg0KUmVzcGVjdCwNCkNoZW5nDQoN ClsxXS4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXJ0Z3dnLWVuaGFuY2Vk LXRpLWxmYS0wMg0KDQoNCkZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIFZhaW5zaHRlaW4NClNlbnQ6IFR1ZXNkYXksIEF1 Z3VzdCAxOCwgMjAyMCAxMTo0NCBQTQ0KVG86IE1hcnRpbiBIb3JuZWZmZXIgPG1haG9AbGFiLmR0 YWcuZGU+DQpDYzogc3ByaW5nQGlldGYub3JnOyBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVr Lm5ldD47IEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tIDxBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0 PjsgS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmll dGYub3JnPjsgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KU3ViamVjdDog UmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eQ0KDQpNYXJ0aW4sDQpMb3RzIG9mIHRoYW5rcyBmb3IgYW4gaW1wb3J0YW50IGlucHV0IHRvIHRo aXMgZGlzY3Vzc2lvbi4NCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGFiaWxpdHkgdG8g dHVybiBvZmYgdGhlIG5vZGUgcHJvdGVjdGlvbiBzY2hlbWUgZm9yIGEgc3BlY2lmaWMgUExSIG5l aWdoYm9yIChpLmUuLCBvbiBhIHNwZWNpZmljIFBMUiBwb3J0KSBieSBzdWl0YWJsZSBsb2NhbCBj b25maWd1cmF0aW9uIGluIHRoZSBQTFIgaXMgZGVmaW5pdGVseSByZXF1aXJlZC4gU3VjaCBhbiBh YmlsaXR5IHdvdWxkIHByb2JhYmx5IGFkZHJlc3MgbW9zdCAoaWYgbm90IGFsbCkgc2NlbmFyaW9z IGFzc29jaWF0ZWQgd2l0aCB0aGUgc28tY2FsbGVkIOKAnHNlcnZpY2Ugbm9kZXPigJ0gdGhhdCBj YW5ub3QgYmUgYnlwYXNzZWQuDQoNCkkgYWxzbyB0aGluayB0aGF0IHNlcnZpY2Ugbm9kZXMgdGhh dCBjYW5ub3QgYmUgYnlwYXNzZWQgdHlwaWNhbGx5IHdvdWxkIGFkdmVydGlzZSB0aGVtc2VsdmVz IGFzIOKAnHN0dWIgbm9kZXPigJ0gaW4gSUdQIGluIG9yZGVyIHRvIHByZXZlbnQgaW5hZHZlcnRl bnQgYXBwbGljYXRpb24gb2YgdGhlaXIgc2VydmljZSBmdW5jdGlvbiB0byB0cmFuc2l0IHRyYWZm aWMgKHdoaWNoIGNvdWxkIG90aGVyd2lzZSBwYXNzIHRocnUgdGhlIHNlcnZpY2Ugbm9kZSBkdWUg dG8gc29tZSB0b3BvbG9neSBjaGFuZ2UpLiBUaGVyZWZvcmUgYSBsb2NhbCBwb2xpY3kgdGhhdCB3 b3VsZCBleGNsdWRlIElHUCBuZWlnaGJvcnMgYWR2ZXJ0aXNpbmcgIHRoZW1zZWx2ZXMgYXMgc3R1 YiBub2RlcyBpbiBJR1AgZnJvbSB0aGUgbm9kZSBwcm90ZWN0aW9uIHNjaGVtZSBjb3VsZCBiZSBh bHNvIHVzZWZ1bC4NCg0KTGFzdCBidXQgbm90IGxlYXN0LCBhYmlsaXR5IG9mIHRoZSBub2RlIHRv IGFkdmVydGlzZSBhIHNwZWNpZmljIFByZWZpeCBTSUQgaXQgb3JpZ2luYXRlcyBhcyDigJxub3Qg ZWxpZ2libGUgZm9yIGJ5cGFzcyBwcm90ZWN0aW9u4oCdIChlLmcuLCB1c2luZyBhIG5ldyBmbGFn IGluIHRoZSBQcmVmaXggTm9kZSBUTFYgZm9yIElTLUlTIG9yIE9TUEYpIHNob3VsZCBiZSBjb25z aWRlcmVkLg0KDQpNeSAyYywNClNhc2hhDQoNCk9mZmljZTogKzk3Mi0zOTI2NjMwMg0KQ2VsbDog ICAgICArOTcyLTU0OTI2NjMwMg0KRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KDQpGcm9tOiBz cHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZz4+IE9uIEJlaGFsZiBPZiBNYXJ0aW4gSG9ybmVmZmVyDQpTZW50OiBUdWVzZGF5LCBBdWd1 c3QgMTgsIDIwMjAgNTo1MSBQTQ0KVG86IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPg0KQ2M6IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBy YmJuLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+PjsgUm9iZXJ0IFJh c3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj47IEVYVC1B bmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbT4gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRv OkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+PjsgU2hyYWRkaGEgSGVnZGUgPHNocmFk ZGhhQGp1bmlwZXIubmV0PG1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldD4+OyBLZXRhbiBUYWxh dWxpa2FyIChrZXRhbnQpIDxrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv OmtldGFudD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pg0KU3ViamVjdDog UmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0 eQ0KDQpBIGZldyB0aG91Z2h0cyBmcm9tIG15IChvcGVyYXRvcidzKSBQb1Y6DQoNCiAtIFRoZSBk aXN1c3Npb24gaXMgYSB2ZXJ5IGdvb2QgYW5kIGltcG9ydGFudCBvbmUuIEl0IHByb2JhYmx5IHNo b3VsZCBiZSBkaXNjdXNzZWQgYW5kIGRvY3VtZW50ZWQgd2VsbCBpbiBvcmRlciB0byBqdXN0aWZ5 IHRoZSBwcm9wb3NlZCBwcm90ZWN0aW9ucyBtZWNoYW5pc21zLg0KDQogLSBOb3QgYWxsIG9wZXJh dG9ycyBzZWVtIHRvIGhhdmUgdGhlIHNhbWUgcmVxdWlyZW1lbnRzLg0KICAgIChBIHNvbWV3aGF0 IHNpbWlsYXIgZGlzY3Vzc2lvbiBtaWdodCBiZSB0aGUgb25lIGZvciBkaXNqb2ludCBwYXRocy4g VGhvc2UgYXJlIG9mdGVuIGVxdWlyZWQgYnkgdm9pY2Ugc2lnbmFsbGluZyBhcHBsaWNhdGlvbnMu IEluIHNvbWUgY2FzZXMgdGhlIHZvaWNlIHNlcnZpY2UgZGVtYW5kcyB0aGF0IHRyYWZmaWMgaXMg YmxhY2tob2xlZCByYXRoZXIgdGhhbiBvbiBmb3J3YXJkZWQgb24gdGhlIHdyb25nIHBhdGguIElu IG90aGVyIGNhc2VzIGRpc2pvaW50IHBhdGhzIGFyZSBqdXN0IHJlcXVpcmVkIGZvciB0aGUgImdv b2QgY2FzZSIuIFRyYWZmaWMgTUFZIGJlIGZvcndhcmRlZCBvbiB0aGUgd3JvbmcgcGF0aCwgYXMg bG9uZyBhcyB0aGUgbmV0d29yayBqdXN0IG1ha2VzIHN1cmUgdGhlIHRyYWZmaWMgb24gdGhlIG90 aGVyIHBhdGggaXMgbmV2ZXIgYWZmZWN0ZWQgYnkgdGhlIHNhbWUgZmFpbHVyZS4pDQoNCiAtIFBl cnNvbmFsbHkgSSB3b3VsZCBoYXRlIHRvIHNlZSB5ZXQgYW5vdGhlciBJR1AgZXh0ZW5zaW9uIGZv ciB0aGlzIHB1cnBvc2UuDQoNCiAtIEkgd291bGQgcmF0aGVyIHByZWZlciBhIGdvb2QgZGlzY3Vz c2lvbiBvZiB3aGF0IGNhbiBiZSBhY2hpZXZlZCBieSB1c2luZyBlYXN5IHRvIG1ha2Ugc3dpdGNo ZXM6DQogICAgLSBUaGUgcHJvdGVjdGlvbiBiZWhhdmlvdXIgY291bGQgYmUgc3dpdGNoZWQgb24g b3Igb2ZmIHBlciBub2RlLg0KICAgICAgIC0gQW4gb3BlcmF0b3Igd2l0aCBzdHJpY3QgInNvbWUg dHJhZmZpYyBtYXkgbmV2ZXIgdG91Y2ggY2VydGFpbiBwYXJ0cyBvZiB0aGUgbmV0d29yayIgcmVx dWlyZW1lbnRzIG1pZ2h0IHN3aXRjaCBvZmYgdGhlIGJlaGF2aW91ciwgd2hpbGUgb3RoZXJzIG1p Z2h0IHN3aXRjaCBpdCBvbi4NCiAgICAtIEEgbm9kZSBjb3VsZCBhbGxvdyBhIHN3aXRjaCBldmVu IGluZGl2aWR1YWxseSBmb3IgZXZlcnkgcG9ydCBvciBuZWlnaGJvci4NCiAgICAgICAtIElmIGEg bm9kZSBrbm93cyB0aGF0IG9uZSBvZiBpdCdzIG5laWdoYm91cnMgaXMgYSBzZXJ2aWNlIG5vZGUg cmF0aGVyIHRoYW4gYSBwbGFpbiB0b3BvbG9naWNhbCBvbmUsIGl0IGNvdWxkIHN3aXRjaCBvZmYg cHJvdGVjdGlvbi4gVGhpcyBpcyBob3cgSSB3b3VsZCBwcmVmZXIgdG8gc29sdmUgdGhlIHByb2Js ZW0gd2l0aCBzZXJydmljZSBub2Rlcy4NCg0KU2hvdWxkIHRoaXMgYmUgZGlzY3Vzc2VkIGluIHRo ZSBwcm90ZWN0aW9uIGRvY3VtZW50LCBvciBpbiBhIHNlcGFyYXRlIG9uZT8NCg0KQmVzdCByZWdh cmRzLCBNYXJ0aW4NCkFtIDE0LjA4LjIwIHVtIDE5OjQ1IHNjaHJpZWIgS2V0YW4gVGFsYXVsaWth ciAoa2V0YW50KToNCkhpIFJvYmVydCwNCg0KV2UgZG8gbm90IGhhdmUgYSBzaWduYWxsaW5nIG1l Y2hhbmlzbSBpbiBJR1BzIHRvZGF5IHRvIGluZGljYXRlIGEg4oCcYnlwYXNzLWFibGXigJ0gaW5k aWNhdGlvbiBmb3IgUHJlZml4IFNJRHMuIElmIHRoZXJlIHdhcyBhIGRlc2lyZSBmb3IgaXQsIGFu IElHUCBleHRlbnNpb24gd291bGQgYmUgcmVxdWlyZWQgKHRoZXJlIGlzIG5vbmUgaW4gcHJvZ3Jl c3MgQUZBSUspLiBOb3RlIHRoYXQgdGhpcyByZXN1bHRzIGluIGRvdWJsaW5nIHRoZSBwcmVmaXgg U0lEIHNjYWxlIChnbG9iYWwgbGFiZWxzKSBpbiB0aGUgbmV0d29yay4gU28gSSB3b3VsZCBub3Qg Z28gYWJvdXQgdGhpcyB0cml2aWFsbHkuDQoNCkkgdGhpbmsgaXQgaGVscHMgdG8gZ2V0IG1vcmUg aW5wdXRzIGFuZCBwZXJzcGVjdGl2ZXMgZnJvbSBvcGVyYXRvcnMgb24gdGhlaXIgdmlld3MgZm9y IGRvaW5nIGEgYnlwYXNzIHZpYSBsb2NhbCBwcm90ZWN0aW9uIGZvciBzZWdtZW50cyBpbiBhbiBT UiBQb2xpY3kuIFRoZXJlIG1heSBiZSB0aG9zZSB0aGF0IHByZWZlciBlbmQtdG8tZW5kIHBhdGgg cHJvdGVjdGlvbiB1c2luZyBhIGZhbGxiYWNrIHBhdGggdGhhdCBpcyBzYXkgZGlzam9pbnQgd2l0 aCB0aGUgcHJpbWFyeSBidXQgcHJvdmlkZXMgYW4gYXBwcm9wcmlhdGUgU0xBL2ludGVudD8NCg0K VGhhbmtzLA0KS2V0YW4NCg0KRnJvbTogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+ PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4NClNlbnQ6IDE0IEF1Z3VzdCAyMDIwIDIzOjA0DQpU bzogS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbT48bWFpbHRvOmtl dGFudEBjaXNjby5jb20+DQpDYzogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWlu c2h0ZWluQHJiYm4uY29tPjxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+OyBK b2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+PG1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PjxtYWlsdG86c2hy YWRkaGFAanVuaXBlci5uZXQ+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxt YWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+IDxBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPjxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bT47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0K DQpLZXRhbiwNCg0KTG9va3MgbGlrZSB3ZSBhcmUgcHJldHR5IG11Y2ggaW4gc3luYyBoZXJlLg0K DQpCdXQgbGV0IG1lIGp1c3Qgb2JzZXJ2ZSB0aGF0IEkgcHVycG9zZWx5IGRpZCBub3QgbWVudGlv biBhYm91dCBTUiBwb2xpY2llcyBhcyB3ZSBhcmUgbm90IGFibGUgdG8gc2lnbmFsIHRoZSBpbnRl bnQgd2l0aCB0aGUgcGFja2V0cyBpdHNlbGYuDQoNClNvIGFsbCB3ZSBoYXZlIHRoZXJlIGlzIFNJ RHMuIEJTSURzIG9yIHByZWZpeCBTSURzIG5lZWQgdG8gYmUgZmxvb2RlZCB3aXRoIGluZm9ybWF0 aW9uIGlmIHBvbGljaWVzIGJ1aWxkIHdpdGggdXNpbmcgdGhlbSBhcmUgYnlwYXNzIGVsaWdpYmxl IG9yIG5vdC4NCg0KSSB3YXMgYWN0dWFsbHkgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCB0aGlz IGlzIGFscmVhZHkgdGhlcmUgYW5kIEkgYW0ganVzdCBub3QgYXdhcmUsIGJ1dCBsb29raW5nIGRl ZXBlciBpbmRlZWQgSSBkbyBub3Qgc2VlIHRoaXMgbWFya2luZyBuZWl0aGVyIGluIElTSVMgbm9y IE9TUEYgZm9yIHByZWZpeCBTSURzLg0KDQpJcyB0aGVyZSBzb21lIHdvcmsgaW4gcHJvZ3Jlc3Mg dG8gYWRkIGl0IHRvIHRob3NlIHByb3RvY29scyBvciBoYXZlIHdlIGp1c3QgZG9jdW1lbnRlZCBu ZWVkIGZvciBhIHNob3J0IExTUiBkcmFmdCAgPw0KDQpUaHgsDQpSLg0KDQoNCk9uIEZyaSwgQXVn IDE0LCAyMDIwIGF0IDY6MTcgUE0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNp c2NvLmNvbTxtYWlsdG86a2V0YW50QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgUm9iZXJ0LA0KDQpQ bGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRA cmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KU2VudDogMTQgQXVndXN0IDIw MjAgMjE6MTMNClRvOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29t PG1haWx0bzprZXRhbnRAY2lzY28uY29tPj4NCkNjOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxl eGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJi Ym4uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFAanVuaXBlci5uZXQ8 bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj47IEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4gPEFu ZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlk dGVsZWNvbS5jb20+Pjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBs aWNhYmlsaXR5DQoNCkhpIEtldGFuLA0KDQpXaGlsZSBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5 b3VyIG5vdGUgdGhlIGNvbnNlcXVlbmNlcyBvZiBpdCBhcmUgcHJldHR5IHNldnJlLg0KW0tUXSBJ IHVuZGVyc3RhbmQuIFdlIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiBpbXBsaWNhdGlvbnMgb2YgcHJv dGVjdGlvbiBzY2hlbWVzIGZvciB0aGUgU0xBcy9pbnRlbnQgb2YgU1IgUG9saWNpZXMuDQoNClVu bGVzcyB3ZSBzaWduYWwgd2hpY2ggcHJlZml4IFNJRCBpcyBwcm90ZWN0aW9uIGVsaWdpYmxlIGFu ZCB3aGljaCBpcyBub3QgaG93IHdvdWxkIG90aGVyIG5vZGVzIGtub3cgaWYgdGhleSBjYW4gcHJv dGVjdCBpdCBvciBub3QgPw0KW0tUXSBDb3JyZWN0LiBUbyBiZSBtb3JlIGFjY3VyYXRlLCB3ZSBu ZWVkIHRvIGNvbnNpZGVyIHRoaXMgbW9yZSBpbiB0aGUgY29udGV4dCBvZiBTTEEgb3Ig4oCcaW50 ZW504oCdIG9mIFNSIFBvbGljaWVzIGFuZCB3aGljaCBzZWdtZW50cyBtYXkgYmUg4oCcYnlwYXNz LWFibGXigJ0gZm9yIGxvY2FsIHByb3RlY3Rpb24gZm9yIHNvbWUgb2YgdGhvc2UgU1IgUG9saWNp ZXMuIFdlIGFsc28gaGF2ZSBwYXRoLXByb3RlY3Rpb24gbWVjaGFuaXNtcy4NCg0KSXQgc2VlbXMg dGhhdCB0b2RheSdzIHNhZmUgdGhpbmcgaXMgbm90IHRvIGFwcGx5IGFueSBub2RlIHByb3RlY3Rp b24gb24gU1IgZmxvd3MgYXQgdGhlIFBMUnMgdGhlbi4NCg0KQW5kIGxpbmsgcHJvdGVjdGlvbiBN VVNUIGFzc3VyZSB0aGF0IHBhY2tldHMgd2lsbCBhcnJpdmUgYXQgdGhlIG5laWdoYm9yIG5vZGUg dmlhIHNvbWUgb3RoZXIgbGluayByZWdhcmRsZXNzIG9mIGZ1cnRoZXIgcGF0aCB0b3dhcmRzIGRl c3RpbmF0aW9uLg0KW0tUXSBZZXMuIFdlIGhhdmUgYSBtZWNoYW5pc20gdG8gaW5kaWNhdGUgd2hp Y2ggYWRqLVNJRHMgaGF2ZSBwcm90ZWN0aW9uICh0aGF0IG1lY2hhbmlzbSBvbmx5IHByb3ZpZGVz IGxpbmsgcHJvdGVjdGlvbiB0byBnZXQgdG8gdGhlIG5laWdoYm9yIG5vZGUpIHNvIHRoZSBTUiBQ b2xpY3kgY29tcHV0YXRpb24gaXMgYWJsZSB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoYXQgc3BlY2lm aWMgbGluayBpcyDigJxieXBhc3MtYWJsZeKAnSBvciBub3QgYnkgaXRzIGNob2ljZSBvZiBwcm90 ZWN0ZWQgb3IgdW5wcm90ZWN0ZWQgYWRqLVNJRHMgcmVzcGVjdGl2ZWx5Lg0KDQpUaGFua3MsDQpL ZXRhbg0KDQpJcyBpdCBjb3JyZWN0ID8NCg0KVGh4DQpSDQoNCk9uIEZyaSwgQXVnIDE0LCAyMDIw IGF0IDU6MzIgUE0gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSA8a2V0YW50QGNpc2NvLmNvbTxt YWlsdG86a2V0YW50QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgU2FzaGEsDQoNClRoZSBzZXJ2aWNl IG5vZGUgYWR2ZXJ0aXNlcyBpdHMgb3duIFByZWZpeCBTSUQuIFRoZSBzZXJ2aWNlIGZ1bmN0aW9u IHRoYXQgdGhpcyBzZXJ2aWNlIG5vZGUgaW1wbGVtZW50cyBkb2VzIG5vdCByZXF1aXJlIGFueSBj b250ZXh0IChpLmUuIGFsbCBwYWNrZXRzIGFycml2aW5nIGF0IHRoZSBub2RlIGFyZSBzdWJqZWN0 ZWQgdG8gdGhhdCBzZXJ2aWNlKS4gVGhlcmVmb3JlIHRoZSBzZXJ2aWNlIG5vZGUgZG9lcyBub3Qg bmVlZCB0byByZWNlaXZlIGEgcGFja2V0IHdpdGggaXTigJlzIG93biBQcmVmaXggU0lELg0KDQpU aHVzLCB3ZSBjYW5ub3QgYXNzdW1lIHRoYXQgd2hlbiBQSFAgaXMgdXNlZCwgdGhlbiB0aGUgU0lE IGlzIG9ubHkgYXNzb2NpYXRlZCB3aXRoIGEgdG9wb2xvZ2ljYWwgaW5zdHJ1Y3Rpb24uDQoNCkhv cGUgdGhhdCBjbGFyaWZpZXM/DQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IEFsZXhhbmRlciBW YWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNvbTxtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AcmJibi5jb20+Pg0KU2VudDogMTQgQXVndXN0IDIwMjAgMjA6MjQNClRvOiBL ZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPG1haWx0bzprZXRhbnRA Y2lzY28uY29tPj47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT4+OyBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFAanVuaXBlci5u ZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj47IEVYVC1BbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4g PEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkFuZHJldy5BbHN0b25AbGlx dWlkdGVsZWNvbS5jb20+PjsgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRv OnJvYmVydEByYXN6dWsubmV0Pj4NCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVy bWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KS2V0YW4sIGFuZCBhbGwsDQpJIGhhdmUgc3RhdGVkIHRo YXQsIElNSE8gYW5kIEZXSVcsIGJvdGggQWRqLVNJRHMgYW5kIFByZWZpeCBTSURzIHRoYXQgYXJl IGFkdmVydGlzZWQgd2l0aCBQSFAgY2FuICBPTkxZIHJlcHJlc2VudCB0b3BvbG9naWNhbCBpbnN0 cnVjdGlvbnMgaW4gU1ItTVBMUyAtIGJlY2F1c2UgdGhlIGFkdmVydGlzaW5nIG5vZGUgd2lsbCBu b3QgcmVjZWl2ZSB0aGVtIGFuZCB0aGVyZWZvcmUgY2FuIGhhcmRseSBiZSBleHBlY3RlZCB0byBh c3NvY2lhdGUgYW55IHNlcnZpY2UgZnVuY3Rpb24gd2l0aCB0aGVtLg0KDQpUaGlzIGlzIGNvbXBs ZW1lbnRhcnkgdG8gd2hhdCB5b3UgaGF2ZSBzYWlkLg0KDQpIb3BlIHRoaXMgY2xhcmlmaWVzIG15 IHBvc2l0aW9uLg0KV2hhdCwgaWYgYW55dGhpbmcsIGRpZCBJIG1pc3M/DQoNClJlZ2FyZHMsDQpT YXNoYQ0KDQpHZXQgT3V0bG9vayBmb3IgQW5kcm9pZDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vMzNHaTd6cHREeVJwUmt4NFJjRHBiVUM2SDI/dT1odHRwcyUzQSUyRiUyRmFrYS5tcyUy RmdoZWkzNj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEtldGFu IFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb208bWFpbHRvOmtldGFudEBjaXNj by5jb20+Pg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTQsIDIwMjAsIDE2OjIzDQpUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW47IEpvZWwgTS4gSGFscGVybjsgU2hyYWRkaGEgSGVnZGU7IEVYVC1BbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1 aWR0ZWxlY29tLmNvbT47IFJvYmVydCBSYXN6dWsNCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlv biAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk5PVElDRTogVGhpcyBlbWFpbCB3YXMgcmVjZWl2ZWQgZnJvbSBhbiBFWFRFUk5B TCBzZW5kZXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkhpIFNhc2hhLA0K DQpJZiB0aGUgc2VydmljZSBkb2VzIG5vdCBuZWVkIGFueSBhZGRpdGlvbmFsIGNvbnRleHQgKGUu Zy4gYSBmaXJld2FsbCB0aGF0IGp1c3QgYXBwbGllcyBsb2NhbGx5IGNvbmZpZ3VyZWQgZGVmYXVs dCBydWxlcyBvbiBpdCksIHRoZW4gSSBkb27igJl0IHNlZSB3aHkgUEhQIGNvdWxkIG5vdCBiZSBk b25lIGZvciBhIFByZWZpeCBTSUQgYXNzb2NpYXRlZCB3aXRoIGEgc2VydmljZSBub2RlLg0KDQpB bHNvLCBJIGRpZG7igJl0IGZvbGxvdyB0aGUgcG9pbnQgdGhhdCB5b3Ugd2VyZSB0cnlpbmcgdG8g bWFrZSBhYm91dCBBZGotU0lEcy4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KRnJvbTogQWxleGFuZGVy IFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPG1haWx0bzpBbGV4YW5k ZXIuVmFpbnNodGVpbkByYmJuLmNvbT4+DQpTZW50OiAxNCBBdWd1c3QgMjAyMCAxODoyNA0KVG86 IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgPGtldGFudEBjaXNjby5jb208bWFpbHRvOmtldGFu dEBjaXNjby5jb20+PjsgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPj47IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIu VmFpbnNodGVpbkByYmJuLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+ PjsgU2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PG1haWx0bzpzaHJhZGRoYUBq dW5pcGVyLm5ldD4+OyBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86 RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20+IDxBbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPj47IFJv YmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+ DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5 DQoNCkhpIGFsbCwNClJlZ2FyZGluZyB0aGUgc3RhdGVtZW50ICJQcmVmaXggU0lEIGNvdWxkIGJl IGp1c3QgYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbiBvciBtYXkgYWxzbyBiZSB1c2VkIHRvIHN0 ZWVyIHRoZSBmbG93IHRvIGEgbm9kZSB3aGljaCBpcyBhcHBseWluZyBhIHNlcnZpY2UgZnVuY3Rp b24gdG8gaXQiOg0KDQoNCkkgdGhpbmsgdGhhdCBpbiBTUi1NUExTIGEgTm9kZSBTSUQgdGhhdCBp cyBhZHZlcnRpc2VkIHdpdGggUEhQIGFjaXRvbiBjYW4gYmUgc2FmZWx5IGNvbnNpZGVyZWQgYXMg Imp1c3QgYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbiIgYnkgdGhlIFBMUiBiZWNhdXNlIHRoZSBv cmlnaW5hdGluZyBub2RlIHdpbGwgbm90IHJlY2VpdmUgaXQuDQpUaGUgc2FtZSBhcHBsaWVzIHRv IEFkai1TRElzLg0KDQpNeSAyYy4NCg0KR2V0IE91dGxvb2sgZm9yIEFuZHJvaWQ8aHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM3NWM1WVlCZUViYUVad1VjSHBDWTFtNkgyP3U9aHR0cHMl M0ElMkYlMkZha2EubXMlMkZnaGVpMzY+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQp IDxrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmtldGFudD00MGNpc2Nv LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxNCwgMjAyMCwgMTU6 MDANClRvOiBKb2VsIE0uIEhhbHBlcm47IEFsZXhhbmRlciBWYWluc2h0ZWluOyBTaHJhZGRoYSBI ZWdkZTsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkVYVC1BbmRy ZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPjsgUm9iZXJ0IFJhc3p1aw0KQ2M6IHNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KDQpIaSBBbGwsDQoN Ckkgd291bGQgbGlrZSB0byBzaGFyZSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSBvbiB0aGlzLg0K DQpGaXJzdCwgdGhhbmtzIHRvIEpvZWwgZm9yIGJyaW5naW5nIHVwIHRoZSBkaXNjdXNzaW9uLiBD bGVhcmx5IHdlIG5lZWQgYSB3ZWxsLWRlZmluZWQgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZm9y IGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkgb2YgcHJvdGVjdGlvbiBmb3Igc2VnbWVudCB1c2Vk IGluIGFuIFNSIFBvbGljeS4gU29tZSBvZiB0aGlzIGlzIGNhcHR1cmVkIGluIFsxXS4NCg0KVGhp cyBpcyBhYm91dCBsb2NhbCByZXBhaXIgYXQgYSBQTFIuIEJ5IGl0J3MgdmVyeSBuYXR1cmUsIHRo ZSBQTFIgZG9lcyBub3QgaGF2ZSBhIG5vdGlvbiBvZiBob3cgInN0cmljdCBvciBub3QiIGlzIHRo ZSBTTEEgdGhhdCBpcyBiZWluZyBwcm92aWRlZCBieSB0aGUgU1IgUG9saWN5LiBBd2FyZW5lc3Mg b2YgdGhhdCBub3Rpb24gZXhpc3RzIGF0IHRoZSBTUiBQb2xpY3kgaGVhZGVuZCBhbmQvb3IgY29t cHV0YXRpb24tbm9kZS4NCg0KV2UgaGF2ZSBwcm90ZWN0ZWQgYW5kIHVuLXByb3RlY3RlZCB2YXJp YW50cyBvZiBhZGphY2VuY3kgU0lEcyB0byBlbmFibGUgdGhlIGNvbXB1dGF0aW9uIHRvIHBpY2sg b3IgdGhlIG90aGVyIGJhc2VkIG9uIHRoZSAic3RyaWN0bmVzcyIgb2YgdGhlIFNMQSByZXF1aXJl bWVudCBmb3IgcGlja2luZyB0aGF0IGxpbmsuIFdlIGRvIG5vdCBoYXZlIHN1Y2ggYSBub3Rpb24g Zm9yIFByZWZpeCBTSURzLiBPbmUgY2FuIHNheSB0aGF0IHdlIGNvdWxkIGludHJvZHVjZSBzaWdu YWxsaW5nIChlLmcuIGEgQiBmbGFnKSB0byBpbmRpY2F0ZSB3aGV0aGVyIGEgUHJlZml4IFNJRCBj YW4gYmUgYnlwYXNzZWQgb3Igbm90LiBUaGlzIHByb3ZpZGVzIHRoZSBvcHBvcnR1bml0eSBmb3Ig dGhlIGNvbXB1dGF0aW9uIHRvIHVzZSBvbmUgb3IgdGhlIG90aGVyIGZsYXZvciBkZXBlbmRpbmcg b24gdGhlIG5hdHVyZSBvZiB0aGUgU0xBIGZvciB0aGUgU1IgUG9saWN5Lg0KDQpJIGhhdmUgYSBw cm9ibGVtIGFuZCBhIGNvbmNlcm4gaW4gdGhlIGFzc3VtcHRpb24gdGhhdCBQTFJzIGNhbiBhc3N1 bWUgdGhhdCB0aGUgY3VycmVudGx5IGRlZmluZWQgdmFyaWFudCBvZiBQcmVmaXggU0lEcyBpbiBS RkM4NDAyIChhbmQgSUdQIHNwZWNzKSBhcmUgImJ5cGFzcy1hYmxlIi4NCg0KQXMgSm9lbCBhbmQg b3RoZXJzIGhhdmUgYnJvdWdodCBvdXQsIHRoZSBQcmVmaXggU0lEIGNvdWxkIGJlIGp1c3QgYSB0 b3BvbG9naWNhbCBpbnN0cnVjdGlvbiBvciBtYXkgYWxzbyBiZSB1c2VkIHRvIHN0ZWVyIHRoZSBm bG93IHRvIGEgbm9kZSB3aGljaCBpcyBhcHBseWluZyBhIHNlcnZpY2UgZnVuY3Rpb24gdG8gaXQu IEluIG9yZGVyIHRvIHN1cHBvcnQgYSBtaXggb2YgU1IgUG9saWNpZXMgb2YgZGlmZmVyZW50IFNM QXMgKHN0cmljdCBhbmQgbm90LXN0cmljdCksIHdlIG5lZWQgdG8gZW5hYmxlIHRoZSBjaG9pY2Ug b2YgU0lEcyB0aGF0IGluZGljYXRlcyB0byB0aGUgUExSIHdoZXRoZXIgdGhleSBhcmUgImJ5cGFz cy1hYmxlIiBvciBub3QuDQoNCkZvciB0aGUgY2FzZXMsIHdoZXJlIHRoZSBTUiBQb2xpY3kgaGFz IGEgc3BlY2lmaWMgU0xBLCBpdCBpcyByZXF1aXJlZCBmb3Igbm9kZXMgdG8gZHJvcCB0aGUgcGFj a2V0cyBtZWFudCBmb3IgdGhlICJhY3RpdmUgc2VnbWVudCIgdGhhbiB0byBieXBhc3MgaXQuIFdo ZW4gdGhpcyBtZWNoYW5pc20gaXMgdXNlZCBhbG9uZyBzaWRlIFNSVEUgcGF0aCBtb25pdG9yaW5n IG1lY2hhbmlzbXMsIGl0IGVuYWJsZXMgdGhlIGhlYWRlbmQgdG8gZGV0ZWN0IHRoZSBmYWlsdXJl IGFuZCBmYWxsYmFjayB0byBhbiBhbHRlcm5hdGUgcGF0aCB1c2luZyB0aGUgcGF0aCBwcm90ZWN0 aW9uIGFwcHJvYWNoLiBUaGlzIGlzIHNvbWV0aGluZyB0aGF0IGlzIGRlc2NyaWJlZCBhbmQgaW4g dXNlIGluIGRlcGxveW1lbnRzIHRvZGF5IFsxXS4uDQoNClRoYW5rcywNCktldGFuDQoNClsxXSBo dHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1kzZld1TkZZQ2pNSlVpaUFpV3dVbXM2SDI/ dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5n LXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTkNClsyXSBodHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzZmQ01yZ21FZXdDNGE0QUpScm1uN0g2SDI/dT1odHRwcyUzQSUy RiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91 dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTkuMw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQpTZW50OiAwNCBB dWd1c3QgMjAyMCAyMDoyNQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFp bnNodGVpbkByYmJuLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20+Pjsg U2hyYWRkaGEgSGVnZGUgPHNocmFkZGhhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOnNocmFkZGhhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+PjsgRVhULUFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb208bWFpbHRvOkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRl bGVjb20uY29tPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+OyBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVr Lm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPjsgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29t PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTcHJp bmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHkNCg0KVGhlcmUgYXJlLCBh cyBmYXIgYXMgSSBjYW4gdGVsbCwgYSBudW1iZXIgb2Ygd2F5cyB0byBhZGRyZXNzIHRoaXMgZmFt aWx5IG9mIHJlbGF0ZWQgcXVlc3Rpb25zLg0KV2hhdCBzdHJ1Y2sgbWUsIGFuZCBwcm9tcHRlZCB0 aGUgc3RhcnRpbmcgcXVlc3Rpb24sIHdhcyB0aGF0IG5vbmUgb2YgdGhlbSB3ZXJlIHNwZWxsZWQg b3V0LiAgSSBzZWUgbG90cyBvZiBpbnRlcmVzdGluZyBpZGVhcyAvIHByb3Bvc2Fscy4NClNvbWUg b2YgdGhlbSBhcmUgY29tcGF0aWJsZSB3aXRoIG90aGVycy4gICBTb21lIGFyZSBub3QuDQpJdCB3 b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxkIHJlYWNoIGFncmVlbWVudCBvbiBob3cgd2UgdGhvdWdo dCBpdCBzaG91bGQgYmUgaGFuZGxlZC4NCg0KVGhhbmsgeW91LA0KSm9lbA0KDQpPbiA4LzQvMjAy MCAzOjU0IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCj4gSGkgYWxsLA0KPg0KPiBJ IGFtIHN0aWxsIG5vdCBzdXJlIHRoYXQgdGhlIHByb2JsZW0gb2YgYnlwYXNzIGdvaW5nIHRocnUg dW5kZXNpcmFibGUNCj4gbGlua3Mvbm9kZXMgZXhpc3RzIGluIHRoZSBjYXNlIG9mIHRvcG9sb2dp Y2FsIFNJRHMuDQo+DQo+IEFGQUlLLCBGYWNpbGl0eSBQcm90ZWN0aW9uIGluIFJTVlAtVEUgRlJS IChSRkMgNDA5MA0KPiA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNROTJrbkU5WEp1 anJmOEJrN29KdnM2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJm YzQwOTA+KSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgZGVwbG95ZWQNCj4gZm9yIG1hbnkgeWVhcnMg YmVmb3JlIFNSLU1QTFMgaGFzIGJlZW4gaW50cm9kdWNlZC4gV2hhdOKAmXMgbW9yZSwNCj4gc2ln bmFsaW5nIG9mIGJ5cGFzcyB0dW5uZWxzIGhlIFBMUiB1c3VhbGx5IGRpZCBub3QgaW5jbHVkZSBh bnkgb2YgdGhlDQo+IGNvbnN0cmFpbnRzIHVzZWQgZm9yIGNvbXB1dGluZyBvZiBhbnkgc3BlY2lm aWMgTFNQIHRoYXQgdGhlIGJ5cGFzcyBMU1ANCj4gd291bGQgcHJvdGVjdCDigJMgYmVjYXVzZSBp biB0aGUgRmFjaWxpdHkgUHJvdGVjdGlvbiBtb2RlIHRoZSBzYW1lDQo+IGJ5cGFzcyBMU1Agd291 bGQgYmUgdXNlZCB0byBwcm90ZWN0IG11bHRpcGxlIExTUHMgcGFzc2luZyB0aHJ1IHRoZQ0KPiBm YWlsZWQgbGluay9ub2RlLg0KPg0KPiAgRnJvbSBteSBQT1YgdGhlIG9ubHkgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoaXMgYmVoYXZpb3IgYW5kIHRoYXQNCj4gaW50cm9kdWNlZCBieSB0aGUg4oCcYnlw YXNzaW5n4oCdIGRyYWZ0cyBpbiBTUiBpcyB0aGF0LCBpbiB0aGUgY2FzZSBvZg0KPiBSU1ZQLVRF LCB0aGUgb3BlcmF0b3Igd291bGQgZXhwbGljaXRseSBpbmRpY2F0ZSwgYXMgcGFydCBvZiBMU1AN Cj4gc2lnbmFsaW5nLCB3aGV0aGVyIGl0IHdvdWxkIG9yIHdvdWxkIG5vdCB1c2UgRlJSOyBMU1Bz IHRoYXQgd291bGQgbm90DQo+IHVzZSBGUlIgd291bGQgdGhlbiBkcm9wIHRyYWZmaWMgcmF0aGVy IHRoYW4gZGVsaXZlcmluZyBpdCB0aGUgd3Jvbmcgd2F5Lg0KPg0KPiBTdWNoIGFuIG9wdGlvbiBp bmRlZWQgZG9lcyBub3QgZXhpc3QgaW4gU1ItVEUgdG9kYXksIGJ1dCB3b3VsZCBiZSBlYXN5DQo+ IHRvIHByb3ZpZGUgaWYgc28gZGVzaXJlZCBJTUhPLg0KPg0KPiBEaWQgSSBtaXNzIHNvbWV0aGlu ZyBzdWJzdGFudGlhbD8NCj4NCj4gUmVnYXJkcywgYW5kIGxvdHMgb2YgdGhhbmtzIGluIGFkdmFu Y2UsDQo+DQo+IFNhc2hhDQo+DQo+IE9mZmljZTogKzk3Mi0zOTI2NjMwMg0KPg0KPiBDZWxsOiAg ICAgICs5NzItNTQ5MjY2MzAyDQo+DQo+IEVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4NCj4g KkZyb206KiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZz4+ICpPbiBCZWhhbGYgT2YgKlNocmFkZGhhIEhlZ2RlDQo+ICpTZW50Oiog VHVlc2RheSwgQXVndXN0IDQsIDIwMjAgOTo0MSBBTQ0KPiAqVG86KiBFWFQtQW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNv bS5jb20+DQo+IDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1haWx0bzpBbmRyZXcu QWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPj47IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsu bmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQo+ICpDYzoqIHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPjsgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4u Y29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4gKlN1YmplY3Q6KiBSZTogW3Nwcmlu Z10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQo+DQo+IEFs bCwNCj4NCj4gVGhpcyBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBhbmQgdGhhbmtz IHRvIEpvZWwgZm9yIHN0YXJ0aW5nDQo+IHRoaXMgZGlzY3Vzc2lvbi4gSU1PLCB3aGVuIHRoZXJl IGFyZSBzdHJpY3QgcmVxdWlyZW1lbnRzIG9mIGF2b2lkaW5nDQo+IGNlcnRhaW4gbm9kZXMvbGlu a3MgaXQgY2FuIGJlIHJlYWxpemVkICBlaXRoZXIgYnkgZGVmaW5pbmcgYSBmbGV4LWFsZ28NCj4g YXZvaWRpbmcgdGhvc2UNCj4NCj4gTm9kZXMgYW5kIGxpbmtzIG9yIGJ5IHVzaW5nIGEgc3RhY2sg b2YgdW5wcm90ZWN0ZWQgYWRqLXNpZHMgdGhhdCBhdm9pZA0KPiByZXN0cmljdGVkIG5vZGVzIGFu ZCBsaW5rcy4gV2hlbiBhIHN0YWNrIG9mIGFkai1zaWRzIGlzIHVzZWQgdG8NCj4gcmVhbGl6ZSB0 aGUgcGF0aCwgdGhlIGhlYWQtZW5kIGJhc2VkIChzQkZEKSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMg Y2FuIGJlIGFwcGxpZWQuDQo+DQo+IElmIE5vZGUtc2lkcy9wcmVmaXgtc2lkL2FueWNhc3Qtc2lk cyBhcmUgdXNlZCB0byBidWlsZCB0aGUgc3RhY2ssIHRoZQ0KPiBmYWlsdXJlIGV2ZW50cyBtYXkg Y2F1c2UgdHJhZmZpYyB0byBnbyB0aHJvdWdoIHJlc3RyaWN0ZWQgbm9kZXMgYW5kDQo+IGxpbmtz LiBUaGlzIHdvdWxkIGhhcHBlbiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgYW55IGtpbmQgb2YgcHJv dGVjdGlvbg0KPiBpcyBpbiB1c2Ugb3Igbm90Lg0KPg0KPiBSZ2RzDQo+DQo+IFNocmFkZGhhDQo+ DQo+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCj4NCj4gKkZyb206KiBzcHJpbmcgPHNwcmlu Zy1ib3VuY2VzQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnJTIwJTBi Pj4gPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+ICpPbiBCZWhhbGYgT2YgKkFuZHJl dyBBbHN0b24NCj4gKlNlbnQ6KiBUdWVzZGF5LCBBdWd1c3QgNCwgMjAyMCA1OjQxIEFNDQo+ICpU bzoqIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldD4gPG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQo+ICpDYzoqIHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IEpvZWwg TS4gSGFscGVybg0KPiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbT4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4NCj4gKlN1YmplY3Q6KiBSZTogW3Nw cmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5DQo+DQo+ ICpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdKg0KPg0KPiBSb2JlcnQg dGhpcyBpcyBhY3R1YWxseSBmYXIgbW9yZSBkaWZmaWN1bHQgd2hlbiDigJMgaXQgY2FuIGJlIGFu IGVudGlyZQ0KPiAobG9uZykgc2VyaWVzIG9mIG5vZGVzIHRoYXQgbmVlZCB0byBiZSBhdm9pZGVk Lg0KPg0KPiBJdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBtYWRlIHRvIHdvcmsgYnV0IEnigJlkIHdv cnJ5IHRoYXQgdG8gZG8gdGhpcyDigJMNCj4geW914oCZZCBoYXZlIHRvIHN0YWNrIDEwIOKAkyAy MCDigJMgMzAgbmVnYXRpdmUgbGFiZWxzIOKAkyBhbmQgdGhhdCB3b3VsZG7igJl0DQo+IGJlIHZp YWJsZS4NCj4NCj4gSXTigJlzIGVhc2llciB0byB1c2UgYWxnb3JpdGhtcyBhbmQgYWRqYWNlbmN5 IHNpZHMgYW5kIG90aGVyIHN1Y2ggdGhpbmdzDQo+IHRvIGNhbGN1bGF0ZSBwYXRocyDigJMgdGhl IGJpZ2dlc3QgdHJpY2sgaXMgYWJvdXQgdGhlIHN0YWNrIGRlcHRoLiAgV2hlbg0KPiB5b3UgaGF2 ZSB0aGlzIG5lZWQgZm9yIG5vZGUgYXZvaWRhbmNlIOKAkyB0aGUgbmVlZCBmb3IgMTArIGxhYmVs IGRlcHRoDQo+IGlzIGNyaXRpY2FsIOKAkyB1bmxlc3MgeW91IHdhbm5hIGJlIGFwcGx5aW5nIG9u ZSBoZWxsIG9mIGEgbG90IG9mDQo+IGJpbmRpbmcgbGFiZWxzIGFsb25nIHRoZSB3YXkgd2hpY2gg aXMgYSBuaWdodG1hcmUuDQo+DQo+IEJ1dCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaXMgdGhp cyBhIGNvbW1vbiB1c2UgY2FzZSDigJMgaXTigJlzIGEgdXNlDQo+IGNhc2UgdGhhdCBtb3N0IG9m IHRoZSBwZW9wbGUgSSBkaXNjdXNzIHRoaXMgd2l0aCBjZXJ0YWluIGhhdmUg4oCTIEkgY2FudA0K PiBjb21tZW50IG9uIGEgZ2xvYmFsIHNjYWxlLCBvciBmb3IgYW55b25lIGVsc2UsIGJ1dCBldmVy eSBpbmRpY2F0aW9uIEkNCj4gaGF2ZSBpcyB0aGF0IHllcyDigJMgaXRzIHNvbWV0aGluZyBwZW9w bGUgbmVlZCwgYW5kIHdhbnQNCj4NCj4gQW5kcmV3DQo+DQo+ICpGcm9tOiogUm9iZXJ0IFJhc3p1 ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PiA8bWFpbHRvOnJv YmVydEByYXN6dWsubmV0Pj4NCj4gKlNlbnQ6KiBUdWVzZGF5LCA0IEF1Z3VzdCAyMDIwIDAxOjI3 DQo+ICpUbzoqIEFuZHJldyBBbHN0b24gPEFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20N CjxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSUyMCUwYj4+IDxtYWlsdG86 QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4+DQo+ICpDYzoqIEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTIwJTBi Pj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPg0KPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gKlN1YmplY3Q6 KiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmls aXR5DQo+DQo+IElzIHRoaXMgYSBjb21tb24gdXNlIGNhc2UgaWUuICAiYnV0IHJhdGhlciDigJMg d2hpY2ggbm9kZXMgLyBuZXR3b3JrDQo+IHNlZ21lbnRzIGl0IGNhbiBuZXZlciB0b3VjaCBvciBm bG93IHRocm91Z2guIg0KPg0KPiBJZiBzbyBwZXJoYXBzIGl0cyB0aW1lIHRvIGRlZmluZSBub3Rp b24gb2YgKm5lZ2F0aXZlLVNJRCogaWUuIGxpc3QgaW4NCj4gdGhlIHBhY2tldCByZXNvdXJjZXMg d2hpY2ggZ2l2ZW4gcGFja2V0IE1VU1Qgbm90IGV2ZXIgdHJhdmVyc2UuDQo+DQo+IFB1dCBpbiB0 aGUgcGFja2V0IHNldCBvZiBub2RlcyBvciBsaW5rcyB3aGljaCB0aGUgcGFja2V0IHNob3VsZCBu ZXZlcg0KPiB0cmF2ZXJzZS4NCj4NCj4gVGhhdCBnb2VzIGluIGxpbmUgb2YgcmVjZW50IHdhdmUg b2YgbmVnYXRpdmUgcm91dGluZyBpbXBsZW1lbnRhdGlvbnMNCj4gKFJJRlQpIG9yIGRpc2N1c3Np b25zIChMU1IpDQo+DQo+IEJlc3QsDQo+IFIuDQo+DQo+IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQg MTE6NDYgUE0gQW5kcmV3IEFsc3Rvbg0KPiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNv bQ0KPG1haWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tJTIwJTBiPj4gPG1haWx0 bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPj4gd3JvdGU6DQo+DQo+ICAgICBTbyDi gJMNCj4NCj4gICAgIE9uZSBvZiB0aGUgdXNlIGNhc2VzLCBpbiBmYWN0LCBzb21lIHZlcnkgbWFq b3IgdXNlIGNhc2VzIGluIGFueQ0KPiAgICAgc3ByaW5nIHRlY2hub2xvZ3kgZm9yIHVzIHJldm9s dmUgYXJvdW5kIHRoZSBmb2xsb3dpbmcNCj4NCj4gICAgIGEuVGhlIGV4cGxpY2l0IGF2b2lkYW5j ZSBvZiBjZXJ0YWluIG5vZGVzDQo+DQo+ICAgICBiLlRoZSBleHBsaWNpdCBhdm9pZGFuY2Ugb2Yg Y2VydGFpbiBzZWN0aW9ucyBvZiB0aGUgbmV0d29yaw0KPg0KPiAgICAgQW55dGhpbmcgdGhhdCBj b3VsZCByZXN1bHQgaW4gdGhhdCBleHBsaWNpdCBhdm9pZGFuY2UgYmVpbmcgdmlvbGF0ZWQNCj4g ICAgIOKAkyB3b3VsZCBjcmVhdGUsIHNoYWxsIHdlIHNheSBzaWduaWZpY2FudCBwcm9ibGVtcy4N Cj4NCj4gICAgIE11Y2ggb2YgdGhlIHVzZSBjYXNlIGlzIG5vdCBhIGNhc2Ugb2Ygd2hpY2ggbm9k ZXMgdGhlIHBhY2tldHMgZmxvdw0KPiAgICAgdGhyb3VnaCDigJMgYnV0IHJhdGhlciDigJMgd2hp Y2ggbm9kZXMgLyBuZXR3b3JrIHNlZ21lbnRzIGl0IGNhbiBuZXZlcg0KPiAgICAgdG91Y2ggb3Ig ZmxvdyB0aHJvdWdoLiAgRWZmZWN0aXZlbHksIHRvIGJlIHVzZWQgYXMgYSB0ZWNobm9sb2d5IHRv DQo+ICAgICBhdm9pZCBjZXJ0YWluIHRoaW5ncyBmb3Igc3BlY2lmaWMgcmVhc29ucy4NCj4NCj4g ICAgIFRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIG5lZWRpbmcgc3VjaCBkZWVw IGxhYmVsIHN0YWNrcyDigJMNCj4gICAgIHRoaXMga2luZCBvZiBkZXRhaWxlZCBwYXRoIHByb2dy YW1taW5nIHRlbmRzIHRvIGRlZXBlbiB0aGUgc3RhY2sNCj4gICAgIGJlY2F1c2UgeW91IHNvbWV0 aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBleHBsaWNpdC4NCj4NCj4gICAgIEl0IGlzIGFic29sdXRl bHkgY3JpdGljYWwgdG8gdXMgdGhhdCB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUg4oCTDQo+ ICAgICBhbmQgdGhhdCB3ZSBjYW4gYXZvaWQgc2l0dWF0aW9ucyB3aGljaCBjb3VsZCBjYXVzZSB0 cmFmZmljIHRvDQo+ICAgICBhY2NpZGVudGx5IGhpdCB0aGluZ3MgZXhwbGljaXRseSBhdm9pZGVk Lg0KPg0KPiAgICAgSSB3aXNoIEkgY291bGQgYmUgbW9yZSBzcGVjaWZpYyB0aGFuIHRoaXMsIGJ1 dCBpdCBpcyB3aGF0IGl0IGlzLg0KPg0KPiAgICAgVGhhbmtzDQo+DQo+ICAgICBBbmRyZXcNCj4N Cj4gICAgICpGcm9tOiogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZw0KPG1haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYj4+ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGll dGYub3JnPj4gKk9uIEJlaGFsZiBPZiAqSm9lbCBNLiBIYWxwZXJuDQo+ICAgICAqU2VudDoqIE1v bmRheSwgMyBBdWd1c3QgMjAyMCAyMTozNg0KPiAgICAgKlRvOiogUm9iZXJ0IFJhc3p1ayA8cm9i ZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PiA8bWFpbHRvOnJvYmVydEBy YXN6dWsubmV0Pj4NCj4gICAgICpDYzoqIHNwcmluZ0BpZXRmLi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgKlN1YmplY3Q6KiBSZTog W3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZw0KPiBhcHBsaWNhYmlsaXR5 DQo+DQo+ICAgICAoU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxvbmcgZW5vdWdoLCByZWl0 ZXJhdGluZyB0aGF0IHRoaXMgaXMgYXMgYQ0KPiAgICAgcGFydGljaXBhbnQsIG5vdCBhIFdHIGNo YWlyLikNCj4NCj4gICAgIFllcywgd2UgYXJlIHRhbGtpbmcgSVAgbmV0d29ya3MuIEFuZCB5ZXMs IEkgaGF2ZSBzZWVuIElQIG5ldHdvcmtzIHRoYXQNCj4gICAgIGNob29zZSB0byBkcm9wIHBhY2tl dHMuIEZvciBhbGwgc29ydHMgb2YgcmVhc29ucy4NCj4gICAgIEkgdGhpbmsgdGhlcmUgYXJlIGxp a2VseSBvdGhlciByZWFzb25zIHdoeSBvbmUgbWF5IG5vdCB3YW50IGEgcmFuZG9tDQo+ICAgICBw YXRoIHJhdGhlciB0aGFuIGEgY2hvc2VuIFRFIHBhdGguIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50 IHdlIGJlIGNsZWFyDQo+ICAgICBhYm91dCB3aGF0IGNvbnN0cmFpbnRzIG1heSBiZSAvIGFyZSB2 aW9sYXRlZCB3aGVuIHdlIHRlbGwgcGVvcGxlIHRoZXkNCj4gICAgIGhhdmUgdGhpcyB0b29sIChw cm90ZWN0aXZlIHJlcm91dGluZykgdGhhdCBpcyBpbnRlbmRlZCB0byBwcmVzZXJ2ZSBRb1MuDQo+ DQo+ICAgICBMZXQncyBiZSBjbGVhci4gSSBhbSBub3QgYXJndWluZyB0aGF0IHRoaXMgaXMgbm90 IGEgZ29vZCBpZGVhLiBJdCBpcyBhDQo+ICAgICBnb29kIGlkZWEuIEFuZCB1c2VmdWwuIEkgYW0g dHJ5aW5nIHRvIGZpZ3VyZSBvdHUgd2hhdCBjb21iaW5hdGlvbiBvZg0KPiAgICAgYWRkaXRpb25h bCBtZWNoYW5pc21zIGFuZCBjbGVhciBkZXNjcmlwdGlvbnMgd2lsbCBsZWFkIHRvIGV2ZXJ5b25l DQo+ICAgICBnZXR0aW5nIHRoZSBiZWhhdmlvciB0aGV5IGV4cGVjdCAod2hpY2ggbWF5IG5vdCBi ZSB0aGUgYmVoYXZpb3IgdGhleQ0KPiAgICAgZGVzaXJlLCBidXQgc29tZXRpbWVzIGlzIHRoZSBi ZXN0IHdlIGNhbiBkby4pDQo+DQo+ICAgICBZb3VycywNCj4gICAgIEpvZWwNCj4NCj4gICAgIE9u IDgvMy8yMDIwIDI6MzAgUE0sIFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+ICAgICAgPiBKb2VsLA0K PiAgICAgID4NCj4gICAgICA+IEFyZSB3ZSBzdGlsbCB0YWxraW5nIGFib3V0IElQIG5ldHdvcmtz IGhlcmUgPyBPciBwZXJoYXBzIHNvbWUgaGFyZA0KPiAgICAgID4gc2xpY2luZyB3aXRoIHJlYWwg cmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5ldHMgPw0KPiAgICAgID4NCj4gICAgICA+IEJl Y2F1c2UgaWYgd2UgYXJlIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya2luZyBJIGhhdmUgdHdvDQo+ ICAgICBvYnNlcnZhdGlvbnM6DQo+ICAgICAgPg0KPiAgICAgID4gQSkgSWYgeW91IG5lZWQgdG8g dHJhdmVyc2UgdmlhIGEgc3BlY2lmaWMgbm9kZSAoaWUuIGZpcmV3YWxsKSB5b3UNCj4gICAgIGJl dHRlcg0KPiAgICAgID4gYXBwbHkgSVAgZW5jYXBzdWxhdGlvbiB0byB0aGF0IG5vZGUuLiBJIGRv bid0IHRoaW5rIElQDQo+ICAgICBlbmNhcHN1bGF0aW9uIGNhbg0KPiAgICAgID4gYmUgaGlqYWNr ZWQgdG9kYXkgc3VjaCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpcw0K PiAgICAgaWdub3JlZC4NCj4gICAgICA+DQo+ICAgICAgPiBCKSBIYXZlIHlvdSBzZWVuIGFueSBJ UCBuZXR3b3JrIHdoZXJlIHVwb24gdG9wb2xvZ3kgY2hhbmdlIChsaW5rDQo+ICAgICBvciBub2Rl DQo+ICAgICAgPiBmYWlsdXJlKSB5b3Ugc3VkZGVubHkgc3RhcnQgZHJvcHBpbmcgZmxvd3MgaW4g c3BpdGUgb2YgU1BUIG9mZmVyaW5nDQo+ICAgICAgPiBwZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0 aCB3aXRoIDEwIG1zIG1vcmUgaml0dGVyID8NCj4gICAgICA+DQo+ICAgICAgPiBPciBhcmUgc29t ZSBTUiBtYXJrZXRpbmcgc2xpZGVzIHByb21pc2UgdG8gdHVybiBJUCBuZXR3b3JrcyBpbg0KPiAg ICAgID4gc29tZXRoaW5nIG5ldyA/IFdvcnNlIC4uLiBkbyB0aGV5IG1lbnRpb24gcGF0aCBxdWFs aXR5IGd1YXJhbnRlZXMsDQo+ICAgICAgPiByZXNvdXJjZSByZXNlcnZhdGlvbnMgPyBJIGhvcGUg bm90Lg0KPiAgICAgID4NCj4gICAgICA+IFRoeCwNCj4gICAgICA+IFIuDQo+ICAgICAgPg0KPiAg ICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPg0K PiAgICAgID4NCj4gICAgICA+DQo+ICAgICAgPiBPbiBNb24sIEF1ZyAzLCAyMDIwIGF0IDg6MTAg UE0gSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tDQo8bWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20lMGI+PiAgICAgPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tJTIwJTBiPj4g PG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQo+ICAgICAgPg0KPiAgICAgID4g V2VsbCBsZXNzIHNlcmlvdXMgZm9yIFRFIFNJRHMsIEkgYW0gbm90IHN1cmUgdGhlIHByb2JsZW0g aXMNCj4gICAgIHJlc3RyaWN0ZWQNCj4gICAgICA+IHRvIGp1c3Qgc2VydmljZSBTSURzLg0KPiAg ICAgID4NCj4gICAgICA+IFN1cHBvc2UgdGhhdCB0aGUgUENFIGhhcyBzcGVjaWZpZWQgdGhlIHBh dGggdG8gbWVldCBzb21lIGNvbXBsZXggdGUNCj4gICAgICA+IG9iamVjdGl2ZS4gIFRoZSBieXBh c3Mgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dpbmcgd2hhdCB0aG9zZQ0KPiAgICAgID4gY29uc3Ry YWludHMNCj4gICAgICA+IHdlcmUuICBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywgaXQg aXMgYmV0dGVyIHRvIGRyb3AgdGhlIHBhY2tldA0KPiAgICAgID4gdGhhbiB0byBkZWxpdmVyIGl0 IG91dHNpZGUgdGhlIGVudmVsb3AuICBJIHN1c3BlY3QgdGhhdCB0aGUgcmlnaHQNCj4gICAgICA+ IGFuc3dlcg0KPiAgICAgID4gdG8gdGhpcyBpcyAidG9vIGJhZCIuICBJZiBzbywgYXMgd2l0aCB0 aGUgZGlzdGluY3Rpb24gcmVnYXJkaW5nDQo+ICAgICBzZXJ2aWNlDQo+ICAgICAgPiBub2Rlcywg d2Ugc2hvdWxkIHNheSBzbywgc2hvdWxkbid0IHdlPw0KPiAgICAgID4NCj4gICAgICA+IFlvdXJz LA0KPiAgICAgID4gSm9lbA0KPiAgICAgID4NCj4gICAgICA+IE9uIDgvMy8yMDIwIDI6MzYgQU0s IEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOg0KPiAgICAgID4gPiBNYWNoLCBKb2VsIGFuZCBh bGwsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IEkgdGhpbmsgdGhhdCBpbiBtb3N0IGNhc2VzOg0K PiAgICAgID4gPg0KPiAgICAgID4gPiAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlvbiBi ZXR3ZWVuICJ0b3BvbG9naWNhbCIgYW5kDQo+ICAgICAic2VydmljZSINCj4gICAgICA+ID4gaW5z dHJ1Y3Rpb25zIGluIFNJRCBhZHZlcnRpc2VtZW50cy4gRS5nLjoNCj4gICAgICA+ID4NCj4gICAg ICA+ID4gb0lHUCBQcmVmaXggTm9kZSBTSURzIElHUCBBZGotU0lEcyAoaWRlbnRpZmllZCBhcyBz dWNoIGluIHRoZQ0KPiAgICAgID4gPiBjb3JyZXNwb25kaW5nIElHUCBhZHZlcnRpc2VtZW50cykg cmVwcmVzZW50IHRvcG9sb2dpY2FsDQo+ICAgICBpbnN0cnVjdGlvbnMNCj4gICAgICA+ID4NCj4g ICAgICA+ID4gb1NlcnZpY2UgU0lEcyBmb3IgU1J2NiAoc2VlIFNSdjYgQkdQLUJhc2VkIE92ZXJs YXkgU2VydmljZXMNCj4gICAgICA+ID4NCj4gICAgICA+DQo+ICAgICA8aHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNDQ2N5OW1ZNmNNZmJrN1FmamhpQTNSNkgyP3U9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWJlc3Mtc3J2 Ni1zZXJ2aWNlcy0wNA0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ0NjeTltWTZj TWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2VydmljZXMtMDQlMGI+PiAgICAgPGh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zR0M1YWYyejNKenBoWkRrUG5jSEFRaTZIMj91 PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWJlc3Mtc3J2Ni1zZXJ2aWNl cy0wNF9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgw d3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG80VC1MMG5sJTI0Pj4NCj4gICAgICA+DQo+ICAg ICAgPiA+IGRyYWZ0KSB1bnN1cnByaXNpbmdseSByZXByZXNlbnQg4oCcc2VydmljZeKAnSBpbnN0 cnVjdGlvbnMNCj4gICAgICA+ID4NCj4gICAgICA+ID4gMi5TZWdtZW50cyB0aGF0IHJlcHJlc2Vu dCB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbnMgY2FuIGJlIGJ5cGFzc2VkLA0KPiAgICAgID4gPiB3 aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2VudCBzZXJ2aWNlIGluc3RydWN0aW9ucyByZXF1aXJl DQo+ICAgICAgPiBhbHRlcm5hdGl2ZQ0KPiAgICAgID4gPiBwcm90ZWN0aW9uIG1lY2hhbmlzbXMu DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IFRoaXMgdmlldyBzZWVtcyB0byBiZSBhbGlnbmVkIHdp dGggUkZDIDg0MDINCj4gICAgICA+ID4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z NDVOTENCNlR5ZHh1dXFVanRjRFJaeTZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGcmZjODQwMg0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNDVOTENC NlR5ZHh1dXFVanRjRFJaeTZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1s JTJGcmZjODQwMiUwYj4+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM3UHpV S0FEODJjalN2bVZjR3Zwa2hGNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYz JTJGX19odHRwcyUzQSUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDJfXyUzQiUyMSUy MU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZw UkhPR3Q4QWtUUkR1aURvMEk0WWJ0bSUyND4+DQo+ICAgICB0aGF0IHNheXMgaW4gU2VjdGlvbiAx Og0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgICAgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJh c2VkIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHR3bw0KPiAgICAgID4gPg0KPiAgICAgID4g PiB0b3BvbG9naWNhbCBzZWdtZW50cyBhcmUgZGVmaW5lZDogdGhlIElHUC1BZGphY2VuY3kgc2Vn bWVudCBhbmQgdGhlDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBJR1AtUHJlZml4IHNlZ21l bnQuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICAgICBJbiB0aGUgY29udGV4dCBvZiBhIEJHUC1i YXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d28NCj4gICAgICA+ID4NCj4gICAgICA+ ID4gdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBCR1AgcGVlcmluZyBzZWdt ZW50IGFuZCB0aGUNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIEJHUC1QcmVmaXggc2VnbWVu dC4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gSW4gdGhlIGNhc2Ugb2YgU1ItTVBMUyB0aGlzIGRp ZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNlY3Rpb24NCj4gICAgICA+IDMuNCBvZg0KPiAg ICAgID4gPiB0aGUgTm9kZSBQcm90ZWN0aW9uIGZvciBTUi1URSBQYXRoDQo+ICAgICAgPiA+DQo+ ICAgICAgPg0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zSmJTV0d4NURB Zk5Qc1pkaHBFeHh4OTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1mb3Itc3ItdGUt cGF0aHMtMDclMjNzZWN0aW9uLTMuNA0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8z SmJTV0d4NURBZk5Qc1pkaHBFeHh4OTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0 Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaGVnZGUtc3ByaW5nLW5vZGUtcHJvdGVjdGlvbi1m b3Itc3ItdGUtcGF0aHMtMDclMjNzZWN0aW9uLTMuNCUwYj4+ICAgICA8aHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNDclVnQVJXOHNvbUFidzZUaXNqZ0oxNkgyP3U9aHR0cHMlM0ElMkYl MkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWhlZ2RlLXNwcmluZy1ub2RlLXByb3RlY3Rpb24tZm9yLXNy LXRlLXBhdGhzLTA3JTJBc2VjdGlvbi0zLjRfXyUzQkl3JTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1 c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG85d08t U3NuJTI0Pj4NCj4gICAgICA+DQo+ICAgICAgPiA+IGRyYWZ0IHRoYXQgc2F5czoNCj4gICAgICA+ ID4NCj4gICAgICA+ID4gICAgIFRoZSBub2RlIHByb3RlY3Rpb24gbWVjaGFuaXNtIGRlc2NyaWJl ZCBpbiB0aGUgcHJldmlvdXMNCj4gICAgIHNlY3Rpb25zDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICAgICBkZXBlbmRzIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGxhYmVsIGltbWVkaWF0ZWx5 IGJlbG93DQo+ICAgICAgPiB0aGUgdG9wDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IGxhYmVsIGlu IHRoZSBsYWJlbCBzdGFjayBpcyB1bmRlcnN0b29kIGluIHRoZSBJR1AgZG9tYWluLiAgV2hlbiB0 aGUNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIHByb3ZpZGVyIGVkZ2Ugcm91dGVycyBleGNo YW5nZSBzZXJ2aWNlIGxhYmVscyB2aWEgQkdQIG9yIHNvbWUNCj4gICAgICA+IG90aGVyDQo+ICAg ICAgPiA+DQo+ICAgICAgPiA+ICAgICBub24tSUdQIG1lY2hhbmlzbSB0aGUgYm90dG9tIGxhYmVs IGlzIG5vdCB1bmRlcnN0b29kIGluIHRoZSBJR1ANCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAg IGRvbWFpbi4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIFRoZSBlZ3Jlc3Mgbm9kZSBwcm90 ZWN0aW9uIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdA0KPiAgICAgID4gPg0KPiAg ICAgID4gPiAgICAgW1JGQzg2NzkgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zSmZ2 dEJBbWFRUE4xakEzcE02VGRDRTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5v cmclMkZkb2MlMkZodG1sJTJGcmZjODY3OQ0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zSmZ2dEJBbWFRUE4xakEzcE02VGRDRTZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIu aWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODY3OSUwYj4+ICAgICA8aHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzM2ZE1BanVZVFFvdm84akh3bW0zZUp3NkgyP3U9aHR0cHMlM0ElMkYl MkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGaHRtbCUyRnJmYzg2NzlfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZ TkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOE1HaXBYYyUy ND4+XQ0KPiAgICAgaXMNCj4gICAgICA+ID4gYXBwbGljYWJsZSB0byB0aGlzIHVzZSBjYXNlIGFu ZCBubyBhZGRpdGlvbmFsIGNoYW5nZXMNCj4gICAgICA+ID4NCj4gICAgICA+ID4gICAgIHdpbGwg YmUgcmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ IFRoZSBzY2VuYXJpb3MgaW4gd2hpY2ggIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIOKAnHRvcG9s b2dpY2Fs4oCdIGFuZA0KPiAgICAgID4gPiDigJxzZXJ2aWNl4oCdIGluc3RydWN0aW9ucyBpcyBi cm9rZW4gYXJlIGluZGVlZCBwcm9ibGVtYXRpYy4gRS5nLiwNCj4gICAgICA+IGNvbnNpZGVyDQo+ ICAgICAgPiA+IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUgU0lEIGluIHRoZSBFUk8gb2Yg YSBTUi1URSBwYXRoDQo+ICAgICAgPiBpZGVudGlmaWVzIGENCj4gICAgICA+ID4gbm9kZSB0aGF0 IGFjdHMgYXMgYSBmaXJld2FsbCBmb3IgYWxsIHBhY2tldHMgaXQgcmVjZWl2ZXMsIGkuZS4sDQo+ ICAgICAgPiBwcm92aWRlcw0KPiAgICAgID4gPiB0aGUgZmlyZXdhbGwgc2VydmljZSB3aXRob3V0 IGFueSBkZWRpY2F0ZWQgc2VydmljZSBTSUQNCj4gICAgICA+IGlkZW50aWZ5aW5nIGl0Lg0KPiAg ICAgID4gPiBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2ggYSBub2RlIHdv dWxkIGNvbWJpbmUNCj4gICAgICA+IHRvcG9sb2dpY2FsDQo+ICAgICAgPiA+IGFuZCBzZXJ2aWNl IGluc3RydWN0aW9ucyB0aHVzIGJyZWFraW5nIHRoZSBkaWZmZXJlbnRpYXRpb24NCj4gICAgICA+ IGJldHdlZW4gdGhlIHR3by4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gSSBhbSBub3Qgc3VyZSBp ZiB1c2FnZSBvZiBzdWNoIOKAnGNvbWJpbmVk4oCdIFNJRHMgY291bGQgYmUgcHJldmVudGVkDQo+ ICAgICAgPiBvciBhdA0KPiAgICAgID4gPiBsZWFzdCBkaXNjb3VyYWdlZC4NCj4gICAgICA+ID4N Cj4gICAgICA+ID4gSWYgbm90LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0byBpZGVudGlmeSBzdWNo IFNJRHMgaW4gdGhlDQo+ICAgICAgPiBhZHZlcnRpc2VtZW50DQo+ICAgICAgPiA+IG1lY2hhbmlz bXMgd291bGQgYmUgdXNlZnVsIElNSE8uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IE15IDJjLA0K PiAgICAgID4gPg0KPiAgICAgID4gPiBTYXNoYQ0KPiAgICAgID4gPg0KPiAgICAgID4gPiBPZmZp Y2U6ICs5NzItMzkyNjYzMDINCj4gICAgICA+ID4NCj4gICAgICA+ID4gQ2VsbDogICAgICArOTcy LTU0OTI2NjMwMg0KPiAgICAgID4gPg0KPiAgICAgID4gPiBFbWFpbDogQWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t Pg0KPiAgICAgPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCj4gICAg ICA+IDxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICAgPiA+IEZyb206 IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCjxtYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYj4+DQo+ ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1hY2gg Q2hlbg0KPiAgICAgID4gPiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDY6MzAgQU0NCj4g ICAgICA+ID4gVG86IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPG1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiPj4gICAgIDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSUwYj4+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+Ow0KPiAgICAgc3ByaW5nQGlldGYu b3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+ID4gU3ViamVjdDogUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eQ0KPiAgICAgID4gPg0K PiAgICAgID4gPiBIaSBKb2VsLA0KPiAgICAgID4gPg0KPiAgICAgID4gPiBJIHRoaW5rIHRoaXMg aXMgYSBnb29kIHBvaW50IHRoYXQgbWF5IG5vdCBiZSBkaXNjdXNzZWQgaW4gdGhlDQo+ICAgICAg PiBwYXN0LiBBbmQNCj4gICAgICA+ID4gSSBhbHNvIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgImNh biBiZSBieXBhc3NlZCIgaW5kaWNhdGlvbiBpbiB0aGUNCj4gICAgICA+ID4gcm91dGluZyBhZHZl cnRpc2VtZW50IGZvciBub3cuDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IElNSE8sIHRoZSBpbmZv cm1hdGlvbiBhZHZlcnRpc2VkIGJ5IHJvdXRpbmcgaXMgbmV1dHJhbCwgc3VjaA0KPiAgICAgID4g aW5mb3JtYXRpb24NCj4gICAgICA+ID4gKGNhbiBvciBjYW5ub3QgYmUgYnlwYXNzZWQpIGlzIG1v cmUgcGF0aCBzcGVjaWZpYywgdGh1cw0KPiAgICAgbm9ybWFsbHkgdGhlDQo+ICAgICAgPiA+IGNv bnRyb2xsZXIgc2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciBkZWNpZGluZyB3aGV0aGVyL3doaWNo IFNJRA0KPiAgICAgID4gY2FuIGJlDQo+ICAgICAgPiA+IGJ5cGFzc2VkLg0KPiAgICAgID4gPg0K PiAgICAgID4gPiBCZXN0IHJlZ2FyZHMsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IE1hY2gNCj4g ICAgICA+ID4NCj4gICAgICA+ID4gID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gICAg ICA+ID4NCj4gICAgICA+ID4gID4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPg0KPiAgICAgID4gPG1haWx0 bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmclMGIlM2UlMjAlM2NtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclM2U+XQ0K PiAgICAgT24gQmVoYWxmIE9mIEpvZWwgTS4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gSGFs cGVybg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAy MDIwIDc6NTEgQU0NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gVG86IHNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAg IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgID4gPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcNCjxtYWlsdG86c3ByaW5nQGlldGYub3JnJTIwJTNj bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUwYj4+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUy MCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4g U3ViamVjdDogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNh YmlsaXR5DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ ICA+IChXRyBDaGFpciBoYXQgT2ZmLCB0aGlzIGlzIG1lcmVseSBhIG5vdGUgZnJvbSBhIHNsaWdo dGx5DQo+ICAgICAgPiBjb25mdXNlZCBXRw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBwYXJ0 aWNpcGFudC4pDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+DQo+ICAgICAg PiA+ICA+IEkgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIHZhcmlvdXMgcmVwYWlyIGRyYWZ0cywgYW5k IHRoZSB2YXJpb3VzDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IG5ldHdvcmtzIHByb2dyYW1t aW5nIGFuZCBzZXJ2aWNlIHByb2dyYW1taW5nIGRyYWZ0LCBhbmQgSSBhbQ0KPiAgICAgID4gdHJ5 aW5nIHRvDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IGZpZ3VyZSBvdXQgb25lIGFzcGVjdCBv ZiB0aGUgY29tYmluYXRpb24uDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+ICA+IEhvdyBkb2VzIGEgbm9kZSB0aGF0IGlzIGRvaW5nIHNvbWUgZm9ybSBv ZiBieXBhc3MgKHN1cHBvc2UsIGZvcg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBzaW1wbGlj aXR5LCBpdCBpcyBOb2RlIE4yIGRlY2lkaW5nIHRvIGJ5cGFzcyB0aGUgbmV4dCBTSUQgZm9yDQo+ ICAgICAgPiBhIGZhaWxlZA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBub2RlIE4zKSBrbm93 IHRoYXQgaXQgaXMgc2FmZSB0byBkbyBzbz8NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4NCj4g ICAgICA+ID4NCj4gICAgICA+ID4gID4gSWYgdGhlIHBhdGggd2FzIGp1c3QgZm9yIFRFLCB0aGVu IGl0IGlzICJzYWZlIiBpZiB0aGUgbmV3IHBhdGgNCj4gICAgICA+IG1lZXRzDQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+ICA+IHRoZSBURSBjcml0ZXJpYS4gIG9yIG1heWJlIGl0IGlzIHNhZmUgaWYg aXQgaXMgZXZlbiBjbG9zZSwgYXMNCj4gICAgICA+IGxvbmcgYXMNCj4gICAgICA+ID4NCj4gICAg ICA+ID4gID4gaXQgaXMgbm90IHVzZWQgZm9yIHRvbyBsb25nLg0KPiAgICAgID4gPg0KPiAgICAg ID4gPiAgPg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBCdXQgd2hhdCBpZiB0aGUgbm9kZSB3 ZXJlIGEgRmlyZXdhbGwsIGluY2x1ZGVkIHRvIG1lZXQgbGVnYWwNCj4gICAgICA+ID4gcmVxdWly ZW1lbnRzPw0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBPciB3YXMgc29tZSBvdGhlciBuZWNl c3NhcnkgcHJvZ3JhbW1hdGljIHRyYW5zZm9ybSAod2luY2Ugd2UgYXJlDQo+ICAgICAgPiA+DQo+ ICAgICAgPiA+ICA+IGRlbGliZXJhdGVseSB2YWd1ZSBhYm91dCB3aGF0IG5vZGVzIGNhbiBkbyB3 aGVuIGFza2VkIHN1aXRhYmx5LikNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4NCj4gICAgICA+ ID4NCj4gICAgICA+ID4gID4gSXMgdGhlcmUgc29tZSAiY2FuIGJlIGJ5cGFzc2VkIiBpbmRpY2F0 aW9uIGluIHRoZSByb3V0aW5nDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IGFkdmVydGlzZW1l bnRzIHRoYXQgSSBtaXNzZWQ/DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ICAgICAgPiA+ DQo+ICAgICAgPiA+ICA+IFRoYW5rIHlvdSwNCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gWW91 cnMsDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+IEpvZWwNCj4gICAgICA+ID4NCj4gICAgICA+ ID4gID4NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+ID4NCj4gICAgICA+ID4gID4gc3ByaW5n IG1haWxpbmcgbGlzdA0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+IDxtYWlsdG86c3ByaW5nQGlldGYub3Jn IDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21h aWx0bzpzcHJpbmdAaWV0Zi5vcmclMGI+PiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAl M2NtYWlsdG86c3ByaW5nQGlldGYub3JnPj4+DQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ICA+DQo+ ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjxodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTI+ DQo+ICAgICA8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRN3ZYMnFXU1VkV1ZjODky WHVYeTJINkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUz QSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUz RnUlM0RodHRwcyUyQTNBJTJBMl9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllO RThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG82SHdQTGlsJTI0 Pg0KPiAgICAgID4gPg0KPiAgICAgID4NCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRl Yy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyNTINCjxodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2SDI/dT1odHRw cyUzQSUyNTIlMGI+PiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQTVCOEgy Rm0xclBuYVozU3VwandyNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJG X19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRl QXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMjUyX18lM0JKU1UlMjElMjFORXQ2eU1hTy1nayUy MVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlE b3pvUWlBSGslMjQ+Pg0KPiAgICAgID4gPg0KPiAgICAgID4gPiAgPiBGJTJGd3d3LmlldGYub3Jn PGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zMnlDa1BLUnJ1UmoxWmZDdktnTDJHcTZI Mj91PWh0dHAlM0ElMkYlMkYyRnd3dy5pZXRmLm9yZz4NCj4gICAgIDxodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRwcyUzQSUyRiUy RnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9yZ19fJTNCJTIx JTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2 dnBSSE9HdDhBa1RSRHVpRG8tcFBDanZSJTI0Pg0KPiAgICAgID4gPGh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zR1dUOWZ5amFGaTNGY3ZIRHZvb2R2UzZIMj91PWh0dHAlM0ElMkYlMkYy Rnd3dy5pZXRmLm9yZw0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zR1dUOWZ5amFG aTNGY3ZIRHZvb2R2UzZIMj91PWh0dHAlM0ElMkYlMkYyRnd3dy5pZXRmLm9yZyUwYj4+ICAgICA8 aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgy P3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cu aWV0Zi5vcmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhn bTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvLXBQQ2p2UiUyND4+JTJGbWFpbG1hbiUy Rmxpc3RpbmZvJTJGc3ByaW5nDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+ IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgICA+ID4NCj4gICAgICA+ID4gc3ByaW5nQGlldGYu b3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAg ICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnDQo8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZyUwYj4+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUwYj4+ IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCj4gICAgICA+ID4NCj4gICAgICA+ID4NCj4gICAg ICA+DQo+ICAgICBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1 R0M0ZUF2UDQ2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnNwcmluZw0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQmh5 RXR4NFE3bjc0QmhpUm5mTUp0VDZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2 MyUyRl9faHR0cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1 R0M0ZUF2UDQ2SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTJGJTJBMkZ3d3cuaWV0Zi5vcmclMkEyRm1h aWxtYW4lMkEyRmxpc3RpbmZvJTJBMkZzcHJpbmdfXyUzQkpTVWxKU1VsJTIxJTIxTkV0NnlNYU8t Z2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RS RHVpRG8taFIzZ0FEJTI0Pg0KPiAgICAgID4gPg0KPiAgICAgID4gPg0KPiAgICAgID4gPg0KPiAg ICAgID4gPg0KPiAgICAgID4NCj4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgID4gPiBOb3Rp Y2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWlu DQo+ICAgICAgPiA+IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRo YXQgaXMgY29uZmlkZW50aWFsDQo+ICAgICAgPiBhbmQvb3INCj4gICAgICA+ID4gcHJvcHJpZXRh cnkgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3 LA0KPiAgICAgID4gPiBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3Ro ZXJzIG9yIGZvcndhcmRpbmcNCj4gICAgIHdpdGhvdXQNCj4gICAgICA+ID4gZXhwcmVzcyBwZXJt aXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZQ0KPiAgICAg ID4gaW50ZW5kZWQNCj4gICAgICA+ID4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbA0KPiAgICAgID4gPiBjb3BpZXMsIGlu Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMuDQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ICAgICAgPiA+DQo+ICAgICAgPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPiA+IHNwcmluZyBtYWlsaW5nIGxp c3QNCj4gICAgICA+ID4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxt YWlsdG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gICAgICA+ ID4gaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxx NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz cHJpbmcNCj4gICAgIDxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2 NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0 dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nX18lM0Il MjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3 cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQ+DQo+ICAgICAgPiA+DQo+ICAgICAgPg0KPiAg ICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g ICAgICA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gICAgICA+IHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPiA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4gPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQo+ICAgICAgPiBodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1Ex eHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1h aWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZw0KPiAgICAgPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVm ZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzcHJpbmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9p UUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyND4NCj4gICAg ICA+DQo+DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAgICAgc3ByaW5nIG1haWxpbmcgbGlzdA0KPiAgICAgc3ByaW5nQGlldGYub3JnPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+IDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgaHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcN Cj4NCj4gPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNUUmVYaDY3MUc3OUJW R0VxMTZIMj91PWh0dHBzJTNBJQ0KPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJE blNUUmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTI1JTBiPj4gMkYlMkZ1cmxkZWZlbnNl LmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZzxodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzJ5Q2tQS1JydVJqMVpmQ3ZLZ0wyR3E2SDI/dT1odHRwJTNBJTJGJTJGMkZ3 d3cuaWV0Zi5vcmc+JTJGbWFpbG1hbiUyRmxpc3RpDQo+IG5mbyUyRnNwcmluZ19fJTNCJTIxJTIx TkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3UNCj4gb1pIZ3dw NnZwUkhPR3Q4QWtUUkR1aURvNUtsUG5iaiUyND4NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAtLQ0KPiBOb3RpY2U6IFRoaXMgZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRz IG1heSBjb250YWluDQo+IGluZm9ybWF0aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMu IHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vcg0KPiBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsDQo+IGRpc2Nsb3N1cmUs IHJlbGlhbmNlIG9yIGRpc3RyaWJ1dGlvbiBieSBvdGhlcnMgb3IgZm9yd2FyZGluZyB3aXRob3V0 DQo+IGV4cHJlc3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQNCj4gcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbA0KPiBjb3BpZXMsIGluY2x1ZGluZyBhbnkg YXR0YWNobWVudHMuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmlu Z0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cu aWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJp bmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vY2xpY2t0aW1lLnN5 bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBh bnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmlj YXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwgYW5kL29yIHByb3ByaWV0YXJ5IGZvciB0 aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgZGlzY2xv c3VyZSwgcmVsaWFuY2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nIHdp dGhvdXQgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsIGNvcGllcywgaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpzcHJpbmcgbWFpbGlu ZyBsaXN0DQoNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL2NsaWNrdGlt ZS5zeW1hbnRlYy5jb20vMzVQWGtLS1Q2RXpMVVZmRFQ0NDNRb3k2SDI/dT1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZz4NCg0K --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4CCdggeml509mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuSFRNTFByZWZv cm1hdHRlZCwgbGkuSFRNTFByZWZvcm1hdHRlZCwgZGl2LkhUTUxQcmVmb3JtYXR0ZWQNCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SGkgU2FzaGEgYW5kIE1hcnRpbiwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5NYW55IHRoYW5rcyBmb3IgeW91ciBpbnB1dC4gSSBmdWxseSBhZ3JlZSB3aXRo IHlvdXIgcG9pbnQgb2Ygd2UgbmVlZCB0byBjb25zaWRlciB0byBhZHZlcnRpc2UgdGhlIGFiaWxp dHkgb2YNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+dGhlIG5vZGUgdG8gYWR2 ZXJ0aXNlIGEgc3BlY2lmaWMgUHJlZml4IFNJRCBpdCBvcmlnaW5hdGVzIGFzIOKAnG5vdCBlbGln aWJsZSBmb3IgYnlwYXNzIHByb3RlY3Rpb27igJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5BbHNvLCB0aGlzIGV4dGVuc2lvbiBzaG91bGQgYmUgd3JpdHRlbiBpbiBhIHBy b3RlY3Rpb24gZG9jdW1lbnQgbGlrZSBNYXJ0aW4gc2FpZC4gV2UgaGF2ZSBhIHN0cmF3bWFuIGRy YWZ0IHBvc2VkIDEgeWVhciBhZ28gWzFdLCBidXQgaXQgaGFzIG5vdCBiZWVuIGRpc2N1c3NlZCB5 ZXQuICZuYnNwO1RoZSBtYWluIGlkZWEgb2YgdGhlIGRyYWZ0IGlzIHRvIGFkZCBhIG5vLWJ5cGFz cw0KIGZsYWcgaW50byBTSUQoaW5jbHVkaW5nIFByZWZpeCBTSUQsIGFuZCBhZGotU0lEKS4gQnV0 IHdlIGFyZSBkaXNjdXNzaW5nIHdpdGggc29tZSBleHBlcnRzIHRoYXQgZG8gd2UgbmVlZCB0aGUg Tm8tYnlwYXNzIGZsYWcgZm9yIEFkai1TSUQgb3Igbm90LCBpdCBzZWVtcyBsaWtlIHdlIGhhdmUg YSBCIGZsYWcgYWxyZWFkeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0 IGlzIHNvIG5pY2UgdG8gc2VlIHRoaXMgcG9pbnQgaXMgcmFpc2VkIGFuZCBkaXNjdXNzZWQuIEFs c28sIHdlbGNvbWUgdG8gcmV2aWV3IHRoZSBkb2N1bWVudCwgYW5kIGhvcGUgdG8gaGF2ZSB5b3Vy IHZhbHVhYmxlIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ UmVzcGVjdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bMV0uPC9zcGFuPiA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktcnRnd2ctZW5oYW5jZWQtdGktbGZhLTAy Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1ydGd3Zy1lbmhhbmNlZC10 aS1sZmEtMDI8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHNwcmluZyBb bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5BbGV4 YW5kZXIgVmFpbnNodGVpbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTgsIDIw MjAgMTE6NDQgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBIb3JuZWZmZXIgJmx0O21haG9AbGFi LmR0YWcuZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmdAaWV0Zi5vcmc7IFJvYmVydCBSYXN6 dWsgJmx0O3JvYmVydEByYXN6dWsubmV0Jmd0OzsgRVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20gJmx0O0FuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20mZ3Q7OyBTaHJhZGRo YSBIZWdkZSAmbHQ7c2hyYWRkaGFAanVuaXBlci5uZXQmZ3Q7OyBLZXRhbiBUYWxhdWxpa2FyIChr ZXRhbnQpICZsdDtrZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBKb2VsIE0u IEhhbHBlcm4gJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxp dHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5NYXJ0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxvdHMgb2YgdGhhbmtzIGZvciBh biBpbXBvcnRhbnQgaW5wdXQgdG8gdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SSBmdWxseSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGFiaWxpdHkgdG8g dHVybiBvZmYgdGhlIG5vZGUgcHJvdGVjdGlvbiBzY2hlbWUgZm9yIGEgc3BlY2lmaWMgUExSIG5l aWdoYm9yIChpLmUuLCBvbiBhIHNwZWNpZmljIFBMUiBwb3J0KSBieSBzdWl0YWJsZSBsb2NhbCBj b25maWd1cmF0aW9uIGluIHRoZSBQTFIgaXMgZGVmaW5pdGVseSByZXF1aXJlZC4gU3VjaCBhbg0K IGFiaWxpdHkgd291bGQgcHJvYmFibHkgYWRkcmVzcyBtb3N0IChpZiBub3QgYWxsKSBzY2VuYXJp b3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBzby1jYWxsZWQg4oCcc2VydmljZSBub2Rlc+KAnSB0aGF0 IGNhbm5vdCBiZSBieXBhc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkkgYWxzbyB0aGluayB0aGF0IHNlcnZpY2Ugbm9kZXMgdGhhdCBjYW5ub3QgYmUgYnlwYXNzZWQg dHlwaWNhbGx5IHdvdWxkIGFkdmVydGlzZSB0aGVtc2VsdmVzIGFzIOKAnHN0dWIgbm9kZXPigJ0g aW4gSUdQIGluIG9yZGVyIHRvIHByZXZlbnQgaW5hZHZlcnRlbnQgYXBwbGljYXRpb24gb2YgdGhl aXIgc2VydmljZSBmdW5jdGlvbiB0byB0cmFuc2l0IHRyYWZmaWMgKHdoaWNoDQogY291bGQgb3Ro ZXJ3aXNlIHBhc3MgdGhydSB0aGUgc2VydmljZSBub2RlIGR1ZSB0byBzb21lIHRvcG9sb2d5IGNo YW5nZSkuIFRoZXJlZm9yZSBhIGxvY2FsIHBvbGljeSB0aGF0IHdvdWxkIGV4Y2x1ZGUgSUdQIG5l aWdoYm9ycyBhZHZlcnRpc2luZyAmbmJzcDt0aGVtc2VsdmVzIGFzIHN0dWIgbm9kZXMgaW4gSUdQ IGZyb20gdGhlIG5vZGUgcHJvdGVjdGlvbiBzY2hlbWUgY291bGQgYmUgYWxzbyB1c2VmdWwuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MYXN0IGJ1dCBub3QgbGVhc3QsIGFi aWxpdHkgb2YgdGhlIG5vZGUgdG8gYWR2ZXJ0aXNlIGEgc3BlY2lmaWMgUHJlZml4IFNJRCBpdCBv cmlnaW5hdGVzIGFzIOKAnG5vdCBlbGlnaWJsZSBmb3IgYnlwYXNzIHByb3RlY3Rpb27igJ0gKGUu Zy4sIHVzaW5nIGEgbmV3IGZsYWcgaW4gdGhlIFByZWZpeCBOb2RlIFRMViBmb3IgSVMtSVMgb3Ig T1NQRikgc2hvdWxkIGJlIGNvbnNpZGVyZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5NeSAyYyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U2FzaGE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9mZmljZTogJiM0Mzs5NzItMzkyNjYzMDI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Q2VsbDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzs5NzItNTQ5 MjY2MzAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVtYWlsOiZuYnNwOyZuYnNwOyA8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTwvYT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBz cHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJ0aW4gSG9y bmVmZmVyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAxOCwgMjAyMCA1OjUxIFBN PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tIj5BbGV4YW5kZXIuVmFp bnNodGVpbkByYmJuLmNvbTwvYT4mZ3Q7OyBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWls dG86cm9iZXJ0QHJhc3p1ay5uZXQiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs7DQo8YSBocmVm PSJtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iPkVYVC1BbmRyZXcu QWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb20iPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208 L2E+Jmd0OzsgU2hyYWRkaGEgSGVnZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBqdW5p cGVyLm5ldCI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+Jmd0OzsNCiBLZXRhbiBUYWxhdWxpa2Fy IChrZXRhbnQpICZsdDs8YSBocmVmPSJtYWlsdG86a2V0YW50PTQwY2lzY28uY29tQGRtYXJjLmll dGYub3JnIj5rZXRhbnQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsgSm9lbCBN LiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpv ZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBT cHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ QSBmZXcgdGhvdWdodHMgZnJvbSBteSAob3BlcmF0b3IncykgUG9WOjxicj4NCjxicj4NCiZuYnNw Oy0gVGhlIGRpc3Vzc2lvbiBpcyBhIHZlcnkgZ29vZCBhbmQgaW1wb3J0YW50IG9uZS4gSXQgcHJv YmFibHkgc2hvdWxkIGJlIGRpc2N1c3NlZCBhbmQgZG9jdW1lbnRlZCB3ZWxsIGluIG9yZGVyIHRv IGp1c3RpZnkgdGhlIHByb3Bvc2VkIHByb3RlY3Rpb25zIG1lY2hhbmlzbXMuPGJyPg0KPGJyPg0K Jm5ic3A7LSBOb3QgYWxsIG9wZXJhdG9ycyBzZWVtIHRvIGhhdmUgdGhlIHNhbWUgcmVxdWlyZW1l bnRzLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAoQSBzb21ld2hhdCBzaW1pbGFyIGRpc2N1c3Np b24gbWlnaHQgYmUgdGhlIG9uZSBmb3IgZGlzam9pbnQgcGF0aHMuIFRob3NlIGFyZSBvZnRlbiBl cXVpcmVkIGJ5IHZvaWNlIHNpZ25hbGxpbmcgYXBwbGljYXRpb25zLiBJbiBzb21lIGNhc2VzIHRo ZSB2b2ljZSBzZXJ2aWNlIGRlbWFuZHMgdGhhdCB0cmFmZmljIGlzIGJsYWNraG9sZWQgcmF0aGVy IHRoYW4gb24gZm9yd2FyZGVkIG9uIHRoZSB3cm9uZyBwYXRoLiBJbiBvdGhlciBjYXNlcyBkaXNq b2ludA0KIHBhdGhzIGFyZSBqdXN0IHJlcXVpcmVkIGZvciB0aGUgJnF1b3Q7Z29vZCBjYXNlJnF1 b3Q7LiBUcmFmZmljIE1BWSBiZSBmb3J3YXJkZWQgb24gdGhlIHdyb25nIHBhdGgsIGFzIGxvbmcg YXMgdGhlIG5ldHdvcmsganVzdCBtYWtlcyBzdXJlIHRoZSB0cmFmZmljIG9uIHRoZSBvdGhlciBw YXRoIGlzIG5ldmVyIGFmZmVjdGVkIGJ5IHRoZSBzYW1lIGZhaWx1cmUuKTxicj4NCjxicj4NCiZu YnNwOy0gUGVyc29uYWxseSBJIHdvdWxkIGhhdGUgdG8gc2VlIHlldCBhbm90aGVyIElHUCBleHRl bnNpb24gZm9yIHRoaXMgcHVycG9zZS48YnI+DQo8YnI+DQombmJzcDstIEkgd291bGQgcmF0aGVy IHByZWZlciBhIGdvb2QgZGlzY3Vzc2lvbiBvZiB3aGF0IGNhbiBiZSBhY2hpZXZlZCBieSB1c2lu ZyBlYXN5IHRvIG1ha2Ugc3dpdGNoZXM6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVGhlIHBy b3RlY3Rpb24gYmVoYXZpb3VyIGNvdWxkIGJlIHN3aXRjaGVkIG9uIG9yIG9mZiBwZXIgbm9kZS48 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBBbiBvcGVyYXRvciB3 aXRoIHN0cmljdCAmcXVvdDtzb21lIHRyYWZmaWMgbWF5IG5ldmVyIHRvdWNoIGNlcnRhaW4gcGFy dHMgb2YgdGhlIG5ldHdvcmsmcXVvdDsgcmVxdWlyZW1lbnRzIG1pZ2h0IHN3aXRjaCBvZmYgdGhl IGJlaGF2aW91ciwgd2hpbGUgb3RoZXJzIG1pZ2h0IHN3aXRjaCBpdCBvbi48YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgLSBBIG5vZGUgY291bGQgYWxsb3cgYSBzd2l0Y2ggZXZlbiBpbmRpdmlkdWFs bHkgZm9yIGV2ZXJ5IHBvcnQgb3IgbmVpZ2hib3IuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gSWYgYSBub2RlIGtub3dzIHRoYXQgb25lIG9mIGl0J3MgbmVpZ2hi b3VycyBpcyBhIHNlcnZpY2Ugbm9kZSByYXRoZXIgdGhhbiBhIHBsYWluIHRvcG9sb2dpY2FsIG9u ZSwgaXQgY291bGQgc3dpdGNoIG9mZiBwcm90ZWN0aW9uLiBUaGlzIGlzIGhvdyBJIHdvdWxkIHBy ZWZlciB0byBzb2x2ZSB0aGUgcHJvYmxlbSB3aXRoIHNlcnJ2aWNlIG5vZGVzLjxicj4NCjxicj4N ClNob3VsZCB0aGlzIGJlIGRpc2N1c3NlZCBpbiB0aGUgcHJvdGVjdGlvbiBkb2N1bWVudCwgb3Ig aW4gYSBzZXBhcmF0ZSBvbmU/PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLCBNYXJ0aW48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFtIDE0LjA4LjIwIHVtIDE5OjQ1IHNjaHJpZWIgS2V0YW4gVGFs YXVsaWthciAoa2V0YW50KTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBSb2JlcnQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGRvIG5vdCBoYXZl IGEgc2lnbmFsbGluZyBtZWNoYW5pc20gaW4gSUdQcyB0b2RheSB0byBpbmRpY2F0ZSBhIOKAnGJ5 cGFzcy1hYmxl4oCdIGluZGljYXRpb24gZm9yIFByZWZpeCBTSURzLiBJZiB0aGVyZSB3YXMgYSBk ZXNpcmUgZm9yIGl0LCBhbiBJR1AgZXh0ZW5zaW9uIHdvdWxkIGJlIHJlcXVpcmVkICh0aGVyZSBp cyBub25lIGluIHByb2dyZXNzIEFGQUlLKS4gTm90ZSB0aGF0IHRoaXMgcmVzdWx0cyBpbiBkb3Vi bGluZw0KIHRoZSBwcmVmaXggU0lEIHNjYWxlIChnbG9iYWwgbGFiZWxzKSBpbiB0aGUgbmV0d29y ay4gU28gSSB3b3VsZCBub3QgZ28gYWJvdXQgdGhpcyB0cml2aWFsbHkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgaXQgaGVscHMgdG8gZ2V0IG1vcmUgaW5wdXRzIGFuZCBwZXJzcGVj dGl2ZXMgZnJvbSBvcGVyYXRvcnMgb24gdGhlaXIgdmlld3MgZm9yIGRvaW5nIGEgYnlwYXNzIHZp YSBsb2NhbCBwcm90ZWN0aW9uIGZvciBzZWdtZW50cyBpbiBhbiBTUiBQb2xpY3kuIFRoZXJlIG1h eSBiZSB0aG9zZSB0aGF0IHByZWZlciBlbmQtdG8tZW5kIHBhdGggcHJvdGVjdGlvbiB1c2luZyBh IGZhbGxiYWNrIHBhdGggdGhhdA0KIGlzIHNheSBkaXNqb2ludCB3aXRoIHRoZSBwcmltYXJ5IGJ1 dCBwcm92aWRlcyBhbiBhcHByb3ByaWF0ZSBTTEEvaW50ZW50PzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXRhbjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gUm9iZXJ0IFJhc3p1ayA8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiPg0K Jmx0O3JvYmVydEByYXN6dWsubmV0Jmd0OzwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IDE0IEF1Z3Vz dCAyMDIwIDIzOjA0PGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxh IGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIj4mbHQ7a2V0YW50QGNpc2NvLmNvbSZndDs8 L2E+PGJyPg0KPGI+Q2M6PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8YSBocmVmPSJtYWlsdG86 QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20iPiZsdDtBbGV4YW5kZXIuVmFpbnNodGVpbkBy YmJuLmNvbSZndDs8L2E+OyBKb2VsIE0uIEhhbHBlcm4NCjxhIGhyZWY9Im1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tIj4mbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs8L2E+OyBTaHJhZGRoYSBI ZWdkZSA8YSBocmVmPSJtYWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQiPg0KJmx0O3NocmFkZGhh QGp1bmlwZXIubmV0Jmd0OzwvYT47IDxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBs aXF1aWR0ZWxlY29tLmNvbSI+DQpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwv YT4gPGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iPg0KJmx0 O0FuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmls aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktldGFuLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va3MgbGlrZSB3ZSBhcmUg cHJldHR5IG11Y2ggaW4gc3luYyBoZXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgbGV0IG1lIGp1c3Qgb2JzZXJ2ZSB0aGF0 IEkgcHVycG9zZWx5Jm5ic3A7ZGlkIG5vdCBtZW50aW9uIGFib3V0IFNSIHBvbGljaWVzIGFzIHdl IGFyZSBub3QgYWJsZSB0byBzaWduYWwgdGhlIGludGVudCB3aXRoIHRoZSBwYWNrZXRzIGl0c2Vs Zi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U28gYWxsIHdlIGhhdmUgdGhlcmUgaXMgU0lEcy4gQlNJRHMgb3IgcHJlZml4IFNJRHMg bmVlZCB0byBiZSBmbG9vZGVkIHdpdGggaW5mb3JtYXRpb24gaWYgcG9saWNpZXMgYnVpbGQgd2l0 aCB1c2luZyB0aGVtIGFyZSBieXBhc3MgZWxpZ2libGUgb3Igbm90LiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBhY3R1YWxs eSB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMgaXMgYWxyZWFkeSB0aGVyZSBhbmQgSSBh bSBqdXN0IG5vdCBhd2FyZSwgYnV0IGxvb2tpbmcgZGVlcGVyIGluZGVlZCBJIGRvIG5vdCBzZWUg dGhpcyBtYXJraW5nIG5laXRoZXIgaW4gSVNJUyBub3IgT1NQRiBmb3IgcHJlZml4IFNJRHMuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklzIHRoZXJlIHNvbWUgd29yayBpbiBwcm9ncmVzcyB0byBhZGQgaXQgdG8gdGhvc2UgcHJvdG9j b2xzIG9yIGhhdmUgd2UganVzdCBkb2N1bWVudGVkIG5lZWQmbmJzcDtmb3IgYSBzaG9ydCBMU1Ig ZHJhZnQmbmJzcDsgPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaHgsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgQXVnIDE0LCAyMDIwIGF0IDY6MTcgUE0gS2V0YW4g VGFsYXVsaWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudEBjaXNjby5jb20i PmtldGFudEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgUm9iZXJ0LDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+UGxlYXNlIGNoZWNrIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBSb2JlcnQg UmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2Js YW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXVn dXN0IDIwMjAgMjE6MTM8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkg Jmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0 YW50QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVp biAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tIiB0YXJn ZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208L2E+Jmd0OzsgSm9lbCBN LiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OzsgU2hyYWRkaGEgSGVnZGUgJmx0 OzxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnNo cmFkZGhhQGp1bmlwZXIubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86RVhULUFuZHJldy5B bHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5FWFQtQW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3RvbkBsaXF1aWR0 ZWxlY29tLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgS2V0YW4sPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpbGUgSSBjb21w bGV0ZWx5IGFncmVlIHdpdGggeW91ciBub3RlIHRoZSBjb25zZXF1ZW5jZXMgb2YgaXQgYXJlIHBy ZXR0eSBzZXZyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PGk+W0tUXSBJIHVuZGVyc3RhbmQuIFdlIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiBpbXBsaWNh dGlvbnMgb2YgcHJvdGVjdGlvbiBzY2hlbWVzIGZvciB0aGUgU0xBcy9pbnRlbnQgb2YgU1IgUG9s aWNpZXMuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlVubGVzcyB3ZSBzaWduYWwgd2hpY2ggcHJlZml4IFNJRCBpcyBwcm90 ZWN0aW9uIGVsaWdpYmxlIGFuZCB3aGljaCBpcyBub3QgaG93IHdvdWxkIG90aGVyIG5vZGVzIGtu b3cgaWYgdGhleSBjYW4gcHJvdGVjdCBpdCBvciBub3QgPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5bS1RdIENvcnJlY3QuIFRvIGJlIG1vcmUgYWNj dXJhdGUsIHdlIG5lZWQgdG8gY29uc2lkZXIgdGhpcyBtb3JlIGluIHRoZSBjb250ZXh0IG9mIFNM QSBvciDigJxpbnRlbnTigJ0gb2YgU1IgUG9saWNpZXMgYW5kIHdoaWNoIHNlZ21lbnRzIG1heSBi ZSDigJxieXBhc3MtYWJsZeKAnSBmb3IgbG9jYWwgcHJvdGVjdGlvbg0KIGZvciBzb21lIG9mIHRo b3NlIFNSIFBvbGljaWVzLiBXZSBhbHNvIGhhdmUgcGF0aC1wcm90ZWN0aW9uIG1lY2hhbmlzbXMu PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkl0IHNlZW1zIHRoYXQgdG9kYXkncyBzYWZlIHRoaW5nIGlzIG5vdCB0byBhcHBs eSBhbnkgbm9kZSBwcm90ZWN0aW9uIG9uIFNSIGZsb3dzIGF0IHRoZSBQTFJzIHRoZW4uJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BbmQgbGluayBwcm90ZWN0aW9uIE1VU1QgYXNzdXJlIHRoYXQgcGFja2V0cyB3aWxsIGFycml2 ZSBhdCB0aGUgbmVpZ2hib3Igbm9kZSB2aWEgc29tZSBvdGhlciBsaW5rIHJlZ2FyZGxlc3Mgb2Yg ZnVydGhlciBwYXRoIHRvd2FyZHMgZGVzdGluYXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPltLVF0gWWVzLiBXZSBoYXZlIGEgbWVjaGFuaXNt IHRvIGluZGljYXRlIHdoaWNoIGFkai1TSURzIGhhdmUgcHJvdGVjdGlvbiAodGhhdCBtZWNoYW5p c20gb25seSBwcm92aWRlcyBsaW5rIHByb3RlY3Rpb24gdG8gZ2V0IHRvIHRoZSBuZWlnaGJvciBu b2RlKSBzbyB0aGUgU1IgUG9saWN5IGNvbXB1dGF0aW9uDQogaXMgYWJsZSB0byBpbmRpY2F0ZSB3 aGV0aGVyIHRoYXQgc3BlY2lmaWMgbGluayBpcyDigJxieXBhc3MtYWJsZeKAnSBvciBub3QgYnkg aXRzIGNob2ljZSBvZiBwcm90ZWN0ZWQgb3IgdW5wcm90ZWN0ZWQgYWRqLVNJRHMgcmVzcGVjdGl2 ZWx5LjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxp PiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPlRoYW5rcyw8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48aT5LZXRhbjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JcyBpdCBjb3JyZWN0ID8mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoeDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmks IEF1ZyAxNCwgMjAyMCBhdCA1OjMyIFBNIEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0Ozxh IGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50QGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSBTYXNoYSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBzZXJ2aWNlIG5vZGUgYWR2ZXJ0aXNlcyBpdHMgb3duIFByZWZpeCBTSUQuIFRoZSBzZXJ2 aWNlIGZ1bmN0aW9uIHRoYXQgdGhpcyBzZXJ2aWNlIG5vZGUgaW1wbGVtZW50cyBkb2VzIG5vdCBy ZXF1aXJlIGFueSBjb250ZXh0IChpLmUuIGFsbCBwYWNrZXRzIGFycml2aW5nIGF0IHRoZSBub2Rl IGFyZSBzdWJqZWN0ZWQNCiB0byB0aGF0IHNlcnZpY2UpLiBUaGVyZWZvcmUgdGhlIHNlcnZpY2Ug bm9kZSBkb2VzIG5vdCBuZWVkIHRvIHJlY2VpdmUgYSBwYWNrZXQgd2l0aCBpdOKAmXMgb3duIFBy ZWZpeCBTSUQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRodXMsIHdlIGNhbm5vdCBh c3N1bWUgdGhhdCB3aGVuIFBIUCBpcyB1c2VkLCB0aGVuIHRoZSBTSUQgaXMgb25seSBhc3NvY2lh dGVkIHdpdGggYSB0b3BvbG9naWNhbCBpbnN0cnVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkhvcGUgdGhhdCBjbGFyaWZpZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPktldGFuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+RnJvbTo8L2I+IEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDs8YSBocmVmPSJtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFp bnNodGVpbkByYmJuLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXVndXN0IDIw MjAgMjA6MjQ8YnI+DQo8Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0Ozxh IGhyZWY9Im1haWx0bzprZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50QGNp c2NvLmNvbTwvYT4mZ3Q7OyBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4m Z3Q7OyBTaHJhZGRoYSBIZWdkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIu bmV0IiB0YXJnZXQ9Il9ibGFuayI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+Jmd0OzsNCjxhIGhy ZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5r Ij5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBSYXN6dWsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJv YmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWlu aW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPktldGFu LCBhbmQgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzti YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5JIGhhdmUgc3Rh dGVkIHRoYXQsIElNSE8gYW5kIEZXSVcsIGJvdGggQWRqLVNJRHMgYW5kIFByZWZpeCBTSURzIHRo YXQgYXJlIGFkdmVydGlzZWQgd2l0aCBQSFAgY2FuJm5ic3A7IE9OTFkgcmVwcmVzZW50IHRvcG9s b2dpY2FsIGluc3RydWN0aW9ucyBpbiBTUi1NUExTIC0gYmVjYXVzZSB0aGUgYWR2ZXJ0aXNpbmcg bm9kZSB3aWxsIG5vdCByZWNlaXZlIHRoZW0gYW5kIHRoZXJlZm9yZSBjYW4gaGFyZGx5IGJlDQog ZXhwZWN0ZWQgdG8gYXNzb2NpYXRlIGFueSBzZXJ2aWNlIGZ1bmN0aW9uIHdpdGggdGhlbS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMyMTIxMjEiPlRoaXMgaXMgY29tcGxlbWVudGFyeSB0byB3aGF0IHlvdSBoYXZl IHNhaWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5Ib3BlIHRoaXMgY2xhcmlmaWVzIG15IHBvc2l0 aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5XaGF0LCBpZiBhbnl0aGlu ZywgZGlkIEkgbWlzcz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPlNhc2hhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp diBpZD0iZ21haWwtbV8tMTY5OTUyMjQxOTU0NjMwMDY0M2dtYWlsLW1fLTU3NTYwNjU0NTU4NDMy NTA5MG1zLW91dGxvb2stbW9iaWxlLXNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5HZXQNCjxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zM0dpN3pw dER5UnBSa3g0UmNEcGJVQzZIMj91PWh0dHBzJTNBJTJGJTJGYWthLm1zJTJGZ2hlaTM2IiB0YXJn ZXQ9Il9ibGFuayI+DQpPdXRsb29rIGZvciBBbmRyb2lkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+ DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYg aWQ9ImdtYWlsLW1fLTE2OTk1MjI0MTk1NDYzMDA2NDNnbWFpbC1tXy01NzU2MDY1NDU1ODQzMjUw OTBkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L3N0cm9uZz4gS2V0YW4gVGFsYXVsaWthciAoa2V0YW50KSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmtldGFudEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5rZXRhbnRAY2lzY28uY29tPC9h PiZndDs8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiBGcmlkYXksIEF1Z3VzdCAx NCwgMjAyMCwgMTY6MjM8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvOjwvc3Bhbj48L3N0cm9uZz4gQWxleGFuZGVy IFZhaW5zaHRlaW47IEpvZWwgTS4gSGFscGVybjsgU2hyYWRkaGEgSGVnZGU7DQo8YSBocmVmPSJt YWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5r Ij5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT47IFJvYmVydCBSYXN6dWs8 YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkNjOjwvc3Bhbj48L3N0cm9uZz4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+IFJFOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlv biAtIGRldGVybWluaW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIy IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Tk9USUNFOiBUaGlzIGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNl bmRlcjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBh bGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIFNhc2hhLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhlIHNlcnZpY2UgZG9lcyBub3QgbmVlZCBhbnkg YWRkaXRpb25hbCBjb250ZXh0IChlLmcuIGEgZmlyZXdhbGwgdGhhdCBqdXN0IGFwcGxpZXMgbG9j YWxseSBjb25maWd1cmVkIGRlZmF1bHQgcnVsZXMgb24gaXQpLCB0aGVuIEkgZG9u4oCZdCBzZWUg d2h5IFBIUCBjb3VsZCBub3QgYmUgZG9uZSBmb3IgYQ0KIFByZWZpeCBTSUQgYXNzb2NpYXRlZCB3 aXRoIGEgc2VydmljZSBub2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgSSBk aWRu4oCZdCBmb2xsb3cgdGhlIHBvaW50IHRoYXQgeW91IHdlcmUgdHJ5aW5nIHRvIG1ha2UgYWJv dXQgQWRqLVNJRHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPktldGFuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IEFs ZXhhbmRlciBWYWluc2h0ZWluICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AcmJibi5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkByYmJuLmNv bTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTQgQXVndXN0IDIwMjAgMTg6MjQ8YnI+DQo8 Yj5Ubzo8L2I+IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzpr ZXRhbnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V0YW50QGNpc2NvLmNvbTwvYT4mZ3Q7 OyBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t IiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7OyBBbGV4YW5kZXIg VmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4u Y29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AcmJibi5jb208L2E+Jmd0 OzsNCiBTaHJhZGRoYSBIZWdkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIu bmV0IiB0YXJnZXQ9Il9ibGFuayI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+Jmd0OzsNCjxhIGhy ZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5r Ij5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBSYXN6dWsg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJv YmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWlu aW5nIGFwcGxpY2FiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPkhpIGFs bCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+UmVnYXJkaW5nIHRoZSBzdGF0 ZW1lbnQgJnF1b3Q7UHJlZml4IFNJRCBjb3VsZCBiZSBqdXN0IGEgdG9wb2xvZ2ljYWwgaW5zdHJ1 Y3Rpb24gb3IgbWF5IGFsc28gYmUgdXNlZCB0byBzdGVlciB0aGUgZmxvdyB0byBhIG5vZGUgd2hp Y2ggaXMgYXBwbHlpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGl0JnF1b3Q7Ojwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IzIxMjEyMSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPkkg dGhpbmsgdGhhdCBpbiBTUi1NUExTIGEgTm9kZSBTSUQgdGhhdCBpcyBhZHZlcnRpc2VkIHdpdGgg UEhQIGFjaXRvbiBjYW4gYmUgc2FmZWx5IGNvbnNpZGVyZWQgYXMgJnF1b3Q7anVzdCBhIHRvcG9s b2dpY2FsIGluc3RydWN0aW9uJnF1b3Q7IGJ5IHRoZSBQTFIgYmVjYXVzZSB0aGUgb3JpZ2luYXRp bmcgbm9kZSB3aWxsIG5vdCByZWNlaXZlIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj MjEyMTIxIj5UaGUgc2FtZSBhcHBsaWVzIHRvIEFkai1TRElzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEy MSI+TXkgMmMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0iZ21haWwtbV8tMTY5OTUy MjQxOTU0NjMwMDY0M2dtYWlsLW1fLTU3NTYwNjU0NTU4NDMyNTA5MG1zLW91dGxvb2stbW9iaWxl LXNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HZXQNCjxhIGhyZWY9Imh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNzVjNVlZQmVFYmFFWndVY0hwQ1kxbTZIMj91 PWh0dHBzJTNBJTJGJTJGYWthLm1zJTJGZ2hlaTM2IiB0YXJnZXQ9Il9ibGFuayI+DQpPdXRsb29r IGZvciBBbmRyb2lkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9 Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fLTE2OTk1MjI0 MTk1NDYzMDA2NDNnbWFpbC1tXy01NzU2MDY1NDU1ODQzMjUwOTBkaXZScGx5RndkTXNnIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L3N0cm9uZz4gc3ByaW5n ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZg0KIG9mIEtldGFu IFRhbGF1bGlrYXIgKGtldGFudCkgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnQ9NDBjaXNjby5j b21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5rZXRhbnQ9NDBjaXNjby5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDo8L3NwYW4+PC9zdHJvbmc+IEZy aWRheSwgQXVndXN0IDE0LCAyMDIwLCAxNTowMDxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG86PC9zcGFuPjwvc3Ry b25nPiBKb2VsIE0uIEhhbHBlcm47IEFsZXhhbmRlciBWYWluc2h0ZWluOyBTaHJhZGRoYSBIZWdk ZTsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPjsg Um9iZXJ0IFJhc3p1azxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2M6PC9zcGFuPjwvc3Ryb25nPiA8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzcHJpbmdAaWV0Zi5vcmc8 L2E+PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0Ojwvc3Bhbj48L3N0cm9uZz4gUmU6IFtzcHJpbmddIFNw cmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJtaW5pbmcgYXBwbGljYWJpbGl0eTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQWxsLDxicj4NCjxicj4NCkkgd291bGQgbGlrZSB0 byBzaGFyZSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSBvbiB0aGlzLjxicj4NCjxicj4NCkZpcnN0 LCB0aGFua3MgdG8gSm9lbCBmb3IgYnJpbmdpbmcgdXAgdGhlIGRpc2N1c3Npb24uIENsZWFybHkg d2UgbmVlZCBhIHdlbGwtZGVmaW5lZCBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBmb3IgZGV0ZXJt aW5pbmcgYXBwbGljYWJpbGl0eSBvZiBwcm90ZWN0aW9uIGZvciBzZWdtZW50IHVzZWQgaW4gYW4g U1IgUG9saWN5LiBTb21lIG9mIHRoaXMgaXMgY2FwdHVyZWQgaW4gWzFdLjxicj4NCjxicj4NClRo aXMgaXMgYWJvdXQgbG9jYWwgcmVwYWlyIGF0IGEgUExSLiBCeSBpdCdzIHZlcnkgbmF0dXJlLCB0 aGUgUExSIGRvZXMgbm90IGhhdmUgYSBub3Rpb24gb2YgaG93ICZxdW90O3N0cmljdCBvciBub3Qm cXVvdDsgaXMgdGhlIFNMQSB0aGF0IGlzIGJlaW5nIHByb3ZpZGVkIGJ5IHRoZSBTUiBQb2xpY3ku IEF3YXJlbmVzcyBvZiB0aGF0IG5vdGlvbiBleGlzdHMgYXQgdGhlIFNSIFBvbGljeSBoZWFkZW5k IGFuZC9vciBjb21wdXRhdGlvbi1ub2RlLjxicj4NCjxicj4NCldlIGhhdmUgcHJvdGVjdGVkIGFu ZCB1bi1wcm90ZWN0ZWQgdmFyaWFudHMgb2YgYWRqYWNlbmN5IFNJRHMgdG8gZW5hYmxlIHRoZSBj b21wdXRhdGlvbiB0byBwaWNrIG9yIHRoZSBvdGhlciBiYXNlZCBvbiB0aGUgJnF1b3Q7c3RyaWN0 bmVzcyZxdW90OyBvZiB0aGUgU0xBIHJlcXVpcmVtZW50IGZvciBwaWNraW5nIHRoYXQgbGluay4g V2UgZG8gbm90IGhhdmUgc3VjaCBhIG5vdGlvbiBmb3IgUHJlZml4IFNJRHMuIE9uZSBjYW4gc2F5 IHRoYXQgd2UgY291bGQgaW50cm9kdWNlDQogc2lnbmFsbGluZyAoZS5nLiBhIEIgZmxhZykgdG8g aW5kaWNhdGUgd2hldGhlciBhIFByZWZpeCBTSUQgY2FuIGJlIGJ5cGFzc2VkIG9yIG5vdC4gVGhp cyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHRoZSBjb21wdXRhdGlvbiB0byB1c2Ugb25l IG9yIHRoZSBvdGhlciBmbGF2b3IgZGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgdGhlIFNMQSBm b3IgdGhlIFNSIFBvbGljeS48YnI+DQo8YnI+DQpJIGhhdmUgYSBwcm9ibGVtIGFuZCBhIGNvbmNl cm4gaW4gdGhlIGFzc3VtcHRpb24gdGhhdCBQTFJzIGNhbiBhc3N1bWUgdGhhdCB0aGUgY3VycmVu dGx5IGRlZmluZWQgdmFyaWFudCBvZiBQcmVmaXggU0lEcyBpbiBSRkM4NDAyIChhbmQgSUdQIHNw ZWNzKSBhcmUgJnF1b3Q7YnlwYXNzLWFibGUmcXVvdDsuPGJyPg0KPGJyPg0KQXMgSm9lbCBhbmQg b3RoZXJzIGhhdmUgYnJvdWdodCBvdXQsIHRoZSBQcmVmaXggU0lEIGNvdWxkIGJlIGp1c3QgYSB0 b3BvbG9naWNhbCBpbnN0cnVjdGlvbiBvciBtYXkgYWxzbyBiZSB1c2VkIHRvIHN0ZWVyIHRoZSBm bG93IHRvIGEgbm9kZSB3aGljaCBpcyBhcHBseWluZyBhIHNlcnZpY2UgZnVuY3Rpb24gdG8gaXQu IEluIG9yZGVyIHRvIHN1cHBvcnQgYSBtaXggb2YgU1IgUG9saWNpZXMgb2YgZGlmZmVyZW50IFNM QXMgKHN0cmljdCBhbmQgbm90LXN0cmljdCksDQogd2UgbmVlZCB0byBlbmFibGUgdGhlIGNob2lj ZSBvZiBTSURzIHRoYXQgaW5kaWNhdGVzIHRvIHRoZSBQTFIgd2hldGhlciB0aGV5IGFyZSAmcXVv dDtieXBhc3MtYWJsZSZxdW90OyBvciBub3QuPGJyPg0KPGJyPg0KRm9yIHRoZSBjYXNlcywgd2hl cmUgdGhlIFNSIFBvbGljeSBoYXMgYSBzcGVjaWZpYyBTTEEsIGl0IGlzIHJlcXVpcmVkIGZvciBu b2RlcyB0byBkcm9wIHRoZSBwYWNrZXRzIG1lYW50IGZvciB0aGUgJnF1b3Q7YWN0aXZlIHNlZ21l bnQmcXVvdDsgdGhhbiB0byBieXBhc3MgaXQuIFdoZW4gdGhpcyBtZWNoYW5pc20gaXMgdXNlZCBh bG9uZyBzaWRlIFNSVEUgcGF0aCBtb25pdG9yaW5nIG1lY2hhbmlzbXMsIGl0IGVuYWJsZXMgdGhl IGhlYWRlbmQgdG8gZGV0ZWN0IHRoZQ0KIGZhaWx1cmUgYW5kIGZhbGxiYWNrIHRvIGFuIGFsdGVy bmF0ZSBwYXRoIHVzaW5nIHRoZSBwYXRoIHByb3RlY3Rpb24gYXBwcm9hY2guIFRoaXMgaXMgc29t ZXRoaW5nIHRoYXQgaXMgZGVzY3JpYmVkIGFuZCBpbiB1c2UgaW4gZGVwbG95bWVudHMgdG9kYXkg WzFdLi48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2V0YW48YnI+DQo8YnI+DQpbMV0gPGEgaHJl Zj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNZM2ZXdU5GWUNqTUpVaWlBaVd3VW1z NkgyP3U9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTA4JTIzc2VjdGlvbi05IiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1kzZld1TkZZQ2pNSlVpaUFpV3dV bXM2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYt c3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTk8L2E+PGJyPg0KWzJd IDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmZDTXJnbUVld0M0YTRB SlJybW43SDZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0wOCUyM3NlY3Rpb24tOS4zIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzZmQ01yZ21FZXdD NGE0QUpScm1uN0g2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRy YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMDglMjNzZWN0aW9uLTkuMzwv YT48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHNwcmlu ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhhbGYgT2YgSm9lbCBN LiBIYWxwZXJuPGJyPg0KU2VudDogMDQgQXVndXN0IDIwMjAgMjA6MjU8YnI+DQpUbzogQWxleGFu ZGVyIFZhaW5zaHRlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBy YmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQHJiYm4uY29tPC9h PiZndDs7IFNocmFkZGhhIEhlZ2RlICZsdDs8YSBocmVmPSJtYWlsdG86c2hyYWRkaGE9NDBqdW5p cGVyLm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNocmFkZGhhPTQwanVuaXBl ci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpFWFQtQW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkVYVC1BbmRyZXcuQWxz dG9uQGxpcXVpZHRlbGVjb20uY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVp ZHRlbGVjb20uY29tPC9hPiZndDs7IFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpy b2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZn dDs8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4u Y29tPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24g LSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KPGJyPg0KVGhlcmUgYXJlLCBhcyBmYXIg YXMgSSBjYW4gdGVsbCwgYSBudW1iZXIgb2Ygd2F5cyB0byBhZGRyZXNzIHRoaXMgZmFtaWx5IG9m IHJlbGF0ZWQgcXVlc3Rpb25zLjxicj4NCldoYXQgc3RydWNrIG1lLCBhbmQgcHJvbXB0ZWQgdGhl IHN0YXJ0aW5nIHF1ZXN0aW9uLCB3YXMgdGhhdCBub25lIG9mIHRoZW0gd2VyZSBzcGVsbGVkIG91 dC4mbmJzcDsgSSBzZWUgbG90cyBvZiBpbnRlcmVzdGluZyBpZGVhcyAvIHByb3Bvc2Fscy48YnI+ DQpTb21lIG9mIHRoZW0gYXJlIGNvbXBhdGlibGUgd2l0aCBvdGhlcnMuJm5ic3A7Jm5ic3A7IFNv bWUgYXJlIG5vdC48YnI+DQpJdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxkIHJlYWNoIGFncmVl bWVudCBvbiBob3cgd2UgdGhvdWdodCBpdCBzaG91bGQgYmUgaGFuZGxlZC48YnI+DQo8YnI+DQpU aGFuayB5b3UsPGJyPg0KSm9lbDxicj4NCjxicj4NCk9uIDgvNC8yMDIwIDM6NTQgQU0sIEFsZXhh bmRlciBWYWluc2h0ZWluIHdyb3RlOjxicj4NCiZndDsgSGkgYWxsLDxicj4NCiZndDsgPGJyPg0K Jmd0OyBJIGFtIHN0aWxsIG5vdCBzdXJlIHRoYXQgdGhlIHByb2JsZW0gb2YgYnlwYXNzIGdvaW5n IHRocnUgdW5kZXNpcmFibGUgPGJyPg0KJmd0OyBsaW5rcy9ub2RlcyBleGlzdHMgaW4gdGhlIGNh c2Ugb2YgdG9wb2xvZ2ljYWwgU0lEcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgQUZBSUssIEZhY2ls aXR5IFByb3RlY3Rpb24gaW4gUlNWUC1URSBGUlIgKFJGQyA0MDkwPGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNROTJrbkU5WEp1anJmOEJrN29K dnM2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzQwOTAiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1E5MmtuRTlYSnVq cmY4Qms3b0p2czZIMj91PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGcmZj NDA5MDwvYT4mZ3Q7KSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkNCiBkZXBsb3llZCA8YnI+DQomZ3Q7 IGZvciBtYW55IHllYXJzIGJlZm9yZSBTUi1NUExTIGhhcyBiZWVuIGludHJvZHVjZWQuIFdoYXTi gJlzIG1vcmUsIDxicj4NCiZndDsgc2lnbmFsaW5nIG9mIGJ5cGFzcyB0dW5uZWxzIGhlIFBMUiB1 c3VhbGx5IGRpZCBub3QgaW5jbHVkZSBhbnkgb2YgdGhlIDxicj4NCiZndDsgY29uc3RyYWludHMg dXNlZCBmb3IgY29tcHV0aW5nIG9mIGFueSBzcGVjaWZpYyBMU1AgdGhhdCB0aGUgYnlwYXNzIExT UCA8YnI+DQomZ3Q7IHdvdWxkIHByb3RlY3Qg4oCTIGJlY2F1c2UgaW4gdGhlIEZhY2lsaXR5IFBy b3RlY3Rpb24gbW9kZSB0aGUgc2FtZSA8YnI+DQomZ3Q7IGJ5cGFzcyBMU1Agd291bGQgYmUgdXNl ZCB0byBwcm90ZWN0IG11bHRpcGxlIExTUHMgcGFzc2luZyB0aHJ1IHRoZSA8YnI+DQomZ3Q7IGZh aWxlZCBsaW5rL25vZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7IEZyb20gbXkgUE9WIHRo ZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIGJlaGF2aW9yIGFuZCB0aGF0IDxicj4NCiZn dDsgaW50cm9kdWNlZCBieSB0aGUg4oCcYnlwYXNzaW5n4oCdIGRyYWZ0cyBpbiBTUiBpcyB0aGF0 LCBpbiB0aGUgY2FzZSBvZiA8YnI+DQomZ3Q7IFJTVlAtVEUsIHRoZSBvcGVyYXRvciB3b3VsZCBl eHBsaWNpdGx5IGluZGljYXRlLCBhcyBwYXJ0IG9mIExTUCA8YnI+DQomZ3Q7IHNpZ25hbGluZywg d2hldGhlciBpdCB3b3VsZCBvciB3b3VsZCBub3QgdXNlIEZSUjsgTFNQcyB0aGF0IHdvdWxkIG5v dCA8YnI+DQomZ3Q7IHVzZSBGUlIgd291bGQgdGhlbiBkcm9wIHRyYWZmaWMgcmF0aGVyIHRoYW4g ZGVsaXZlcmluZyBpdCB0aGUgd3Jvbmcgd2F5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBTdWNoIGFu IG9wdGlvbiBpbmRlZWQgZG9lcyBub3QgZXhpc3QgaW4gU1ItVEUgdG9kYXksIGJ1dCB3b3VsZCBi ZSBlYXN5IDxicj4NCiZndDsgdG8gcHJvdmlkZSBpZiBzbyBkZXNpcmVkIElNSE8uPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IERpZCBJIG1pc3Mgc29tZXRoaW5nIHN1YnN0YW50aWFsPzxicj4NCiZndDsg PGJyPg0KJmd0OyBSZWdhcmRzLCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2YW5jZSw8YnI+DQom Z3Q7IDxicj4NCiZndDsgU2FzaGE8YnI+DQomZ3Q7IDxicj4NCiZndDsgT2ZmaWNlOiAmIzQzOzk3 Mi0zOTI2NjMwMjxicj4NCiZndDsgPGJyPg0KJmd0OyBDZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOzk3Mi01NDkyNjYzMDI8YnI+DQomZ3Q7IDxicj4NCiZndDsgRW1haWw6 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9h Pjxicj4NCiZndDsgPGJyPg0KJmd0OyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Jmd0OyAqT24gQmVoYWxmIE9mICpTaHJhZGRoYSBIZWdkZTxicj4NCiZndDsg KlNlbnQ6KiBUdWVzZGF5LCBBdWd1c3QgNCwgMjAyMCA5OjQxIEFNPGJyPg0KJmd0OyAqVG86KiA8 YSBocmVmPSJtYWlsdG86RVhULUFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdl dD0iX2JsYW5rIj5FWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT48YnI+DQom Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0Ozsg Um9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJn ZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgKkNjOiogPGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRm Lm9yZzwvYT47IEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+ DQomZ3Q7ICpTdWJqZWN0OiogUmU6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJt aW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgPGJyPg0KJmd0OyBBbGwsPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFRoaXMgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIHRoYW5r cyB0byBKb2VsIGZvciBzdGFydGluZyA8YnI+DQomZ3Q7IHRoaXMgZGlzY3Vzc2lvbi4gSU1PLCB3 aGVuIHRoZXJlIGFyZSBzdHJpY3QgcmVxdWlyZW1lbnRzIG9mIGF2b2lkaW5nIDxicj4NCiZndDsg Y2VydGFpbiBub2Rlcy9saW5rcyBpdCBjYW4gYmUgcmVhbGl6ZWQmbmJzcDsgZWl0aGVyIGJ5IGRl ZmluaW5nIGEgZmxleC1hbGdvIDxicj4NCiZndDsgYXZvaWRpbmcgdGhvc2U8YnI+DQomZ3Q7IDxi cj4NCiZndDsgTm9kZXMgYW5kIGxpbmtzIG9yIGJ5IHVzaW5nIGEgc3RhY2sgb2YgdW5wcm90ZWN0 ZWQgYWRqLXNpZHMgdGhhdCBhdm9pZCA8YnI+DQomZ3Q7IHJlc3RyaWN0ZWQgbm9kZXMgYW5kIGxp bmtzLiBXaGVuIGEgc3RhY2sgb2YgYWRqLXNpZHMgaXMgdXNlZCB0byA8YnI+DQomZ3Q7IHJlYWxp emUgdGhlIHBhdGgsIHRoZSBoZWFkLWVuZCBiYXNlZCAoc0JGRCkgcHJvdGVjdGlvbiBtZWNoYW5p c21zIGNhbiBiZSBhcHBsaWVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBOb2RlLXNpZHMvcHJl Zml4LXNpZC9hbnljYXN0LXNpZHMgYXJlIHVzZWQgdG8gYnVpbGQgdGhlIHN0YWNrLCB0aGUgPGJy Pg0KJmd0OyBmYWlsdXJlIGV2ZW50cyBtYXkgY2F1c2UgdHJhZmZpYyB0byBnbyB0aHJvdWdoIHJl c3RyaWN0ZWQgbm9kZXMgYW5kIDxicj4NCiZndDsgbGlua3MuIFRoaXMgd291bGQgaGFwcGVuIHJl Z2FyZGxlc3Mgb2Ygd2hldGhlciBhbnkga2luZCBvZiBwcm90ZWN0aW9uIDxicj4NCiZndDsgaXMg aW4gdXNlIG9yIG5vdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmdkczxicj4NCiZndDsgPGJyPg0K Jmd0OyBTaHJhZGRoYTxicj4NCiZndDsgPGJyPg0KJmd0OyBKdW5pcGVyIEJ1c2luZXNzIFVzZSBP bmx5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpGcm9tOiogc3ByaW5nICZsdDs8YSBocmVmPSJtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMjAlMGIiIHRhcmdldD0iX2JsYW5rIj5zcHJpbmct Ym91bmNlc0BpZXRmLm9yZw0KPGJyPg0KPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmctYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyAqT24gQmVoYWxmIE9mICpBbmRyZXcgQWxzdG9uPGJyPg0K Jmd0OyAqU2VudDoqIFR1ZXNkYXksIEF1Z3VzdCA0LCAyMDIwIDU6NDEgQU08YnI+DQomZ3Q7ICpU bzoqIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIg dGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJvYmVydEByYXN6dWsu bmV0PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyAqQ2M6KiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc8L2E+Jmd0OzsgSm9lbCBNLiBIYWxwZXJuDQo8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVy bi5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7PGJyPg0KJmd0 OyAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAtIGRldGVybWluaW5n IGFwcGxpY2FiaWxpdHk8YnI+DQomZ3Q7IDxicj4NCiZndDsgKltFeHRlcm5hbCBFbWFpbC4gQmUg Y2F1dGlvdXMgb2YgY29udGVudF0qPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJvYmVydCB0aGlzIGlz IGFjdHVhbGx5IGZhciBtb3JlIGRpZmZpY3VsdCB3aGVuIOKAkyBpdCBjYW4gYmUgYW4gZW50aXJl PGJyPg0KJmd0OyAobG9uZykgc2VyaWVzIG9mIG5vZGVzIHRoYXQgbmVlZCB0byBiZSBhdm9pZGVk Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBtYWRlIHRvIHdv cmsgYnV0IEnigJlkIHdvcnJ5IHRoYXQgdG8gZG8gdGhpcyDigJMgPGJyPg0KJmd0OyB5b3XigJlk IGhhdmUgdG8gc3RhY2sgMTAg4oCTIDIwIOKAkyAzMCBuZWdhdGl2ZSBsYWJlbHMg4oCTIGFuZCB0 aGF0IHdvdWxkbuKAmXQgPGJyPg0KJmd0OyBiZSB2aWFibGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEl04oCZcyBlYXNpZXIgdG8gdXNlIGFsZ29yaXRobXMgYW5kIGFkamFjZW5jeSBzaWRzIGFuZCBv dGhlciBzdWNoIHRoaW5ncyA8YnI+DQomZ3Q7IHRvIGNhbGN1bGF0ZSBwYXRocyDigJMgdGhlIGJp Z2dlc3QgdHJpY2sgaXMgYWJvdXQgdGhlIHN0YWNrIGRlcHRoLiZuYnNwOyBXaGVuIDxicj4NCiZn dDsgeW91IGhhdmUgdGhpcyBuZWVkIGZvciBub2RlIGF2b2lkYW5jZSDigJMgdGhlIG5lZWQgZm9y IDEwJiM0MzsgbGFiZWwgZGVwdGggPGJyPg0KJmd0OyBpcyBjcml0aWNhbCDigJMgdW5sZXNzIHlv dSB3YW5uYSBiZSBhcHBseWluZyBvbmUgaGVsbCBvZiBhIGxvdCBvZiA8YnI+DQomZ3Q7IGJpbmRp bmcgbGFiZWxzIGFsb25nIHRoZSB3YXkgd2hpY2ggaXMgYSBuaWdodG1hcmUuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEJ1dCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaXMgdGhpcyBhIGNvbW1vbiB1 c2UgY2FzZSDigJMgaXTigJlzIGEgdXNlIDxicj4NCiZndDsgY2FzZSB0aGF0IG1vc3Qgb2YgdGhl IHBlb3BsZSBJIGRpc2N1c3MgdGhpcyB3aXRoIGNlcnRhaW4gaGF2ZSDigJMgSSBjYW50IDxicj4N CiZndDsgY29tbWVudCBvbiBhIGdsb2JhbCBzY2FsZSwgb3IgZm9yIGFueW9uZSBlbHNlLCBidXQg ZXZlcnkgaW5kaWNhdGlvbiBJIDxicj4NCiZndDsgaGF2ZSBpcyB0aGF0IHllcyDigJMgaXRzIHNv bWV0aGluZyBwZW9wbGUgbmVlZCwgYW5kIHdhbnQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgQW5kcmV3 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICpGcm9tOiogUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5u ZXQ8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2Js YW5rIj5tYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICpTZW50 OiogVHVlc2RheSwgNCBBdWd1c3QgMjAyMCAwMToyNzxicj4NCiZndDsgKlRvOiogQW5kcmV3IEFs c3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20l MjAlMGIiIHRhcmdldD0iX2JsYW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8 YnI+DQo8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVs ZWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsgKkNjOiogSm9lbCBNLiBIYWxwZXJuICZsdDs8 YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUyMCUwYiIgdGFyZ2V0PSJfYmxhbmsi PmptaEBqb2VsaGFscGVybi5jb20NCjxicj4NCjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tPC9hPiZndDsmZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW3NwcmluZ10gU3ByaW5nIHBy b3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmlsaXR5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IElzIHRoaXMgYSBjb21tb24gdXNlIGNhc2UgaWUuJm5ic3A7ICZxdW90O2J1dCByYXRoZXIg4oCT IHdoaWNoIG5vZGVzIC8gbmV0d29yayA8YnI+DQomZ3Q7IHNlZ21lbnRzIGl0IGNhbiBuZXZlciB0 b3VjaCBvciBmbG93IHRocm91Z2guJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHNvIHBl cmhhcHMgaXRzIHRpbWUgdG8gZGVmaW5lIG5vdGlvbiBvZiAqbmVnYXRpdmUtU0lEKiBpZS4gbGlz dCBpbiA8YnI+DQomZ3Q7IHRoZSBwYWNrZXQgcmVzb3VyY2VzIHdoaWNoIGdpdmVuJm5ic3A7cGFj a2V0IE1VU1Qgbm90IGV2ZXIgdHJhdmVyc2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFB1dCBpbiB0 aGUgcGFja2V0IHNldCBvZiBub2RlcyBvciBsaW5rcyB3aGljaCB0aGUgcGFja2V0IHNob3VsZCBu ZXZlciA8YnI+DQomZ3Q7IHRyYXZlcnNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IGdvZXMg aW4gbGluZSBvZiByZWNlbnQgd2F2ZSBvZiBuZWdhdGl2ZSByb3V0aW5nIGltcGxlbWVudGF0aW9u czxicj4NCiZndDsgKFJJRlQpIG9yIGRpc2N1c3Npb25zIChMU1IpPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEJlc3QsPGJyPg0KJmd0OyBSLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIEF1ZyAz LCAyMDIwIGF0IDExOjQ2IFBNIEFuZHJldyBBbHN0b24gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20lMjAlMGIiIHRhcmdldD0iX2Js YW5rIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tDQo8YnI+DQo8L2E+Jmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb20iIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTwvYT4mZ3Q7Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU28g 4oCTPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uZSBvZiB0 aGUgdXNlIGNhc2VzLCBpbiBmYWN0LCBzb21lIHZlcnkgbWFqb3IgdXNlIGNhc2VzIGluIGFueTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3ByaW5nIHRlY2hub2xvZ3kgZm9yIHVz IHJldm9sdmUgYXJvdW5kIHRoZSBmb2xsb3dpbmc8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYS5UaGUgZXhwbGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gbm9k ZXM8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYi5UaGUgZXhw bGljaXQgYXZvaWRhbmNlIG9mIGNlcnRhaW4gc2VjdGlvbnMgb2YgdGhlIG5ldHdvcms8YnI+DQom Z3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW55dGhpbmcgdGhhdCBjb3Vs ZCByZXN1bHQgaW4gdGhhdCBleHBsaWNpdCBhdm9pZGFuY2UgYmVpbmcgdmlvbGF0ZWQ8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAkyB3b3VsZCBjcmVhdGUsIHNoYWxsIHdlIHNh eSBzaWduaWZpY2FudCBwcm9ibGVtcy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTXVjaCBvZiB0aGUgdXNlIGNhc2UgaXMgbm90IGEgY2FzZSBvZiB3aGljaCBu b2RlcyB0aGUgcGFja2V0cyBmbG93PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aHJvdWdoIOKAkyBidXQgcmF0aGVyIOKAkyB3aGljaCBub2RlcyAvIG5ldHdvcmsgc2VnbWVudHMg aXQgY2FuIG5ldmVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b3VjaCBvciBm bG93IHRocm91Z2guJm5ic3A7IEVmZmVjdGl2ZWx5LCB0byBiZSB1c2VkIGFzIGEgdGVjaG5vbG9n eSB0bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXZvaWQgY2VydGFpbiB0aGlu Z3MgZm9yIHNwZWNpZmljIHJlYXNvbnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIG5lZWRpbmcg c3VjaCBkZWVwIGxhYmVsIHN0YWNrcyDigJM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoaXMga2luZCBvZiBkZXRhaWxlZCBwYXRoIHByb2dyYW1taW5nIHRlbmRzIHRvIGRlZXBl biB0aGUgc3RhY2s8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlY2F1c2UgeW91 IHNvbWV0aW1lcyBoYXZlIHRvIGJlIHByZXR0eSBleHBsaWNpdC48YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgaXMgYWJzb2x1dGVseSBjcml0aWNhbCB0byB1 cyB0aGF0IHRoaXMgZnVuY3Rpb25hbGl0eSBpcyB0aGVyZSDigJM8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGFuZCB0aGF0IHdlIGNhbiBhdm9pZCBzaXR1YXRpb25zIHdoaWNoIGNv dWxkIGNhdXNlIHRyYWZmaWMgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFj Y2lkZW50bHkgaGl0IHRoaW5ncyBleHBsaWNpdGx5IGF2b2lkZWQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2lzaCBJIGNvdWxkIGJlIG1vcmUgc3BlY2lm aWMgdGhhbiB0aGlzLCBidXQgaXQgaXMgd2hhdCBpdCBpcy48YnI+DQomZ3Q7IDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZHJldzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAqRnJvbToqIHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsmZ3Q7ICpPbiBCZWhhbGYgT2YgKkpvZWwgTS4gSGFs cGVybjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlNlbnQ6KiBNb25kYXksIDMg QXVndXN0IDIwMjAgMjE6MzY8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpUbzoq IFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFy Z2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv YmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnJvYmVydEByYXN6dWsubmV0 PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqQ2M6KiA8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRm Li5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAqU3ViamVjdDoqIFJlOiBbc3ByaW5nXSBTcHJpbmcgcHJvdGVjdGlvbiAt IGRldGVybWluaW5nIDxicj4NCiZndDsgYXBwbGljYWJpbGl0eTxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoU2luY2UgdGhlIHRocmVhZCBoYXMgZ290dGVuIGxv bmcgZW5vdWdoLCByZWl0ZXJhdGluZyB0aGF0IHRoaXMgaXMgYXMgYTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcGFydGljaXBhbnQsIG5vdCBhIFdHIGNoYWlyLik8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWVzLCB3ZSBhcmUgdGFsa2luZyBJ UCBuZXR3b3Jrcy4gQW5kIHllcywgSSBoYXZlIHNlZW4gSVAgbmV0d29ya3MgdGhhdDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hvb3NlIHRvIGRyb3AgcGFja2V0cy4gRm9yIGFs bCBzb3J0cyBvZiByZWFzb25zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0 aGluayB0aGVyZSBhcmUgbGlrZWx5IG90aGVyIHJlYXNvbnMgd2h5IG9uZSBtYXkgbm90IHdhbnQg YSByYW5kb208YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGggcmF0aGVyIHRo YW4gYSBjaG9zZW4gVEUgcGF0aC4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgd2UgYmUgY2xlYXI8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFib3V0IHdoYXQgY29uc3RyYWludHMg bWF5IGJlIC8gYXJlIHZpb2xhdGVkIHdoZW4gd2UgdGVsbCBwZW9wbGUgdGhleTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGF2ZSB0aGlzIHRvb2wgKHByb3RlY3RpdmUgcmVyb3V0 aW5nKSB0aGF0IGlzIGludGVuZGVkIHRvIHByZXNlcnZlIFFvUy48YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGV0J3MgYmUgY2xlYXIuIEkgYW0gbm90IGFyZ3Vp bmcgdGhhdCB0aGlzIGlzIG5vdCBhIGdvb2QgaWRlYS4gSXQgaXMgYTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZ29vZCBpZGVhLiBBbmQgdXNlZnVsLiBJIGFtIHRyeWluZyB0byBm aWd1cmUgb3R1IHdoYXQgY29tYmluYXRpb24gb2Y8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBhbmQgY2xlYXIgZGVzY3JpcHRpb25zIHdpbGwg bGVhZCB0byBldmVyeW9uZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ2V0dGlu ZyB0aGUgYmVoYXZpb3IgdGhleSBleHBlY3QgKHdoaWNoIG1heSBub3QgYmUgdGhlIGJlaGF2aW9y IHRoZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2lyZSwgYnV0IHNvbWV0 aW1lcyBpcyB0aGUgYmVzdCB3ZSBjYW4gZG8uKTxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBZb3Vycyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEpvZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gOC8z LzIwMjAgMjozMCBQTSwgUm9iZXJ0IFJhc3p1ayB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSm9lbCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgQXJlIHdlIHN0aWxsIHRhbGtpbmcgYWJvdXQgSVAgbmV0d29ya3MmbmJzcDtoZXJlID8g T3IgcGVyaGFwcyBzb21lIGhhcmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgc2xpY2luZyB3aXRoIHJlYWwgcmVzb3VyY2UgcmVzZXJ2YXRpb25zIG9yIGRldG5l dHMgPzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBCZWNhdXNlJm5ic3A7aWYgd2Ug YXJlIHRhbGtpbmcmbmJzcDthYm91dCBJUCBuZXR3b3JraW5nIEkgaGF2ZSB0d288YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9ic2VydmF0aW9uczo8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgQSkgSWYgeW91IG5lZWQgdG8gdHJhdmVyc2UgdmlhIGEgc3BlY2lmaWMg bm9kZSAoaWUuIGZpcmV3YWxsKSB5b3U8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGJldHRlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhcHBs eSBJUCBlbmNhcHN1bGF0aW9uIHRvIHRoYXQgbm9kZS4uIEkgZG9uJ3QgdGhpbmsgSVA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuY2Fwc3VsYXRpb24mbmJzcDtjYW48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYmUgaGlqYWNrZWQgdG9kYXkg c3VjaCB0aGF0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBpczxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWdub3JlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgQikgSGF2ZSB5b3Ugc2VlbiBhbnkgSVAgbmV0d29yayB3aGVyZSB1cG9uIHRvcG9s b2d5IGNoYW5nZSAobGluazxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3Igbm9k ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBmYWlsdXJlKSB5 b3Ugc3VkZGVubHkmbmJzcDtzdGFydCBkcm9wcGluZyZuYnNwO2Zsb3dzIGluIHNwaXRlIG9mIFNQ VCBvZmZlcmluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBw ZXJoYXBzIGZldyBtcyBsb25nZXIgcGF0aCB3aXRoIDEwIG1zIG1vcmUgaml0dGVyID88YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgT3IgYXJlIHNvbWUgU1IgbWFya2V0aW5nIHNsaWRl cyBwcm9taXNlIHRvIHR1cm4gSVAgbmV0d29ya3MgaW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgc29tZXRoaW5nJm5ic3A7bmV3ID8gV29yc2UgLi4uIGRvIHRo ZXkgbWVudGlvbiBwYXRoIHF1YWxpdHkgZ3VhcmFudGVlcyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcmVzb3VyY2UgcmVzZXJ2YXRpb25zJm5ic3A7PyBJIGhv cGUgbm90Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBUaHgsPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFIuPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IE9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgODox MCBQTSBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tJTBiIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTxicj4NCjwvYT4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSUyMCUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t JTIwJTBiPC9hPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7 IHdyb3RlOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBXZWxsIGxlc3Mgc2VyaW91 cyBmb3IgVEUgU0lEcywgSSBhbSBub3Qgc3VyZSB0aGUgcHJvYmxlbSBpczxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzdHJpY3RlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyB0byBqdXN0IHNlcnZpY2UgU0lEcy48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgU3VwcG9zZSB0aGF0IHRoZSBQQ0UgaGFzIHNwZWNpZmllZCB0aGUg cGF0aCB0byBtZWV0IHNvbWUgY29tcGxleCB0ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBvYmplY3RpdmUuJm5ic3A7IFRoZSBieXBhc3Mgbm9kZSBoYXMgbm8g d2F5IG9mIGtub3dpbmcgd2hhdCB0aG9zZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBjb25zdHJhaW50czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyB3ZXJlLiZuYnNwOyBBbmQgZm9yIHNvbWUga2luZHMgb2YgdHJhZmZpYywg aXQgaXMgYmV0dGVyIHRvIGRyb3AgdGhlIHBhY2tldDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyB0aGFuIHRvIGRlbGl2ZXIgaXQgb3V0c2lkZSB0aGUgZW52ZWxv cC4mbmJzcDsgSSBzdXNwZWN0IHRoYXQgdGhlIHJpZ2h0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFuc3dlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyB0byB0aGlzIGlzICZxdW90O3RvbyBiYWQmcXVvdDsuJm5ic3A7IElm IHNvLCBhcyB3aXRoIHRoZSBkaXN0aW5jdGlvbiByZWdhcmRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHNlcnZpY2U8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgbm9kZXMsIHdlIHNob3VsZCBzYXkgc28sIHNob3VsZG4ndCB3ZT88YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgWW91cnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgT24gOC8zLzIwMjAgMjozNiBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgTWFjaCwgSm9lbCBh bmQgYWxsLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSB0aGlu ayB0aGF0IGluIG1vc3QgY2FzZXM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyAxLlRoZXJlIGlzIGNsZWFyIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuICZxdW90O3Rv cG9sb2dpY2FsJnF1b3Q7IGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7c2VydmljZSZxdW90Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IGluc3RydWN0aW9ucyBpbiBTSUQgYWR2ZXJ0aXNlbWVudHMuIEUuZy46PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBvSUdQIFByZWZpeCBOb2RlIFNJ RHMgSUdQIEFkai1TSURzIChpZGVudGlmaWVkIGFzIHN1Y2ggaW4gdGhlPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgY29ycmVzcG9uZGluZyBJR1AgYWR2 ZXJ0aXNlbWVudHMpIHJlcHJlc2VudCB0b3BvbG9naWNhbDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaW5zdHJ1Y3Rpb25zPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyBvU2VydmljZSBTSURzIGZvciBTUnY2IChzZWUgU1J2NiBCR1AtQmFzZWQgT3Zl cmxheSBTZXJ2aWNlczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNDQ2N5OW1ZNmNNZmJrN1FmamhpQTNSNkgyP3U9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1pZXRmLWJlc3Mtc3J2 Ni1zZXJ2aWNlcy0wNCUwYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zQ0NjeTltWTZjTWZiazdRZmpoaUEzUjZIMj91PWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2Vydmlj ZXMtMDQ8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHQzVhZjJ6M0p6cGhaRGtQbmNIQVFpNkgy P3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtYmVzcy1zcnY2LXNlcnZp Y2VzLTA0X18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20w eDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzRULUwwbmwlMjQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0dDNWFmMnozSnpwaFpEa1BuY0hBUWk2 SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1iZXNzLXNydjYtc2Vy dmljZXMtMDRfXyUzQiUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhn bTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvNFQtTDBubCUyNDwvYT4mZ3Q7Jmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRyYWZ0KSB1bnN1cnByaXNpbmds eSByZXByZXNlbnQg4oCcc2VydmljZeKAnSBpbnN0cnVjdGlvbnM8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDIuU2VnbWVudHMgdGhhdCByZXByZXNlbnQgdG9wb2xv Z2ljYWwgaW5zdHJ1Y3Rpb25zIGNhbiBiZSBieXBhc3NlZCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyB3aGlsZSBzZWdtZW50cyB0aGF0IHJlcHJlc2Vu dCBzZXJ2aWNlIGluc3RydWN0aW9ucyByZXF1aXJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGFsdGVybmF0aXZlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgcHJvdGVjdGlvbiBtZWNoYW5pc21zLjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgVGhpcyB2aWV3IHNlZW1zIHRvIGJlIGFs aWduZWQgd2l0aCBSRkMgODQwMjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v MzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRnJmYzg0MDIlMGIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzQ1TkxDQjZUeWR4dXVxVWp0Y0RSWnk2SDI/dT1odHRwcyUzQSUyRiUyRnRv b2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDI8YnI+DQo8L2E+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM3 UHpVS0FEODJjalN2bVZjR3Zwa2hGNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUy RnYzJTJGX19odHRwcyUzQSUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRnJmYzg0MDJfXyUzQiUy MSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dw NnZwUkhPR3Q4QWtUUkR1aURvMEk0WWJ0bSUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zN1B6VUtBRDgyY2pTdm1WY0d2cGtoRjZIMj91PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMlM0ElMkZ0b29scy5pZXRmLm9yZyUy Rmh0bWwlMkZyZmM4NDAyX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFv aVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzBJNFlidG0lMjQ8L2E+Jmd0 OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgc2F5cyBpbiBTZWN0 aW9uIDE6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsmbmJzcDsgSW4gdGhlIGNvbnRleHQgb2YgYW4gSUdQLWJhc2VkIGRpc3RyaWJ1dGVkIGNv bnRyb2wgcGxhbmUsIHR3bzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsgdG9wb2xvZ2ljYWwgc2VnbWVudHMgYXJlIGRlZmluZWQ6IHRoZSBJR1AtQWRqYWNlbmN5IHNl Z21lbnQgYW5kIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7Jm5ic3A7IElHUC1QcmVmaXggc2VnbWVudC48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBJbiB0aGUgY29udGV4 dCBvZiBhIEJHUC1iYXNlZCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lLCB0d288YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRvcG9sb2dpY2FsIHNlZ21lbnRzIGFy ZSBkZWZpbmVkOiB0aGUgQkdQIHBlZXJpbmcgc2VnbWVudCBhbmQgdGhlPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgQkdQLVByZWZp eCBzZWdtZW50Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSW4g dGhlIGNhc2Ugb2YgU1ItTVBMUyB0aGlzIGRpZmZlcmVudGlhdGlvbiBpcyBhc3N1bWVkIGluIFNl Y3Rpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgMy40IG9m PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgdGhlIE5v ZGUgUHJvdGVjdGlvbiBmb3IgU1ItVEUgUGF0aDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKYlNXR3g1REFmTlBzWmRocEV4eHg5Nkgy P3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFm dC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rp b24tMy40JTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNKYlNXR3g1REFmTlBzWmRocEV4eHg5NkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5p ZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9u LWZvci1zci10ZS1wYXRocy0wNyUyM3NlY3Rpb24tMy40PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNv bS8zQ3JVZ0FSVzhzb21BYnc2VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5j b20lMkZ2MyUyRl9faHR0cHMlM0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwl MkZkcmFmdC1oZWdkZS1zcHJpbmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUy QXNlY3Rpb24tMy40X18lM0JJdyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9p UUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNzbiUyNCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQ3JVZ0FSVzhzb21BYnc2 VGlzamdKMTZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1oZWdkZS1zcHJp bmctbm9kZS1wcm90ZWN0aW9uLWZvci1zci10ZS1wYXRocy0wNyUyQXNlY3Rpb24tMy40X18lM0JJ dyUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pI Z3dwNnZwUkhPR3Q4QWtUUkR1aURvOXdPLVNzbiUyNDwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGRyYWZ0IHRoYXQgc2F5czo8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBUaGUgbm9kZSBw cm90ZWN0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIHByZXZpb3VzPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZWN0aW9uczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGRlcGVuZHMgb24gdGhlIGFzc3Vt cHRpb24gdGhhdCB0aGUgbGFiZWwgaW1tZWRpYXRlbHkgYmVsb3c8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdGhlIHRvcDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsgbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrIGlzIHVuZGVyc3Rv b2QgaW4gdGhlIElHUCBkb21haW4uJm5ic3A7IFdoZW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgcHJvdmlkZXIgZWRnZSBy b3V0ZXJzIGV4Y2hhbmdlIHNlcnZpY2UgbGFiZWxzIHZpYSBCR1Agb3Igc29tZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBvdGhlcjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IG5vbi1JR1AgbWVj aGFuaXNtIHRoZSBib3R0b20gbGFiZWwgaXMgbm90IHVuZGVyc3Rvb2QgaW4gdGhlIElHUDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7 IGRvbWFpbi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyZuYnNwOyBUaGUgZWdyZXNzIG5vZGUgcHJvdGVjdGlvbiBtZWNoYW5pc21zIGRlc2Ny aWJlZCBpbiB0aGUgZHJhZnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBbUkZDODY3OSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFqQTNwTTZUZENFNkgyP3U9aHR0cHMlM0El MkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5JTBiIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKZnZ0QkFtYVFQTjFq QTNwTTZUZENFNkgyP3U9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUy Rmh0bWwlMkZyZmM4Njc5PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNmRNQWp1WVRRb3ZvOGpI d21tM2VKdzZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cHMl M0ElMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4Njc5X18lM0IlMjEl MjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2 cFJIT0d0OEFrVFJEdWlEbzhNR2lwWGMlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vMzZkTUFqdVlUUW92bzhqSHdtbTNlSnc2SDI/dT1odHRwcyUzQSUy RiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGZGF0YXRyYWNrZXIuaWV0Zi5v cmclMkZkb2MlMkZodG1sJTJGcmZjODY3OV9fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5 RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG84TUdpcFhj JTI0PC9hPiZndDsmZ3Q7XTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXM8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBhcHBsaWNhYmxl IHRvIHRoaXMgdXNlIGNhc2UgYW5kIG5vIGFkZGl0aW9uYWwgY2hhbmdlczxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHdpbGwgYmUg cmVxdWlyZWQgZm9yIFNSIGJhc2VkIG5ldHdvcmtzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyBUaGUgc2NlbmFyaW9zIGluIHdoaWNoICZuYnNwO2RpZmZlcmVudGlh dGlvbiBiZXR3ZWVuIOKAnHRvcG9sb2dpY2Fs4oCdIGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IOKAnHNlcnZpY2XigJ0gaW5zdHJ1Y3Rpb25zIGlz IGJyb2tlbiBhcmUgaW5kZWVkIHByb2JsZW1hdGljLiBFLmcuLDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjb25zaWRlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRoZSB1c2UgY2FzZSBpbiB3aGljaCBhIE5vZGUg U0lEIGluIHRoZSBFUk8gb2YgYSBTUi1URSBwYXRoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGlkZW50aWZpZXMgYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IG5vZGUgdGhhdCBhY3RzIGFzIGEgZmlyZXdhbGwgZm9y IGFsbCBwYWNrZXRzIGl0IHJlY2VpdmVzLCBpLmUuLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBwcm92aWRlczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IHRoZSBmaXJld2FsbCBzZXJ2aWNlIHdpdGhvdXQgYW55IGRl ZGljYXRlZCBzZXJ2aWNlIFNJRDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBpZGVudGlmeWluZyBpdC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyBPbmUgY291bGQgc2F5IHRoYXQgdGhlIE5vZGUgU0lEIG9mIHN1Y2gg YSBub2RlIHdvdWxkIGNvbWJpbmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgdG9wb2xvZ2ljYWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyBhbmQgc2VydmljZSBpbnN0cnVjdGlvbnMgdGh1cyBicmVha2luZyB0aGUg ZGlmZmVyZW50aWF0aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IGJldHdlZW4gdGhlIHR3by48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IEkgYW0gbm90IHN1cmUgaWYgdXNhZ2Ugb2Ygc3VjaCDigJxjb21iaW5lZOKAnSBTSURz IGNvdWxkIGJlIHByZXZlbnRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBvciBhdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IGxlYXN0IGRpc2NvdXJhZ2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgSWYgbm90LCBwcm92aWRpbmcgYW4gYWJpbGl0eSB0byBpZGVudGlmeSBzdWNo IFNJRHMgaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGFkdmVydGlzZW1lbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBtZWNoYW5pc21zIHdvdWxkIGJlIHVzZWZ1bCBJTUhPLjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgTXkgMmMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyBTYXNoYTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgT2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgQ2VsbDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0Mzs5NzItNTQ5MjY2MzAyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRl bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOkFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgRnJvbTogc3ByaW5nICZs dDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIiIHRhcmdldD0iX2Js YW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGIi IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmclMGI8L2E+Jmd0 OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgT24gQmVoYWxmIE9mIE1hY2ggQ2hlbjxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRh eSwgQXVndXN0IDMsIDIwMjAgNjozMCBBTTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7IFRvOiBKb2VsIE0uIEhhbHBlcm4gJmx0OzxhIGhyZWY9Im1haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tJTBiIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJu LmNvbTxicj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSUwYiIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tJTBiPC9hPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpv ZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t PC9hPiZndDsmZ3Q7Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBTdWJqZWN0 OiBSZTogW3NwcmluZ10gU3ByaW5nIHByb3RlY3Rpb24gLSBkZXRlcm1pbmluZyBhcHBsaWNhYmls aXR5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBIaSBKb2VsLDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgSSB0aGluayB0aGlzIGlz IGEgZ29vZCBwb2ludCB0aGF0IG1heSBub3QgYmUgZGlzY3Vzc2VkIGluIHRoZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBwYXN0LiBBbmQ8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBJIGFsc28gZG9uJ3QgdGhpbmsg dGhlcmUgaXMgYSAmcXVvdDtjYW4gYmUgYnlwYXNzZWQmcXVvdDsgaW5kaWNhdGlvbiBpbiB0aGU8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyByb3V0aW5n IGFkdmVydGlzZW1lbnQgZm9yIG5vdy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IElNSE8sIHRoZSBpbmZvcm1hdGlvbiBhZHZlcnRpc2VkIGJ5IHJvdXRpbmcgaXMg bmV1dHJhbCwgc3VjaDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBpbmZvcm1hdGlvbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7IChjYW4gb3IgY2Fubm90IGJlIGJ5cGFzc2VkKSBpcyBtb3JlIHBhdGggc3BlY2lmaWMs IHRodXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vcm1hbGx5IHRoZTxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IGNvbnRyb2xsZXIg c2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciBkZWNpZGluZyB3aGV0aGVyL3doaWNoIFNJRDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjYW4gYmU8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBieXBhc3NlZC48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IE1hY2g8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgRnJvbTogc3ByaW5nIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUy MCUzY21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUzZSIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyUwYiUzZSUyMCUzY21haWx0bzpzcHJpbmctYm91 bmNlc0BpZXRmLm9yZyUzZTwvYT4mZ3Q7XTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT24gQmVoYWxmIE9mIEpvZWwgTS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSGFscGVybjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBTZW50OiBNb25kYXksIEF1Z3VzdCAzLCAyMDIwIDc6 NTEgQU08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgVG86IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z cHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmclMGIiIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnICZsdDttYWlsdG86c3ByaW5nQGlldGYub3Jn PGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmc8 L2E+Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IFN1YmplY3Q6IFtzcHJpbmddIFNwcmluZyBwcm90ZWN0aW9uIC0gZGV0ZXJt aW5pbmcgYXBwbGljYWJpbGl0eTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0OyAoV0cgQ2hhaXIgaGF0IE9mZiwgdGhpcyBpcyBtZXJlbHkgYSBub3RlIGZy b20gYSBzbGlnaHRseTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBjb25mdXNlZCBXRzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJmd0OyBwYXJ0aWNpcGFudC4pPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmZ3Q7IEkgaGF2ZSBiZWVuIHJlYWRpbmcgdGhlIHZhcmlvdXMgcmVwYWly IGRyYWZ0cywgYW5kIHRoZSB2YXJpb3VzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IG5ldHdvcmtzIHByb2dyYW1taW5nIGFuZCBzZXJ2aWNlIHBy b2dyYW1taW5nIGRyYWZ0LCBhbmQgSSBhbTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyB0cnlpbmcgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgZmlndXJlIG91dCBvbmUgYXNwZWN0IG9mIHRoZSBjb21iaW5h dGlvbi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg SG93IGRvZXMgYSBub2RlIHRoYXQgaXMgZG9pbmcgc29tZSBmb3JtIG9mIGJ5cGFzcyAoc3VwcG9z ZSwgZm9yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAm Z3Q7IHNpbXBsaWNpdHksIGl0IGlzIE5vZGUgTjIgZGVjaWRpbmcgdG8gYnlwYXNzIHRoZSBuZXh0 IFNJRCBmb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYSBm YWlsZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgbm9kZSBOMykga25vdyB0aGF0IGl0IGlzIHNhZmUgdG8gZG8gc28/PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IElmIHRoZSBwYXRoIHdhcyBqdXN0 IGZvciBURSwgdGhlbiBpdCBpcyAmcXVvdDtzYWZlJnF1b3Q7IGlmIHRoZSBuZXcgcGF0aDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBtZWV0czxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyB0aGUgVEUgY3JpdGVy aWEuJm5ic3A7IG9yIG1heWJlIGl0IGlzIHNhZmUgaWYgaXQgaXMgZXZlbiBjbG9zZSwgYXM8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbG9uZyBhczxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBpdCBpcyBub3Qg dXNlZCBmb3IgdG9vIGxvbmcuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmZ3Q7IEJ1dCB3aGF0IGlmIHRoZSBub2RlIHdlcmUgYSBGaXJld2FsbCwgaW5jbHVk ZWQgdG8gbWVldCBsZWdhbDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7IHJlcXVpcmVtZW50cz88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgT3Igd2FzIHNvbWUgb3RoZXIgbmVjZXNzYXJ5IHByb2dyYW1t YXRpYyB0cmFuc2Zvcm0gKHdpbmNlIHdlIGFyZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0OyBkZWxpYmVyYXRlbHkgdmFndWUgYWJvdXQgd2hhdCBu b2RlcyBjYW4gZG8gd2hlbiBhc2tlZCBzdWl0YWJseS4pPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7IElzIHRoZXJlIHNvbWUgJnF1b3Q7Y2FuIGJlIGJ5 cGFzc2VkJnF1b3Q7IGluZGljYXRpb24gaW4gdGhlIHJvdXRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgYWR2ZXJ0aXNlbWVudHMgdGhhdCBJ IG1pc3NlZD88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgVGhhbmsgeW91LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgSm9lbDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJmd0 OyBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJpbmdAaWV0Zi5vcmcl MGIiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnICZsdDttYWlsdG86c3By aW5nQGlldGYub3JnPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmclMjAlM2NtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyUyMCUzY21haWx0bzpzcHJp bmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8v Y2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMj91PWh0dHBz JTNBJTI1MiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjwvYT48YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1h bnRlYy5jb20vM1E3dlgycVdTVWRXVmM4OTJYdVh5Mkg2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRl ZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUyRjM2 N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyX18lM0JKU1UlMjEl MjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2 cFJIT0d0OEFrVFJEdWlEbzZId1BMaWwlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNr dGltZS5zeW1hbnRlYy5jb20vM1E3dlgycVdTVWRXVmM4OTJYdVh5Mkg2SDI/dT1odHRwcyUzQSUy RiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVj LmNvbSUyRjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyX18l M0JKU1UlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFn dW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzZId1BMaWwlMjQ8L2E+Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVr elc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMjUyJTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0 cHMlM0ElMjUyPGJyPg0KPC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhy ZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zQTVCOEgyRm0xclBuYVozU3Vwandy NkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRmNs aWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lVa3pXOXVHQzRlQXZQNDZIMiUzRnUlM0Ro dHRwcyUyQTNBJTJBMjUyX18lM0JKU1UlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVf UjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEb3pvUWlBSGslMjQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0E1QjhIMkZtMXJQ bmFaM1N1cGp3cjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0 cHMlM0ElMkZjbGlja3RpbWUuc3ltYW50ZWMuY29tJTJGMzY3cWhVNEtpVWt6Vzl1R0M0ZUF2UDQ2 SDIlM0Z1JTNEaHR0cHMlMkEzQSUyQTI1Ml9fJTNCSlNVJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1 c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG96b1Fp QUhrJTI0PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Jmd0OyZuYnNwOyAmZ3Q7IEYlPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzMyeUNrUEtScnVSajFaZkN2S2dMMkdxNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3LmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+MkZ3d3cuaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzM5TnpubVlCdFJ1SEFSaEdKNVc1ZEdCNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNv bSUyRnYzJTJGX19odHRwJTNBJTJGMkZ3d3cuaWV0Zi5vcmdfXyUzQiUyMSUyMU5FdDZ5TWFPLWdr JTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pIZ3dwNnZwUkhPR3Q4QWtUUkR1 aURvLXBQQ2p2UiUyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVj LmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5z ZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYub3JnX18lM0IlMjElMjFORXQ2eU1h Ty1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFr VFJEdWlEby1wUENqdlIlMjQ8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNHV1Q5ZnlqYUZpM0ZjdkhEdm9vZHZTNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3LmlldGYub3Jn JTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNHV1Q5 ZnlqYUZpM0ZjdkhEdm9vZHZTNkgyP3U9aHR0cCUzQSUyRiUyRjJGd3d3LmlldGYub3JnPGJyPg0K PC9hPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zOU56bm1ZQnRSdUhBUmhHSjVXNWRHQjZIMj91PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5jb20lMkZ2MyUyRl9faHR0cCUzQSUyRjJGd3d3LmlldGYub3JnX18l M0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9a SGd3cDZ2cFJIT0d0OEFrVFJEdWlEby1wUENqdlIlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzlOem5tWUJ0UnVIQVJoR0o1VzVkR0I2SDI/dT1odHRw cyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHAlM0ElMkYyRnd3dy5pZXRmLm9y Z19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hx Z3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG8tcFBDanZSJTI0PC9hPiZndDsmZ3Q7JTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGc3ByaW5nPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgc3ByaW5nIG1haWxpbmcg bGlzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgPGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwv YT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3By aW5nQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzxi cj4NCjwvYT4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnJTBiIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9y ZyUwYjwvYT4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1haWx0bzpzcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzY3cWhVNEtpVWt6Vzl1R0M0 ZUF2UDQ2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRnNwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMu Y29tLzM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5v cmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNCaHlFdHg0UTduNzRCaGlSbmZNSnRUNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNv bSUyRnYzJTJGX19odHRwcyUzQSUyRmNsaWNrdGltZS5zeW1hbnRlYy5jb20lMkYzNjdxaFU0S2lV a3pXOXVHQzRlQXZQNDZIMiUzRnUlM0RodHRwcyUyQTNBJTJBMkYlMkEyRnd3dy5pZXRmLm9yZyUy QTJGbWFpbG1hbiUyQTJGbGlzdGluZm8lMkEyRnNwcmluZ19fJTNCSlNVbEpTVWwlMjElMjFORXQ2 eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0 OEFrVFJEdWlEby1oUjNnQUQlMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vM0JoeUV0eDRRN243NEJoaVJuZk1KdFQ2SDI/dT1odHRwcyUzQSUyRiUyRnVy bGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGY2xpY2t0aW1lLnN5bWFudGVjLmNvbSUy RjM2N3FoVTRLaVVrelc5dUdDNGVBdlA0NkgyJTNGdSUzRGh0dHBzJTJBM0ElMkEyRiUyQTJGd3d3 LmlldGYub3JnJTJBMkZtYWlsbWFuJTJBMkZsaXN0aW5mbyUyQTJGc3ByaW5nX18lM0JKU1VsSlNV bCUyMSUyMU5FdDZ5TWFPLWdrJTIxUzBZdXN4OUZZTkU4RV9SMW9pUUF0UXhnbTB4MHd4cWd1b1pI Z3dwNnZwUkhPR3Q4QWtUUkR1aURvLWhSM2dBRCUyNDwvYT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IE5vdGljZTogVGhpcyBl LW1haWwgdG9nZXRoZXIgd2l0aCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW48YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBvZiBS aWJib24gQ29tbXVuaWNhdGlvbnMgSW5jLiB0aGF0IGlzIGNvbmZpZGVudGlhbDxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhbmQvb3I8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBwcm9wcmlldGFyeSBmb3IgdGhlIHNv bGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgZGlzY2xvc3VyZSwgcmVsaWFu Y2Ugb3IgZGlzdHJpYnV0aW9uIGJ5IG90aGVycyBvciBmb3J3YXJkaW5nPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRob3V0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7ICZndDsgZXhwcmVzcyBwZXJtaXNzaW9uIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBpbnRlbmRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmZ3Q7IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCB0aGVuIGRlbGV0ZSBhbGw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgJmd0OyBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMuPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBz cHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3By aW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1Ex eHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1h aWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzNRMXhzS0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0El MkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYl MkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllO RThFX1Ixb2lRQXRReGdtMHgwd3hxZ3VvWkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RS ZVhoNjcxRzc5QlZHRXExNkgyP3U9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJG X19odHRwcyUzQSUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZ19f JTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdtMHgwd3hxZ3Vv Wkhnd3A2dnBSSE9HdDhBa1RSRHVpRG81S2xQbmJqJTI0PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBzcHJpbmcgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0 Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZ0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFM cTZIMj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20v M1ExeHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZzwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05y RG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJG djMlMkZfX2h0dHBzJTNBJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3By aW5nX18lM0IlMjElMjFORXQ2eU1hTy1nayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3 eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM05yRG5TVFJlWGg2NzFHNzlCVkdFcTE2SDI/ dT1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nX18lM0IlMjElMjFORXQ2eU1hTy1n ayUyMVMwWXVzeDlGWU5FOEVfUjFvaVFBdFF4Z20weDB3eHFndW9aSGd3cDZ2cFJIT0d0OEFrVFJE dWlEbzVLbFBuYmolMjQ8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nQGlldGYub3JnPC9hPiZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vY2xp Y2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNB JTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1ExeHNLR3lNek5KQ0t5 VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnNwcmluZzwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4N CiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zTnJEblNU UmVYaDY3MUc3OUJWR0VxMTZIMj91PWh0dHBzJTNBJTI1JTBiIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNOckRuU1RSZVhoNjcxRzc5QlZHRXExNkgyP3U9 aHR0cHMlM0ElPGJyPg0KPC9hPiZndDsgMkYlMkZ1cmxkZWZlbnNlLmNvbSUyRnYzJTJGX19odHRw cyUzQSU8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzJ5Q2tQS1JydVJq MVpmQ3ZLZ0wyR3E2SDI/dT1odHRwJTNBJTJGJTJGMkZ3d3cuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj4yRnd3dy5pZXRmLm9yZzwvYT4lMkZtYWlsbWFuJTJGbGlzdGk8YnI+DQomZ3Q7IG5mbyUy RnNwcmluZ19fJTNCJTIxJTIxTkV0NnlNYU8tZ2slMjFTMFl1c3g5RllORThFX1Ixb2lRQXRReGdt MHgwd3hxZ3U8YnI+DQomZ3Q7IG9aSGd3cDZ2cFJIT0d0OEFrVFJEdWlEbzVLbFBuYmolMjQmZ3Q7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRo IGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIG9mIFJp YmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMgY29uZmlkZW50aWFsIGFuZC9vciA8YnI+ DQomZ3Q7IHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lw aWVudC4gQW55IHJldmlldywgPGJyPg0KJmd0OyBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0 cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dCA8YnI+DQomZ3Q7IGV4cHJl c3MgcGVybWlzc2lvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgPGJyPg0KJmd0OyByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsIDxicj4NCiZndDsgY29waWVzLCBpbmNsdWRp bmcgYW55IGF0dGFjaG1lbnRzLjxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgLS08 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZI Mj91PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3By aW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNRMXhz S0d5TXpOSkNLeVZQQnlocUxxNkgyP3U9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWls bWFuJTJGbGlzdGluZm8lMkZzcHJpbmc8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1Ex eHNLR3lNek5KQ0t5VlBCeWhxTHE2SDI/dT1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1h aWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zUTF4c0tHeU16TkpDS3lWUEJ5aHFMcTZIMj91PWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+DQo8aHIgc2l6ZT0iMiIgd2lk dGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdGljZTogVGhpcyBlLW1haWwgdG9nZXRoZXIgd2l0aCBh bnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gb2YgUmliYm9uIENvbW11bmlj YXRpb25zIEluYy4gdGhhdCBpcyBjb25maWRlbnRpYWwNCiBhbmQvb3IgcHJvcHJpZXRhcnkgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCBkaXNj bG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcg d2l0aG91dCBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5DQogYW5kIHRoZW4gZGVsZXRlIGFsbCBjb3BpZXMsIGluY2x1ZGluZyBhbnkg YXR0YWNobWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNwcmluZyBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9j bGlja3RpbWUuc3ltYW50ZWMuY29tLzM1UFhrS0tUNkV6TFVWZkRUNDQzUW95NkgyP3U9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmciPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9D4CCdggeml509mbschi_-- From nobody Fri Aug 28 00:41:25 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B723A1526 for ; Fri, 28 Aug 2020 00:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.499, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 bODu9p7uGJUT for ; Fri, 28 Aug 2020 00:41:19 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DE43A14A4 for ; Fri, 28 Aug 2020 00:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1598600477; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M2Yw6mQqIT4CBoobs7FG2+1H5vN+2/JxuRQvsA/bHtY=; b=oGCrTTgWqADp/N4C8zqIIZ3AITHU4UeFMdGTViIrkWPqCcj9FDZun76r6RKJEg5nMnCqAS 2+dKz3IL4C71c1WuGLvWB0DzmwLgb8Hv+Y4RrHarQxA9WWT3u5wAiu3tSfZdg9gJLrbEFk 2jcVSnUK6f/9sNOM9CfbwHFGrTKLKa0= Received: from AZWPVEXEdge02.ecitele.com (13.81.42.245 [13.81.42.245]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-142-ZekYTTxBMVS01mI5k2eCFw-1; Fri, 28 Aug 2020 03:41:14 -0400 X-MC-Unique: ZekYTTxBMVS01mI5k2eCFw-1 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (40.114.150.83) by AZWPVEXEdge02.ecitele.com (10.0.2.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Fri, 28 Aug 2020 10:41:11 +0300 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com (2603:10a6:208:c4::33) by AM0PR03MB4833.eurprd03.prod.outlook.com (2603:10a6:208:fd::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.25; Fri, 28 Aug 2020 07:41:09 +0000 Received: from AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1]) by AM0PR03MB4499.eurprd03.prod.outlook.com ([fe80::8920:3fbc:c06a:49a1%6]) with mapi id 15.20.3326.023; Fri, 28 Aug 2020 07:41:09 +0000 From: Alexander Vainshtein To: "Chengli (Cheng Li)" , Alexander Vainshtein , Martin Horneffer CC: "spring@ietf.org" , Robert Raszuk , "EXT-Andrew.Alston@liquidtelecom.com" , Shraddha Hegde , "Ketan Talaulikar (ketant)" , "Joel M. Halpern" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfCODf9rN3izE+yW9JumUctqqklun0AgAAq2JCAAMsLAIAABZ+AgAABgICAADUrgIAAC1aAgAAdJoCAAGzfgIAAD7UQgAB6ewCAD4ZhAIAAC+KLgAALZwCAABX95oAADfeAgAAC7gCAAAmbgIAAFWyAgAADZQCABhhmgIAACWPQgA8j+ICAAAt9EQ== Date: Fri, 28 Aug 2020 07:41:09 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> , In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.177.18.93] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 008562c1-1364-480c-a288-08d84b25bb00 x-ms-traffictypediagnostic: AM0PR03MB4833: x-microsoft-antispam-prvs: x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qYMYy//SFk8f98MYE6meghuEJ45Uy3jltOX7VdESEI4uySJr9wtqdGfaIjARPvF4LDFHemdKKiPv5LyBZ+pdNqsn3YQWIQWHE3S32ihGoxnuHuz32m074TZTnC5dq+1XQcxqLbnNUJ8giHc6n0FjeqjpxYinyQRSRApz5tfEMoMYN1+e5onHL+5yy6EvfFwgMnKLfi1J+ZlCkqW+qtcCRB+pqSW6tk5E/WI2cNioOv/uiBjzm4OmjK1/kmyiM0TwTwc/k7DH+bVx4f7wzagUPiJbyLuqrseTZdT7YlO3qKJSfueaeRvAXVgLdc/fB3QDbOWYMyR+znJ986kEwHuxeQ/QREALmUtQTcGtf3y4+lsFNwvIBthfjR7hJADIvssy4hCDPeaMIIX7KJ5Gr9TfBZbWrH6YZwC61+6eyb3Dpt93bXuPmKYemFH8KGbjsXuPftijdPSGqoxlTvbgue1Z8fbJmnizGfIx48vTsFw6ls4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4499.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(376002)(346002)(136003)(396003)(366004)(54906003)(71200400001)(478600001)(52536014)(316002)(66446008)(76116006)(53546011)(6506007)(64756008)(66476007)(66946007)(66556008)(9686003)(8676002)(7696005)(110136005)(186003)(4326008)(83380400001)(33656002)(30864003)(26005)(8936002)(966005)(166002)(55016002)(5660300002)(45080400002)(86362001)(2906002)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: OkEL5hOUfwjRD6duBSIwmtRAF5m7FMG3vcn3wz05cnBXhhZH/Bbr0rEosvlqCnPCTTLk7VS0A0+2bLZdqnFVWbBz0LdUmrPF0mY5F9Aoau1LiitjsdbG1j0OCQbhLC0jbaJidxq6AOIca6jB6dfmi+bVyRn6v4FDxnNNc/lpn+s5fMcqwGQ1efmVW+XE9d8wYcfZVRBCNC0bSP59kCPAiK+IdcSoGgWAeKBehbO7Wz2tE7yQH1hwiBE/gcwgIFE49LDbM+YOpyFDot3hufP/XglQRaCa06TA7vWNB3SXN8cQOzX9Hkhl1HVosA5kE5jMZ0ClAJnxzxZbNAlM9bwm7+rzT3nWlBJSpg0I/ENm5vKrqULWJgSeIKiDy2ejsvQA2CiLeaYq4ySqa8zd68ZTyf9TZqiO1II5+qNFHU7uwBzY9MaHJutAHXF9L/CUEaWXG5/mkx150bSx+P01buiij+4WsW80ehXKFn/6z0r+86TPe9ZNbWOlXv+cMURFk/j55xvXjbuK4Y82eeJFREts0YyL1cO+qVXdgPltiIaVq9Lv8neHzhhotMtOQjKh98YL0iLvb/7lWXxtcLzC3A2OlfdPhZjb1+HVJTJeZkti2hvaUfgAfW0/0Fd5NHwiMfSgyVNnWV8ez1YCo0mp/w0R3A== MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4499.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 008562c1-1364-480c-a288-08d84b25bb00 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 07:41:09.5020 (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-CrossTenant-userprincipalname: f4+P4loqaqRxncklfFxxsIyqEQD2PsVEEckBxDKZjPnuRUPP2aBGSf0ojdF5EThK4KtjhUnmDUx/I5eCxNrtAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4833 X-CFilter-Loop: Reflected Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA81A106 smtp.mailfrom=alexander.vainshtein@rbbn.com X-Mimecast-Spam-Score: 0.004 X-Mimecast-Originator: rbbn.com Content-Type: multipart/alternative; boundary="_000_AM0PR03MB449916FB54DE81EEC8333C829D520AM0PR03MB4499eurp_" Content-Language: en-US Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 07:41:24 -0000 --_000_AM0PR03MB449916FB54DE81EEC8333C829D520AM0PR03MB4499eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cheng and all, A few short comments. 1. I support the idea to mark some IGP Prefix SIDs as "not bypassable" 2. I think that, while such marking is not yet available the neighbors = of a node that advertises itself as a "stub node" in IGP MAY use this as a = hint that Node SIDs advertised by this node are "not bypassable". 3. I do not think that B-flag in the advertisment of Adj-SIDs can be use= d as n indication that it can be bypassed - the current semantics of this f= lag is different. 4. At the same time I do not think that ability to advertise a certain = Adj-SID as leading to a not bypassable node is needed or would be useful. A= bility of the operator to exclude acific neighbor from protection would suf= fice, especially in the case of local Adj-SID. 5. Last bot not least, I think that none of the above must be addressed= befire adoption of the draft as a SPRING WG document. My 2c, Sasha Get Outlook for Android ________________________________ From: spring on behalf of Chengli (Cheng Li) Sent: Friday, August 28, 2020, 09:37 To: Alexander Vainshtein; Martin Horneffer Cc: spring@ietf.org; Robert Raszuk; EXT-Andrew.Alston@liquidtelecom.com; Sh= raddha Hegde; Ketan Talaulikar (ketant); Joel M. Halpern Subject: Re: [spring] Spring protection - determining applicability Hi Sasha and Martin, Many thanks for your input. I fully agree with your point of we need to con= sider to advertise the ability of the node to advertise a specific Prefix S= ID it originates as =93not eligible for bypass protection=94. Also, this extension should be written in a protection document like Martin= said. We have a strawman draft posed 1 year ago [1], but it has not been d= iscussed yet. The main idea of the draft is to add a no-bypass flag into S= ID(including Prefix SID, and adj-SID). But we are discussing with some expe= rts that do we need the No-bypass flag for Adj-SID or not, it seems like we= have a B flag already. It is so nice to see this point is raised and discussed. Also, welcome to r= eview the document, and hope to have your valuable comments. Respect, Cheng [1]. https://tools.ietf.org/html/draft-li-rtgwg-enhanced-ti-lfa-02 From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Alexander Vainsh= tein Sent: Tuesday, August 18, 2020 11:44 PM To: Martin Horneffer Cc: spring@ietf.org; Robert Raszuk ; EXT-Andrew.Alston@l= iquidtelecom.com ; Shraddha Hegde ; Ketan Talaulikar (ketant) ; Joel M. Halpern Subject: Re: [spring] Spring protection - determining applicability Martin, Lots of thanks for an important input to this discussion. I fully agree with you that ability to turn off the node protection scheme = for a specific PLR neighbor (i.e., on a specific PLR port) by suitable loca= l configuration in the PLR is definitely required. Such an ability would pr= obably address most (if not all) scenarios associated with the so-called = =93service nodes=94 that cannot be bypassed. I also think that service nodes that cannot be bypassed typically would adv= ertise themselves as =93stub nodes=94 in IGP in order to prevent inadverten= t application of their service function to transit traffic (which could oth= erwise pass thru the service node due to some topology change). Therefore a= local policy that would exclude IGP neighbors advertising themselves as s= tub nodes in IGP from the node protection scheme could be also useful. Last but not least, ability of the node to advertise a specific Prefix SID = it originates as =93not eligible for bypass protection=94 (e.g., using a ne= w flag in the Prefix Node TLV for IS-IS or OSPF) should be considered. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: spring > On B= ehalf Of Martin Horneffer Sent: Tuesday, August 18, 2020 5:51 PM To: spring@ietf.org Cc: Alexander Vainshtein >; Robert Raszuk >; EXT-Andrew.Alston@liquidtelecom.com >; Shraddha Hegde >; Ketan Talaulikar (ketant) >; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability A few thoughts from my (operator's) PoV: - The disussion is a very good and important one. It probably should be di= scussed and documented well in order to justify the proposed protections me= chanisms. - Not all operators seem to have the same requirements. (A somewhat similar discussion might be the one for disjoint paths. Tho= se are often equired by voice signalling applications. In some cases the vo= ice service demands that traffic is blackholed rather than on forwarded on = the wrong path. In other cases disjoint paths are just required for the "go= od case". Traffic MAY be forwarded on the wrong path, as long as the networ= k just makes sure the traffic on the other path is never affected by the sa= me failure.) - Personally I would hate to see yet another IGP extension for this purpos= e. - I would rather prefer a good discussion of what can be achieved by using= easy to make switches: - The protection behaviour could be switched on or off per node. - An operator with strict "some traffic may never touch certain part= s of the network" requirements might switch off the behaviour, while others= might switch it on. - A node could allow a switch even individually for every port or neigh= bor. - If a node knows that one of it's neighbours is a service node rath= er than a plain topological one, it could switch off protection. This is ho= w I would prefer to solve the problem with serrvice nodes. Should this be discussed in the protection document, or in a separate one? Best regards, Martin Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant): Hi Robert, We do not have a signalling mechanism in IGPs today to indicate a =93bypass= -able=94 indication for Prefix SIDs. If there was a desire for it, an IGP e= xtension would be required (there is none in progress AFAIK). Note that thi= s results in doubling the prefix SID scale (global labels) in the network. = So I would not go about this trivially. I think it helps to get more inputs and perspectives from operators on thei= r views for doing a bypass via local protection for segments in an SR Polic= y. There may be those that prefer end-to-end path protection using a fallba= ck path that is say disjoint with the primary but provides an appropriate S= LA/intent? Thanks, Ketan From: Robert Raszuk Sent: 14 August 2020 23:04 To: Ketan Talaulikar (ketant) Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.com ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Ketan, Looks like we are pretty much in sync here. But let me just observe that I purposely did not mention about SR policies = as we are not able to signal the intent with the packets itself. So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with = information if policies build with using them are bypass eligible or not. I was actually under the impression that this is already there and I am jus= t not aware, but looking deeper indeed I do not see this marking neither in= ISIS nor OSPF for prefix SIDs. Is there some work in progress to add it to those protocols or have we just= documented need for a short LSR draft ? Thx, R. On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) > wrote: Hi Robert, Please check inline below. From: Robert Raszuk > Sent: 14 August 2020 21:13 To: Ketan Talaulikar (ketant) > Cc: Alexander Vainshtein >; Joel M. Halpern >; Shraddha Hegde >; EXT-Andrew.Alston@liquidtelecom.com >; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi Ketan, While I completely agree with your note the consequences of it are pretty s= evre. [KT] I understand. We need to be mindful of implications of protection sche= mes for the SLAs/intent of SR Policies. Unless we signal which prefix SID is protection eligible and which is not h= ow would other nodes know if they can protect it or not ? [KT] Correct. To be more accurate, we need to consider this more in the con= text of SLA or =93intent=94 of SR Policies and which segments may be =93byp= ass-able=94 for local protection for some of those SR Policies. We also hav= e path-protection mechanisms. It seems that today's safe thing is not to apply any node protection on SR = flows at the PLRs then. And link protection MUST assure that packets will arrive at the neighbor no= de via some other link regardless of further path towards destination. [KT] Yes. We have a mechanism to indicate which adj-SIDs have protection (t= hat mechanism only provides link protection to get to the neighbor node) so= the SR Policy computation is able to indicate whether that specific link i= s =93bypass-able=94 or not by its choice of protected or unprotected adj-SI= Ds respectively. Thanks, Ketan Is it correct ? Thx R On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) > wrote: Hi Sasha, The service node advertises its own Prefix SID. The service function that t= his service node implements does not require any context (i.e. all packets = arriving at the node are subjected to that service). Therefore the service = node does not need to receive a packet with it=92s own Prefix SID. Thus, we cannot assume that when PHP is used, then the SID is only associat= ed with a topological instruction. Hope that clarifies? Thanks, Ketan From: Alexander Vainshtein > Sent: 14 August 2020 20:24 To: Ketan Talaulikar (ketant) >; = Joel M. Halpern >; Shraddha= Hegde >; EXT-Andrew.Alst= on@liquidtelecom.com >; Robert Ras= zuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Ketan, and all, I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are a= dvertised with PHP can ONLY represent topological instructions in SR-MPLS = - because the advertising node will not receive them and therefore can hard= ly be expected to associate any service function with them. This is complementary to what you have said. Hope this clarifies my position. What, if anything, did I miss? Regards, Sasha Get Outlook for Android ________________________________ From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 16:23 To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: RE: [spring] Spring protection - determining applicability ________________________________ NOTICE: This email was received from an EXTERNAL sender ________________________________ Hi Sasha, If the service does not need any additional context (e.g. a firewall that j= ust applies locally configured default rules on it), then I don=92t see why= PHP could not be done for a Prefix SID associated with a service node. Also, I didn=92t follow the point that you were trying to make about Adj-SI= Ds. Thanks, Ketan From: Alexander Vainshtein > Sent: 14 August 2020 18:24 To: Ketan Talaulikar (ketant) >; = Joel M. Halpern >; Alexande= r Vainshtein >; Shraddha Hegde >= ; EXT-Andrew.Alston@liquidtelecom.com >; Robert Raszuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi all, Regarding the statement "Prefix SID could be just a topological instruction= or may also be used to steer the flow to a node which is applying a servic= e function to it": I think that in SR-MPLS a Node SID that is advertised with PHP aciton can b= e safely considered as "just a topological instruction" by the PLR because = the originating node will not receive it. The same applies to Adj-SDIs. My 2c. Get Outlook for Android ________________________________ From: spring > on b= ehalf of Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 15:00 To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi All, I would like to share a different perspective on this. First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1]. This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being provided by t= he SR Policy. Awareness of that notion exists at the SR Policy headend and/= or computation-node. We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of the SLA requ= irement for picking that link. We do not have such a notion for Prefix SIDs= . One can say that we could introduce signalling (e.g. a B flag) to indicat= e whether a Prefix SID can be bypassed or not. This provides the opportunit= y for the computation to use one or the other flavor depending on the natur= e of the SLA for the SR Policy. I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able". As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or not. For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to bypass it. = When this mechanism is used along side SRTE path monitoring mechanisms, it = enables the headend to detect the failure and fallback to an alternate path= using the path protection approach. This is something that is described an= d in use in deployments today [1].. Thanks, Ketan [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9 [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9.3 -----Original Message----- From: spring > On B= ehalf Of Joel M. Halpern Sent: 04 August 2020 20:25 To: Alexander Vainshtein >; Shraddha Hegde >; EXT-Andrew.Alston@liqui= dtelecom.com >; Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability There are, as far as I can tell, a number of ways to address this family of= related questions. What struck me, and prompted the starting question, was that none of them w= ere spelled out. I see lots of interesting ideas / proposals. Some of them are compatible with others. Some are not. It would be good if we could reach agreement on how we thought it should be= handled. Thank you, Joel On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > Hi all, > > I am still not sure that the problem of bypass going thru undesirable > links/nodes exists in the case of topological SIDs. > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > ) has been successfully deployed > for many years before SR-MPLS has been introduced. What=92s more, > signaling of bypass tunnels he PLR usually did not include any of the > constraints used for computing of any specific LSP that the bypass LSP > would protect =96 because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node. > > From my POV the only difference between this behavior and that > introduced by the =93bypassing=94 drafts in SR is that, in the case of > RSVP-TE, the operator would explicitly indicate, as part of LSP > signaling, whether it would or would not use FRR; LSPs that would not > use FRR would then drop traffic rather than delivering it the wrong way. > > Such an option indeed does not exist in SR-TE today, but would be easy > to provide if so desired IMHO. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:* spring > = *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM > *To:* EXT-Andrew.Alston@liquidtelecom.com > >= ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > All, > > This is a very interesting discussion and thanks to Joel for starting > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized either by defining a flex-algo > avoiding those > > Nodes and links or by using a stack of unprotected adj-sids that avoid > restricted nodes and links. When a stack of adj-sids is used to > realize the path, the head-end based (sBFD) protection mechanisms can be = applied. > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection > is in use or not. > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* spring > > *= On Behalf Of *Andrew Alston > *Sent:* Tuesday, August 4, 2020 5:41 AM > *To:* Robert Raszuk > > *Cc:* spring@ietf.org ; J= oel M. Halpern > > > *Subject:* Re: [spring] Spring protection - determining applicability > > *[External Email. Be cautious of content]* > > Robert this is actually far more difficult when =96 it can be an entire > (long) series of nodes that need to be avoided. > > It could potentially be made to work but I=92d worry that to do this =96 > you=92d have to stack 10 =96 20 =96 30 negative labels =96 and that would= n=92t > be viable. > > It=92s easier to use algorithms and adjacency sids and other such things > to calculate paths =96 the biggest trick is about the stack depth. When > you have this need for node avoidance =96 the need for 10+ label depth > is critical =96 unless you wanna be applying one hell of a lot of > binding labels along the way which is a nightmare. > > But to answer your question, is this a common use case =96 it=92s a use > case that most of the people I discuss this with certain have =96 I cant > comment on a global scale, or for anyone else, but every indication I > have is that yes =96 its something people need, and want > > Andrew > > *From:* Robert Raszuk > > *Sent:* Tuesday, 4 August 2020 01:27 > *To:* Andrew Alston > > > *Cc:* Joel M. Halpern > >; spring@i= etf.org > > *Subject:* Re: [spring] Spring protection - determining applicability > > Is this a common use case ie. "but rather =96 which nodes / network > segments it can never touch or flow through." > > If so perhaps its time to define notion of *negative-SID* ie. list in > the packet resources which given packet MUST not ever traverse. > > Put in the packet set of nodes or links which the packet should never > traverse. > > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR) > > Best, > R. > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > wrote: > > So =96 > > One of the use cases, in fact, some very major use cases in any > spring technology for us revolve around the following > > a.The explicit avoidance of certain nodes > > b.The explicit avoidance of certain sections of the network > > Anything that could result in that explicit avoidance being violated > =96 would create, shall we say significant problems. > > Much of the use case is not a case of which nodes the packets flow > through =96 but rather =96 which nodes / network segments it can neve= r > touch or flow through. Effectively, to be used as a technology to > avoid certain things for specific reasons. > > This is also one of the reasons for needing such deep label stacks = =96 > this kind of detailed path programming tends to deepen the stack > because you sometimes have to be pretty explicit. > > It is absolutely critical to us that this functionality is there =96 > and that we can avoid situations which could cause traffic to > accidently hit things explicitly avoided. > > I wish I could be more specific than this, but it is what it is. > > Thanks > > Andrew > > *From:* spring > > = *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > > *Cc:* spring@ietf..org > *Subject:* Re: [spring] Spring protection - determining > applicability > > (Since the thread has gotten long enough, reiterating that this is as= a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks tha= t > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clea= r > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve Qo= S. > > Let's be clear. I am not arguing that this is not a good idea. It is = a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two > observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you > better > > apply IP encapsulation to that node.. I don't think IP > encapsulation can > > be hijacked today such that destination address of the packet is > ignored. > > > > B) Have you seen any IP network where upon topology change (link > or node > > failure) you suddenly start dropping flows in spite of SPT offerin= g > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > > wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is > restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex t= e > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the pac= ket > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding > service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and > "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological > instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > >= > > > > > > draft) unsurprisingly represent =93service=94 instructions > > > > > > 2.Segments that represent topological instructions can be bypass= ed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, tw= o > > > > > > topological segments are defined: the IGP-Adjacency segment and = the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and th= e > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Sectio= n > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > > > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous > sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When = the > > > > > > provider edge routers exchange service labels via BGP or som= e > > other > > > > > > non-IGP mechanism the bottom label is not understood in the = IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 > >] > is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between =93topological= =94 and > > > =93service=94 instructions is broken are indeed problematic. E.g= ., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such =93combined=94 SIDs could be prev= ented > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > > > > On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > > >; > spring@ietf.org > > > Subject: Re: [spring] Spring protection - determining applicabil= ity > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in th= e > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus > normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicabili= ty > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the variou= s > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, f= or > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new pat= h > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we = are > > > > > > > deliberately vague about what nodes can do when asked suitabl= y.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > > >> > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2 > > > > > > > > > > > > > > > > F%2Fwww.ietf.org > > > > >%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= --- > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any revi= ew, > > > disclosure, reliance or distribution by others or forwarding > without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete = all > > > copies, including any attachments. > > > > > > ---------------------------------------------------------------------= --- > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org = > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <= mailto:spring@ietf.org> > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2= Fmailman%2Flisti > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > ---------------------------------------------------------------------- > -- > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ---------------------------------------------------------------------- > -- _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ________________________________ Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for th= e sole use of the intended recipient. Any review, disclosure, reliance or d= istribution by others or forwarding without express permission is strictly = prohibited. If you are not the intended recipient, please notify the sender= immediately and then delete all copies, including any attachments. ________________________________ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_AM0PR03MB449916FB54DE81EEC8333C829D520AM0PR03MB4499eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
    Cheng and all,
    A few short comments.

    1. I support the idea to mark some IGP Prefix SIDs as "not bypassa= ble"
    2. I think that, while such marking is not yet available=   the neighbors of a node that advertises itself as a "stub node&= quot; in IGP MAY use this as a hint that Node SIDs advertised by this node = are "not bypassable".
    3. I do not think that B-flag i= n the advertisment of Adj-SIDs can be used as n indication that it can be b= ypassed - the current semantics of this flag is different.
    4. At the s= ame time I do not think  that ability to advertise a certain Adj-SID a= s leading to a not bypassable node is needed or would be useful. Ability of= the operator to exclude acific neighbor from protection would suffice, esp= ecially in the case of local Adj-SID.
    5. Last bot not  least, I think that none of the above = must be addressed befire adoption of the draft as a SPRING WG document.

    My 2c,
    Sasha

    From: spring <spring-bounces@= ietf.org> on behalf of Chengli (Cheng Li) <c.l@huawei.com>
    Sent: Friday, August 28, 2020, 09:37
    To: Alexander Vainshtein; Martin Horneffer
    Cc: spring@ietf.org; Robert Raszuk; EXT-Andrew.Alston@liqu= idtelecom.com; Shraddha Hegde; Ketan Talaulikar (ketant); Joel M. Halpern Subject: Re: [spring] Spring protection - determining appl= icability

    Hi Sasha = and Martin,

     

    Many than= ks for your input. I fully agree with your point of we need to consider to = advertise the ability of the node to advertise a s= pecific Prefix SID it originates as =93not eligible for bypass protection= =94.

     

    Also, thi= s extension should be written in a protection document like Martin said. We= have a strawman draft posed 1 year ago [1], but it has not been discussed = yet.  The main idea of the draft is to add a no-bypass flag into SID(including Prefix SID, and adj-SID). But w= e are discussing with some experts that do we need the No-bypass flag for A= dj-SID or not, it seems like we have a B flag already.

     

    It is so = nice to see this point is raised and discussed. Also, welcome to review the= document, and hope to have your valuable comments.

     

    Respect,<= /span>

    Cheng

     

    [1]. https://tools.ietf.org/html/draft-li-rtgwg-enhanced-ti-lfa-02

     

     

    From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of Alexander Vainshtein
    Sent: Tuesday, August 18, 2020 11:44 PM
    To: Martin Horneffer <maho@lab.dtag.de>
    Cc: spring@ietf.org; Robert Raszuk <robert@raszuk.net>; EXT-An= drew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Shra= ddha Hegde <shraddha@juniper.net>; Ketan Talaulikar (ketant) <keta= nt=3D40cisco.com@dmarc.ietf.org>; Joel M. Halpern <jmh@joelhalpern.co= m>
    Subject: Re: [spring] Spring protection - determining applicability<= /p>

     

    Martin,

    Lots of t= hanks for an important input to this discussion.

     

    I fully a= gree with you that ability to turn off the node protection scheme for a spe= cific PLR neighbor (i.e., on a specific PLR port) by suitable local configu= ration in the PLR is definitely required. Such an ability would probably address most (if not all) scenarios associa= ted with the so-called =93service nodes=94 that cannot be bypassed.<= /p>

     

    I also th= ink that service nodes that cannot be bypassed typically would advertise th= emselves as =93stub nodes=94 in IGP in order to prevent inadvertent applica= tion of their service function to transit traffic (which could otherwise pass thru the service node due to some topo= logy change). Therefore a local policy that would exclude IGP neighbors adv= ertising  themselves as stub nodes in IGP from the node protection sch= eme could be also useful.

     

    Last but = not least, ability of the node to advertise a specific Prefix SID it origin= ates as =93not eligible for bypass protection=94 (e.g., using a new flag in= the Prefix Node TLV for IS-IS or OSPF) should be considered.

     

    My 2c,

    Sasha

     

    Office: += 972-39266302

    Cell:&nbs= p;     +972-549266302

    Email:&nb= sp;  Alexan= der.Vainshtein@ecitele.com

     

    From: spring <spring-bounces@ietf.org> On Behalf Of Martin Horneffer
    Sent: Tuesday, August 18, 2020 5:51 PM
    To: spring@ietf.org
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Robert Raszuk <robert@raszuk.net>; EXT-Andrew.Alston@li= quidtelecom.com <= Andrew.Alston@liquidtelecom.com>; Shraddha Hegde <shraddha@juniper.net>; Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>; Joel M. Halpern <= ;jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability<= /p>

     

    A few thoughts from m= y (operator's) PoV:

     - The disussion is a very good and important one. It probably should = be discussed and documented well in order to justify the proposed protectio= ns mechanisms.

     - Not all operators seem to have the same requirements.
        (A somewhat similar discussion might be the one for disj= oint paths. Those are often equired by voice signalling applications. In so= me cases the voice service demands that traffic is blackholed rather than o= n forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forw= arded on the wrong path, as long as the network just makes sure the traffic= on the other path is never affected by the same failure.)

     - Personally I would hate to see yet another IGP extension for this p= urpose.

     - I would rather prefer a good discussion of what can be achieved by = using easy to make switches:
        - The protection behaviour could be switched on or off p= er node.
           - An operator with strict "some t= raffic may never touch certain parts of the network" requirements migh= t switch off the behaviour, while others might switch it on.
        - A node could allow a switch even individually for ever= y port or neighbor.
           - If a node knows that one of it's nei= ghbours is a service node rather than a plain topological one, it could swi= tch off protection. This is how I would prefer to solve the problem with se= rrvice nodes.

    Should this be discussed in the protection document, or in a separate one?<= br>
    Best regards, Martin

    Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketan= t):

    Hi Robert,

     

    We do not have a signalling mechanism in IGPs today = to indicate a =93bypass-able=94 indication for Prefix SIDs. If there was a = desire for it, an IGP extension would be required (there is none in progres= s AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go abo= ut this trivially.

     

    I think it helps to get more inputs and perspectives= from operators on their views for doing a bypass via local protection for = segments in an SR Policy. There may be those that prefer end-to-end path pr= otection using a fallback path that is say disjoint with the primary but provides an appropriate SLA/intent?

     

    Thanks,

    Ketan

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 23:04
    To: Ketan Talaulikar (ketant) &l= t;ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>; Shr= addha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability<= /p>

     

    Ketan,

     

    Looks like we are pretty much in sync here. 

     

    But let me just observe that I purposely did no= t mention about SR policies as we are not able to signal the intent with th= e packets itself. 

     

    So all we have there is SIDs. BSIDs or prefix SIDs n= eed to be flooded with information if policies build with using them are by= pass eligible or not. 

     

    I was actually under the impression that this is alr= eady there and I am just not aware, but looking deeper indeed I do not see = this marking neither in ISIS nor OSPF for prefix SIDs. 

     

    Is there some work in progress to add it to those pr= otocols or have we just documented need for a short LSR draft  ?&= nbsp;

     

    Thx,

    R.

     

     

    On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ke= tant) <ketant@cisco.com> wrot= e:

    Hi Robert,

     

    Please check inline below.

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 21:13
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability<= /p>

     

    Hi Ketan,

     

    While I completely agree with your note t= he consequences of it are pretty sevre. 

    [KT] I understand. We need to be mi= ndful of implications of protection schemes for the SLAs/intent of SR Polic= ies.

     

    Unless we signal which prefix SID is prot= ection eligible and which is not how would other nodes know if they can pro= tect it or not ? 

    [KT] Correct. To be more accurate, = we need to consider this more in the context of SLA or =93intent=94 of SR P= olicies and which segments may be =93bypass-able=94 for local protection fo= r some of those SR Policies. We also have path-protection mechanisms.

     

    It seems that today's safe thing is not t= o apply any node protection on SR flows at the PLRs then. 

     

    And link protection MUST assure that pack= ets will arrive at the neighbor node via some other link regardless of furt= her path towards destination. 

    [KT] Yes. We have a mechanism to in= dicate which adj-SIDs have protection (that mechanism only provides link pr= otection to get to the neighbor node) so the SR Policy computation is able = to indicate whether that specific link is =93bypass-able=94 or not by its choice of protected or unprotected adj-= SIDs respectively.

     

    Thanks,

    Ketan

     

    Is it correct ? 

     

    Thx

    R

     

    On Fri, Aug 14, 2020 at 5:32 PM Ketan Tal= aulikar (ketant) <= ketant@cisco.com> wrote:

    Hi Sasha,

     

    The service node advertises its own Prefi= x SID. The service function that this service node implements does not requ= ire any context (i.e. all packets arriving at the node are subjected to tha= t service). Therefore the service node does not need to receive a packet with it=92s own Prefix SID.

     

    Thus, we cannot assume that when PHP is u= sed, then the SID is only associated with a topological instruction.

     

    Hope that clarifies?

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.V= ainshtein@rbbn.com>
    Sent: 14 August 2020 20:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= /p>

     

    Ketan, and all,

    I have stated that, IMHO and FWIW, both Adj= -SIDs and Prefix SIDs that are advertised with PHP can  ONLY represent= topological instructions in SR-MPLS - because the advertising node will not receive them and therefore can hardly be exp= ected to associate any service function with them.

     

    This is complementary to what you have said= .

     

    Hope this clarifies my position.

    What, if anything, did I miss?

     

    Regards,

    Sasha

     

    Get Outlook for Android

     

    From: Ketan Talaulikar (ketant) &= lt;ketant@cisco.com>
    Sent: Friday, August 14, 2020, 16:23
    To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde;     EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject:= RE: [spring] Spring protection - determining applicability=

     

    NOTICE: This email was received from an E= XTERNAL sender

     

    Hi Sasha,

     

    If the service does not need any addition= al context (e.g. a firewall that just applies locally configured default ru= les on it), then I don=92t see why PHP could not be done for a Prefix SID a= ssociated with a service node.

     

    Also, I didn=92t follow the point that yo= u were trying to make about Adj-SIDs.

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.V= ainshtein@rbbn.com>
    Sent: 14 August 2020 18:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= /p>

     

    Hi all,

    Regarding the statement "Prefix SID co= uld be just a topological instruction or may also be used to steer the flow= to a node which is applying a service function to it":

     

     

    I think that in SR-MPLS a Node SID that is = advertised with PHP aciton can be safely considered as "just a topolog= ical instruction" by the PLR because the originating node will not receive it.

    The same applies to Adj-SDIs.

     

    My 2c.

     

    Get Outlook for Android

     

    From: spring <spring-bounces@ietf.org>= ; on behalf of Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.= org>
    Sent: Friday, August 14, 2020, 15:00
    To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject:= Re: [spring] Spring protection - determining applicability=

     

    Hi All,

    I would like to share a different perspective on this.

    First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

    This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being pro= vided by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

    We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

    I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

    As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

    For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

    Thanks,
    Ketan

    [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
    [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

    -----Original Message-----
    From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
    Sent: 04 August 2020 20:25
    To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability

    There are, as far as I can tell, a number of ways to address this family of= related questions.
    What struck me, and prompted the starting question, was that none of them w= ere spelled out.  I see lots of interesting ideas / proposals.
    Some of them are compatible with others.   Some are not.
    It would be good if we could reach agreement on how we thought it should be= handled.

    Thank you,
    Joel

    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
    > Hi all,
    >
    > I am still not sure that the problem of bypass going thru undesirable =
    > links/nodes exists in the case of topological SIDs.
    >
    > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
    > <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
    > for many years before SR-MPLS has been introduced. What=92s more,
    > signaling of bypass tunnels he PLR usually did not include any of the =
    > constraints used for computing of any specific LSP that the bypass LSP=
    > would protect =96 because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
    >
    >  From my POV the only difference between this behavior and that <= br> > introduced by the =93bypassing=94 drafts in SR is that, in the case of=
    > RSVP-TE, the operator would explicitly indicate, as part of LSP
    > signaling, whether it would or would not use FRR; LSPs that would not =
    > use FRR would then drop traffic rather than delivering it the wrong wa= y.
    >
    > Such an option indeed does not exist in SR-TE today, but would be easy=
    > to provide if so desired IMHO.
    >
    > Did I miss something substantial?
    >
    > Regards, and lots of thanks in advance,
    >
    > Sasha
    >
    > Office: +972-39266302
    >
    > Cell:      +972-549266302
    >
    > Email:   Alexander.Vainshtein@ecitele.com
    >
    > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM
    > *To:* EXT-Andrew.Alston@liquidtelecom.com
    > <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    > *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > All,
    >
    > This is a very interesting discussion and thanks to Joel for starting =
    > this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized  either by defining a flex= -algo
    > avoiding those
    >
    > Nodes and links or by using a stack of unprotected adj-sids that avoid=
    > restricted nodes and links. When a stack of adj-sids is used to
    > realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
    >
    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
    > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
    > is in use or not.
    >
    > Rgds
    >
    > Shraddha
    >
    > Juniper Business Use Only
    >
    > *From:* spring <spring-bounces@ietf.org
    > <m= ailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
    > *Sent:* Tuesday, August 4, 2020 5:41 AM
    > *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern
    > <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > *[External Email. Be cautious of content]*
    >
    > Robert this is actually far more difficult when =96 it can be an entir= e
    > (long) series of nodes that need to be avoided.
    >
    > It could potentially be made to work but I=92d worry that to do this = =96
    > you=92d have to stack 10 =96 20 =96 30 negative labels =96 and that wo= uldn=92t
    > be viable.
    >
    > It=92s easier to use algorithms and adjacency sids and other such thin= gs
    > to calculate paths =96 the biggest trick is about the stack depth.&nbs= p; When
    > you have this need for node avoidance =96 the need for 10+ label depth=
    > is critical =96 unless you wanna be applying one hell of a lot of
    > binding labels along the way which is a nightmare.
    >
    > But to answer your question, is this a common use case =96 it=92s a us= e
    > case that most of the people I discuss this with certain have =96 I ca= nt
    > comment on a global scale, or for anyone else, but every indication I =
    > have is that yes =96 its something people need, and want
    >
    > Andrew
    >
    > *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Sent:* Tuesday, 4 August 2020 01:27
    > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>>
    > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
    > <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org > <mailto:spring= @ietf.org>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > Is this a common use case ie.  "but rather =96 which nodes /= network
    > segments it can never touch or flow through."
    >
    > If so perhaps its time to define notion of *negative-SID* ie. list in =
    > the packet resources which given packet MUST not ever traverse. >
    > Put in the packet set of nodes or links which the packet should never =
    > traverse.
    >
    > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
    >
    > Best,
    > R.
    >
    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
    > <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
    >
    >     So =96
    >
    >     One of the use cases, in fact, some very major= use cases in any
    >     spring technology for us revolve around the fo= llowing
    >
    >     a.The explicit avoidance of certain nodes
    >
    >     b.The explicit avoidance of certain sections o= f the network
    >
    >     Anything that could result in that explicit av= oidance being violated
    >     =96 would create, shall we say significant pro= blems.
    >
    >     Much of the use case is not a case of which no= des the packets flow
    >     through =96 but rather =96 which nodes / netwo= rk segments it can never
    >     touch or flow through.  Effectively, to b= e used as a technology to
    >     avoid certain things for specific reasons.
    >
    >     This is also one of the reasons for needing su= ch deep label stacks =96
    >     this kind of detailed path programming tends t= o deepen the stack
    >     because you sometimes have to be pretty explic= it.
    >
    >     It is absolutely critical to us that this func= tionality is there =96
    >     and that we can avoid situations which could c= ause traffic to
    >     accidently hit things explicitly avoided.
    >
    >     I wish I could be more specific than this, but= it is what it is.
    >
    >     Thanks
    >
    >     Andrew
    >
    >     *From:* spring <spring-bounces@ietf.org
    >     <mailto:spring-bounces@ietf.org>> *On Behal= f Of *Joel M. Halpern
    >     *Sent:* Monday, 3 August 2020 21:36
    >     *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
    >     *Cc:* spring@ietf..org <mailto:spring@ietf.org>
    >     *Subject:* Re: [spring] Spring protection - de= termining
    > applicability
    >
    >     (Since the thread has gotten long enough, reit= erating that this is as a
    >     participant, not a WG chair.)
    >
    >     Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
    >     choose to drop packets. For all sorts of reaso= ns.
    >     I think there are likely other reasons why one= may not want a random
    >     path rather than a chosen TE path. I think it = is important we be clear
    >     about what constraints may be / are violated w= hen we tell people they
    >     have this tool (protective rerouting) that is = intended to preserve QoS.
    >
    >     Let's be clear. I am not arguing that this is = not a good idea. It is a
    >     good idea. And useful. I am trying to figure o= tu what combination of
    >     additional mechanisms and clear descriptions w= ill lead to everyone
    >     getting the behavior they expect (which may no= t be the behavior they
    >     desire, but sometimes is the best we can do.)<= br> >
    >     Yours,
    >     Joel
    >
    >     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
    >      > Joel,
    >      >
    >      > Are we still talking about IP netwo= rks here ? Or perhaps some hard
    >      > slicing with real resource reservat= ions or detnets ?
    >      >
    >      > Because if we are talking = ;about IP networking I have two
    >     observations:
    >      >
    >      > A) If you need to traverse via a sp= ecific node (ie. firewall) you
    >     better
    >      > apply IP encapsulation to that node= .. I don't think IP
    >     encapsulation can
    >      > be hijacked today such that destina= tion address of the packet is
    >     ignored.
    >      >
    >      > B) Have you seen any IP network whe= re upon topology change (link
    >     or node
    >      > failure) you suddenly start dr= opping flows in spite of SPT offering
    >      > perhaps few ms longer path with 10 = ms more jitter ?
    >      >
    >      > Or are some SR marketing slides pro= mise to turn IP networks in
    >      > something new ? Worse ... do t= hey mention path quality guarantees,
    >      > resource reservations ? I hope= not.
    >      >
    >      > Thx,
    >      > R.
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
    >     <mailto:jmh@joelhalpern.com%20%0b>> <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">mailto:jmh@joelhalp= ern.com>> wrote:
    >      >
    >      > Well less serious for TE SIDs, I am= not sure the problem is
    >     restricted
    >      > to just service SIDs.
    >      >
    >      > Suppose that the PCE has specified = the path to meet some complex te
    >      > objective.  The bypass node ha= s no way of knowing what those
    >      > constraints
    >      > were.  And for some kinds of t= raffic, it is better to drop the packet
    >      > than to deliver it outside the enve= lop.  I suspect that the right
    >      > answer
    >      > to this is "too bad".&nbs= p; If so, as with the distinction regarding
    >     service
    >      > nodes, we should say so, shouldn't = we?
    >      >
    >      > Yours,
    >      > Joel
    >      >
    >      > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
    >      > > Mach, Joel and all,
    >      > >
    >      > > I think that in most cases: >      > >
    >      > > 1.There is clear differentiati= on between "topological" and
    >     "service"
    >      > > instructions in SID advertisem= ents. E.g.:
    >      > >
    >      > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
    >      > > corresponding IGP advertisemen= ts) represent topological
    >     instructions
    >      > >
    >      > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
    >      > >
    >      >
    >     <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
    >     <https://clicktime.symantec.com/3GC5a= f2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F= datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 4T-L0nl%24>>
    >      >
    >      > > draft) unsurprisingly represen= t =93service=94 instructions
    >      > >
    >      > > 2.Segments that represent topo= logical instructions can be bypassed,
    >      > > while segments that represent = service instructions require
    >      > alternative
    >      > > protection mechanisms.
    >      > >
    >      > > This view seems to be aligned = with RFC 8402
    >      > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24>>
    >     that says in Section 1:
    >      > >
    >      > >     In the cont= ext of an IGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defin= ed: the IGP-Adjacency segment and the
    >      > >
    >      > >     IGP-Prefix = segment.
    >      > >
    >      > >     In the cont= ext of a BGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defin= ed: the BGP peering segment and the
    >      > >
    >      > >     BGP-Prefix = segment.
    >      > >
    >      > > In the case of SR-MPLS this di= fferentiation is assumed in Section
    >      > 3.4 of
    >      > > the Node Protection for SR-TE = Path
    >      > >
    >      >
    >     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
    >     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdr= aft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21= %21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9= wO-Ssn%24>>
    >      >
    >      > > draft that says:
    >      > >
    >      > >     The node pr= otection mechanism described in the previous
    >     sections
    >      > >
    >      > >     depends on = the assumption that the label immediately below
    >      > the top
    >      > >
    >      > > label in the label stack is un= derstood in the IGP domain.  When the
    >      > >
    >      > >     provider ed= ge routers exchange service labels via BGP or some
    >      > other
    >      > >
    >      > >     non-IGP mec= hanism the bottom label is not understood in the IGP
    >      > >
    >      > >     domain.
    >      > >
    >      > >     The egress = node protection mechanisms described in the draft
    >      > >
    >      > >     [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
    >     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u= =3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2F= doc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
    >     is
    >      > > applicable to this use case an= d no additional changes
    >      > >
    >      > >     will be req= uired for SR based networks
    >      > >
    >      > > The scenarios in which  d= ifferentiation between =93topological=94 and
    >      > > =93service=94 instructions is = broken are indeed problematic. E.g.,
    >      > consider
    >      > > the use case in which a Node S= ID in the ERO of a SR-TE path
    >      > identifies a
    >      > > node that acts as a firewall f= or all packets it receives, i.e.,
    >      > provides
    >      > > the firewall service without a= ny dedicated service SID
    >      > identifying it.
    >      > > One could say that the Node SI= D of such a node would combine
    >      > topological
    >      > > and service instructions thus = breaking the differentiation
    >      > between the two.
    >      > >
    >      > > I am not sure if usage of such= =93combined=94 SIDs could be prevented
    >      > or at
    >      > > least discouraged.
    >      > >
    >      > > If not, providing an ability t= o identify such SIDs in the
    >      > advertisement
    >      > > mechanisms would be useful IMH= O.
    >      > >
    >      > > My 2c,
    >      > >
    >      > > Sasha
    >      > >
    >      > > Office: +972-39266302
    >      > >
    >      > > Cell:    &= nbsp; +972-549266302
    >      > >
    >      > > Email: Alexander.Vainshtein@ecitele.com
    >     <mailto:Alexander.Vainshtein@ecitele.com>=
    >      > <mailto:Alexander.Vainshtein@ecitele.= com>
    >      > >
    >      > > -----Original Message-----
    >      > > From: spring <spring-bounces@ietf.org<= br> >     <mailto:spring-bounces@ietf.org%0b>>
    >     <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen
    >      > > Sent: Monday, August 3, 2020 6= :30 AM
    >      > > To: Joel M. Halpern <jmh@joelhalpern.com >     <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.co= m>>;
    >     spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > Subject: Re: [spring] Spring p= rotection - determining applicability
    >      > >
    >      > > Hi Joel,
    >      > >
    >      > > I think this is a good point t= hat may not be discussed in the
    >      > past. And
    >      > > I also don't think there is a = "can be bypassed" indication in the
    >      > > routing advertisement for now.=
    >      > >
    >      > > IMHO, the information advertis= ed by routing is neutral, such
    >      > information
    >      > > (can or cannot be bypassed) is= more path specific, thus
    >     normally the
    >      > > controller should be responsib= le for deciding whether/which SID
    >      > can be
    >      > > bypassed.
    >      > >
    >      > > Best regards,
    >      > >
    >      > > Mach
    >      > >
    >      > >  > -----Original Messa= ge-----
    >      > >
    >      > >  > From: spring [mailt= o:spring-bounc= es@ietf.org
    >      > <mailto:spring-bounces@ietf.org>
    >     <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>] >     On Behalf Of Joel M.
    >      > >
    >      > >  > Halpern
    >      > >
    >      > >  > Sent: Monday, Augus= t 3, 2020 7:51 AM
    >      > >
    >      > >  > To: spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >      > >
    >      > >  > Subject: [spring] S= pring protection - determining applicability
    >      > >
    >      > >  >
    >      > >
    >      > >  > (WG Chair hat Off, = this is merely a note from a slightly
    >      > confused WG
    >      > >
    >      > >  > participant.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > I have been reading= the various repair drafts, and the various
    >      > >
    >      > >  > networks programmin= g and service programming draft, and I am
    >      > trying to
    >      > >
    >      > >  > figure out one aspe= ct of the combination.
    >      > >
    >      > >  >
    >      > >
    >      > >  > How does a node tha= t is doing some form of bypass (suppose, for
    >      > >
    >      > >  > simplicity, it is N= ode N2 deciding to bypass the next SID for
    >      > a failed
    >      > >
    >      > >  > node N3) know that = it is safe to do so?
    >      > >
    >      > >  >
    >      > >
    >      > >  > If the path was jus= t for TE, then it is "safe" if the new path
    >      > meets
    >      > >
    >      > >  > the TE criteria.&nb= sp; or maybe it is safe if it is even close, as
    >      > long as
    >      > >
    >      > >  > it is not used for = too long.
    >      > >
    >      > >  >
    >      > >
    >      > >  > But what if the nod= e were a Firewall, included to meet legal
    >      > > requirements?
    >      > >
    >      > >  > Or was some other n= ecessary programmatic transform (wince we are
    >      > >
    >      > >  > deliberately vague = about what nodes can do when asked suitably.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > Is there some "= ;can be bypassed" indication in the routing
    >      > >
    >      > >  > advertisements that= I missed?
    >      > >
    >      > >  >
    >      > >
    >      > >  > Thank you,
    >      > >
    >      > >  > Yours,
    >      > >
    >      > >  > Joel
    >      > >
    >      > >  >
    >      > >
    >      > >  > ___________________= ____________________________
    >      > >
    >      > >  > spring mailing list=
    >      > >
    >      > >  > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >      > >
    >      > >  >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
    >     <    https://clicktime.symantec.com/3Q= 7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A= %2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2= __%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt= 8AkTRDuiDo6HwPLil%24>
    >      > >
    >      >
    >     <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
    >     <https://clicktime.symantec.c= om/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http= s%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A= %2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6v= pRHOGt8AkTRDuiDozoQiAHk%24>>
    >      > >
    >      > >  > F%2Fwww.ietf.org
    >     <https://clicktime.sy= mantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
    >      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
    >     <https://clicktim= e.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%= 2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1o= iQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2F= listinfo%2Fspring
    >      > >
    >      > > ______________________________= _________________
    >      > >
    >      > > spring mailing list
    >      > >
    >      > > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org> <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>> >      > >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRn= fMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sym= antec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.o= rg%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yu= sx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
    >      > >
    >      > >
    >      > >
    >      > >
    >      >
    >     ----------------------------------------------= --------------------------
    >      > > Notice: This e-mail together w= ith any attachments may contain
    >      > > information of Ribbon Communic= ations Inc. that is confidential
    >      > and/or
    >      > > proprietary for the sole use o= f the intended recipient. Any review,
    >      > > disclosure, reliance or distri= bution by others or forwarding
    >     without
    >      > > express permission is strictly= prohibited. If you are not the
    >      > intended
    >      > > recipient, please notify the s= ender immediately and then delete all
    >      > > copies, including any attachme= nts.
    >      > >
    >      >
    >     ----------------------------------------------= --------------------------
    >      > >
    >      > > ______________________________= _________________
    >      > > spring mailing list
    >      > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >      > >
    >      >
    >      > ___________________________________= ____________
    >      > spring mailing list
    >      > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >      >
    >
    >     ______________________________________________= _
    >     spring mailing list
    >     spring@ietf.org <mailto:spring@ietf.org>
    >     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >    
    > <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
    > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
    > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >
    >
    >
    > ----------------------------------------------------------------------=
    > --
    > Notice: This e-mail together with any attachments may contain
    > information of Ribbon Communications Inc. that is confidential and/or =
    > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
    > recipient, please notify the sender immediately and then delete all > copies, including any attachments.
    > ----------------------------------------------------------------------=
    > --

    _______________________________________________
    spring mailing list
    spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring
    _______________________________________________
    spring mailing list
    spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring

     

     

    Notice: This e-mail together with any atta= chments may contain information of Ribbon Communications Inc. that is confi= dential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by ot= hers or forwarding without express permission is strictly prohibited. If yo= u are not the intended recipient, please notify the sender immediately and = then delete all copies, including any attachments.

     

      

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ie=
tf.org/mailman/listinfo/spring

     


    --_000_AM0PR03MB449916FB54DE81EEC8333C829D520AM0PR03MB4499eurp_-- From nobody Fri Aug 28 03:10:41 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B663A0853 for ; Fri, 28 Aug 2020 03:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=lab.dtag.de 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 K41Qd8IhS4wY for ; Fri, 28 Aug 2020 03:10:37 -0700 (PDT) Received: from OldBailey.lab.dtag.de (OldBailey.lab.DTAG.DE [194.25.1.220]) (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 4D1B33A08CC for ; Fri, 28 Aug 2020 03:10:36 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id D5380CB7B0; Fri, 28 Aug 2020 12:10:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1598609429; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=Cka/Ksn7vlK3I0mkSFygm37J44qBJkeglkv8YvokJrU=; b=TVAWGoyuhRP1v99HrAVBoCwC8ItWiU+PJpGcWzW7giFKBEK2wsbiuUp/HctyHskPMGpgLq eXNeCihMwhZmRq0XphLf7iMLpBEj1/JaCGGnlMjDLKeOrjM2Cwav3aSFIdEG2OoFY8QF/m q/ZJvYIGT1asH8KGkoeQ3TIhyERiCwXVRElPZN2FHnaVdwf0Y4Cd0jNonIIMPK2gGxbrmY aDg3/JrMXFe5wwxRDleIbcudGQqf6JtY0QrpjyuiGeYJzvEIsv/UFEtr8qpx5t6n+M2qgG F+8QzJHf7mTMYMv2Htf2RG/guPu+E7dr3Cg2VyPA5V+QjXmvf8TFctKin6YLZw== To: Robert Raszuk Cc: SPRING WG References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> From: Martin Horneffer Message-ID: <13e512a0-44e6-7fe8-d44d-54c3c4136d16@lab.dtag.de> Date: Fri, 28 Aug 2020 12:10:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E9303A289B834A51E55492C" X-Last-TLS-Session-Version: TLSv1.3 Archived-At: Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 10:10:40 -0000 This is a multi-part message in MIME format. --------------9E9303A289B834A51E55492C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Robert, the setup I sketched does not cover double failures nor 100 % of all topological cases for forwarding. And in fact, forwarding the traffic is not the main purpose. The main purpose it to DETECT the failure in a useful way. For the same reason we would sure not want to add yet another encapsulation technology. But, of course, if the behavior (drop or forward unlabelled) would be configurable, that would be perfectly ok from my point of view. Best regards, Martin Am 27.08.20 um 14:45 schrieb Robert Raszuk: > Martin, > > > it follows an IGP default route to a central device, > > So putting aside that such default must point domian wide to the same > address (could be anycast if you are careful) once this "central > device" receives a packet and does a BGP full table lookup it will > again try to encapsulate it in MPLS towards exit. > > What if the path is again via a device which breaks LDP LSP or SR > path and the packet will again go back to central device creating a > very nice loop ? > > Sure central device could give up on MPLS all together and IP encap to > egress via your BGP free core - but you are not mentioning that. > > Bottom line if you would not have BGP free core (or Internet route > free core) I would say sure good idea to continue. But since you do I > think this is a lot of hidden traps number of networks may fall into > by doing it. So at least it should not be a default behaviour. > > Thx, > R. > > > > > > On Thu, Aug 27, 2020 at 12:35 PM Martin Horneffer > wrote: > > Hello everyone, > > may I come back the the question below? Or rather let me update it > a little: > > In case an SR-MPLS path is broken, should a node rather drop the > packet, > or forward it? > This can happen whenever the IGP points to a certain next hop, but > that > neither supplies a valid SID, nor allows LDP-stitching for whatever > reason. For PUSH as well as for CONTINUE. > > We have been using MPLS transport and a BGP free core since about two > decades now, using LDP. In the analog case, LDP creates "unlabelled" > entries in the LFIB, does the equivalent of a POP operation and > forwards > the packet to the next-hop as chosen by the IGP. > > This behavior obviously breaks any traffic that relies on a service > label, but it can protect some traffic. > In our case a huge percentage of all traffic still is public IPv4. > This > needs MPLS only for a transport label, be it LDP or SR-MPLS. If this > traffic gets forwarded unlabelled, it follows an IGP default route > to a > central device, where it is 1) redirected to the correct > destination and > 2) counted in a way that operators can quickly see whether and where > this kind of failure occurs at some point in the network. > > After more operational experience and several internal discussions we > agreed that we want packets to be forwarded unlabelled rather than > dropped. Anyone to share, or oppose this position? > > Best regards, Martin > > > Am 31.01.20 um 16:50 schrieb Martin Horneffer: > > Hello everyone, > > > > again it seems the interesting questions only show up when applying > > something to the live network... > > > > We ran into something that poses a question related to RFC8660: > What > > is the exact meaning of section 2.10.1, "Forwarding for PUSH and > > CONTINUE of Global SIDs", when the chosen neighbor doesn't > provide a > > valid MPLS path? > > > > The relevant sections reads: > > > >       -  Else, if there are other usable next hops, use them to > forward > >          the incoming packet.  The method by which the router "R0" > >          decides on the possibility of using other next hops is > beyond > >          the scope of this document.  For example, the MCC on > "R0" may > >          chose the send an IPv4 packet without pushing any label to > >          another next hop. > > > > Does the part "send an IPv4 packet without pushing any label" > apply to > > PUSH and CONTINUE, or just to PUSH? > > Does R0 have to validate that neighbor N can correctly process to > > packet? Or can it forward the packet regardless? > > > > The reason for asking is that we are now seeing issues similar > to ones > > we had when starting with LDP based MPLS about two decades ago: > > traffic being black holed even though a path to the destination > > exists, because the MPLS path is interrupted somewhere in the > middle. > > > > With LDP we know the case of LFIBentries called "unlabelled".. > While > > this does break connectivity for many kinds of service, e.g. those > > relying on an additional service labels, it still works for plain > > IP(v4) traffic. In our cases, this works perfectly fine for all > > internal routing and control traffic. And even for IPv4 traffic > that > > gets collected by a central router that injects a default route. > > > > However, depending on the exact interpretation of the above > paragraph, > > an implementor might feel obliged to chose the next paragraph: > > > >       -  Otherwise, drop the packet. > > > > Which is, at least in our case, very unfortunate... > > > > Any advice or opinion appreciated! > > > > > > Best regards, Martin > > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------9E9303A289B834A51E55492C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Robert,

    the setup I sketched does not cover double failures nor 100 % of all topological cases for forwarding.
    And in fact, forwarding the traffic is not the main purpose. The main purpose it to DETECT the failure in a useful way.

    For the same reason we would sure not want to add yet another encapsulation technology.

    But, of course, if the behavior (drop or forward unlabelled) would be configurable, that would be perfectly ok from my point of view.

    Best regards, Martin


    Am 27.08.20 um 14:45 schrieb Robert Raszuk:
    Martin,

    > it follows an IGP default route to a central device,  

    So putting aside that such default must point domian wide to the same address (could be anycast if you are careful) once this "central device" receives a packet and does a BGP full table lookup it will again try to encapsulate it in MPLS towards exit. 

    What if the path is again via a device which breaks LDP LSP or SR path and the packet will again go back to central device creating a very nice loop ? 

    Sure central device could give up on MPLS all together and IP encap to egress via your BGP free core - but you are not mentioning that. 

    Bottom line if you would not have BGP free core (or Internet route free core) I would say sure good idea to continue. But since you do I think this is a lot of hidden traps number of networks may fall into by doing it. So at least it should not be a default behaviour. 

    Thx,
    R.





    On Thu, Aug 27, 2020 at 12:35 PM Martin Horneffer <maho@lab.dtag.de> wrote:
    Hello everyone,

    may I come back the the question below? Or rather let me update it a little:

    In case an SR-MPLS path is broken, should a node rather drop the packet,
    or forward it?
    This can happen whenever the IGP points to a certain next hop, but that
    neither supplies a valid SID, nor allows LDP-stitching for whatever
    reason. For PUSH as well as for CONTINUE.

    We have been using MPLS transport and a BGP free core since about two
    decades now, using LDP. In the analog case, LDP creates "unlabelled"
    entries in the LFIB, does the equivalent of a POP operation and forwards
    the packet to the next-hop as chosen by the IGP.

    This behavior obviously breaks any traffic that relies on a service
    label, but it can protect some traffic.
    In our case a huge percentage of all traffic still is public IPv4. This
    needs MPLS only for a transport label, be it LDP or SR-MPLS. If this
    traffic gets forwarded unlabelled, it follows an IGP default route to a
    central device, where it is 1) redirected to the correct destination and
    2) counted in a way that operators can quickly see whether and where
    this kind of failure occurs at some point in the network.

    After more operational experience and several internal discussions we
    agreed that we want packets to be forwarded unlabelled rather than
    dropped. Anyone to share, or oppose this position?

    Best regards, Martin


    Am 31.01.20 um 16:50 schrieb Martin Horneffer:
    > Hello everyone,
    >
    > again it seems the interesting questions only show up when applying
    > something to the live network...
    >
    > We ran into something that poses a question related to RFC8660: What
    > is the exact meaning of section 2.10.1, "Forwarding for PUSH and
    > CONTINUE of Global SIDs", when the chosen neighbor doesn't provide a
    > valid MPLS path?
    >
    > The relevant sections reads:
    >
    >       -  Else, if there are other usable next hops, use them to forward
    >          the incoming packet.  The method by which the router "R0"
    >          decides on the possibility of using other next hops is beyond
    >          the scope of this document.  For example, the MCC on "R0" may
    >          chose the send an IPv4 packet without pushing any label to
    >          another next hop.
    >
    > Does the part "send an IPv4 packet without pushing any label" apply to
    > PUSH and CONTINUE, or just to PUSH?
    > Does R0 have to validate that neighbor N can correctly process to
    > packet? Or can it forward the packet regardless?
    >
    > The reason for asking is that we are now seeing issues similar to ones
    > we had when starting with LDP based MPLS about two decades ago:
    > traffic being black holed even though a path to the destination
    > exists, because the MPLS path is interrupted somewhere in the middle.
    >
    > With LDP we know the case of LFIBentries called "unlabelled".. While
    > this does break connectivity for many kinds of service, e.g. those
    > relying on an additional service labels, it still works for plain
    > IP(v4) traffic. In our cases, this works perfectly fine for all
    > internal routing and control traffic. And even for IPv4 traffic that
    > gets collected by a central router that injects a default route.
    >
    > However, depending on the exact interpretation of the above paragraph,
    > an implementor might feel obliged to chose the next paragraph:
    >
    >       -  Otherwise, drop the packet.
    >
    > Which is, at least in our case, very unfortunate...
    >
    > Any advice or opinion appreciated!
    >
    >
    > Best regards, Martin
    >
    >
    >
    >
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    > https://www.ietf.org/mailman/listinfo/spring

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    _______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

    --------------9E9303A289B834A51E55492C-- From nobody Fri Aug 28 03:13:32 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033693A08E5 for ; Fri, 28 Aug 2020 03:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=lab.dtag.de 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 0JQvJExI1ROu for ; Fri, 28 Aug 2020 03:13:28 -0700 (PDT) Received: from OldBailey.lab.dtag.de (OldBailey.lab.DTAG.DE [194.25.1.220]) (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 0DE653A0853 for ; Fri, 28 Aug 2020 03:13:27 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id C7D1CC1120; Fri, 28 Aug 2020 12:13:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1598609603; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=xczt3cE88B9dMcPR3o8A83K4xmKH0Aaumqd3FyxgogY=; b=Mie/ScMW6O+Yt6gm32IqV04QgD/1rNNtFJ0xd0ufeJUt9qvp4mO6c8I41T/JRuasNnWbpC 7H55mDQpVoTCqEgv137vKCaxz/fqYJ3xo/mXcKE4JJhzUIavBoXwJhY7QY7EmlOe75dbq8 mWbC+25eVu/cChDWFug84iZhAeO6DAPx3CWyaQneqzg64P6sbOmJAQcpHVrNgj+ymPe8xP 0Rwh7BFVQUdHfzKPnIJ1Emh912CPzjLfaOMvwbXsF26mp3dJ4jORtYxOrQUCbnY5SWoQ7M EPE90Oe7Rb4gkMwRN5VziXzFXwNAL4lfBHr19Wt8OF98+AbT7+nBjw4UgL+Pbw== To: peng.shaofu@zte.com.cn Cc: spring@ietf.org References: <202008281131380547490@zte.com.cn> From: Martin Horneffer Message-ID: <05d5bf15-9d7a-a093-d32f-e3af839bd41e@lab.dtag.de> Date: Fri, 28 Aug 2020 12:13:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <202008281131380547490@zte.com.cn> Content-Type: multipart/alternative; boundary="------------173249FF22F82B138A614718" X-Last-TLS-Session-Version: TLSv1.3 Archived-At: Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 10:13:31 -0000 This is a multi-part message in MIME format. --------------173249FF22F82B138A614718 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi PSF, limiting the "forward unlabelled" behavior to packets with the bottom-of-stack bit set is an interesting idea. I haven't though about that yet. In my case that would definitely help and be perfectly ok. Best regards, Martin Am 28.08.20 um 05:31 schrieb peng.shaofu@zte.com.cn: > > > Hi Martin, > > > For the matched LFIB entry with unlabeled outgoing forwarding > information, I agree your opinion that public traffic need to be > forwarded. > > I think the above LFIB entry can easiely drop VPN traffic according to > no bottom flag of incomming LDP/SR label. > > > Regards, > > PSF > > > > 原始邮件 > *å‘件人：*MartinHorneffer > *收件人：*spring@ietf.org ; > *æ—¥ 期 ：*2020å¹´08月27æ—¥ 18:35 > *主 题 ：**[spring] to drop or to forward unlabelled (Re: Question on > RFC8660)* > Hello everyone, > > may I come back the the question below? Or rather let me update it a little: > > In case an SR-MPLS path is broken, should a node rather drop the packet, > or forward it? > This can happen whenever the IGP points to a certain next hop, but that > neither supplies a valid SID, nor allows LDP-stitching for whatever > reason. For PUSH as well as for CONTINUE. > > We have been using MPLS transport and a BGP free core since about two > decades now, using LDP. In the analog case, LDP creates "unlabelled" > entries in the LFIB, does the equivalent of a POP operation and forwards > the packet to the next-hop as chosen by the IGP. > > This behavior obviously breaks any traffic that relies on a service > label, but it can protect some traffic. > In our case a huge percentage of all traffic still is public IPv4. This > needs MPLS only for a transport label, be it LDP or SR-MPLS. If this > traffic gets forwarded unlabelled, it follows an IGP default route to a > central device, where it is 1) redirected to the correct destination and > 2) counted in a way that operators can quickly see whether and where > this kind of failure occurs at some point in the network. > > After more operational experience and several internal discussions we > agreed that we want packets to be forwarded unlabelled rather than > dropped. Anyone to share, or oppose this position? > > Best regards, Martin > > > Am 31.01.20 um 16:50 schrieb Martin Horneffer: > > Hello everyone, > > > > again it seems the interesting questions only show up when applying > > something to the live network... > > > > We ran into something that poses a question related to RFC8660: What > > is the exact meaning of section 2.10.1, "Forwarding for PUSH and > > CONTINUE of Global SIDs", when the chosen neighbor doesn't provide a > > valid MPLS path? > > > > The relevant sections reads: > > > >       -  Else, if there are other usable next hops, use them to forward > >          the incoming packet.  The method by which the router "R0" > >          decides on the possibility of using other next hops is beyond > >          the scope of this document.  For example, the MCC on "R0" may > >          chose the send an IPv4 packet without pushing any label to > >          another next hop. > > > > Does the part "send an IPv4 packet without pushing any label" apply to > > PUSH and CONTINUE, or just to PUSH? > > Does R0 have to validate that neighbor N can correctly process to > > packet? Or can it forward the packet regardless? > > > > The reason for asking is that we are now seeing issues similar to ones > > we had when starting with LDP based MPLS about two decades ago: > > traffic being black holed even though a path to the destination > > exists, because the MPLS path is interrupted somewhere in the middle. > > > > With LDP we know the case of LFIBentries called "unlabelled". While > > this does break connectivity for many kinds of service, e.g. those > > relying on an additional service labels, it still works for plain > > IP(v4) traffic. In our cases, this works perfectly fine for all > > internal routing and control traffic. And even for IPv4 traffic that > > gets collected by a central router that injects a default route. > > > > However, depending on the exact interpretation of the above paragraph, > > an implementor might feel obliged to chose the next paragraph: > > > >       -  Otherwise, drop the packet. > > > > Which is, at least in our case, very unfortunate... > > > > Any advice or opinion appreciated! > > > > > > Best regards, Martin > > > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------173249FF22F82B138A614718 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi PSF,

    limiting the "forward unlabelled" behavior to packets with the bottom-of-stack bit set is an interesting idea. I haven't though about that yet. In my case that would definitely help and be perfectly ok.

    Best regards, Martin


    Am 28.08.20 um 05:31 schrieb peng.shaofu@zte.com.cn:


    Hi Martin,


    For the matched LFIB entry with unlabeled outgoing forwarding information, I agree your opinion that public traffic need to be forwarded. 

    I think the above LFIB entry can easiely drop VPN traffic according to no bottom flag of incomming LDP/SR label.


    Regards,

    PSF



    原始邮件
    å‘件人：MartinHorneffer <maho@lab.dtag.de>
    收件人：spring@ietf.org <spring@ietf.org>;
    日 期 ：2020年08月27日 18:35
    主 题 ：[spring] to drop or to forward unlabelled (Re: Question on RFC8660)
    Hello everyone,

    may I come back the the question below? Or rather let me update it a little:

    In case an SR-MPLS path is broken, should a node rather drop the packet, 
    or forward it?
    This can happen whenever the IGP points to a certain next hop, but that 
    neither supplies a valid SID, nor allows LDP-stitching for whatever 
    reason. For PUSH as well as for CONTINUE.

    We have been using MPLS transport and a BGP free core since about two 
    decades now, using LDP. In the analog case, LDP creates "unlabelled" 
    entries in the LFIB, does the equivalent of a POP operation and forwards 
    the packet to the next-hop as chosen by the IGP.

    This behavior obviously breaks any traffic that relies on a service 
    label, but it can protect some traffic.
    In our case a huge percentage of all traffic still is public IPv4. This 
    needs MPLS only for a transport label, be it LDP or SR-MPLS. If this 
    traffic gets forwarded unlabelled, it follows an IGP default route to a 
    central device, where it is 1) redirected to the correct destination and 
    2) counted in a way that operators can quickly see whether and where 
    this kind of failure occurs at some point in the network.

    After more operational experience and several internal discussions we 
    agreed that we want packets to be forwarded unlabelled rather than 
    dropped. Anyone to share, or oppose this position?

    Best regards, Martin


    Am 31.01.20 um 16:50 schrieb Martin Horneffer:
    > Hello everyone,
    >
    > again it seems the interesting questions only show up when applying 
    > something to the live network...
    >
    > We ran into something that poses a question related to RFC8660: What 
    > is the exact meaning of section 2.10.1, "Forwarding for PUSH and 
    > CONTINUE of Global SIDs", when the chosen neighbor doesn't provide a 
    > valid MPLS path?
    >
    > The relevant sections reads:
    >
    >       -  Else, if there are other usable next hops, use them to forward
    >          the incoming packet.  The method by which the router "R0"
    >          decides on the possibility of using other next hops is beyond
    >          the scope of this document.  For example, the MCC on "R0" may
    >          chose the send an IPv4 packet without pushing any label to
    >          another next hop.
    >
    > Does the part "send an IPv4 packet without pushing any label" apply to 
    > PUSH and CONTINUE, or just to PUSH?
    > Does R0 have to validate that neighbor N can correctly process to 
    > packet? Or can it forward the packet regardless?
    >
    > The reason for asking is that we are now seeing issues similar to ones 
    > we had when starting with LDP based MPLS about two decades ago: 
    > traffic being black holed even though a path to the destination 
    > exists, because the MPLS path is interrupted somewhere in the middle.
    >
    > With LDP we know the case of LFIBentries called "unlabelled". While 
    > this does break connectivity for many kinds of service, e.g. those 
    > relying on an additional service labels, it still works for plain 
    > IP(v4) traffic. In our cases, this works perfectly fine for all 
    > internal routing and control traffic. And even for IPv4 traffic that 
    > gets collected by a central router that injects a default route.
    >
    > However, depending on the exact interpretation of the above paragraph, 
    > an implementor might feel obliged to chose the next paragraph:
    >
    >       -  Otherwise, drop the packet.
    >
    > Which is, at least in our case, very unfortunate...
    >
    > Any advice or opinion appreciated!
    >
    >
    > Best regards, Martin
    >
    >
    >
    >
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    > https://www.ietf.org/mailman/listinfo/spring

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring



    _______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

    --------------173249FF22F82B138A614718-- From nobody Fri Aug 28 11:31:15 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED633A0114 for ; Fri, 28 Aug 2020 11:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Nk2HC0oV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T/TV1dZF 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 Ux6mASkSkJjV for ; Fri, 28 Aug 2020 11:31:11 -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 E8DEC3A0112 for ; Fri, 28 Aug 2020 11:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6184; q=dns/txt; s=iport; t=1598639470; x=1599849070; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dRrsZIDXtI09kknXOBldIfkn7gcRJXeOkVySRp67tTg=; b=Nk2HC0oVEQ5qu4R825pe6CznIB6KEPn1sYQpKoMAWVd6ODIkzGqi+ygY 5cy1aek4jHq6vdUCwkTv6jj0oLxdQPg4Z66UFE+FLBBrSnHNfbVPLmLX3 uztZUlfCAfeJFHQekZqq2StaNYdTmlQ8uFOl1HcWyaMHDjOWsVJ3Ufuxq k=; IronPort-PHdr: =?us-ascii?q?9a23=3ABia+yxeBPRhM56Dc74m9bCzslGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQDdff4vgCh/bfvObsVD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Wq3f04SIbFV?= =?us-ascii?q?PzOFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnIQD4TElf/4oNJK1fHAEBATwBAQQ?= =?us-ascii?q?EAQECAQEHAQEVgUyBPAIBAQEBDikoB3BYLyyEOINGA410mHGCUwNVCwEBAQw?= =?us-ascii?q?BARgLCgIEAQGECEQCF4IyAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQE?= =?us-ascii?q?DAQEQEREMAQEsDAsEAgEGAg4DBAEBAwImAgICJQsVCAgCBAESCBqDBYJLAy4?= =?us-ascii?q?BDpZLkGgCgTmIYXaBMoMBAQEFhTQYghADBoEOKAIBAQEBAQGCa4JXS0OGTxu?= =?us-ascii?q?BQT+BEUOCTT6BBIFYAQGBYYMVM4Itj36DGKJFgQgKgmSaUYMHnUOSTYFtmTu?= =?us-ascii?q?EKAIEAgQFAg4BAQWBayOBV3AVO4JpUBcCDY4rF4ECAQmCQoUUhUJ0NwIGAQk?= =?us-ascii?q?BAQMJfIkiLYIXAQE?= X-IronPort-AV: E=Sophos;i="5.76,364,1592870400"; d="scan'208";a="548165999" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Aug 2020 18:31:09 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 07SIV9Et011767 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2020 18:31:09 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 28 Aug 2020 13:31:09 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 28 Aug 2020 14:31:08 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 28 Aug 2020 14:31:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lRAiEElWHYK9dimcdp4Ag1jqZsy4NXY18kfs9g+YP96xEucCqtmQj6/DSounPu2fj+p5fiWUgHDsrCLQ404dubNQ0vSHIFbqdXAwG3IwlKGfoBJ1hLqIBc+YvkNUX63oRPA9/9vPyMSbXXGTH+ACjrg/gNHmUcTitvFkjJJiXZfHrgjzhzBOy32nDJkWzJawr3nTBmL57qMgfNAblA9Kwggn0hTgRycnuhigJuN8aDi6xqrLzEpZflJgFDCG6/wSd6HTyVzNAgPEYgFrc43j+UimnVOPMRnPypC5eFUcYcGJVDBRpxddOfnC5dt+j93gyVYBNa6tjeCSGkwRxir+Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dRrsZIDXtI09kknXOBldIfkn7gcRJXeOkVySRp67tTg=; b=jSF/zF89/Uo42Qn7AxFsBOTdSMvboyz7V389N0DcO1rrSrl9pfpr18vG8OFG9vdcHhQbhb6dogFzf3dCtrKxDqM6FxzWVnxTELj9inW7xl36sh6APlhSMwpwl7T07ICFBMs4I5F3RpMDrJdtEtOELkH2YfMucn6EEIkGnGghKAIt5N9uCyU4OvoqtvRpOYoFVuUkTRZMjRYRBTgujvwd4IPlV8xl2LDEPAB6z8EDk6ZoiaaKjMkOOc0r8zDOkOyCMlrfqxqb34dWbs8kS92sJHvmBxYRvhTaVUPuv5ysGzXAOTuLn2TCU5y88sxIbukpa6cm3Cx2eYId6TXqzXX1Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dRrsZIDXtI09kknXOBldIfkn7gcRJXeOkVySRp67tTg=; b=T/TV1dZF0PqQ9kBScP+x1L14VTQ/ZVlbhC5l+o0bwkfOD/559Xrc+psCiuULUcSkvdH/A15V8KbkePKE5A5E+5nmldOFTaO5fua9+drY1802Qlh6N85syjitwBRo5uTt+1l/DK2JxEyl/hbJ8DX6UwWIUFg76cHDqccKGUMimgk= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3205.namprd11.prod.outlook.com (2603:10b6:a03:1e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Fri, 28 Aug 2020 18:31:08 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e857:a3fb:11ad:faff]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e857:a3fb:11ad:faff%2]) with mapi id 15.20.3326.023; Fri, 28 Aug 2020 18:31:08 +0000 From: "Jakob Heitz (jheitz)" To: Martin Horneffer , "spring@ietf.org" Thread-Topic: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) Thread-Index: AQHWfF3Pqlu9eBrlr0q+WATlLptSIalN2AtA Date: Fri, 28 Aug 2020 18:31:08 +0000 Message-ID: References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> In-Reply-To: <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lab.dtag.de; dkim=none (message not signed) header.d=none;lab.dtag.de; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:934:5c1d:b9a:bda8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad053236-8913-45e7-77d4-08d84b8087f4 x-ms-traffictypediagnostic: BYAPR11MB3205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OiFlvPwLxE0cGRH81hKOfCK1TF3xd9c0JxIqRY/Orv13cIfks1jsz7E/8Mzy/qmzZxDi8voBIu6FDpz5cIAaZUW638jAuCMDPke9580vwEts5Z9aNH6Sxrea6NNC0IX8r1izdmcUjAoETCO0wNPf1kzLqgdApEw0Sy+Ds3QrBq6OJLhhwfuTeihcqV5MRYsy01tfSXnnjuv7ptICUL2AjgeOwHDa6yC0LqOiiuDymI1Hz7PY3fR29ajIiOWJ+mAGwx1HKjVD8pP+NaFrckyjPycgSROjDD5Eu/OJhBCZOHlIt1rMkE61diHK3upMMPx2PuNW+lnkXO+enBJQuRuJclriM5PG7HbINNSu1r2+R5ghBAklEPSimMRpzozLD84YAZYmSGzyWQwABlVg5NWK4g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(136003)(39860400002)(366004)(53546011)(86362001)(6506007)(966005)(2906002)(9686003)(33656002)(55016002)(478600001)(64756008)(71200400001)(8676002)(5660300002)(7696005)(66556008)(110136005)(76116006)(66946007)(83380400001)(52536014)(8936002)(66446008)(66574015)(316002)(186003)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: sE/M9YaIhZiRTHp/8nEKz+U0I3cG58AmtmrLQR89VrEf05QK581TWnGoNUr+oLQlBl5C1o59gQRBP3Q9uVAy8+HyuntO3SvsfbtsYgzMD0Rt7Vgu2s6i7KN5DMz2rvJGTLnHwuX/uTsoXnJ3K0jkvh8RT/RFP4Lvz8fzR3UlczG9Z6L/XG4jLCVZXnYD0IULAukEc7N2wQKyF3m6BbwzOBnMQg/7bJCkiaLYrMir9NNLFHvjNlCrAUFzjeQLaykqirB5FB9lt78VksCZlTkavT37tDj6T9kq42H8WXy3ZHa2oR3+uH8Uuq5sPp5EqKqhNHV8MOOY0SObqPkwZT1RK9jsodfb8EzeYKshdN6CHz9lDu6DdCSUnK2nbNwM/TxcYaoRX02bm//3Ua3FRl5p7uwfkliQ/O1zJP9cQ/toTZhiUykkDISN8Mg3i2lZ/K5LUm08jlJBwkk2hkq+ElddnmxnvXVKtETOd9ntlhCYt1pU8qb/cDnxC2GNZStZfOM3X1jypoVf6rgmLtz0GQ9HOYG+Qh6SU0a9uEN8US+pgGSFCYmlzWvM/34WCaW73Rn67O5so0Mfda7/nrybfA31hmZ0onmHv6HgE1M2jq5X7N97yP1TxTSLBJwiwlD5MxBJ5AP8t27mcrsJkjCdrsh0rhrZIWGJXrmfMYGwjsEnXLWM+Fotvhn5CdxA/eAc6jImbn0SItfng1XPrNFMnhy9Ig== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad053236-8913-45e7-77d4-08d84b8087f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2020 18:31:08.0538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UO8aEVD3DllZcyv+86RV1ayT91g0NQad98lWaVmOlm4ixygPpF0bIBKwzb2mQKOzsFrNLiQdOT0KTUJcxBGg0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3205 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 18:31:13 -0000 SXQgYWxsIGhpbmdlcyBvbiAidXNlYWJsZSBuZXh0IGhvcHMiLiBJZiB0aGUgY29ubmVjdGVkIG5l eHQgaG9wDQooYSBiZ3AgbmV4dCBob3AgbWF5IG5vdCBiZSBjb25uZWN0ZWQpIGhhcyBhIGNvcnJl Y3Qgcm91dGUgZm9yIHRoZQ0KcGFja2V0LCB0aGVuIGl0IGlzIHVzZWFibGUuDQoNCk9uZSBtb3Jl IGNvbnNpZGVyYXRpb246IFdpdGggdGhlIEJHUCBmcmVlIGNvcmUsIGV4dGVybmFsIGRldmljZXMN CmNhbm5vdCBzZW5kIHBhY2tldHMgdG8geW91ciBpbnRlcm5hbCByb3V0ZXJzLiBPbmNlIHlvdSBh bGxvdyB0bw0KZm9yd2FyZCBwYWNrZXRzIHdpdGhvdXQgYSBsYWJlbGxlZCByb3V0ZSwgeW91IG5l ZWQgdG8gbWFrZSBzdXJlIHRoYXQNCnRoaXMgcHJvdGVjdGlvbiByZW1haW5zLg0KDQpSZWdhcmRz LA0KSmFrb2IuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzcHJpbmcgPHNw cmluZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGluIEhvcm5lZmZlcg0KU2Vu dDogVGh1cnNkYXksIEF1Z3VzdCAyNywgMjAyMCAzOjM1IEFNDQpUbzogc3ByaW5nQGlldGYub3Jn DQpTdWJqZWN0OiBbc3ByaW5nXSB0byBkcm9wIG9yIHRvIGZvcndhcmQgdW5sYWJlbGxlZCAoUmU6 IFF1ZXN0aW9uIG9uIFJGQzg2NjApDQoNCkhlbGxvIGV2ZXJ5b25lLA0KDQptYXkgSSBjb21lIGJh Y2sgdGhlIHRoZSBxdWVzdGlvbiBiZWxvdz8gT3IgcmF0aGVyIGxldCBtZSB1cGRhdGUgaXQgYSBs aXR0bGU6DQoNCkluIGNhc2UgYW4gU1ItTVBMUyBwYXRoIGlzIGJyb2tlbiwgc2hvdWxkIGEgbm9k ZSByYXRoZXIgZHJvcCB0aGUgcGFja2V0LCANCm9yIGZvcndhcmQgaXQ/DQpUaGlzIGNhbiBoYXBw ZW4gd2hlbmV2ZXIgdGhlIElHUCBwb2ludHMgdG8gYSBjZXJ0YWluIG5leHQgaG9wLCBidXQgdGhh dCANCm5laXRoZXIgc3VwcGxpZXMgYSB2YWxpZCBTSUQsIG5vciBhbGxvd3MgTERQLXN0aXRjaGlu ZyBmb3Igd2hhdGV2ZXIgDQpyZWFzb24uIEZvciBQVVNIIGFzIHdlbGwgYXMgZm9yIENPTlRJTlVF Lg0KDQpXZSBoYXZlIGJlZW4gdXNpbmcgTVBMUyB0cmFuc3BvcnQgYW5kIGEgQkdQIGZyZWUgY29y ZSBzaW5jZSBhYm91dCB0d28gDQpkZWNhZGVzIG5vdywgdXNpbmcgTERQLiBJbiB0aGUgYW5hbG9n IGNhc2UsIExEUCBjcmVhdGVzICJ1bmxhYmVsbGVkIiANCmVudHJpZXMgaW4gdGhlIExGSUIsIGRv ZXMgdGhlIGVxdWl2YWxlbnQgb2YgYSBQT1Agb3BlcmF0aW9uIGFuZCBmb3J3YXJkcyANCnRoZSBw YWNrZXQgdG8gdGhlIG5leHQtaG9wIGFzIGNob3NlbiBieSB0aGUgSUdQLg0KDQpUaGlzIGJlaGF2 aW9yIG9idmlvdXNseSBicmVha3MgYW55IHRyYWZmaWMgdGhhdCByZWxpZXMgb24gYSBzZXJ2aWNl IA0KbGFiZWwsIGJ1dCBpdCBjYW4gcHJvdGVjdCBzb21lIHRyYWZmaWMuDQpJbiBvdXIgY2FzZSBh IGh1Z2UgcGVyY2VudGFnZSBvZiBhbGwgdHJhZmZpYyBzdGlsbCBpcyBwdWJsaWMgSVB2NC4gVGhp cyANCm5lZWRzIE1QTFMgb25seSBmb3IgYSB0cmFuc3BvcnQgbGFiZWwsIGJlIGl0IExEUCBvciBT Ui1NUExTLiBJZiB0aGlzIA0KdHJhZmZpYyBnZXRzIGZvcndhcmRlZCB1bmxhYmVsbGVkLCBpdCBm b2xsb3dzIGFuIElHUCBkZWZhdWx0IHJvdXRlIHRvIGEgDQpjZW50cmFsIGRldmljZSwgd2hlcmUg aXQgaXMgMSkgcmVkaXJlY3RlZCB0byB0aGUgY29ycmVjdCBkZXN0aW5hdGlvbiBhbmQgDQoyKSBj b3VudGVkIGluIGEgd2F5IHRoYXQgb3BlcmF0b3JzIGNhbiBxdWlja2x5IHNlZSB3aGV0aGVyIGFu ZCB3aGVyZSANCnRoaXMga2luZCBvZiBmYWlsdXJlIG9jY3VycyBhdCBzb21lIHBvaW50IGluIHRo ZSBuZXR3b3JrLg0KDQpBZnRlciBtb3JlIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgYW5kIHNldmVy YWwgaW50ZXJuYWwgZGlzY3Vzc2lvbnMgd2UgDQphZ3JlZWQgdGhhdCB3ZSB3YW50IHBhY2tldHMg dG8gYmUgZm9yd2FyZGVkIHVubGFiZWxsZWQgcmF0aGVyIHRoYW4gDQpkcm9wcGVkLiBBbnlvbmUg dG8gc2hhcmUsIG9yIG9wcG9zZSB0aGlzIHBvc2l0aW9uPw0KDQpCZXN0IHJlZ2FyZHMsIE1hcnRp bg0KDQoNCkFtIDMxLjAxLjIwIHVtIDE2OjUwIHNjaHJpZWIgTWFydGluIEhvcm5lZmZlcjoNCj4g SGVsbG8gZXZlcnlvbmUsDQo+DQo+IGFnYWluIGl0IHNlZW1zIHRoZSBpbnRlcmVzdGluZyBxdWVz dGlvbnMgb25seSBzaG93IHVwIHdoZW4gYXBwbHlpbmcgDQo+IHNvbWV0aGluZyB0byB0aGUgbGl2 ZSBuZXR3b3JrLi4uDQo+DQo+IFdlIHJhbiBpbnRvIHNvbWV0aGluZyB0aGF0IHBvc2VzIGEgcXVl c3Rpb24gcmVsYXRlZCB0byBSRkM4NjYwOiBXaGF0IA0KPiBpcyB0aGUgZXhhY3QgbWVhbmluZyBv ZiBzZWN0aW9uIDIuMTAuMSwgIkZvcndhcmRpbmcgZm9yIFBVU0ggYW5kIA0KPiBDT05USU5VRSBv ZiBHbG9iYWwgU0lEcyIsIHdoZW4gdGhlIGNob3NlbiBuZWlnaGJvciBkb2Vzbid0IHByb3ZpZGUg YSANCj4gdmFsaWQgTVBMUyBwYXRoPw0KPg0KPiBUaGUgcmVsZXZhbnQgc2VjdGlvbnMgcmVhZHM6 DQo+DQo+IMKgwqDCoMKgwqAgLcKgIEVsc2UsIGlmIHRoZXJlIGFyZSBvdGhlciB1c2FibGUgbmV4 dCBob3BzLCB1c2UgdGhlbSB0byBmb3J3YXJkDQo+IMKgwqDCoMKgwqDCoMKgwqAgdGhlIGluY29t aW5nIHBhY2tldC7CoCBUaGUgbWV0aG9kIGJ5IHdoaWNoIHRoZSByb3V0ZXIgIlIwIg0KPiDCoMKg wqDCoMKgwqDCoMKgIGRlY2lkZXMgb24gdGhlIHBvc3NpYmlsaXR5IG9mIHVzaW5nIG90aGVyIG5l eHQgaG9wcyBpcyBiZXlvbmQNCj4gwqDCoMKgwqDCoMKgwqDCoCB0aGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudC7CoCBGb3IgZXhhbXBsZSwgdGhlIE1DQyBvbiAiUjAiIG1heQ0KPiDCoMKgwqDCoMKg wqDCoMKgIGNob3NlIHRoZSBzZW5kIGFuIElQdjQgcGFja2V0IHdpdGhvdXQgcHVzaGluZyBhbnkg bGFiZWwgdG8NCj4gwqDCoMKgwqDCoMKgwqDCoCBhbm90aGVyIG5leHQgaG9wLg0KPg0KPiBEb2Vz IHRoZSBwYXJ0ICJzZW5kIGFuIElQdjQgcGFja2V0IHdpdGhvdXQgcHVzaGluZyBhbnkgbGFiZWwi IGFwcGx5IHRvIA0KPiBQVVNIIGFuZCBDT05USU5VRSwgb3IganVzdCB0byBQVVNIPw0KPiBEb2Vz IFIwIGhhdmUgdG8gdmFsaWRhdGUgdGhhdCBuZWlnaGJvciBOIGNhbiBjb3JyZWN0bHkgcHJvY2Vz cyB0byANCj4gcGFja2V0PyBPciBjYW4gaXQgZm9yd2FyZCB0aGUgcGFja2V0IHJlZ2FyZGxlc3M/ DQo+DQo+IFRoZSByZWFzb24gZm9yIGFza2luZyBpcyB0aGF0IHdlIGFyZSBub3cgc2VlaW5nIGlz c3VlcyBzaW1pbGFyIHRvIG9uZXMgDQo+IHdlIGhhZCB3aGVuIHN0YXJ0aW5nIHdpdGggTERQIGJh c2VkIE1QTFMgYWJvdXQgdHdvIGRlY2FkZXMgYWdvOiANCj4gdHJhZmZpYyBiZWluZyBibGFjayBo b2xlZCBldmVuIHRob3VnaCBhIHBhdGggdG8gdGhlIGRlc3RpbmF0aW9uIA0KPiBleGlzdHMsIGJl Y2F1c2UgdGhlIE1QTFMgcGF0aCBpcyBpbnRlcnJ1cHRlZCBzb21ld2hlcmUgaW4gdGhlIG1pZGRs ZS4NCj4NCj4gV2l0aCBMRFAgd2Uga25vdyB0aGUgY2FzZSBvZiBMRklCZW50cmllcyBjYWxsZWQg InVubGFiZWxsZWQiLiBXaGlsZSANCj4gdGhpcyBkb2VzIGJyZWFrIGNvbm5lY3Rpdml0eSBmb3Ig bWFueSBraW5kcyBvZiBzZXJ2aWNlLCBlLmcuIHRob3NlIA0KPiByZWx5aW5nIG9uIGFuIGFkZGl0 aW9uYWwgc2VydmljZSBsYWJlbHMsIGl0IHN0aWxsIHdvcmtzIGZvciBwbGFpbiANCj4gSVAodjQp IHRyYWZmaWMuIEluIG91ciBjYXNlcywgdGhpcyB3b3JrcyBwZXJmZWN0bHkgZmluZSBmb3IgYWxs IA0KPiBpbnRlcm5hbCByb3V0aW5nIGFuZCBjb250cm9sIHRyYWZmaWMuIEFuZCBldmVuIGZvciBJ UHY0IHRyYWZmaWMgdGhhdCANCj4gZ2V0cyBjb2xsZWN0ZWQgYnkgYSBjZW50cmFsIHJvdXRlciB0 aGF0IGluamVjdHMgYSBkZWZhdWx0IHJvdXRlLg0KPg0KPiBIb3dldmVyLCBkZXBlbmRpbmcgb24g dGhlIGV4YWN0IGludGVycHJldGF0aW9uIG9mIHRoZSBhYm92ZSBwYXJhZ3JhcGgsIA0KPiBhbiBp bXBsZW1lbnRvciBtaWdodCBmZWVsIG9ibGlnZWQgdG8gY2hvc2UgdGhlIG5leHQgcGFyYWdyYXBo Og0KPg0KPiDCoMKgwqDCoMKgIC3CoCBPdGhlcndpc2UsIGRyb3AgdGhlIHBhY2tldC4NCj4NCj4g V2hpY2ggaXMsIGF0IGxlYXN0IGluIG91ciBjYXNlLCB2ZXJ5IHVuZm9ydHVuYXRlLi4uDQo+DQo+ IEFueSBhZHZpY2Ugb3Igb3BpbmlvbiBhcHByZWNpYXRlZCENCj4NCj4NCj4gQmVzdCByZWdhcmRz LCBNYXJ0aW4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiBzcHJpbmdAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5n IGxpc3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmcNCg== From nobody Fri Aug 28 20:46:28 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEC63A1034 for ; Fri, 28 Aug 2020 20:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, PDS_BTC_ID=0.499, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QrC7Lt-7hc0W for ; Fri, 28 Aug 2020 20:46: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 C50B13A102B for ; Fri, 28 Aug 2020 20:46:17 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id ECD33F917D33F341320F; Sat, 29 Aug 2020 04:46:15 +0100 (IST) Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 29 Aug 2020 04:46:14 +0100 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Sat, 29 Aug 2020 04:46:14 +0100 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.60]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Sat, 29 Aug 2020 11:46:10 +0800 From: "Chengli (Cheng Li)" To: Alexander Vainshtein , Martin Horneffer CC: "spring@ietf.org" , Robert Raszuk , "EXT-Andrew.Alston@liquidtelecom.com" , Shraddha Hegde , "Ketan Talaulikar (ketant)" , "Joel M. Halpern" Thread-Topic: [spring] Spring protection - determining applicability Thread-Index: AQHWaSfMxHlh+yzcCkewTBiyswjXMaklNGAAgAA0D4CAAMHVAIAABZ6AgAABgICAADUsgIAAC1WAgAAdJ4CAAGzfgIAAFLcAgAB1eACAD4ZiAIAADy+AgAAIGQCAABlPgIAACqaAgAAC7QCAAAmcgIAAFWuAgAADZQCABhhmgIAADwSAgA+hnYD//46tgIAB1LPg Date: Sat, 29 Aug 2020 03:46:10 +0000 Message-ID: References: <7e29a863-70e9-f0a8-638f-5151348be515@joelhalpern.com> <4692aa7f-babe-71c3-970f-b448f4bb8343@lab.dtag.de> , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.130] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9DE44dggeml509mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Spring protection - determining applicability X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 03:46:27 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9DE44dggeml509mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, Agree. This is not the topic about to adopt a draft or not. I also support = the adoption. :) Regarding the not bypassable flag for prefix SID, thanks for your input. Wi= ll update the draft after we have enough discussion in the mailing list. Se= ems like we are heading to the same direction, that is wonderful! Thanks, Cheng From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Alexander Vainsh= tein Sent: Friday, August 28, 2020 3:41 PM To: Chengli (Cheng Li) ; Alexander Vainshtein ; Martin Horneffer Cc: spring@ietf.org; Robert Raszuk ; EXT-Andrew.Alston@l= iquidtelecom.com ; Shraddha Hegde ; Ketan Talaulikar (ketant) ; Joel M. Halpern Subject: Re: [spring] Spring protection - determining applicability Cheng and all, A few short comments. 1. I support the idea to mark some IGP Prefix SIDs as "not bypassable" 2. I think that, while such marking is not yet available the neighbors = of a node that advertises itself as a "stub node" in IGP MAY use this as a = hint that Node SIDs advertised by this node are "not bypassable". 3. I do not think that B-flag in the advertisment of Adj-SIDs can be use= d as n indication that it can be bypassed - the current semantics of this f= lag is different. 4. At the same time I do not think that ability to advertise a certain = Adj-SID as leading to a not bypassable node is needed or would be useful. A= bility of the operator to exclude acific neighbor from protection would suf= fice, especially in the case of local Adj-SID. 5. Last bot not least, I think that none of the above must be addressed= befire adoption of the draft as a SPRING WG document. My 2c, Sasha Get Outlook for Android ________________________________ From: spring > on b= ehalf of Chengli (Cheng Li) > Sent: Friday, August 28, 2020, 09:37 To: Alexander Vainshtein; Martin Horneffer Cc: spring@ietf.org; Robert Raszuk; EXT-Andrew.Alst= on@liquidtelecom.com; Shraddha = Hegde; Ketan Talaulikar (ketant); Joel M. Halpern Subject: Re: [spring] Spring protection - determining applicability Hi Sasha and Martin, Many thanks for your input. I fully agree with your point of we need to con= sider to advertise the ability of the node to advertise a specific Prefix S= ID it originates as "not eligible for bypass protection". Also, this extension should be written in a protection document like Martin= said. We have a strawman draft posed 1 year ago [1], but it has not been d= iscussed yet. The main idea of the draft is to add a no-bypass flag into S= ID(including Prefix SID, and adj-SID). But we are discussing with some expe= rts that do we need the No-bypass flag for Adj-SID or not, it seems like we= have a B flag already. It is so nice to see this point is raised and discussed. Also, welcome to r= eview the document, and hope to have your valuable comments. Respect, Cheng [1]. https://tools.ietf.org/html/draft-li-rtgwg-enhanced-ti-lfa-02 From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Alexander Vainsh= tein Sent: Tuesday, August 18, 2020 11:44 PM To: Martin Horneffer > Cc: spring@ietf.org; Robert Raszuk >; EXT-Andrew.Alston@liquidtelecom.com >; Shraddha Hegde >; Ketan Talaulikar (ketant) >; Joel M. Halp= ern > Subject: Re: [spring] Spring protection - determining applicability Martin, Lots of thanks for an important input to this discussion. I fully agree with you that ability to turn off the node protection scheme = for a specific PLR neighbor (i.e., on a specific PLR port) by suitable loca= l configuration in the PLR is definitely required. Such an ability would pr= obably address most (if not all) scenarios associated with the so-called "s= ervice nodes" that cannot be bypassed. I also think that service nodes that cannot be bypassed typically would adv= ertise themselves as "stub nodes" in IGP in order to prevent inadvertent ap= plication of their service function to transit traffic (which could otherwi= se pass thru the service node due to some topology change). Therefore a loc= al policy that would exclude IGP neighbors advertising themselves as stub = nodes in IGP from the node protection scheme could be also useful. Last but not least, ability of the node to advertise a specific Prefix SID = it originates as "not eligible for bypass protection" (e.g., using a new fl= ag in the Prefix Node TLV for IS-IS or OSPF) should be considered. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: spring > On B= ehalf Of Martin Horneffer Sent: Tuesday, August 18, 2020 5:51 PM To: spring@ietf.org Cc: Alexander Vainshtein >; Robert Raszuk >; EXT-Andrew.Alston@liquidtelecom.com >; Shraddha Hegde >; Ketan Talaulikar (ketant) >; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability A few thoughts from my (operator's) PoV: - The disussion is a very good and important one. It probably should be di= scussed and documented well in order to justify the proposed protections me= chanisms. - Not all operators seem to have the same requirements. (A somewhat similar discussion might be the one for disjoint paths. Tho= se are often equired by voice signalling applications. In some cases the vo= ice service demands that traffic is blackholed rather than on forwarded on = the wrong path. In other cases disjoint paths are just required for the "go= od case". Traffic MAY be forwarded on the wrong path, as long as the networ= k just makes sure the traffic on the other path is never affected by the sa= me failure.) - Personally I would hate to see yet another IGP extension for this purpos= e. - I would rather prefer a good discussion of what can be achieved by using= easy to make switches: - The protection behaviour could be switched on or off per node. - An operator with strict "some traffic may never touch certain part= s of the network" requirements might switch off the behaviour, while others= might switch it on. - A node could allow a switch even individually for every port or neigh= bor. - If a node knows that one of it's neighbours is a service node rath= er than a plain topological one, it could switch off protection. This is ho= w I would prefer to solve the problem with serrvice nodes. Should this be discussed in the protection document, or in a separate one? Best regards, Martin Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketant): Hi Robert, We do not have a signalling mechanism in IGPs today to indicate a "bypass-a= ble" indication for Prefix SIDs. If there was a desire for it, an IGP exten= sion would be required (there is none in progress AFAIK). Note that this re= sults in doubling the prefix SID scale (global labels) in the network. So I= would not go about this trivially. I think it helps to get more inputs and perspectives from operators on thei= r views for doing a bypass via local protection for segments in an SR Polic= y. There may be those that prefer end-to-end path protection using a fallba= ck path that is say disjoint with the primary but provides an appropriate S= LA/intent? Thanks, Ketan From: Robert Raszuk Sent: 14 August 2020 23:04 To: Ketan Talaulikar (ketant) Cc: Alexander Vainshtein ; Joel M. Halpern ; Shraddha Hegde ; EXT-Andrew.Alston@liquidtelecom.com ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Ketan, Looks like we are pretty much in sync here. But let me just observe that I purposely did not mention about SR policies = as we are not able to signal the intent with the packets itself. So all we have there is SIDs. BSIDs or prefix SIDs need to be flooded with = information if policies build with using them are bypass eligible or not. I was actually under the impression that this is already there and I am jus= t not aware, but looking deeper indeed I do not see this marking neither in= ISIS nor OSPF for prefix SIDs. Is there some work in progress to add it to those protocols or have we just= documented need for a short LSR draft ? Thx, R. On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ketant) > wrote: Hi Robert, Please check inline below. From: Robert Raszuk > Sent: 14 August 2020 21:13 To: Ketan Talaulikar (ketant) > Cc: Alexander Vainshtein >; Joel M. Halpern >; Shraddha Hegde >; EXT-Andrew.Alston@liquidtelecom.com >; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi Ketan, While I completely agree with your note the consequences of it are pretty s= evre. [KT] I understand. We need to be mindful of implications of protection sche= mes for the SLAs/intent of SR Policies. Unless we signal which prefix SID is protection eligible and which is not h= ow would other nodes know if they can protect it or not ? [KT] Correct. To be more accurate, we need to consider this more in the con= text of SLA or "intent" of SR Policies and which segments may be "bypass-ab= le" for local protection for some of those SR Policies. We also have path-p= rotection mechanisms. It seems that today's safe thing is not to apply any node protection on SR = flows at the PLRs then. And link protection MUST assure that packets will arrive at the neighbor no= de via some other link regardless of further path towards destination. [KT] Yes. We have a mechanism to indicate which adj-SIDs have protection (t= hat mechanism only provides link protection to get to the neighbor node) so= the SR Policy computation is able to indicate whether that specific link i= s "bypass-able" or not by its choice of protected or unprotected adj-SIDs r= espectively. Thanks, Ketan Is it correct ? Thx R On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ketant) > wrote: Hi Sasha, The service node advertises its own Prefix SID. The service function that t= his service node implements does not require any context (i.e. all packets = arriving at the node are subjected to that service). Therefore the service = node does not need to receive a packet with it's own Prefix SID. Thus, we cannot assume that when PHP is used, then the SID is only associat= ed with a topological instruction. Hope that clarifies? Thanks, Ketan From: Alexander Vainshtein > Sent: 14 August 2020 20:24 To: Ketan Talaulikar (ketant) >; = Joel M. Halpern >; Shraddha= Hegde >; EXT-Andrew.Alst= on@liquidtelecom.com >; Robert Ras= zuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Ketan, and all, I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs that are a= dvertised with PHP can ONLY represent topological instructions in SR-MPLS = - because the advertising node will not receive them and therefore can hard= ly be expected to associate any service function with them. This is complementary to what you have said. Hope this clarifies my position. What, if anything, did I miss? Regards, Sasha Get Outlook for Android ________________________________ From: Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 16:23 To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: RE: [spring] Spring protection - determining applicability ________________________________ NOTICE: This email was received from an EXTERNAL sender ________________________________ Hi Sasha, If the service does not need any additional context (e.g. a firewall that j= ust applies locally configured default rules on it), then I don't see why P= HP could not be done for a Prefix SID associated with a service node. Also, I didn't follow the point that you were trying to make about Adj-SIDs= . Thanks, Ketan From: Alexander Vainshtein > Sent: 14 August 2020 18:24 To: Ketan Talaulikar (ketant) >; = Joel M. Halpern >; Alexande= r Vainshtein >; Shraddha Hegde >= ; EXT-Andrew.Alston@liquidtelecom.com >; Robert Raszuk > Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi all, Regarding the statement "Prefix SID could be just a topological instruction= or may also be used to steer the flow to a node which is applying a servic= e function to it": I think that in SR-MPLS a Node SID that is advertised with PHP aciton can b= e safely considered as "just a topological instruction" by the PLR because = the originating node will not receive it. The same applies to Adj-SDIs. My 2c. Get Outlook for Android ________________________________ From: spring > on b= ehalf of Ketan Talaulikar (ketant) > Sent: Friday, August 14, 2020, 15:00 To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EXT-Andrew.Alsto= n@liquidtelecom.com; Robert Ras= zuk Cc: spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi All, I would like to share a different perspective on this. First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1]. This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being provided by t= he SR Policy. Awareness of that notion exists at the SR Policy headend and/= or computation-node. We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of the SLA requ= irement for picking that link. We do not have such a notion for Prefix SIDs= . One can say that we could introduce signalling (e.g. a B flag) to indicat= e whether a Prefix SID can be bypassed or not. This provides the opportunit= y for the computation to use one or the other flavor depending on the natur= e of the SLA for the SR Policy. I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able". As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of = SIDs that indicates to the PLR whether they are "bypass-able" or not. For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to bypass it. = When this mechanism is used along side SRTE path monitoring mechanisms, it = enables the headend to detect the failure and fallback to an alternate path= using the path protection approach. This is something that is described an= d in use in deployments today [1].. Thanks, Ketan [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9 [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%= 2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23= section-9.3 -----Original Message----- From: spring > On B= ehalf Of Joel M. Halpern Sent: 04 August 2020 20:25 To: Alexander Vainshtein >; Shraddha Hegde >; EXT-Andrew.Alston@liqui= dtelecom.com >; Robert Raszuk > Cc: spring@ietf.org; Joel M. Halpern > Subject: Re: [spring] Spring protection - determining applicability There are, as far as I can tell, a number of ways to address this family of= related questions. What struck me, and prompted the starting question, was that none of them w= ere spelled out. I see lots of interesting ideas / proposals. Some of them are compatible with others. Some are not. It would be good if we could reach agreement on how we thought it should be= handled. Thank you, Joel On 8/4/2020 3:54 AM, Alexander Vainshtein wrote: > Hi all, > > I am still not sure that the problem of bypass going thru undesirable > links/nodes exists in the case of topological SIDs. > > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090 > ) has been successfully deployed > for many years before SR-MPLS has been introduced. What's more, > signaling of bypass tunnels he PLR usually did not include any of the > constraints used for computing of any specific LSP that the bypass LSP > would protect - because in the Facility Protection mode the same > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node. > > From my POV the only difference between this behavior and that > introduced by the "bypassing" drafts in SR is that, in the case of > RSVP-TE, the operator would explicitly indicate, as part of LSP > signaling, whether it would or would not use FRR; LSPs that would not > use FRR would then drop traffic rather than delivering it the wrong way. > > Such an option indeed does not exist in SR-TE today, but would be easy > to provide if so desired IMHO. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:* spring > = *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM > *To:* EXT-Andrew.Alston@liquidtelecom.com > >= ; Robert Raszuk > > *Cc:* spring@ietf.org; Joel M. Halpern > > *Subject:* Re: [spring] Spring protection - determining applicability > > All, > > This is a very interesting discussion and thanks to Joel for starting > this discussion. IMO, when there are strict requirements of avoiding > certain nodes/links it can be realized either by defining a flex-algo > avoiding those > > Nodes and links or by using a stack of unprotected adj-sids that avoid > restricted nodes and links. When a stack of adj-sids is used to > realize the path, the head-end based (sBFD) protection mechanisms can be = applied. > > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection > is in use or not. > > Rgds > > Shraddha > > Juniper Business Use Only > > *From:* spring > > *= On Behalf Of *Andrew Alston > *Sent:* Tuesday, August 4, 2020 5:41 AM > *To:* Robert Raszuk > > *Cc:* spring@ietf.org ; J= oel M. Halpern > > > *Subject:* Re: [spring] Spring protection - determining applicability > > *[External Email. Be cautious of content]* > > Robert this is actually far more difficult when - it can be an entire > (long) series of nodes that need to be avoided. > > It could potentially be made to work but I'd worry that to do this - > you'd have to stack 10 - 20 - 30 negative labels - and that wouldn't > be viable. > > It's easier to use algorithms and adjacency sids and other such things > to calculate paths - the biggest trick is about the stack depth. When > you have this need for node avoidance - the need for 10+ label depth > is critical - unless you wanna be applying one hell of a lot of > binding labels along the way which is a nightmare. > > But to answer your question, is this a common use case - it's a use > case that most of the people I discuss this with certain have - I cant > comment on a global scale, or for anyone else, but every indication I > have is that yes - its something people need, and want > > Andrew > > *From:* Robert Raszuk > > *Sent:* Tuesday, 4 August 2020 01:27 > *To:* Andrew Alston > > > *Cc:* Joel M. Halpern > >; spring@i= etf.org > > *Subject:* Re: [spring] Spring protection - determining applicability > > Is this a common use case ie. "but rather - which nodes / network > segments it can never touch or flow through." > > If so perhaps its time to define notion of *negative-SID* ie. list in > the packet resources which given packet MUST not ever traverse. > > Put in the packet set of nodes or links which the packet should never > traverse. > > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR) > > Best, > R. > > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston > > > wrote: > > So - > > One of the use cases, in fact, some very major use cases in any > spring technology for us revolve around the following > > a.The explicit avoidance of certain nodes > > b.The explicit avoidance of certain sections of the network > > Anything that could result in that explicit avoidance being violated > - would create, shall we say significant problems. > > Much of the use case is not a case of which nodes the packets flow > through - but rather - which nodes / network segments it can never > touch or flow through. Effectively, to be used as a technology to > avoid certain things for specific reasons. > > This is also one of the reasons for needing such deep label stacks - > this kind of detailed path programming tends to deepen the stack > because you sometimes have to be pretty explicit. > > It is absolutely critical to us that this functionality is there - > and that we can avoid situations which could cause traffic to > accidently hit things explicitly avoided. > > I wish I could be more specific than this, but it is what it is. > > Thanks > > Andrew > > *From:* spring > > = *On Behalf Of *Joel M. Halpern > *Sent:* Monday, 3 August 2020 21:36 > *To:* Robert Raszuk > > *Cc:* spring@ietf..org > *Subject:* Re: [spring] Spring protection - determining > applicability > > (Since the thread has gotten long enough, reiterating that this is as= a > participant, not a WG chair.) > > Yes, we are talking IP networks. And yes, I have seen IP networks tha= t > choose to drop packets. For all sorts of reasons. > I think there are likely other reasons why one may not want a random > path rather than a chosen TE path. I think it is important we be clea= r > about what constraints may be / are violated when we tell people they > have this tool (protective rerouting) that is intended to preserve Qo= S. > > Let's be clear. I am not arguing that this is not a good idea. It is = a > good idea. And useful. I am trying to figure otu what combination of > additional mechanisms and clear descriptions will lead to everyone > getting the behavior they expect (which may not be the behavior they > desire, but sometimes is the best we can do.) > > Yours, > Joel > > On 8/3/2020 2:30 PM, Robert Raszuk wrote: > > Joel, > > > > Are we still talking about IP networks here ? Or perhaps some hard > > slicing with real resource reservations or detnets ? > > > > Because if we are talking about IP networking I have two > observations: > > > > A) If you need to traverse via a specific node (ie. firewall) you > better > > apply IP encapsulation to that node.. I don't think IP > encapsulation can > > be hijacked today such that destination address of the packet is > ignored. > > > > B) Have you seen any IP network where upon topology change (link > or node > > failure) you suddenly start dropping flows in spite of SPT offerin= g > > perhaps few ms longer path with 10 ms more jitter ? > > > > Or are some SR marketing slides promise to turn IP networks in > > something new ? Worse ... do they mention path quality guarantees, > > resource reservations ? I hope not. > > > > Thx, > > R. > > > > > > > > > > > > > > > > > > > > On Mon, Aug 3, 2020 at 8:10 PM Joel M. Halpern > > > wrote: > > > > Well less serious for TE SIDs, I am not sure the problem is > restricted > > to just service SIDs. > > > > Suppose that the PCE has specified the path to meet some complex t= e > > objective. The bypass node has no way of knowing what those > > constraints > > were. And for some kinds of traffic, it is better to drop the pac= ket > > than to deliver it outside the envelop. I suspect that the right > > answer > > to this is "too bad". If so, as with the distinction regarding > service > > nodes, we should say so, shouldn't we? > > > > Yours, > > Joel > > > > On 8/3/2020 2:36 AM, Alexander Vainshtein wrote: > > > Mach, Joel and all, > > > > > > I think that in most cases: > > > > > > 1.There is clear differentiation between "topological" and > "service" > > > instructions in SID advertisements. E.g.: > > > > > > oIGP Prefix Node SIDs IGP Adj-SIDs (identified as such in the > > > corresponding IGP advertisements) represent topological > instructions > > > > > > oService SIDs for SRv6 (see SRv6 BGP-Based Overlay Services > > > > > > >= > > > > > > draft) unsurprisingly represent "service" instructions > > > > > > 2.Segments that represent topological instructions can be bypass= ed, > > > while segments that represent service instructions require > > alternative > > > protection mechanisms. > > > > > > This view seems to be aligned with RFC 8402 > > > > > > that says in Section 1: > > > > > > In the context of an IGP-based distributed control plane, tw= o > > > > > > topological segments are defined: the IGP-Adjacency segment and = the > > > > > > IGP-Prefix segment. > > > > > > In the context of a BGP-based distributed control plane, two > > > > > > topological segments are defined: the BGP peering segment and th= e > > > > > > BGP-Prefix segment. > > > > > > In the case of SR-MPLS this differentiation is assumed in Sectio= n > > 3.4 of > > > the Node Protection for SR-TE Path > > > > > > > > > > > > > draft that says: > > > > > > The node protection mechanism described in the previous > sections > > > > > > depends on the assumption that the label immediately below > > the top > > > > > > label in the label stack is understood in the IGP domain. When = the > > > > > > provider edge routers exchange service labels via BGP or som= e > > other > > > > > > non-IGP mechanism the bottom label is not understood in the = IGP > > > > > > domain. > > > > > > The egress node protection mechanisms described in the draft > > > > > > [RFC8679 > >] > is > > > applicable to this use case and no additional changes > > > > > > will be required for SR based networks > > > > > > The scenarios in which differentiation between "topological" an= d > > > "service" instructions is broken are indeed problematic. E.g., > > consider > > > the use case in which a Node SID in the ERO of a SR-TE path > > identifies a > > > node that acts as a firewall for all packets it receives, i.e., > > provides > > > the firewall service without any dedicated service SID > > identifying it. > > > One could say that the Node SID of such a node would combine > > topological > > > and service instructions thus breaking the differentiation > > between the two. > > > > > > I am not sure if usage of such "combined" SIDs could be prevente= d > > or at > > > least discouraged. > > > > > > If not, providing an ability to identify such SIDs in the > > advertisement > > > mechanisms would be useful IMHO. > > > > > > My 2c, > > > > > > Sasha > > > > > > Office: +972-39266302 > > > > > > Cell: +972-549266302 > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > -----Original Message----- > > > From: spring > > > > On Behalf Of Mach Chen > > > Sent: Monday, August 3, 2020 6:30 AM > > > To: Joel M. Halpern > > >; > spring@ietf.org > > > Subject: Re: [spring] Spring protection - determining applicabil= ity > > > > > > Hi Joel, > > > > > > I think this is a good point that may not be discussed in the > > past. And > > > I also don't think there is a "can be bypassed" indication in th= e > > > routing advertisement for now. > > > > > > IMHO, the information advertised by routing is neutral, such > > information > > > (can or cannot be bypassed) is more path specific, thus > normally the > > > controller should be responsible for deciding whether/which SID > > can be > > > bypassed. > > > > > > Best regards, > > > > > > Mach > > > > > > > -----Original Message----- > > > > > > > From: spring [mailto:spring-bounces@ietf.org > > > ] > On Behalf Of Joel M. > > > > > > > Halpern > > > > > > > Sent: Monday, August 3, 2020 7:51 AM > > > > > > > To: spring@ietf.org > > > > >> > > > > > > > Subject: [spring] Spring protection - determining applicabili= ty > > > > > > > > > > > > > > (WG Chair hat Off, this is merely a note from a slightly > > confused WG > > > > > > > participant.) > > > > > > > > > > > > > > I have been reading the various repair drafts, and the variou= s > > > > > > > networks programming and service programming draft, and I am > > trying to > > > > > > > figure out one aspect of the combination. > > > > > > > > > > > > > > How does a node that is doing some form of bypass (suppose, f= or > > > > > > > simplicity, it is Node N2 deciding to bypass the next SID for > > a failed > > > > > > > node N3) know that it is safe to do so? > > > > > > > > > > > > > > If the path was just for TE, then it is "safe" if the new pat= h > > meets > > > > > > > the TE criteria. or maybe it is safe if it is even close, as > > long as > > > > > > > it is not used for too long. > > > > > > > > > > > > > > But what if the node were a Firewall, included to meet legal > > > requirements? > > > > > > > Or was some other necessary programmatic transform (wince we = are > > > > > > > deliberately vague about what nodes can do when asked suitabl= y.) > > > > > > > > > > > > > > Is there some "can be bypassed" indication in the routing > > > > > > > advertisements that I missed? > > > > > > > > > > > > > > Thank you, > > > > > > > Yours, > > > > > > > Joel > > > > > > > > > > > > > > _______________________________________________ > > > > > > > spring mailing list > > > > > > > spring@ietf.org > > > > >> > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2 > > > > > > > > > > > > > > > > F%2Fwww.ietf.org > > > > >%2Fmailman%2Flistinfo%2Fspring > > > > > > _______________________________________________ > > > > > > spring mailing list > > > > > > spring@ietf.org > > > > > > > > > > > > > https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= --- > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. that is confidential > > and/or > > > proprietary for the sole use of the intended recipient. Any revi= ew, > > > disclosure, reliance or distribution by others or forwarding > without > > > express permission is strictly prohibited. If you are not the > > intended > > > recipient, please notify the sender immediately and then delete = all > > > copies, including any attachments. > > > > > > ---------------------------------------------------------------------= --- > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org = > > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <= mailto:spring@ietf.org> > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2= Fmailman%2Flisti > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24> > > > > ---------------------------------------------------------------------- > -- > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all > copies, including any attachments. > ---------------------------------------------------------------------- > -- _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ________________________________ Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. that is confidential and/or proprietary for th= e sole use of the intended recipient. Any review, disclosure, reliance or d= istribution by others or forwarding without express permission is strictly = prohibited. If you are not the intended recipient, please notify the sender= immediately and then delete all copies, including any attachments. ________________________________ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9DE44dggeml509mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Sasha,

     

    Agree. This is not the= topic about to adopt a draft or not. I also support the adoption. J

     

    Regarding the not bypa= ssable flag for prefix SID, thanks for your input. Will update the draft af= ter we have enough discussion in the mailing list. Seems like we are headin= g to the same direction, that is wonderful!

     

    Thanks,

    Cheng

     

     

    From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of Alexander Vainshtein
    Sent: Friday, August 28, 2020 3:41 PM
    To: Chengli (Cheng Li) <c.l@huawei.com>; Alexander Vainshtein = <Alexander.Vainshtein@rbbn.com>; Martin Horneffer <maho@lab.dtag.d= e>
    Cc: spring@ietf.org; Robert Raszuk <robert@raszuk.net>; EXT-An= drew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; Shra= ddha Hegde <shraddha@juniper.net>; Ketan Talaulikar (ketant) <keta= nt=3D40cisco.com@dmarc.ietf.org>; Joel M. Halpern <jmh@joelhalpern.co= m>
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Cheng and all,=

    A few short comments.

     

    1. I support the idea to mark some IGP Prefix SIDs as "not bypassable<= /b>"
    2. I think that, while such marking is not yet available  the neighbors o= f a node that advertises itself as a "stub node" in IGP MAY use t= his as a hint that Node SIDs advertised by this node are "not bypas= sable".
    3. I do not think that B-flag in the advertisment of Adj-SIDs can be used as n= indication that it can be bypassed - the current semantics of this flag is= different.
    4. At the same time I do not think  that ability to advertise a certain A= dj-SID as leading to a not bypassable node is needed or would be useful. Ab= ility of the operator to exclude acific neighbor from protection would suff= ice, especially in the case of local Adj-SID.
    5. Last bot not  least, I think that none of the above must be addressed = befire adoption of the draft as a SPRING WG document.

     

    My 2c,

    Sasha

     

    Get Outlook for An= droid

     

    From: spring <spring-bounces@ietf.org> on behalf of Chengli (Cheng= Li) <c.l@huawei.com>
    Sent: Friday, August 28, 2020, 09:37
    To: Alexander Vainshtein; Martin Horneffer
    Cc: spring@ietf.org; Robert Raszuk; EXT-Andrew.Alston@liquidtelecom.com; Shraddha Hegde; Ketan Talaulikar (= ketant); Joel M. Halpern
    Subject:= Re: [spring] Spring protection - determining applicability=



    Hi Sasha and Martin, <= /span>

     

    Many thanks for your i= nput. I fully agree with your point of we need to consider to advertise the= ability of the node to advertise a specific Prefix SID it originates as &#= 8220;not eligible for bypass protection”.

     

    Also, this extension s= hould be written in a protection document like Martin said. We have a straw= man draft posed 1 year ago [1], but it has not been discussed yet.  Th= e main idea of the draft is to add a no-bypass flag into SID(including Prefix SID, and adj-SID). But we are discussing wi= th some experts that do we need the No-bypass flag for Adj-SID or not, it s= eems like we have a B flag already.

     

    It is so nice to see t= his point is raised and discussed. Also, welcome to review the document, an= d hope to have your valuable comments.

     

    Respect,

    Cheng

     

    [1]. https://tools.ietf.org/html/draft-li-rtgwg-enhanced-ti-lfa-02

     

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Alexander Vainshtein
    Sent: Tuesday, August 18, 2020 11:44 PM
    To: Martin Horneffer <maho@la= b.dtag.de>
    Cc: spring@ietf.org; Robert R= aszuk <robert@raszuk.net>; EXT-Andrew.Alston@li= quidtelecom.com <= Andrew.Alston@liquidtelecom.com>; Shraddha Hegde <shraddha@juniper.net>; Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>; Joel M. Halpern <= ;jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Martin,

    Lots of thanks for an = important input to this discussion.

     

    I fully agree with you= that ability to turn off the node protection scheme for a specific PLR nei= ghbor (i.e., on a specific PLR port) by suitable local configuration in the= PLR is definitely required. Such an ability would probably address most (if not all) scenarios associated with= the so-called “service nodes” that cannot be bypassed.<= o:p>

     

    I also think that serv= ice nodes that cannot be bypassed typically would advertise themselves as &= #8220;stub nodes” in IGP in order to prevent inadvertent application = of their service function to transit traffic (which could otherwise pass thru the service node due to some topology change). T= herefore a local policy that would exclude IGP neighbors advertising  = themselves as stub nodes in IGP from the node protection scheme could be al= so useful.

     

    Last but not least, ab= ility of the node to advertise a specific Prefix SID it originates as ̶= 0;not eligible for bypass protection” (e.g., using a new flag in the = Prefix Node TLV for IS-IS or OSPF) should be considered.

     

    My 2c,

    Sasha

     

    Office: +972-39266= 302

    Cell:   = ;   +972-549266302

    Email:   Alexander.Vainshtei= n@ecitele.com

     

    From: spring <spring-bounces@ietf.org> On Behalf Of Martin Horneffer
    Sent: Tuesday, August 18, 2020 5:51 PM
    To: spring@ietf.org
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Robert Raszuk <robert@raszuk.net>; EXT-Andrew.Alston@li= quidtelecom.com <= Andrew.Alston@liquidtelecom.com>; Shraddha Hegde <shraddha@juniper.net>; Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>; Joel M. Halpern <= ;jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    A few thoughts from m= y (operator's) PoV:

     - The disussion is a very good and important one. It probably should = be discussed and documented well in order to justify the proposed protectio= ns mechanisms.

     - Not all operators seem to have the same requirements.
        (A somewhat similar discussion might be the one for disj= oint paths. Those are often equired by voice signalling applications. In so= me cases the voice service demands that traffic is blackholed rather than o= n forwarded on the wrong path. In other cases disjoint paths are just required for the "good case". Traffic MAY be forw= arded on the wrong path, as long as the network just makes sure the traffic= on the other path is never affected by the same failure.)

     - Personally I would hate to see yet another IGP extension for this p= urpose.

     - I would rather prefer a good discussion of what can be achieved by = using easy to make switches:
        - The protection behaviour could be switched on or off p= er node.
           - An operator with strict "some t= raffic may never touch certain parts of the network" requirements migh= t switch off the behaviour, while others might switch it on.
        - A node could allow a switch even individually for ever= y port or neighbor.
           - If a node knows that one of it's nei= ghbours is a service node rather than a plain topological one, it could swi= tch off protection. This is how I would prefer to solve the problem with se= rrvice nodes.

    Should this be discussed in the protection document, or in a separate one?<= br>
    Best regards, Martin

    Am 14.08.20 um 19:45 schrieb Ketan Talaulikar (ketan= t):

    Hi Robert,

     

    We do not have a signalling mechanism in IGPs today = to indicate a “bypass-able” indication for Prefix SIDs. If ther= e was a desire for it, an IGP extension would be required (there is none in= progress AFAIK). Note that this results in doubling the prefix SID scale (global labels) in the network. So I would not go abo= ut this trivially.

     

    I think it helps to get more inputs and perspectives= from operators on their views for doing a bypass via local protection for = segments in an SR Policy. There may be those that prefer end-to-end path pr= otection using a fallback path that is say disjoint with the primary but provides an appropriate SLA/intent?

     

    Thanks,

    Ketan

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 23:04
    To: Ketan Talaulikar (ketant) &l= t;ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. Halpern <jmh@joelhalpern.com>; Shr= addha Hegde <shraddha@juniper.net>; EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; spring@ietf.org
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Ketan,

     

    Looks like we are pretty much in sync here. 

     

    But let me just observe that I purposely did no= t mention about SR policies as we are not able to signal the intent with th= e packets itself. 

     

    So all we have there is SIDs. BSIDs or prefix SIDs n= eed to be flooded with information if policies build with using them are by= pass eligible or not. 

     

    I was actually under the impression that this is alr= eady there and I am just not aware, but looking deeper indeed I do not see = this marking neither in ISIS nor OSPF for prefix SIDs. 

     

    Is there some work in progress to add it to those pr= otocols or have we just documented need for a short LSR draft  ?&= nbsp;

     

    Thx,

    R.

     

     

    On Fri, Aug 14, 2020 at 6:17 PM Ketan Talaulikar (ke= tant) <ketant@cisco.com> wrot= e:

    Hi Robert,

     

    Please check inline below.

     

    From: Robert Raszuk <robert@raszuk.net>
    Sent: 14 August 2020 21:13
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Joel M. = Halpern <jmh@jo= elhalpern.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Hi Ketan,

     

    While I completely agree with your note the conseque= nces of it are pretty sevre. 

    [KT] I understand. We need to be mindful of im= plications of protection schemes for the SLAs/intent of SR Policies.

     

    Unless we signal which prefix SID is protection elig= ible and which is not how would other nodes know if they can protect it or = not ? 

    [KT] Correct. To be more accurate, we need to = consider this more in the context of SLA or “intent” of SR Poli= cies and which segments may be “bypass-able” for local protecti= on for some of those SR Policies. We also have path-protection mechanisms.

     

    It seems that today's safe thing is not to apply any= node protection on SR flows at the PLRs then. 

     

    And link protection MUST assure that packets will ar= rive at the neighbor node via some other link regardless of further path to= wards destination. 

    [KT] Yes. We have a mechanism to indicate whic= h adj-SIDs have protection (that mechanism only provides link protection to= get to the neighbor node) so the SR Policy computation is able to indicate= whether that specific link is “bypass-able” or not by its choice of protected or unprotected adj-SIDs respectively.

     

    Thanks,

    Ketan

     

    Is it correct ? 

     

    Thx

    R

     

    On Fri, Aug 14, 2020 at 5:32 PM Ketan Talaulikar (ke= tant) <ketant@cisc= o.com> wrote:

    Hi Sasha,

     

    The service node advertises its own Prefix SID. The = service function that this service node implements does not require any con= text (i.e. all packets arriving at the node are subjected to that service).= Therefore the service node does not need to receive a packet with it’s own Prefix SID.

     

    Thus, we cannot assume that when PHP is used, then t= he SID is only associated with a topological instruction.

     

    Hope that clarifies?

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.Vainshtein@r= bbn.com>
    Sent: 14 August 2020 20:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Ketan, and all,

    I have stated that, IMHO and FWIW, both Adj-SIDs and Prefix SIDs tha= t are advertised with PHP can  ONLY represent topological instructions= in SR-MPLS - because the advertising node will not receive them and therefore can hardly be expected to associate an= y service function with them.

     

    This is complementary to what you have said.

     

    Hope this clarifies my position.

    What, if anything, did I miss?

     

    Regards,

    Sasha

     

    Get Outlook for Android

     

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, August 14, 2020, 16:23
    To: Alexander Vainshtein; Joel M. Halpern; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject:= RE: [spring] Spring protection - determining applicability=

     

    NOTICE: This email was received from an EXTERNAL sen= der

     

    Hi Sasha,

     

    If the service does not need any additional context = (e.g. a firewall that just applies locally configured default rules on it),= then I don’t see why PHP could not be done for a Prefix SID associat= ed with a service node.

     

    Also, I didn’t follow the point that you were = trying to make about Adj-SIDs.

     

    Thanks,

    Ketan

     

    From: Alexander Vainshtein <Alexander.Vainshtein@r= bbn.com>
    Sent: 14 August 2020 18:24
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Joel M. Halpern <jmh@joelhalpern.com&g= t;; Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde <shraddha@juniper.net>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf= .org
    Subject: Re: [spring] Spring protection - determining applicability<= o:p>

     

    Hi all,

    Regarding the statement "Prefix SID could be just a topological= instruction or may also be used to steer the flow to a node which is apply= ing a service function to it":

     

     

    I think that in SR-MPLS a Node SID that is advertised with PHP acito= n can be safely considered as "just a topological instruction" by= the PLR because the originating node will not receive it.

    The same applies to Adj-SDIs.

     

    My 2c.

     

    Get Outlook for Android

     

    From: spring <spring-bounces@ietf.org> on behalf= of Ketan Talaulikar (ketant) <ketant=3D40cisco.com@dmarc.ietf.org>=
    Sent: Friday, August 14, 2020, 15:00
    To: Joel M. Halpern; Alexander Vainshtein; Shraddha Hegde; EX= T-Andrew.Alston@liquidtelecom.com; Robert Raszuk
    Cc: spring@ietf.org
    Subject:= Re: [spring] Spring protection - determining applicability=

     

    Hi All,

    I would like to share a different perspective on this.

    First, thanks to Joel for bringing up the discussion. Clearly we need a wel= l-defined applicability statement for determining applicability of protecti= on for segment used in an SR Policy. Some of this is captured in [1].

    This is about local repair at a PLR. By it's very nature, the PLR does not = have a notion of how "strict or not" is the SLA that is being pro= vided by the SR Policy. Awareness of that notion exists at the SR Policy he= adend and/or computation-node.

    We have protected and un-protected variants of adjacency SIDs to enable the= computation to pick or the other based on the "strictness" of th= e SLA requirement for picking that link. We do not have such a notion for P= refix SIDs. One can say that we could introduce signalling (e.g. a B flag) to indicate whether a Prefix SID can be bypasse= d or not. This provides the opportunity for the computation to use one or t= he other flavor depending on the nature of the SLA for the SR Policy.

    I have a problem and a concern in the assumption that PLRs can assume that = the currently defined variant of Prefix SIDs in RFC8402 (and IGP specs) are= "bypass-able".

    As Joel and others have brought out, the Prefix SID could be just a topolog= ical instruction or may also be used to steer the flow to a node which is a= pplying a service function to it. In order to support a mix of SR Policies = of different SLAs (strict and not-strict), we need to enable the choice of SIDs that indicates to the PLR whether the= y are "bypass-able" or not.

    For the cases, where the SR Policy has a specific SLA, it is required for n= odes to drop the packets meant for the "active segment" than to b= ypass it. When this mechanism is used along side SRTE path monitoring mecha= nisms, it enables the headend to detect the failure and fallback to an alternate path using the path protection approa= ch. This is something that is described and in use in deployments today [1]= ..

    Thanks,
    Ketan

    [1] https://clicktime.symantec.com/3Y3fWuNFYCjMJUiiAiWwUms6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9
    [2] https://clicktime.symantec.com/36fCMrgmEewC4a4AJRrmn7H6H2?u=3Dhttps%3A%2F%2= Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-segment-routing-policy-08%23sect= ion-9.3

    -----Original Message-----
    From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
    Sent: 04 August 2020 20:25
    To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; Shraddha Hegde = <shraddha=3D40juniper.net@dmarc.ietf.org>; EX= T-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>= ; Robert Raszuk <= robert@raszuk.net>
    Cc: spring@ietf.org; Joel M. Halpern <jmh@joelhalpern.com>
    Subject: Re: [spring] Spring protection - determining applicability

    There are, as far as I can tell, a number of ways to address this family of= related questions.
    What struck me, and prompted the starting question, was that none of them w= ere spelled out.  I see lots of interesting ideas / proposals.
    Some of them are compatible with others.   Some are not.
    It would be good if we could reach agreement on how we thought it should be= handled.

    Thank you,
    Joel

    On 8/4/2020 3:54 AM, Alexander Vainshtein wrote:
    > Hi all,
    >
    > I am still not sure that the problem of bypass going thru undesirable =
    > links/nodes exists in the case of topological SIDs.
    >
    > AFAIK, Facility Protection in RSVP-TE FRR (RFC 4090
    > <http= s://clicktime.symantec.com/3Q92knE9XJujrf8Bk7oJvs6H2?u=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Frfc4090>) has been successfully deployed
    > for many years before SR-MPLS has been introduced. What’s more, =
    > signaling of bypass tunnels he PLR usually did not include any of the =
    > constraints used for computing of any specific LSP that the bypass LSP=
    > would protect – because in the Facility Protection mode the same=
    > bypass LSP would be used to protect multiple LSPs passing thru the > failed link/node.
    >
    >  From my POV the only difference between this behavior and that <= br> > introduced by the “bypassing” drafts in SR is that, in the= case of
    > RSVP-TE, the operator would explicitly indicate, as part of LSP
    > signaling, whether it would or would not use FRR; LSPs that would not =
    > use FRR would then drop traffic rather than delivering it the wrong wa= y.
    >
    > Such an option indeed does not exist in SR-TE today, but would be easy=
    > to provide if so desired IMHO.
    >
    > Did I miss something substantial?
    >
    > Regards, and lots of thanks in advance,
    >
    > Sasha
    >
    > Office: +972-39266302
    >
    > Cell:      +972-549266302
    >
    > Email:   Alexander.Vainshtein@ecitele.com
    >
    > *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Shraddha Hegde > *Sent:* Tuesday, August 4, 2020 9:41 AM
    > *To:* EXT-Andrew.Alston@liquidtelecom.com
    > <Andrew.Alston@liquidtelecom.com>; Robert Raszuk <robert@raszuk.net>
    > *Cc:* spring@ietf= .org; Joel M. Halpern <jmh@joelhalpern.com>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > All,
    >
    > This is a very interesting discussion and thanks to Joel for starting =
    > this discussion. IMO, when there are strict requirements of avoiding <= br> > certain nodes/links it can be realized  either by defining a flex= -algo
    > avoiding those
    >
    > Nodes and links or by using a stack of unprotected adj-sids that avoid=
    > restricted nodes and links. When a stack of adj-sids is used to
    > realize the path, the head-end based (sBFD) protection mechanisms can = be applied.
    >
    > If Node-sids/prefix-sid/anycast-sids are used to build the stack, the =
    > failure events may cause traffic to go through restricted nodes and > links. This would happen regardless of whether any kind of protection =
    > is in use or not.
    >
    > Rgds
    >
    > Shraddha
    >
    > Juniper Business Use Only
    >
    > *From:* spring <spring-bounces@ietf.org
    > <m= ailto:spring-bounces@ietf.org>> *On Behalf Of *Andrew Alston
    > *Sent:* Tuesday, August 4, 2020 5:41 AM
    > *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Cc:* spring@ietf= .org <mailto:sp= ring@ietf.org>; Joel M. Halpern
    > <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com>>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > *[External Email. Be cautious of content]*
    >
    > Robert this is actually far more difficult when – it can be an e= ntire
    > (long) series of nodes that need to be avoided.
    >
    > It could potentially be made to work but I’d worry that to do th= is –
    > you’d have to stack 10 – 20 – 30 negative labels = 211; and that wouldn’t
    > be viable.
    >
    > It’s easier to use algorithms and adjacency sids and other such = things
    > to calculate paths – the biggest trick is about the stack depth.=   When
    > you have this need for node avoidance – the need for 10+ lab= el depth
    > is critical – unless you wanna be applying one hell of a lot of =
    > binding labels along the way which is a nightmare.
    >
    > But to answer your question, is this a common use case – it̵= 7;s a use
    > case that most of the people I discuss this with certain have – = I cant
    > comment on a global scale, or for anyone else, but every indication I =
    > have is that yes – its something people need, and want
    >
    > Andrew
    >
    > *From:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>
    > *Sent:* Tuesday, 4 August 2020 01:27
    > *To:* Andrew Alston <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>>
    > *Cc:* Joel M. Halpern <jmh@joelhalpern.com
    > <mailt= o:jmh@joelhalpern.com>>; spring@ietf.org > <mailto:spring= @ietf.org>
    > *Subject:* Re: [spring] Spring protection - determining applicability<= br> >
    > Is this a common use case ie.  "but rather – which nod= es / network
    > segments it can never touch or flow through."
    >
    > If so perhaps its time to define notion of *negative-SID* ie. list in =
    > the packet resources which given packet MUST not ever traverse. >
    > Put in the packet set of nodes or links which the packet should never =
    > traverse.
    >
    > That goes in line of recent wave of negative routing implementations > (RIFT) or discussions (LSR)
    >
    > Best,
    > R.
    >
    > On Mon, Aug 3, 2020 at 11:46 PM Andrew Alston
    > <Andrew.Alston@liquidtelecom.com
    > <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
    >
    >     So –
    >
    >     One of the use cases, in fact, some very major= use cases in any
    >     spring technology for us revolve around the fo= llowing
    >
    >     a.The explicit avoidance of certain nodes
    >
    >     b.The explicit avoidance of certain sections o= f the network
    >
    >     Anything that could result in that explicit av= oidance being violated
    >     – would create, shall we say significant= problems.
    >
    >     Much of the use case is not a case of which no= des the packets flow
    >     through – but rather – which nodes= / network segments it can never
    >     touch or flow through.  Effectively, to b= e used as a technology to
    >     avoid certain things for specific reasons.
    >
    >     This is also one of the reasons for needing su= ch deep label stacks –
    >     this kind of detailed path programming tends t= o deepen the stack
    >     because you sometimes have to be pretty explic= it.
    >
    >     It is absolutely critical to us that this func= tionality is there –
    >     and that we can avoid situations which could c= ause traffic to
    >     accidently hit things explicitly avoided.
    >
    >     I wish I could be more specific than this, but= it is what it is.
    >
    >     Thanks
    >
    >     Andrew
    >
    >     *From:* spring <spring-bounces@ietf.org
    >     <mailto:spring-bounces@ietf.org>> *On Behal= f Of *Joel M. Halpern
    >     *Sent:* Monday, 3 August 2020 21:36
    >     *To:* Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>>=
    >     *Cc:* spring@ietf..org <mailto:spring@ietf.org>
    >     *Subject:* Re: [spring] Spring protection - de= termining
    > applicability
    >
    >     (Since the thread has gotten long enough, reit= erating that this is as a
    >     participant, not a WG chair.)
    >
    >     Yes, we are talking IP networks. And yes, I ha= ve seen IP networks that
    >     choose to drop packets. For all sorts of reaso= ns.
    >     I think there are likely other reasons why one= may not want a random
    >     path rather than a chosen TE path. I think it = is important we be clear
    >     about what constraints may be / are violated w= hen we tell people they
    >     have this tool (protective rerouting) that is = intended to preserve QoS.
    >
    >     Let's be clear. I am not arguing that this is = not a good idea. It is a
    >     good idea. And useful. I am trying to figure o= tu what combination of
    >     additional mechanisms and clear descriptions w= ill lead to everyone
    >     getting the behavior they expect (which may no= t be the behavior they
    >     desire, but sometimes is the best we can do.)<= br> >
    >     Yours,
    >     Joel
    >
    >     On 8/3/2020 2:30 PM, Robert Raszuk wrote:
    >      > Joel,
    >      >
    >      > Are we still talking about IP netwo= rks here ? Or perhaps some hard
    >      > slicing with real resource reservat= ions or detnets ?
    >      >
    >      > Because if we are talking = ;about IP networking I have two
    >     observations:
    >      >
    >      > A) If you need to traverse via a sp= ecific node (ie. firewall) you
    >     better
    >      > apply IP encapsulation to that node= .. I don't think IP
    >     encapsulation can
    >      > be hijacked today such that destina= tion address of the packet is
    >     ignored.
    >      >
    >      > B) Have you seen any IP network whe= re upon topology change (link
    >     or node
    >      > failure) you suddenly start dr= opping flows in spite of SPT offering
    >      > perhaps few ms longer path with 10 = ms more jitter ?
    >      >
    >      > Or are some SR marketing slides pro= mise to turn IP networks in
    >      > something new ? Worse ... do t= hey mention path quality guarantees,
    >      > resource reservations ? I hope= not.
    >      >
    >      > Thx,
    >      > R.
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      > On Mon, Aug 3, 2020 at 8:10 PM Joel= M. Halpern <jmh@joelhalpern.com
    >     <mailto:jmh@joelhalpern.com%20%0b>> <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">mailto:jmh@joelhalp= ern.com>> wrote:
    >      >
    >      > Well less serious for TE SIDs, I am= not sure the problem is
    >     restricted
    >      > to just service SIDs.
    >      >
    >      > Suppose that the PCE has specified = the path to meet some complex te
    >      > objective.  The bypass node ha= s no way of knowing what those
    >      > constraints
    >      > were.  And for some kinds of t= raffic, it is better to drop the packet
    >      > than to deliver it outside the enve= lop.  I suspect that the right
    >      > answer
    >      > to this is "too bad".&nbs= p; If so, as with the distinction regarding
    >     service
    >      > nodes, we should say so, shouldn't = we?
    >      >
    >      > Yours,
    >      > Joel
    >      >
    >      > On 8/3/2020 2:36 AM, Alexander Vain= shtein wrote:
    >      > > Mach, Joel and all,
    >      > >
    >      > > I think that in most cases: >      > >
    >      > > 1.There is clear differentiati= on between "topological" and
    >     "service"
    >      > > instructions in SID advertisem= ents. E.g.:
    >      > >
    >      > > oIGP Prefix Node SIDs IGP Adj-= SIDs (identified as such in the
    >      > > corresponding IGP advertisemen= ts) represent topological
    >     instructions
    >      > >
    >      > > oService SIDs for SRv6 (see SR= v6 BGP-Based Overlay Services
    >      > >
    >      >
    >     <https://clickt= ime.symantec.com/3CCcy9mY6cMfbk7QfjhiA3R6H2?u=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04
    >     <https://clicktime.symantec.com/3GC5a= f2z3JzphZDkPncHAQi6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F= datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-srv6-services-04__%3B%2= 1%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo= 4T-L0nl%24>>
    >      >
    >      > > draft) unsurprisingly represen= t “service” instructions
    >      > >
    >      > > 2.Segments that represent topo= logical instructions can be bypassed,
    >      > > while segments that represent = service instructions require
    >      > alternative
    >      > > protection mechanisms.
    >      > >
    >      > > This view seems to be aligned = with RFC 8402
    >      > > <https://clicktime.symantec.com/345N= LCB6TydxuuqUjtcDRZy6H2?u=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8402 >     <https://clicktime.symantec.com/37PzUKAD82cjSvmVcGvpkhF6H2?u=3Dhttps%3A%2F= %2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8402__%3B%= 21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiD= o0I4Ybtm%24>>
    >     that says in Section 1:
    >      > >
    >      > >     In the cont= ext of an IGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defin= ed: the IGP-Adjacency segment and the
    >      > >
    >      > >     IGP-Prefix = segment.
    >      > >
    >      > >     In the cont= ext of a BGP-based distributed control plane, two
    >      > >
    >      > > topological segments are defin= ed: the BGP peering segment and the
    >      > >
    >      > >     BGP-Prefix = segment.
    >      > >
    >      > > In the case of SR-MPLS this di= fferentiation is assumed in Section
    >      > 3.4 of
    >      > > the Node Protection for SR-TE = Path
    >      > >
    >      >
    >     <https://clicktime.symantec.com/3JbSWGx5DAfNPsZdhpExxx9= 6H2?u=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-sprin= g-node-protection-for-sr-te-paths-07%23section-3.4
    >     <https://clicktime.symantec.com/3CrUgARW8somAbw6TisjgJ16H2?u=3Dhttps%3A%2F%= 2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdr= aft-hegde-spring-node-protection-for-sr-te-paths-07%2Asection-3.4__%3BIw%21= %21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo9= wO-Ssn%24>>
    >      >
    >      > > draft that says:
    >      > >
    >      > >     The node pr= otection mechanism described in the previous
    >     sections
    >      > >
    >      > >     depends on = the assumption that the label immediately below
    >      > the top
    >      > >
    >      > > label in the label stack is un= derstood in the IGP domain.  When the
    >      > >
    >      > >     provider ed= ge routers exchange service labels via BGP or some
    >      > other
    >      > >
    >      > >     non-IGP mec= hanism the bottom label is not understood in the IGP
    >      > >
    >      > >     domain.
    >      > >
    >      > >     The egress = node protection mechanisms described in the draft
    >      > >
    >      > >     [RFC8679 &l= t;https://clicktime.symantec.com/3JfvtBAmaQPN1jA3pM6TdCE6H2?u=3Dhttps%3A= %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8679
    >     <https://clicktime.symantec.com/36dMAjuYTQovo8jHwmm3eJw6H2?u= =3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2F= doc%2Fhtml%2Frfc8679__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wx= qguoZHgwp6vpRHOGt8AkTRDuiDo8MGipXc%24>>]
    >     is
    >      > > applicable to this use case an= d no additional changes
    >      > >
    >      > >     will be req= uired for SR based networks
    >      > >
    >      > > The scenarios in which  d= ifferentiation between “topological” and
    >      > > “service” instruct= ions is broken are indeed problematic. E.g.,
    >      > consider
    >      > > the use case in which a Node S= ID in the ERO of a SR-TE path
    >      > identifies a
    >      > > node that acts as a firewall f= or all packets it receives, i.e.,
    >      > provides
    >      > > the firewall service without a= ny dedicated service SID
    >      > identifying it.
    >      > > One could say that the Node SI= D of such a node would combine
    >      > topological
    >      > > and service instructions thus = breaking the differentiation
    >      > between the two.
    >      > >
    >      > > I am not sure if usage of such= “combined” SIDs could be prevented
    >      > or at
    >      > > least discouraged.
    >      > >
    >      > > If not, providing an ability t= o identify such SIDs in the
    >      > advertisement
    >      > > mechanisms would be useful IMH= O.
    >      > >
    >      > > My 2c,
    >      > >
    >      > > Sasha
    >      > >
    >      > > Office: +972-39266302
    >      > >
    >      > > Cell:    &= nbsp; +972-549266302
    >      > >
    >      > > Email: Alexander.Vainshtein@ecitele.com
    >     <mailto:Alexander.Vainshtein@ecitele.com>=
    >      > <mailto:Alexander.Vainshtein@ecitele.= com>
    >      > >
    >      > > -----Original Message-----
    >      > > From: spring <spring-bounces@ietf.org<= br> >     <mailto:spring-bounces@ietf.org%0b>>
    >     <mailto:spring-bounces@ietf.org>> On Behalf Of = Mach Chen
    >      > > Sent: Monday, August 3, 2020 6= :30 AM
    >      > > To: Joel M. Halpern <jmh@joelhalpern.com >     <mailto:jmh@joelhalpern.com%0b>> <mailto:jmh@joelhalpern.co= m>>;
    >     spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > Subject: Re: [spring] Spring p= rotection - determining applicability
    >      > >
    >      > > Hi Joel,
    >      > >
    >      > > I think this is a good point t= hat may not be discussed in the
    >      > past. And
    >      > > I also don't think there is a = "can be bypassed" indication in the
    >      > > routing advertisement for now.=
    >      > >
    >      > > IMHO, the information advertis= ed by routing is neutral, such
    >      > information
    >      > > (can or cannot be bypassed) is= more path specific, thus
    >     normally the
    >      > > controller should be responsib= le for deciding whether/which SID
    >      > can be
    >      > > bypassed.
    >      > >
    >      > > Best regards,
    >      > >
    >      > > Mach
    >      > >
    >      > >  > -----Original Messa= ge-----
    >      > >
    >      > >  > From: spring [mailt= o:spring-bounc= es@ietf.org
    >      > <mailto:spring-bounces@ietf.org>
    >     <mailto:spri= ng-bounces@ietf.org%0b%3e%20%3cmailto:spring-bounces@ietf.org%3e>] >     On Behalf Of Joel M.
    >      > >
    >      > >  > Halpern
    >      > >
    >      > >  > Sent: Monday, Augus= t 3, 2020 7:51 AM
    >      > >
    >      > >  > To: spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >      > >
    >      > >  > Subject: [spring] S= pring protection - determining applicability
    >      > >
    >      > >  >
    >      > >
    >      > >  > (WG Chair hat Off, = this is merely a note from a slightly
    >      > confused WG
    >      > >
    >      > >  > participant.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > I have been reading= the various repair drafts, and the various
    >      > >
    >      > >  > networks programmin= g and service programming draft, and I am
    >      > trying to
    >      > >
    >      > >  > figure out one aspe= ct of the combination.
    >      > >
    >      > >  >
    >      > >
    >      > >  > How does a node tha= t is doing some form of bypass (suppose, for
    >      > >
    >      > >  > simplicity, it is N= ode N2 deciding to bypass the next SID for
    >      > a failed
    >      > >
    >      > >  > node N3) know that = it is safe to do so?
    >      > >
    >      > >  >
    >      > >
    >      > >  > If the path was jus= t for TE, then it is "safe" if the new path
    >      > meets
    >      > >
    >      > >  > the TE criteria.&nb= sp; or maybe it is safe if it is even close, as
    >      > long as
    >      > >
    >      > >  > it is not used for = too long.
    >      > >
    >      > >  >
    >      > >
    >      > >  > But what if the nod= e were a Firewall, included to meet legal
    >      > > requirements?
    >      > >
    >      > >  > Or was some other n= ecessary programmatic transform (wince we are
    >      > >
    >      > >  > deliberately vague = about what nodes can do when asked suitably.)
    >      > >
    >      > >  >
    >      > >
    >      > >  > Is there some "= ;can be bypassed" indication in the routing
    >      > >
    >      > >  > advertisements that= I missed?
    >      > >
    >      > >  >
    >      > >
    >      > >  > Thank you,
    >      > >
    >      > >  > Yours,
    >      > >
    >      > >  > Joel
    >      > >
    >      > >  >
    >      > >
    >      > >  > ___________________= ____________________________
    >      > >
    >      > >  > spring mailing list=
    >      > >
    >      > >  > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org>
    >      > <mailto:spring@ietf.org= <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%20%3cmail= to:spring@ietf.org>>>
    >      > >
    >      > >  >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2
    >     <    https://clicktime.symantec.com/3Q= 7vX2qWSUdWVc892XuXy2H6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A= %2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2= __%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt= 8AkTRDuiDo6HwPLil%24>
    >      > >
    >      >
    >     <https://c= licktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%252
    >     <https://clicktime.symantec.c= om/3A5B8H2Fm1rPnaZ3Supjwr6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__http= s%3A%2Fclicktime.symantec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A= %2A252__%3BJSU%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6v= pRHOGt8AkTRDuiDozoQiAHk%24>>
    >      > >
    >      > >  > F%2Fwww.ietf.org
    >     <https://clicktime.sy= mantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3= %2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAt= Qxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>
    >      > <https://clicktime.symantec.com/3GWT9fyjaFi3FcvHDvoodvS6H2?= u=3Dhttp%3A%2F%2F2Fwww.ietf.org
    >     <https://clicktim= e.symantec.com/39NznmYBtRuHARhGJ5W5dGB6H2?u=3Dhttps%3A%2F%2Furldefense.com%= 2Fv3%2F__http%3A%2F2Fwww.ietf.org__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1o= iQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-pPCjvR%24>>%2Fmailman%2F= listinfo%2Fspring
    >      > >
    >      > > ______________________________= _________________
    >      > >
    >      > > spring mailing list
    >      > >
    >      > > spring@ietf.org <mailto:spring@ietf.org>
    >     <mailto:spring@ietf.org> <mailto:spring@ietf.org
    >     <mailto:spring@ietf.org%0b>> <mailto:spring@ietf.org>> >      > >
    >      > >
    >      >
    >     https://clicktime.symantec.com/367qhU4KiUkzW9uGC4eAvP46H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3BhyEtx4Q7n74BhiRn= fMJtT6H2?u=3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.sym= antec.com%2F367qhU4KiUkzW9uGC4eAvP46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Fwww.ietf.o= rg%2A2Fmailman%2A2Flistinfo%2A2Fspring__%3BJSUlJSUl%21%21NEt6yMaO-gk%21S0Yu= sx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgwp6vpRHOGt8AkTRDuiDo-hR3gAD%24>
    >      > >
    >      > >
    >      > >
    >      > >
    >      >
    >     ----------------------------------------------= --------------------------
    >      > > Notice: This e-mail together w= ith any attachments may contain
    >      > > information of Ribbon Communic= ations Inc. that is confidential
    >      > and/or
    >      > > proprietary for the sole use o= f the intended recipient. Any review,
    >      > > disclosure, reliance or distri= bution by others or forwarding
    >     without
    >      > > express permission is strictly= prohibited. If you are not the
    >      > intended
    >      > > recipient, please notify the s= ender immediately and then delete all
    >      > > copies, including any attachme= nts.
    >      > >
    >      >
    >     ----------------------------------------------= --------------------------
    >      > >
    >      > > ______________________________= _________________
    >      > > spring mailing list
    >      > > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >      > >
    >      >
    >      > ___________________________________= ____________
    >      > spring mailing list
    >      > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org>
    >      > https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >     <https://clicktime.symantec.com/3NrDnSTReXh671G79BVGEq16H2?u=3Dhttp= s%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqguoZHgw= p6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >      >
    >
    >     ______________________________________________= _
    >     spring mailing list
    >     spring@ietf.org <mailto:spring@ietf.org>
    >     https://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
    >    
    > <https://clicktime.symantec.com/3Nr= DnSTReXh671G79BVGEq16H2?u=3Dhttps%3A%
    > 2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flisti
    > nfo%2Fspring__%3B%21%21NEt6yMaO-gk%21S0Yusx9FYNE8E_R1oiQAtQxgm0x0wxqgu=
    > oZHgwp6vpRHOGt8AkTRDuiDo5KlPnbj%24>
    >
    >
    >
    > ----------------------------------------------------------------------=
    > --
    > Notice: This e-mail together with any attachments may contain
    > information of Ribbon Communications Inc. that is confidential and/or =
    > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without <= br> > express permission is strictly prohibited. If you are not the intended=
    > recipient, please notify the sender immediately and then delete all > copies, including any attachments.
    > ----------------------------------------------------------------------=
    > --

    _______________________________________________
    spring mailing list
    spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring
    _______________________________________________
    spring mailing list
    spring@ietf.org h= ttps://clicktime.symantec.com/3Q1xsKGyMzNJCKyVPByhqLq6H2?u=3Dhttps%3A%2F%2F= www.ietf.org%2Fmailman%2Flistinfo%2Fspring

     

     

    Notice: This e-mail together with any attachments may = contain information of Ribbon Communications Inc. that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or f= orwarding without express permission is strictly prohibited. If you are not= the intended recipient, please notify the sender immediately and then dele= te all copies, including any attachments.

     

     

    _______________________________________________
    spring mailing list
    spring@ietf.org

    https://www.ie=
tf.org/mailman/listinfo/spring

     

     

    --_000_C7C2E1C43D652C4E9E49FE7517C236CB02B9DE44dggeml509mbschi_-- From nobody Sat Aug 29 17:36:59 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A603A1245 for ; Sat, 29 Aug 2020 17:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 dXRasl7maOlq for ; Sat, 29 Aug 2020 17:36:56 -0700 (PDT) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 1BE3E3A0E49 for ; Sat, 29 Aug 2020 17:36:56 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id k4so3726291ilr.12 for ; Sat, 29 Aug 2020 17:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:accept-language:content-language :content-transfer-encoding:mime-version; bh=HFmUy37RBJOOL/5EDhwL4SjbgsOdcJm1aMphWXfWqs0=; b=ZTON9IV/KuZNI1sHrDGrJ157rhvre0OZU/U3tDq0huxbS0c0oGDZUxzlaw/woWTPZa czseYBRRb1XaLtljbXKVVf4oLQcKuRLj4YKihCPXXIzujA14PbvMl8ahWbYr0XvK6N/J xR0U/Y1RQP0SC+Yw8NDj9QbGFv4XOsKIbKinv5AXfqN4KCiXSTVrGrgO3rhuiTDCi6gw YauRQw0Bn5F1kX+Kt3L5yDblgtHJi8NssPyltfYI408k9iFJvzuGLJ4eHw7ifuoh0vmz q8zUXDU4NwmhtZKDO4sYxo/lyFoseZnjcnZgst0KVQAZqM1mxKEy8fI2s1UTLraN3fL7 /sFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:accept-language:content-language :content-transfer-encoding:mime-version; bh=HFmUy37RBJOOL/5EDhwL4SjbgsOdcJm1aMphWXfWqs0=; b=tKzEpKj5M2YK7BQRh/rJ5vicKUZYNbgX98skAiiVVFHixeO1lCDcw+L98k//sUXPR8 +QevpEu6DRaz+bmXXm7r2yRqcYP/6Z+u0iW/SO2nLWmH8h5lhQRqk72KXYc1rrQCz3iC NE/PcIiuaxY/6aSkvHXwTOXCzU3Rysqlor2pp4yZVEuddKuHFA13Z3FfEG2Xq0XqHiUj teo54IuD/GbLhq9KL9v93zzqjfFocAxE7XtnqB9BsPqL3kKAsrJgmTvI8mTpcGDey8J1 J1Qo9AioUyteh+3j7xn52NsE0w6hKhA8yjjBXk64pmDxibk6aCcu8OrjeIQfUnrdRFYW K2hA== X-Gm-Message-State: AOAM530mbnm771pnxFlR6FxZ+sz+Gd7CXAWZIf1Rps3t1u5KJs0V5v2d Mi51u28RpznRH43DI+7pqPMOXOQKv0ic0Q== X-Google-Smtp-Source: ABdhPJwfhZ6KemlKHtPLQh49Fykd2K5JL6JyTnxw+P/Dai7uIru+ffNak9k0XIpe/zqYPIV6b9gdsg== X-Received: by 2002:a92:48da:: with SMTP id j87mr4530097ilg.78.1598747815274; Sat, 29 Aug 2020 17:36:55 -0700 (PDT) Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([2603:1036:4:9e::5]) by smtp.gmail.com with ESMTPSA id k11sm1888571iof.40.2020.08.29.17.36.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Aug 2020 17:36:54 -0700 (PDT) From: Tarek Saad To: Martin Horneffer , "spring@ietf.org" Thread-Topic: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) Thread-Index: AQHWfF3DcbuQKOn2b0uhrpd6J56vXQ== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 30 Aug 2020 00:36:52 +0000 Message-ID: References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 00:36:58 -0000 SGkgTWFydGluLA0KDQpTZWUgaW5saW5lIGZvciBzb21lIGNvbW1lbnRzLg0KDQrvu79PbiA4LzI3 LzIwLCA2OjM1IEFNLCAic3ByaW5nIG9uIGJlaGFsZiBvZiBNYXJ0aW4gSG9ybmVmZmVyIiA8c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1haG9AbGFiLmR0YWcuZGU+IHdyb3Rl Og0KDQogICAgSGVsbG8gZXZlcnlvbmUsDQoNCiAgICBtYXkgSSBjb21lIGJhY2sgdGhlIHRoZSBx dWVzdGlvbiBiZWxvdz8gT3IgcmF0aGVyIGxldCBtZSB1cGRhdGUgaXQgYSBsaXR0bGU6DQoNCiAg ICBJbiBjYXNlIGFuIFNSLU1QTFMgcGF0aCBpcyBicm9rZW4sIHNob3VsZCBhIG5vZGUgcmF0aGVy IGRyb3AgdGhlIHBhY2tldCwgDQogICAgb3IgZm9yd2FyZCBpdD8NCg0KICAgIFRoaXMgY2FuIGhh cHBlbiB3aGVuZXZlciB0aGUgSUdQIHBvaW50cyB0byBhIGNlcnRhaW4gbmV4dCBob3AsIGJ1dCB0 aGF0IA0KICAgIG5laXRoZXIgc3VwcGxpZXMgYSB2YWxpZCBTSUQsIG5vciBhbGxvd3MgTERQLXN0 aXRjaGluZyBmb3Igd2hhdGV2ZXIgDQogICAgcmVhc29uLiBGb3IgUFVTSCBhcyB3ZWxsIGFzIGZv ciBDT05USU5VRS4NCg0KICAgIFdlIGhhdmUgYmVlbiB1c2luZyBNUExTIHRyYW5zcG9ydCBhbmQg YSBCR1AgZnJlZSBjb3JlIHNpbmNlIGFib3V0IHR3byANCiAgICBkZWNhZGVzIG5vdywgdXNpbmcg TERQLiBJbiB0aGUgYW5hbG9nIGNhc2UsIExEUCBjcmVhdGVzICJ1bmxhYmVsbGVkIiANCiAgICBl bnRyaWVzIGluIHRoZSBMRklCLCBkb2VzIHRoZSBlcXVpdmFsZW50IG9mIGEgUE9QIG9wZXJhdGlv biBhbmQgZm9yd2FyZHMgDQogICAgdGhlIHBhY2tldCB0byB0aGUgbmV4dC1ob3AgYXMgY2hvc2Vu IGJ5IHRoZSBJR1AuDQoNCiAgICBUaGlzIGJlaGF2aW9yIG9idmlvdXNseSBicmVha3MgYW55IHRy YWZmaWMgdGhhdCByZWxpZXMgb24gYSBzZXJ2aWNlIA0KICAgIGxhYmVsLCBidXQgaXQgY2FuIHBy b3RlY3Qgc29tZSB0cmFmZmljLg0KICAgIEluIG91ciBjYXNlIGEgaHVnZSBwZXJjZW50YWdlIG9m IGFsbCB0cmFmZmljIHN0aWxsIGlzIHB1YmxpYyBJUHY0LiBUaGlzIA0KICAgIG5lZWRzIE1QTFMg b25seSBmb3IgYSB0cmFuc3BvcnQgbGFiZWwsIGJlIGl0IExEUCBvciBTUi1NUExTLiBJZiB0aGlz IA0KICAgIHRyYWZmaWMgZ2V0cyBmb3J3YXJkZWQgdW5sYWJlbGxlZCwgaXQgZm9sbG93cyBhbiBJ R1AgZGVmYXVsdCByb3V0ZSB0byBhIA0KICAgIGNlbnRyYWwgZGV2aWNlLCB3aGVyZSBpdCBpcyAx KSByZWRpcmVjdGVkIHRvIHRoZSBjb3JyZWN0IGRlc3RpbmF0aW9uIGFuZCANCiAgICAyKSBjb3Vu dGVkIGluIGEgd2F5IHRoYXQgb3BlcmF0b3JzIGNhbiBxdWlja2x5IHNlZSB3aGV0aGVyIGFuZCB3 aGVyZSANCiAgICB0aGlzIGtpbmQgb2YgZmFpbHVyZSBvY2N1cnMgYXQgc29tZSBwb2ludCBpbiB0 aGUgbmV0d29yay4NCg0KW1RTXTogVGhlIFNSIFBhdGggbWF5IGJlIGNvbXBvc2VkIG9mIG11bHRp cGxlIFNJRHMgKGkuZS4gbGFiZWwgc3RhY2spIC0tIHdoZXJlIHRoZSB0b3AgU0lEIGRlc3RpbmF0 aW9uIGlzIG5vdCB0aGUgU1IgUGF0aCBlbmRwb2ludC4uIEkgc2Vuc2UgZnJvbSAiZ2V0cyBmb3J3 YXJkZWQgdW5sYWJlbGxlZCAiIGFzIHlvdSB3aWxsIGRpc2NhcmQgdGhlIGZ1bGwgbGFiZWwgc3Rh Y2sgKD8pIGFuZCBmb3J3YXJkIHRoZSBwYWNrZXQgdW5sYWJlbGVkIHRvIHRoZSBjZW50cmFsIGRl dmljZT8gT3IgYXJlIHlvdSBlbmNhcHN1bGF0aW5nIHRoZSByZW1haW5pbmcgTVBMUyBwYWNrZXQg b3ZlciBJUCBhbmQgSVAgcm91dGluZyBwYWNrZXQgdG8gdGhlIGNlbnRyYWwgZGV2aWNlIHRvIGJl IGluc3BlY3RlZD8gSW4gZWl0aGVyIGNhc2UsIEkgZXhwZWN0IHNvbWVob3cgdGhlIHBhY2tldCB0 byBiZSB1bHRpbWF0ZWx5IGRlbGl2ZXJlZCB0byB0aGUgb3JpZ2luYWwgU1IgUGF0aCBlbmRwb2lu dC9lZ3Jlc3M/DQoNCiAgICBBZnRlciBtb3JlIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgYW5kIHNl dmVyYWwgaW50ZXJuYWwgZGlzY3Vzc2lvbnMgd2UgDQogICAgYWdyZWVkIHRoYXQgd2Ugd2FudCBw YWNrZXRzIHRvIGJlIGZvcndhcmRlZCB1bmxhYmVsbGVkIHJhdGhlciB0aGFuIA0KICAgIGRyb3Bw ZWQuIEFueW9uZSB0byBzaGFyZSwgb3Igb3Bwb3NlIHRoaXMgcG9zaXRpb24/DQpbVFNdOiBhZ2Fp biwgSSdtIG5vdCBjbGVhciBvbiB3aGVuIHlvdSBzYXkgImZvcndhcmQgdW5sYWJlbGxlZCIgLSBk byB5b3UgbWVhbiBwYWNrZXRzIHdpbGwgZm9sbG93IHRoZSB0b3AgU0lEJ3MgdGhlIElQIElHUCBy b3V0ZT8gT3IgYXJlIHlvdSBwZWFraW5nIGludG8gdGhlIGRlc3RpbmF0aW9uIElQIChwdWJsaWMg SVB2NCkgb2YgcGFja2V0IGVuY2Fwc3VsYXRlZCBpbiBNUExTIHRvIGRldGVybWluZSBob3cgdG8g Zm9yd2FyZCBpdD8NCg0KUmVnYXJkcywNClRhcmVrDQoNCiAgICBCZXN0IHJlZ2FyZHMsIE1hcnRp bg0KDQoNCiAgICBBbSAzMS4wMS4yMCB1bSAxNjo1MCBzY2hyaWViIE1hcnRpbiBIb3JuZWZmZXI6 DQogICAgPiBIZWxsbyBldmVyeW9uZSwNCiAgICA+DQogICAgPiBhZ2FpbiBpdCBzZWVtcyB0aGUg aW50ZXJlc3RpbmcgcXVlc3Rpb25zIG9ubHkgc2hvdyB1cCB3aGVuIGFwcGx5aW5nIA0KICAgID4g c29tZXRoaW5nIHRvIHRoZSBsaXZlIG5ldHdvcmsuLi4NCiAgICA+DQogICAgPiBXZSByYW4gaW50 byBzb21ldGhpbmcgdGhhdCBwb3NlcyBhIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gUkZDODY2MDogV2hh dCANCiAgICA+IGlzIHRoZSBleGFjdCBtZWFuaW5nIG9mIHNlY3Rpb24gMi4xMC4xLCAiRm9yd2Fy ZGluZyBmb3IgUFVTSCBhbmQgDQogICAgPiBDT05USU5VRSBvZiBHbG9iYWwgU0lEcyIsIHdoZW4g dGhlIGNob3NlbiBuZWlnaGJvciBkb2Vzbid0IHByb3ZpZGUgYSANCiAgICA+IHZhbGlkIE1QTFMg cGF0aD8NCiAgICA+DQogICAgPiBUaGUgcmVsZXZhbnQgc2VjdGlvbnMgcmVhZHM6DQogICAgPg0K ICAgID4gICAgICAgLSAgRWxzZSwgaWYgdGhlcmUgYXJlIG90aGVyIHVzYWJsZSBuZXh0IGhvcHMs IHVzZSB0aGVtIHRvIGZvcndhcmQNCiAgICA+ICAgICAgICAgIHRoZSBpbmNvbWluZyBwYWNrZXQu ICBUaGUgbWV0aG9kIGJ5IHdoaWNoIHRoZSByb3V0ZXIgIlIwIg0KICAgID4gICAgICAgICAgZGVj aWRlcyBvbiB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgb3RoZXIgbmV4dCBob3BzIGlzIGJleW9u ZA0KICAgID4gICAgICAgICAgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBGb3IgZXhhbXBs ZSwgdGhlIE1DQyBvbiAiUjAiIG1heQ0KICAgID4gICAgICAgICAgY2hvc2UgdGhlIHNlbmQgYW4g SVB2NCBwYWNrZXQgd2l0aG91dCBwdXNoaW5nIGFueSBsYWJlbCB0bw0KICAgID4gICAgICAgICAg YW5vdGhlciBuZXh0IGhvcC4NCiAgICA+DQogICAgPiBEb2VzIHRoZSBwYXJ0ICJzZW5kIGFuIElQ djQgcGFja2V0IHdpdGhvdXQgcHVzaGluZyBhbnkgbGFiZWwiIGFwcGx5IHRvIA0KICAgID4gUFVT SCBhbmQgQ09OVElOVUUsIG9yIGp1c3QgdG8gUFVTSD8NCiAgICA+IERvZXMgUjAgaGF2ZSB0byB2 YWxpZGF0ZSB0aGF0IG5laWdoYm9yIE4gY2FuIGNvcnJlY3RseSBwcm9jZXNzIHRvIA0KICAgID4g cGFja2V0PyBPciBjYW4gaXQgZm9yd2FyZCB0aGUgcGFja2V0IHJlZ2FyZGxlc3M/DQogICAgPg0K ICAgID4gVGhlIHJlYXNvbiBmb3IgYXNraW5nIGlzIHRoYXQgd2UgYXJlIG5vdyBzZWVpbmcgaXNz dWVzIHNpbWlsYXIgdG8gb25lcyANCiAgICA+IHdlIGhhZCB3aGVuIHN0YXJ0aW5nIHdpdGggTERQ IGJhc2VkIE1QTFMgYWJvdXQgdHdvIGRlY2FkZXMgYWdvOiANCiAgICA+IHRyYWZmaWMgYmVpbmcg YmxhY2sgaG9sZWQgZXZlbiB0aG91Z2ggYSBwYXRoIHRvIHRoZSBkZXN0aW5hdGlvbiANCiAgICA+ IGV4aXN0cywgYmVjYXVzZSB0aGUgTVBMUyBwYXRoIGlzIGludGVycnVwdGVkIHNvbWV3aGVyZSBp biB0aGUgbWlkZGxlLg0KICAgID4NCiAgICA+IFdpdGggTERQIHdlIGtub3cgdGhlIGNhc2Ugb2Yg TEZJQmVudHJpZXMgY2FsbGVkICJ1bmxhYmVsbGVkIi4gV2hpbGUgDQogICAgPiB0aGlzIGRvZXMg YnJlYWsgY29ubmVjdGl2aXR5IGZvciBtYW55IGtpbmRzIG9mIHNlcnZpY2UsIGUuZy4gdGhvc2Ug DQogICAgPiByZWx5aW5nIG9uIGFuIGFkZGl0aW9uYWwgc2VydmljZSBsYWJlbHMsIGl0IHN0aWxs IHdvcmtzIGZvciBwbGFpbiANCiAgICA+IElQKHY0KSB0cmFmZmljLiBJbiBvdXIgY2FzZXMsIHRo aXMgd29ya3MgcGVyZmVjdGx5IGZpbmUgZm9yIGFsbCANCiAgICA+IGludGVybmFsIHJvdXRpbmcg YW5kIGNvbnRyb2wgdHJhZmZpYy4gQW5kIGV2ZW4gZm9yIElQdjQgdHJhZmZpYyB0aGF0IA0KICAg ID4gZ2V0cyBjb2xsZWN0ZWQgYnkgYSBjZW50cmFsIHJvdXRlciB0aGF0IGluamVjdHMgYSBkZWZh dWx0IHJvdXRlLg0KICAgID4NCiAgICA+IEhvd2V2ZXIsIGRlcGVuZGluZyBvbiB0aGUgZXhhY3Qg aW50ZXJwcmV0YXRpb24gb2YgdGhlIGFib3ZlIHBhcmFncmFwaCwgDQogICAgPiBhbiBpbXBsZW1l bnRvciBtaWdodCBmZWVsIG9ibGlnZWQgdG8gY2hvc2UgdGhlIG5leHQgcGFyYWdyYXBoOg0KICAg ID4NCiAgICA+ICAgICAgIC0gIE90aGVyd2lzZSwgZHJvcCB0aGUgcGFja2V0Lg0KICAgID4NCiAg ICA+IFdoaWNoIGlzLCBhdCBsZWFzdCBpbiBvdXIgY2FzZSwgdmVyeSB1bmZvcnR1bmF0ZS4uLg0K ICAgID4NCiAgICA+IEFueSBhZHZpY2Ugb3Igb3BpbmlvbiBhcHByZWNpYXRlZCENCiAgICA+DQog ICAgPg0KICAgID4gQmVzdCByZWdhcmRzLCBNYXJ0aW4NCiAgICA+DQogICAgPg0KICAgID4NCiAg ICA+DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgID4gc3ByaW5nIG1haWxpbmcgbGlzdA0KICAgID4gc3ByaW5nQGlldGYub3JnDQogICAg PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQogICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzcHJpbmcg bWFpbGluZyBsaXN0DQogICAgc3ByaW5nQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Sun Aug 30 07:23:22 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37C43A03FC for ; Sun, 30 Aug 2020 07:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 Nud4fZvNCHIw for ; Sun, 30 Aug 2020 07:23:10 -0700 (PDT) Received: from mail-vk1-xa32.google.com (unknown [IPv6:2607:f8b0:4864:20::a32]) (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 17F8E3A0406 for ; Sun, 30 Aug 2020 07:21:40 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id i20so780316vkk.2 for ; Sun, 30 Aug 2020 07:21:40 -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=WGeKMEk3LROpza7yzSmBv3XuWCaYCxT9Vgw/64ptaGs=; b=khpYCuj8g5XFkWahU6QvnnXIYkMT8sjJlpykWk9lC546EhCQe8MrsUiS0z7iqOf3mZ /dQeg+SyHRo3PZmXYzWQnaFJ5GCnBVCKZDIym9n+jf/PvHHgRY0Kuusjuee4yxUisO1d FasiZaE4yDEuMJkIaG5A4TX10sVyJDu+UuLolKs9SbaZldfYUvDnV5wXz1nGSRnqZOmU r7awSJe+nUMuVfKLhpfG0KincW7iankO6bRILj231YCIRCwC89/t7xjBvxUx2Sn/hBwd 2TtGdwSCdF/6+DPOqaKHQNgONyoMW4+fvaSWx22ew7jwrEkopDI0kY05iLra00QYdWeY sSKg== 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=WGeKMEk3LROpza7yzSmBv3XuWCaYCxT9Vgw/64ptaGs=; b=ENrWZfCEYjrrZSr9CtkLIGzAKcUnoPrr+XfByu5wIYT5d7QCSrNn7pTJlaOx9Qduzz md/WVKMY1x48u2CAuWy1iVYZxy2Iea3anIwXIkXZiqfsVxkskveEH79YbopnXTCIXalv SWBt36WnnQfvRmCXvLuX+FWXIAkjgt8gxwQTb1kDdG1NdZNlC9Zzc+d3Kq5ysfZJ/dlh Elbtb/6wif9QW2HKFSFHXbp4SBh7vP6ObIKEFshcymmkTTo7a4qczj4bVmZ7Rt7w/XsM oVauPLbrB4H4MedRMCscIu0LCDKZVGLRJ0iCOB/olyPa9C8z9mPxbWGZOisAj+nkil/1 9Fzg== X-Gm-Message-State: AOAM530AIpI3iQacpiv2nEZE73Bjvn0vicqGwR5FUnXFPKDG51ZI7SpE qITBnLj+joB4YM/1ye7P8Lmd2Ae1PhCtNHgYyJY= X-Google-Smtp-Source: ABdhPJxFPeR7U52SttADmo+JnjGG1JNYtPeDquWHlTnX1uPWEG3cVRNo6ecPzQMxFzI2QpsfY3ljuap1j9JBNO85A7s= X-Received: by 2002:a1f:a402:: with SMTP id n2mr3633937vke.77.1598797284760; Sun, 30 Aug 2020 07:21:24 -0700 (PDT) MIME-Version: 1.0 References: <15389fb7-d7d5-2f28-2869-4ee9fb84fccb@lab.dtag.de> <52be9fc3-0764-93ec-9dca-64291f2f62ab@lab.dtag.de> In-Reply-To: From: Gyan Mishra Date: Sun, 30 Aug 2020 10:21:13 -0400 Message-ID: To: Tarek Saad Cc: Martin Horneffer , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000039e9ba05ae190064" Archived-At: Subject: Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 14:23:21 -0000 --00000000000039e9ba05ae190064 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin That is a very common scenario that occurs where one path where LDP neighbor has lost its label binding for FEC destinations. Most providers don=E2=80=99t label all prefixes and only label interesting = traffic meaning FEC destination which is the egress endpoint loopback iBGP peers for an LSP. So their is an ACL that is used for label allocation, label advertisement and label accept policy to created the label binding LIB and and Label forwarding table LFIB. So the LSP is built from ingress PE to egress PE and the label mapping along the path occurs downstream unsolicited in the opposite direction of the LSP via label mapping message from the egress PE that the LSP is being built to - to the ingress PE from the downstream node to the upstream node. Most operators have a BGP free and PIM free core and usually don=E2=80=99t = dual stack the core and the concept of softwire mesh framework RFC 5565 so 6to4 softwire would be v6 edge over a v4 core or v4 edge over a v6 core. So with the BGP free core all PE are BGP route reflector clients and have a peer to RRs that sit in the P core. The P core is BGP free so only runs an IGP ISIS PE OSPF. This point is critical and that is that since the core is BGP free it can not perform L3 forwarding so all packets must be L2.5 label switched via topmost label either LDP or RSVP or SR-TE. So now that we have established the core construct let=E2=80=99s dig into t= he problem with the label mapping being broken on a node along a path. So with LDPv4 or LDPv6 or SR-MPLS we have a concept called =E2=80=9Cldp-IGP= =E2=80=9D synchronization. SR-MPLS uses IGP sync for SR sid labels as well since SR is reusing the MPLS data plane. So on all MPLS core enabled interfaces on both PE and P LDP sync is enabled. So the goal of ldp-IGP sync is to prevent black hole of packets on MPLS interfaces cause by MPLS LDP failure and so how it works is the IGP prefix that needs to build a label binding for FEC destination for label swapping to occurs in the core so the IGP must not come up and forward traffic along the path until MPLS is up or traffic will be =E2=80=9Cblack holed=E2=80=9D = and dropped. So how this is accomplished is the IGP sets the prefix metric to maximum 65535 for ospf and ISIS wide metric does the same so the path now cannot be utilized until ldp comes up and the label binding message is received via downstream unsolicited to create outgoing label for the LFIB entry. Once LDP is up and the LFIB entry outing label is populated the IGP prefix is =E2=80=9Cunset=E2=80=9D so now is set to its normal IGP metric and traffic = can now flow over the path. For LDP troubleshooting first you have to see if discovery link LDP is up on the interface and then have to check if both Ldp adjacencent nodes have a route in rib for each other=E2=80=99s LDP router id for the ldp neighbor = to come UP and label mapping message to be sent. As you mentioned if their is summarization for FEC which results in a loop the binding does not get built for the FEC resulting in unlabeled FECs in the LFIB. Hope that explanation helps. Kind Regards Gyan On Sat, Aug 29, 2020 at 8:37 PM Tarek Saad wrote: > Hi Martin, > > > > See inline for some comments. > > > > =EF=BB=BFOn 8/27/20, 6:35 AM, "spring on behalf of Martin Horneffer" < > spring-bounces@ietf.org on behalf of maho@lab.dtag.de> wrote: > > > > Hello everyone, > > > > may I come back the the question below? Or rather let me update it a > little: > > > > In case an SR-MPLS path is broken, should a node rather drop the > packet, > > or forward it? > > > > This can happen whenever the IGP points to a certain next hop, but > that > > neither supplies a valid SID, nor allows LDP-stitching for whatever > > reason. For PUSH as well as for CONTINUE. > > > > We have been using MPLS transport and a BGP free core since about two > > decades now, using LDP. In the analog case, LDP creates "unlabelled" > > entries in the LFIB, does the equivalent of a POP operation and > forwards > > the packet to the next-hop as chosen by the IGP. > > > > This behavior obviously breaks any traffic that relies on a service > > label, but it can protect some traffic. > > In our case a huge percentage of all traffic still is public IPv4. > This > > needs MPLS only for a transport label, be it LDP or SR-MPLS. If this > > traffic gets forwarded unlabelled, it follows an IGP default route to > a > > central device, where it is 1) redirected to the correct destination > and > > 2) counted in a way that operators can quickly see whether and where > > this kind of failure occurs at some point in the network. > > > > [TS]: The SR Path may be composed of multiple SIDs (i.e. label stack) -- > where the top SID destination is not the SR Path endpoint.. I sense from > "gets forwarded unlabelled " as you will discard the full label stack (?) > and forward the packet unlabeled to the central device? Or are you > encapsulating the remaining MPLS packet over IP and IP routing packet to > the central device to be inspected? In either case, I expect somehow the > packet to be ultimately delivered to the original SR Path endpoint/egress= ? > > > > After more operational experience and several internal discussions we > > agreed that we want packets to be forwarded unlabelled rather than > > dropped. Anyone to share, or oppose this position? > > [TS]: again, I'm not clear on when you say "forward unlabelled" - do you > mean packets will follow the top SID's the IP IGP route? Or are you peaki= ng > into the destination IP (public IPv4) of packet encapsulated in MPLS to > determine how to forward it? > > > > Regards, > > Tarek > > > > Best regards, Martin > > > > > > Am 31.01.20 um 16:50 schrieb Martin Horneffer: > > > Hello everyone, > > > > > > again it seems the interesting questions only show up when applying > > > something to the live network... > > > > > > We ran into something that poses a question related to RFC8660: Wha= t > > > is the exact meaning of section 2.10.1, "Forwarding for PUSH and > > > CONTINUE of Global SIDs", when the chosen neighbor doesn't provide = a > > > valid MPLS path? > > > > > > The relevant sections reads: > > > > > > - Else, if there are other usable next hops, use them to > forward > > > the incoming packet. The method by which the router "R0" > > > decides on the possibility of using other next hops is > beyond > > > the scope of this document. For example, the MCC on "R0" > may > > > chose the send an IPv4 packet without pushing any label to > > > another next hop. > > > > > > Does the part "send an IPv4 packet without pushing any label" apply > to > > > PUSH and CONTINUE, or just to PUSH? > > > Does R0 have to validate that neighbor N can correctly process to > > > packet? Or can it forward the packet regardless? > > > > > > The reason for asking is that we are now seeing issues similar to > ones > > > we had when starting with LDP based MPLS about two decades ago: > > > traffic being black holed even though a path to the destination > > > exists, because the MPLS path is interrupted somewhere in the middl= e. > > > > > > With LDP we know the case of LFIBentries called "unlabelled". While > > > this does break connectivity for many kinds of service, e.g. those > > > relying on an additional service labels, it still works for plain > > > IP(v4) traffic. In our cases, this works perfectly fine for all > > > internal routing and control traffic. And even for IPv4 traffic tha= t > > > gets collected by a central router that injects a default route. > > > > > > However, depending on the exact interpretation of the above > paragraph, > > > an implementor might feel obliged to chose the next paragraph: > > > > > > - Otherwise, drop the packet. > > > > > > Which is, at least in our case, very unfortunate... > > > > > > Any advice or opinion appreciated! > > > > > > > > > Best regards, Martin > > > > > > > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000039e9ba05ae190064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Martin

    That is a very common scenario that occurs where one pat= h where LDP neighbor has lost its label binding for FEC destinations. =C2= =A0

    Most providers don= =E2=80=99t label all prefixes and only label interesting traffic meaning FE= C destination which is the egress endpoint loopback iBGP peers for an LSP.<= /div>

    So their is an ACL that = is used for label allocation, label advertisement and label accept policy t= o created the label binding LIB and and Label forwarding table LFIB. =C2=A0=

    So the LSP is built fro= m ingress PE to egress PE and the label mapping along the path occurs downs= tream unsolicited in the opposite direction of the LSP via label mapping me= ssage from the egress PE that the LSP is being built to - to the ingress PE= from the downstream node to the upstream node.

    =
    Most operators have a BGP free and PIM free core an= d usually don=E2=80=99t dual stack the core and the concept of softwire mes= h framework RFC 5565 so 6to4 softwire would be v6 edge over a v4 core or v4= edge over a v6 core. =C2=A0

    So with the BGP free core all PE are BGP route reflector clients and h= ave a peer to RRs that sit in the P core.=C2=A0

    =
    The P core is BGP free so only runs an IGP ISIS PE = OSPF.=C2=A0 This point is critical and that is that since the core is BGP f= ree it can not perform L3 forwarding so all packets must be L2.5 label swit= ched via topmost label either LDP or RSVP or SR-TE.
    =
    So now that we have established the core constr= uct let=E2=80=99s dig into the problem with the label mapping being broken = on a node along a path.

    = So with LDPv4 or LDPv6 or SR-MPLS we have a concept called =E2=80=9Cldp-IGP= =E2=80=9D synchronization.=C2=A0 SR-MPLS uses IGP sync for SR sid labels as= well since SR is reusing the MPLS data plane.

    <= /div>
    So on all MPLS core enabled interfaces on both PE an= d P LDP sync is enabled.=C2=A0

    So the goal of ldp-IGP sync is to prevent black hole of packets on M= PLS interfaces cause by MPLS LDP failure and so how it works is the IGP pre= fix that needs to build a label binding for FEC destination for label swapp= ing to occurs in the core so the IGP must not come up and forward traffic a= long the path until MPLS is up or traffic will be =E2=80=9Cblack holed=E2= =80=9D and dropped.=C2=A0 So how this is accomplished is the IGP sets the p= refix metric to maximum 65535 for ospf and ISIS wide metric does the same s= o the path now cannot be utilized until ldp comes up and the label binding = message is received via downstream unsolicited to create outgoing label for= the LFIB entry.=C2=A0 Once LDP is up and the LFIB entry outing label is po= pulated the IGP prefix is =E2=80=9Cunset=E2=80=9D so now is set to its norm= al IGP metric and traffic can now flow over the path.

    For LDP troubleshooting first you have to see= if discovery link LDP is up on the interface and then have to check if bot= h Ldp adjacencent nodes have a route in rib for each other=E2=80=99s LDP ro= uter id for the ldp neighbor to come UP and label mapping message to be sen= t.=C2=A0 As you mentioned if their is summarization for FEC which results i= n a loop the binding does not get built for the FEC resulting in unlabeled = FECs in the LFIB.

    Hope t= hat explanation helps.

    <= br>
    Kind Regards=C2=A0

    Gyan=C2=A0

    <= div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 29, 2020 at 8:37 PM Tarek = Saad <tsaad.net@gmail.com>= wrote:
    Hi Martin,



    See inline for = some comments.



    =EF=BB=BFOn 8/27/20, 6:35 AM, "spring on= behalf of Martin Horneffer" <spring-bounces@ietf.org on behalf of maho@lab.dtag.de> wrote:=



    =C2=A0 =C2=A0 Hello everyone,



    =C2=A0 =C2=A0 = may I come back the the question below? Or rather let me update it a little= :



    =C2=A0 =C2=A0 In case an SR-MPLS path is broken, should a = node rather drop the packet,

    =C2=A0 =C2=A0 or forward it?


    =C2=A0 =C2=A0 This can happen whenever the IGP points to a certain ne= xt hop, but that

    =C2=A0 =C2=A0 neither supplies a valid SID, nor al= lows LDP-stitching for whatever

    =C2=A0 =C2=A0 reason. For PUSH as w= ell as for CONTINUE.



    =C2=A0 =C2=A0 We have been using MPLS t= ransport and a BGP free core since about two

    =C2=A0 =C2=A0 decades = now, using LDP. In the analog case, LDP creates "unlabelled"
    =
    =C2=A0 =C2=A0 entries in the LFIB, does the equivalent of a POP operati= on and forwards

    =C2=A0 =C2=A0 the packet to the next-hop as chosen = by the IGP.



    =C2=A0 =C2=A0 This behavior obviously breaks any= traffic that relies on a service

    =C2=A0 =C2=A0 label, but it can p= rotect some traffic.

    =C2=A0 =C2=A0 In our case a huge percentage of = all traffic still is public IPv4. This

    =C2=A0 =C2=A0 needs MPLS onl= y for a transport label, be it LDP or SR-MPLS. If this

    =C2=A0 =C2= =A0 traffic gets forwarded unlabelled, it follows an IGP default route to a=

    =C2=A0 =C2=A0 central device, where it is 1) redirected to the cor= rect destination and

    =C2=A0 =C2=A0 2) counted in a way that operato= rs can quickly see whether and where

    =C2=A0 =C2=A0 this kind of fai= lure occurs at some point in the network.



    [TS]: The SR Path = may be composed of multiple SIDs (i.e. label stack) -- where the top SID de= stination is not the SR Path endpoint.. I sense from "gets forwarded u= nlabelled " as you will discard the full label stack (?) and forward t= he packet unlabeled to the central device? Or are you encapsulating the rem= aining MPLS packet over IP and IP routing packet to the central device to b= e inspected? In either case, I expect somehow the packet to be ultimately d= elivered to the original SR Path endpoint/egress?



    =C2=A0 =C2= =A0 After more operational experience and several internal discussions we <= br>
    =C2=A0 =C2=A0 agreed that we want packets to be forwarded unlabelled= rather than

    =C2=A0 =C2=A0 dropped. Anyone to share, or oppose this= position?

    [TS]: again, I'm not clear on when you say "forw= ard unlabelled" - do you mean packets will follow the top SID's th= e IP IGP route? Or are you peaking into the destination IP (public IPv4) of= packet encapsulated in MPLS to determine how to forward it?


    Regards,

    Tarek



    =C2=A0 =C2=A0 Best regards, Martin




    =C2=A0 =C2=A0 Am 31.01.20 um 16:50 schrieb Martin Horn= effer:

    =C2=A0 =C2=A0 > Hello everyone,

    =C2=A0 =C2=A0 ><= br>
    =C2=A0 =C2=A0 > again it seems the interesting questions only sho= w up when applying

    =C2=A0 =C2=A0 > something to the live network= ...

    =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 > We ran into somethi= ng that poses a question related to RFC8660: What

    =C2=A0 =C2=A0 >= ; is the exact meaning of section 2.10.1, "Forwarding for PUSH and
    =C2=A0 =C2=A0 > CONTINUE of Global SIDs", when the chosen neig= hbor doesn't provide a

    =C2=A0 =C2=A0 > valid MPLS path?
    <= br>=C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 > The relevant sections reads= :

    =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0-=C2=A0 Else, if there are other usable next hops, use them to forwar= d

    =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the incoming = packet.=C2=A0 The method by which the router "R0"

    =C2=A0 = =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 decides on the possibility of= using other next hops is beyond

    =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 the scope of this document.=C2=A0 For example, the MCC on= "R0" may

    =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 chose the send an IPv4 packet without pushing any label to

    = =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 another next hop.
    <= br>=C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 > Does the part "send an= IPv4 packet without pushing any label" apply to

    =C2=A0 =C2=A0= > PUSH and CONTINUE, or just to PUSH?

    =C2=A0 =C2=A0 > Does R0= have to validate that neighbor N can correctly process to

    =C2=A0 = =C2=A0 > packet? Or can it forward the packet regardless?

    =C2=A0 = =C2=A0 >

    =C2=A0 =C2=A0 > The reason for asking is that we are = now seeing issues similar to ones

    =C2=A0 =C2=A0 > we had when st= arting with LDP based MPLS about two decades ago:

    =C2=A0 =C2=A0 >= ; traffic being black holed even though a path to the destination

    = =C2=A0 =C2=A0 > exists, because the MPLS path is interrupted somewhere i= n the middle.

    =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 > With LDP = we know the case of LFIBentries called "unlabelled". While
    =C2=A0 =C2=A0 > this does break connectivity for many kinds of service= , e.g. those

    =C2=A0 =C2=A0 > relying on an additional service la= bels, it still works for plain

    =C2=A0 =C2=A0 > IP(v4) traffic. I= n our cases, this works perfectly fine for all

    =C2=A0 =C2=A0 > i= nternal routing and control traffic. And even for IPv4 traffic that
    =C2=A0 =C2=A0 > gets collected by a central router that injects a defau= lt route.

    =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 > However, depe= nding on the exact interpretation of the above paragraph,

    =C2=A0 = =C2=A0 > an implementor might feel obliged to chose the next paragraph:<= br>
    =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2= =A0-=C2=A0 Otherwise, drop the packet.

    =C2=A0 =C2=A0 >

    =C2= =A0 =C2=A0 > Which is, at least in our case, very unfortunate...

    = =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 > Any advice or opinion apprecia= ted!

    =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 >

    =C2=A0 =C2= =A0 > Best regards, Martin

    =C2=A0 =C2=A0 >

    =C2=A0 =C2= =A0 >

    =C2=A0 =C2=A0 >

    =C2=A0 =C2=A0 >

    =C2=A0 = =C2=A0 > _______________________________________________

    =C2=A0 = =C2=A0 > spring mailing list

    =C2=A0 =C2=A0 > spring@ietf.org

    =C2=A0 =C2= =A0 > https://www.ietf.org/mailman/listinfo/spring



    =C2=A0 =C2=A0 ____________________________________________= ___

    =C2=A0 =C2=A0 spring mailing list

    =C2=A0 =C2=A0     spring@ietf.org

    = =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/spr= ing

    _______________________________________________

    sprin= g mailing list

    = spring@ietf.org

    https://www.ietf.org/mailman/= listinfo/spring

    --


    Gyan Mishra

    Network Solutions Architect=C2=A0

    M 3= 01 502-1347
    13101 Columbia Pike=C2=A0
    Silver Spring, MD


    --00000000000039e9ba05ae190064-- From nobody Mon Aug 31 07:58:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B443A14A8 for ; Mon, 31 Aug 2020 07:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxUAN6Abl5yE for ; Mon, 31 Aug 2020 07:58:13 -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 A4EDD3A14BB for ; Mon, 31 Aug 2020 07:58:06 -0700 (PDT) Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5C7AE4DB6DA7A5D30C17 for ; Mon, 31 Aug 2020 15:58:04 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 31 Aug 2020 15:58:03 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 31 Aug 2020 22:58:01 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Mon, 31 Aug 2020 22:58:01 +0800 From: "Dongjie (Jimmy)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-dong-spring-sr-for-enhanced-vpn-10.txt Thread-Index: AQHWf18ggGTluKy6qkWpas+7CuC39KlSSdbA Date: Mon, 31 Aug 2020 14:58:01 +0000 Message-ID: References: <159885495416.5924.7558059493029281680@ietfa.amsl.com> In-Reply-To: <159885495416.5924.7558059493029281680@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.220.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] FW: New Version Notification for draft-dong-spring-sr-for-enhanced-vpn-10.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 14:58:16 -0000 SGkgV0csIA0KDQpGWUkgYSBuZXcgcmV2aXNpb24gb2YgZHJhZnQtZG9uZy1zcHJpbmctc3ItZm9y LWVuaGFuY2VkLXZwbiBoYXMgYmVlbiB1cGxvYWRlZC4gDQoNCkFzIHN1Z2dlc3RlZCBieSBXRyBj aGFpcnMsIHRoaXMgaXMgdGhlIGZpcnN0IHVwZGF0ZSBhZnRlciB0aGUgZG9jdW1lbnQgc3BsaXQs IGFuZCB0aGUgZG9jdW1lbnQgdHlwZSBpcyBjaGFuZ2VkIHRvIGluZm9ybWF0aW9uYWwuIFRoZSBt YWpvciBjb250ZW50IGlzIGFib3V0IGhvdyByZXNvdXJjZS1hd2FyZSBTSURzIGNhbiBiZSB1c2Vk IHRvIGJ1aWxkIHZpcnR1YWwgdHJhbnNwb3J0IG5ldHdvcmtzIChWVE5zKSBmb3IgVlBOKyBzZXJ2 aWNlLCBhbmQgZHJhZnQtaWV0Zi1zcHJpbmctcmVzb3VyY2UtYXdhcmUtc2VnbWVudHMgaXMgbGlz dGVkIGFzIG5vcm1hdGl2ZSByZWZlcmVuY2UgDQoNClRoaXMgdmVyc2lvbiBhbHNvIHJlc29sdmVz IHRoZSBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgV0cgYWRvcHRpb24gcG9sbCB3aGljaCBhcmUg bW9yZSByZWxhdGVkIHRvIHRoZSB2aXJ0dWFsIG5ldHdvcmsgY2FzZSBvZiByZXNvdXJjZS1hd2Fy ZSBTSURzLg0KDQpZb3VyIHJldmlldyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuIA0KDQpCZXN0 IHJlZ2FyZHMsDQpKaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBNb25kYXksIEF1Z3VzdCAzMSwgMjAyMCAyOjIzIFBNDQpUbzogVGFrdXlhIE1peWFzYWth IDx0YS1taXlhc2FrYUBrZGRpLmNvbT47IEZlbmd3ZWkgUWluIDxxaW5mZW5nd2VpQGNoaW5hbW9i aWxlLmNvbT47IEZyYW5jb2lzIENsYWQgPGZjbGFkQGNpc2NvLmNvbT47IFpoZW5xaWFuZyBMaSA8 bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPjsgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50 QGdtYWlsLmNvbT47IERvbmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IFlvbmdx aW5nIFpodSA8emh1eXE4QGNoaW5hdGVsZWNvbS5jbj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtZG9uZy1zcHJpbmctc3ItZm9yLWVuaGFuY2VkLXZwbi0xMC50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZG9uZy1zcHJpbmctc3ItZm9yLWVu aGFuY2VkLXZwbi0xMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmll IERvbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQt ZG9uZy1zcHJpbmctc3ItZm9yLWVuaGFuY2VkLXZwbg0KUmV2aXNpb246CTEwDQpUaXRsZToJCVNl Z21lbnQgUm91dGluZyBiYXNlZCBWaXJ0dWFsIFRyYW5zcG9ydCBOZXR3b3JrIGZvciBFbmhhbmNl ZCBWUE4NCkRvY3VtZW50IGRhdGU6CTIwMjAtMDgtMzENCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTE2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRvbmctc3ByaW5nLXNyLWZvci1lbmhhbmNlZC12cG4tMTAu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZG9uZy1zcHJpbmctc3ItZm9yLWVuaGFuY2VkLXZwbi8NCkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9uZy1zcHJpbmctc3ItZm9yLWVuaGFuY2Vk LXZwbi0xMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtZG9uZy1zcHJpbmctc3ItZm9yLWVuaGFuY2VkLXZwbg0KRGlmZjogICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1kb25nLXNwcmluZy1z ci1mb3ItZW5oYW5jZWQtdnBuLTEwDQoNCkFic3RyYWN0Og0KICAgSS1ELmlldGYtc3ByaW5nLXJl c291cmNlLWF3YXJlLXNlZ21lbnRzIGRlc2NyaWJlcyB0aGUgbWVjaGFuaXNtIHRvDQogICBhc3Nv Y2lhdGUgbmV0d29yayByZXNvdXJjZSBhdHRyaWJ1dGVzIHRvIFNlZ21lbnQgUm91dGluZyBJZGVu dGlmaWVycw0KICAgKFNJRHMpLiAgVGhlIHJlc291cmNlLWF3YXJlIFNJRHMgY2FuIGJlIHVzZWQg dG8gYnVpbGQgU1IgcGF0aHMgd2l0aCBhDQogICBzZXQgb2YgcmVzZXJ2ZWQgbmV0d29yayByZXNv dXJjZXMuICBJbiBhZGRpdGlvbiwgdGhlIHJlc291cmNlLWF3YXJlDQogICBTSURzIGNhbiBiZSB1 c2VkIHRvIGJ1aWxkIFNSIGJhc2VkIHZpcnR1YWwgbmV0d29ya3MsIHdoaWNoIGNhbiBiZQ0KICAg dXNlZCBhcyB2aXJ0dWFsIHVuZGVybGF5IG5ldHdvcmtzIHdpdGggdGhlIG5ldHdvcmsgdG9wb2xv Z3kgYW5kDQogICByZXNvdXJjZSBhdHRyaWJ1dGVzIHJlcXVpcmVkIGJ5IGRpZmZlcmVudCBjdXN0 b21lcnMgb3Igc2VydmljZXMuDQogICBTdWNoIHZpcnR1YWwgbmV0d29ya3MgYXJlIGNhbGxlZCB2 aXJ0dWFsIHRyYW5zcG9ydCBuZXR3b3JrcyAoVlROcykuDQogICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyB0aGUgbWVjaGFuaXNtIG9mIHVzaW5nIHJlc291cmNlLWF3YXJlIFNJRHMgdG8NCiAgIGJ1 aWxkIFNSIGJhc2VkIFZUTnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K