From nobody Tue Feb 1 16:19:17 2022 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 4233F3A1769; Tue, 1 Feb 2022 16:19:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164376115018.24067.5182634269610657627@ietfa.amsl.com> Date: Tue, 01 Feb 2022 16:19:10 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-stamp-srpm-03.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, 02 Feb 2022 00:19:10 -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 : Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks Authors : Rakesh Gandhi Clarence Filsfils Daniel Voyer Mach(Guoyi) Chen Bart Janssens Richard Foote Filename : draft-ietf-spring-stamp-srpm-03.txt Pages : 24 Date : 2022-02-01 Abstract: Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and its optional extensions defined in RFC 8972 and further augmented in draft-ietf-ippm-stamp-srpm. The procedure described is applicable to SR-MPLS and SRv6 data planes and is used for both links and end-to- end SR paths including SR Policies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-stamp-srpm/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-stamp-srpm-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Feb 2 04:07:24 2022 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 DAB103A3032; Wed, 2 Feb 2022 04:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 ARNJncZK7OcO; Wed, 2 Feb 2022 04:07:05 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80108.outbound.protection.outlook.com [40.107.8.108]) (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 03D843A3030; Wed, 2 Feb 2022 04:07:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nvxn9R44DW1MG/6iJB1hWGldMEZqSc5ExiuSOJlCUrYn6y9bnrhc5N95AXVnCVSYjRHJ6oQG49qVrnNx6qmbZL8Xr2TD6KUqWaYNm1llh4k2OWkTHfyRxDnEoN5V4AjH9dvF+KjqWa1WKMXdzDsCItOvWfULC6vjvlFPxFpAATpU/XnARxfc9vNeWpRagRMooofv1F/7EStvuL1Vfyo9vgX4j1mL25cwVVH9rtvmyQkzoiWwBIXyYuKK6ZHnk08KbCsvWcA60RXJMWQDt1IzNJtnrVSIOOS6EwSiAD6Nlry6PtaBkWt+lsewR4lM3/XQNtAiKpj/lrlO0jmfT1/srA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9J/3tU3GoDi7nujZNbrI7X6Cy+g3HoanG9UFiTJYZMQ=; b=MTZJQK0hR+dtpKNQXISbj+Yt8rfDfc30abJapbU78p9W9oQWVaHKFDjSQfEb45lfqWOQJ12+AEPHss58yrq3HOl1m4xrmTW0NYC+UZjEVuYIr2bn0jN7Yp1tMtjvb/HnOvBWWhRHM4ip+qK5V8ObNCS56709B8vshIGzL+scyRByZqGFq3PatnOW5Cskb0qlyCMbTOIHBrYx01NfTj9TPICvRZr4dYncAJId8m6sJNNDiunI6im8jteTyNumcYsJS9Q8E1nte77SeBvwJ0x/jFmNPs+dordk9pt4LEbBTNqGwXmOp+mzVF8qrnPdZqt02RQgjuX9iObMhr3hG/0Xrw== 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=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9J/3tU3GoDi7nujZNbrI7X6Cy+g3HoanG9UFiTJYZMQ=; b=VANQJR1ZFMAMyCpRAqTZ796QVFEFjQVy4woxnOZ7J+JVzjf5ncwoF4n06vT3gE094J5LtnMViI0OIgQCfGV2+Tm6jG++0nDTd6chdyYLOugU0fGYCEIJaDM66q8E3XO04+3bylyUiwKyWakytHViv7HVVwNbJR8+Ono8hliyIfg= Received: from VI1PR0701MB6991.eurprd07.prod.outlook.com (2603:10a6:800:17d::22) by AM5PR0701MB2674.eurprd07.prod.outlook.com (2603:10a6:203:6e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 2 Feb 2022 12:07:01 +0000 Received: from VI1PR0701MB6991.eurprd07.prod.outlook.com ([fe80::e545:cd28:2ad7:a945]) by VI1PR0701MB6991.eurprd07.prod.outlook.com ([fe80::e545:cd28:2ad7:a945%4]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 12:07:01 +0000 From: "Bocci, Matthew (Nokia - GB)" To: Ketan Talaulikar CC: "" , "rtg-dir@ietf.org" , "spring@ietf.org" , "last-call@ietf.org" , "draft-ietf-spring-segment-routing-policy.all@ietf.org" Thread-Topic: RtgDir Last Call review: draft-ietf-spring-segment-routing-policy-14 Thread-Index: AQHYFDzafFfVYeWBskCYJFPvsKw3Rax5etAAgAa0TyA= Date: Wed, 2 Feb 2022 12:07:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ccd15f86-6542-40b2-6901-08d9e64484dc x-ms-traffictypediagnostic: AM5PR0701MB2674:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9n2aBxnqWBW8FsoqxmXzOv7mvoLIrBU4OLYHEb6PgUWvKYu3dZVjR35P6UoB/upMUiSySVMsjeAMFlyjy2LJoftVyzSbH3HBGyzlpweSMdOcuyLlVxlqrHFp489a7jxL83gC2Mh4n+fFX0zQcGtOpnruDTzKyaDYvWCWDt3Ns6kOPlTDpW+QVvCCo4SjClQdXb+BXSHn9DZmb2H66cMlggy8ludjpVVwioTVafEz2HesVwBmiTmou8A/fAT8FjwtZY0hwmM2JKgmqdLSkE2zsPAeGDe4gGTJ3cpPq5Kyo//wZncyFGor4uF3uJslgommySiFfZtKVSitoqd7I+GUFB+ZnxsbQSRIHLi8I8puDIxsZdpmsrWL+TkgdFXfqPe2GaaTAtV6uJ6YI+i0bizI+TqibARR8ryfaP3VvZXrR99XKp5SPo1KlDFLyxcLPRT0+U3sD/YbwTkm77Kd9PPXz9bn3VHYUyJrZ8TELISDOW5zIDSykPNbiYHXAvjXLB4ED+3HDzqhmnNc0n+VFoWQhAvrkVZ1/VgkoDWFoArlt1Lph3fMK/5s9zRfmIm2r1R63/Ei6wEYZeQYzwuUyqm95mu4C5ayc9nW3MaxrzwaoQ0tOtHBNz86X/TW+UtpwH5dCW0TZB+TatLAqrTmsy3R2q0io1HsKPmDf4RN8P8CPitbkkUZ7TUWOD+//jqz1XtanHPOvbM+2uucXPJwGxGB1BAyqbz4XORkJtn9XaTJFhQ/6tSgp2HrrhhEc62dUBXtUGwi9wrZcRnufAiLE4jgYaZrYe/GrsRJA8+BgvM5zr1/vr4xNb5QhNPidPsSW84Jwj1A+Wvwi7qDtfCxQPXylw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB6991.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(508600001)(4326008)(86362001)(7696005)(122000001)(6506007)(966005)(33656002)(55016003)(8936002)(316002)(38100700002)(6916009)(53546011)(71200400001)(66556008)(66946007)(8676002)(76116006)(64756008)(66446008)(91956017)(66476007)(83380400001)(9686003)(38070700005)(52536014)(82960400001)(186003)(26005)(5660300002)(2906002)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?V/DCmEDEf/8jYucchYKL6COSerubVU6slVf9nXyplUHWSgdDpz4EItbdd3G1?= =?us-ascii?Q?xm/agOZ0+Ab13Od1RYr0qwk0uZTkMCgvtWCxDDVP80DLM/ibaz4/wWp7n9wV?= =?us-ascii?Q?BpG3mFvD8JDKKG9rzFQRBFjrXxo4nFXnnmAP4Ne1f4HTjJ4rFnCWHVnAOuOh?= =?us-ascii?Q?+VXzDXyFLQ68CR3hx8yc9m2Z1MbHAekeQREUGdvQf+7B42j7lf0m3CrG/gww?= =?us-ascii?Q?fyQLNpwRi8pdsR7mIiGpxPgKJtIJJzswQMu8w45xdrc60ANIeRXFB6D6i+gx?= =?us-ascii?Q?0l8kb99fEBe6H24NCgsPVCVSGr1MuZ8yVb2toeewT0LByPXmIVzHN6gWzfyE?= =?us-ascii?Q?WgmvKTOJ01kri//AHH6gUnUJS5vlZYwtcrH3p9xdfigwbPhuChwS+jlETN9i?= =?us-ascii?Q?6xRND9KlbVIOdAMa+1q/JebBUfzGpXl5pp3O0Sm1uuOjeo9vMRwNzMB2Vo41?= =?us-ascii?Q?V+1y5fTvz6Imt6lumN4nKakE/0WfmhCp8+nok0e5/pArar0kRBvUeMym2mV+?= =?us-ascii?Q?nCKZUbL27DmpQ6BufY10Rtze8gXKXMoorM3KDvzR2xAAss03zaFValU/3omt?= =?us-ascii?Q?2BrH4RSipp1LT3lZZ4b1ZXx0Dt5ptnO8vrzYvXHa20jFEObA1YAdlID+4XiK?= =?us-ascii?Q?IEWfxV3Jnx7gjOBiU+2JSPvPXscAsWr9uyTfO1yMEoD10a+FMkeTRiIa+nuZ?= =?us-ascii?Q?Gf8TfTbRWDlKM9ktt0Q1ueOn/79U+88kuNkqKAq+vLM0Wy2/Ihf4qNA/f2lD?= =?us-ascii?Q?b31XM+lQ0TNme55Gh+OZU4A632/nPCjOACrKtJ9fu2/VLAV9PK/wk8ziyuEv?= =?us-ascii?Q?8KEqrG6//67ds46nraNQCqeS6Pge3KNuYljYksskT91m7L0yT835wCbxaM5z?= =?us-ascii?Q?5Fke69dXixaw8PDi45MCXYdz4d/vs641oXST2CDk9ft0nzUzFC7ON5sIzbvy?= =?us-ascii?Q?In2zP/7dw0AGH+uUWwmdYnH/RStCY+Or4IhT4h8FzenfbUg0x98grCerHIXQ?= =?us-ascii?Q?T16/zhX6JTfV3ijLJVsM8nxsZJGbc0c8xNjiS6a4KVsZwkkto3PxZAZuKdBc?= =?us-ascii?Q?3ZETQwDqrQ+ZlwAcJTdvUDtmomPwAu1riMpP6bOZFMcgbxLlLVnYwAuFZWvo?= =?us-ascii?Q?8AnJ8F5+34SoPduNm/QcgNCZ7ZGkwOhH2J+N0FnwI2PoDuomrXq+dAHqldOd?= =?us-ascii?Q?ngzqrisGuJSNG5ItgeHtYbp1h5S6jt4b+7GcIGZFLOpgoSMIUajCbrU8I7il?= =?us-ascii?Q?j1Xyxa1Hs6RfqzsGLjJf+sEGSE7iVq0M9Tt5lTztyP9Q8QsrWPhpyHBOOPBe?= =?us-ascii?Q?EaZS+MGPM+7GFZ2J2oKaDHSrjv6dIB/b174BJl213cWvCHRcjih0nURJtIYa?= =?us-ascii?Q?n3tqcDdlxLjOQEblTb+8Wpw8bqYLULYZRLMO/QeKTq8gWHeSIL7e4df0o8Vu?= =?us-ascii?Q?JSvD3AePDQtxQ7ZNibJXw5+OKdKA+Xgirk1f2JJtpqX4ZXtSIyoKtMCNluNx?= =?us-ascii?Q?Ea/lh4PQfHqEEm9H7DOGqBb5GMXlSLpoA5q/4fqGAymCbdJLSrtDuFcnOR0b?= =?us-ascii?Q?2F5+q+RfZ0SQc2OxuDQwtfxJZGF3hQk23HfPWElMo9XBHjBfZwHf7ERyDIj1?= =?us-ascii?Q?PeOk/3vsoqZ4sEErFy5+8kQ=3D?= Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB6991965C22626EAC6357478FEB279VI1PR0701MB6991_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR0701MB6991.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ccd15f86-6542-40b2-6901-08d9e64484dc X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 12:07:00.9587 (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: jYs3EMDCjoOHnJ5tbsxQT4Bg5xEZuNL8PT4P2dWpJXpWhZTpD2d1lFqZ5ZLP7uqhJsvB9QNGcuYPa0ZTYlspMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2674 Archived-At: Subject: Re: [spring] RtgDir Last Call review: draft-ietf-spring-segment-routing-policy-14 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, 02 Feb 2022 12:07:11 -0000 --_000_VI1PR0701MB6991965C22626EAC6357478FEB279VI1PR0701MB6991_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ketan Thanks for your quick response. Matthew From: Ketan Talaulikar Date: Saturday, 29 January 2022 at 05:33 To: Bocci, Matthew (Nokia - GB) Cc: , rtg-dir@ietf.org , spring@ietf.or= g , last-call@ietf.org , draft-ietf-sp= ring-segment-routing-policy.all@ietf.org Subject: Re: RtgDir Last Call review: draft-ietf-spring-segment-routing-pol= icy-14 Hi Matthew, Thanks for your detailed review and please find responses inline below. Also, we've posted an updated version to address your comments. Request you= to please check and let us know your feedback. https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-16 MB> Thanks. This looks good to me. See below for some additional responses. On Fri, Jan 28, 2022 at 5:21 PM Bocci, Matthew (Nokia - GB) > wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-spring-segment-routing-policy-14 Reviewer: Matthew Bocci Review Date: 28 January 2022 Intended Status: Standards Track Summary: In general, this is a well written document. Thank you. However, I have some minor concerns about this document that I think should be resolved before publication. This mostly re= volve around the clarity of the document and the use (or lack thereof) of RFC2119 langua= ge. Comments: Major Issues: No major issues found Minor Issues: 1) This is a standards track document, but in general I found that clear sp= ecification language is missing. For example, in section 2.3: "A headend may be.." Should this b= e "A headend MAY be..."? There are many other cases like this where MUST/SHOULD/MAY would be better = used rather than 'is' or 'can'. KT> Ack. Fixed in some places and please let us know if we've missed any. 2) The references to control planes for provisioning and maintaining SR Pol= icies are only informational, but they are referred to in a manner in the text that I read= as normative (although the language is not always clear). For example, in section 2.5: "= When signaling is via PCEP..." and then the paragraph refers to an informative reference t= o the PCE draft for the SR policy control plane. Given that this is a standards t= rack architecture document, it would be much better to be clear about what the normative part= s of the architecture are. If these parts are not normative (for example even if I u= se BGP it is not mandatory to use it according to a particular specification) then please be= explicit and use 'MAY' or 'SHOULD'. KT> Given that this is an architecture document, it describes the architect= ure and not really the protocol mechanisms. This is in line with other SPRI= NG documents. The normative language for the BGP mechanism is in the IDR do= cument. The informative references, in this document, to those protocol mec= hanisms are only to give a better reference/info to the reader. MB> I agree you have followed the precedent of the SR architecture (RFC840= 2), so I am OK with that. 3) Section 2.2: Candidate Path and Segment List. This section describes a h= ierarchical relationship between composite candidate paths, SR Policies, candidate path= s, and segment lists. It would be much clearer if you could provide a diagram illustrating this h= ierarchy. KT> The sec 2.13 illustrates this. We will add a forward reference to it in= Sec 2.2. MB> Thanks. That helps. 3) Terminology section. Since this draft is really the overall guide to all things SR Policy, it would really help t= o include a terminology section summarising new terms and acronyms. KT> The document currently describes the constructs in the flow. A terminol= ogy section would just end up repeating the text up front and without prope= r context. I prefer to keep the current structure. If there is any specific= terminology that you believe is better dealt with in the Terminology secti= on, please let us know. MB> Accepted Nits: 1) The definite/indefinite article ('the', 'a', etc) is missing from the te= xt in many places. I would suggest going through the text carefully and correcting these issue= s. KT> Ack. Fixed in a few places. Please let us know if any others were misse= d out. 2) Section 2.13: In the information model: SR policy POL1 Candidate-path CP1 Preference 200 Priority 10 Weight W1, SID-List1 Weight W2, SID-List2 ^^^^^^^^^ These are referred to as segment lists in the main text, so maybe you shoul= d align the terminology. KT> Ack. Fixed. Section 4: Segment Types. Type A: SR-MPLS Label: "...Additionally, reserved labels..." These are now = commonly referred to in MPLS as "special purpose labels". KT> Ack. Fixed. Thanks, Ketan --_000_VI1PR0701MB6991965C22626EAC6357478FEB279VI1PR0701MB6991_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ketan

 

Thanks for your quick response.

 

Matthew

 

From: Ketan Talaulikar &l= t;ketant.ietf@gmail.com>
Date: Saturday, 29 January 2022 at 05:33
To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>
Cc: <rtg-ads@ietf.org>, rtg-dir@ietf.org <rtg-dir@ietf.org&= gt;, spring@ietf.org <spring@ietf.org>, last-call@ietf.org <last-c= all@ietf.org>, draft-ietf-spring-segment-routing-policy.all@ietf.org <= ;draft-ietf-spring-segment-routing-policy.all@ietf.org>
Subject: Re: RtgDir Last Call review: draft-ietf-spring-segment-rout= ing-policy-14

Hi Matthew,

 

Thanks for your det= ailed review and please find responses inline below.

 

Also, we've posted = an updated version to address your comments. Request you to please check an= d let us know your feedback.

 

 

MB> Thanks. This= looks good to me. See below for some additional responses.

 

On Fri, Jan 28, 202= 2 at 5:21 PM Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:<= /o:p>

Hello,

 

I have been selected as the Routi= ng Directorate reviewer for this draft.

The Routing Directorate seeks to = review all routing or routing-related

drafts as they pass through IETF = last call and IESG review, and

sometimes on special request. The= purpose of the review is to provide

assistance to the Routing ADs. Fo= r more information about the Routing

Directorate, please see

http://trac.tools.ietf.or= g/area/rtg/trac/wiki/RtgDir

 

Although these comments are prima= rily for the use of the Routing ADs, it

would be helpful if you could con= sider them along with any other IETF

Last Call comments that you recei= ve, and strive to resolve them through

discussion or by updating the dra= ft.

 

Document: draft-ietf-spring-segme= nt-routing-policy-14

Reviewer: Matthew Bocci

Review Date: 28 January 2022=

Intended Status: Standards Track<= o:p>

 

Summary:

 

In general, this is a well writte= n document. Thank you.

 

However, I have some minor concer= ns about this

document that I think should be r= esolved before publication. This mostly revolve around

the clarity of the document and t= he use (or lack thereof) of RFC2119 language.

 

Comments:

 

Major Issues: No major issues fou= nd

 

Minor Issues:

 

1) This is a standards track docu= ment, but in general I found that clear specification language

is missing. For example, in secti= on 2.3: "A headend may be.." Should this be "A headend MAY b= e..."?

There are many other cases like t= his where MUST/SHOULD/MAY would be better used rather than

'is' or 'can'.<= /p>

 

KT> Ack. Fixed i= n some places and please let us know if we've missed any.=

 

 

2) The references to control plan= es for provisioning and maintaining SR Policies are only

informational, but they are refer= red to in a manner in the text that I read as normative

(although the language is not alw= ays clear). For example, in section 2.5: "When signaling

is via PCEP..." and then the= paragraph refers to an informative reference to the

PCE draft for the SR policy contr= ol plane. Given that this is a standards track architecture

document, it would be much better= to be clear about what the normative parts of the

architecture are. If these parts = are not normative (for example even if I use BGP it is not

mandatory to use it according to = a particular specification) then please be explicit

and use 'MAY' or 'SHOULD'.

 

KT> Given that t= his is an architecture document, it describes the architecture and not real= ly the protocol mechanisms. This is in line with other SPRING documents. Th= e normative language for the BGP mechanism is in the IDR document. The informative references, in this document, to t= hose protocol mechanisms are only to give a better reference/info to the re= ader. 

 

 MB> I agree you have followed the precedent o= f the SR architecture (RFC8402), so I am OK with that.

 

3) Section 2.2: Candidate Path an= d Segment List. This section describes a hierarchical

relationship between composite ca= ndidate paths, SR Policies, candidate paths, and segment lists.<= /span>

It would be much clearer if you c= ould provide a diagram illustrating this hierarchy.

 

KT> The sec 2.13= illustrates this. We will add a forward reference to it in Sec 2.2.

 

MB> Thanks. That= helps.

 

3) Terminology section. Since thi= s draft

is really the overall guide to al= l things SR Policy, it would really help to include a

terminology section summarising&n= bsp; new terms and acronyms.

 

KT> The document= currently describes the constructs in the flow. A terminology section woul= d just end up repeating the text up front and without proper context. I pre= fer to keep the current structure. If there is any specific terminology that you believe is better dealt with in the T= erminology section, please let us know.

 MB> Accept= ed

 

 

Nits:

 

1) The definite/indefinite articl= e ('the', 'a', etc) is missing from the text in many places.

I would suggest going through the= text carefully and correcting these issues.

 

KT> Ack. Fixed i= n a few places. Please let us know if any others were missed out.

 

 

2) Section 2.13:

 

In the information model:

 

SR policy POL1 <headend =3D H1, color =3D 1, endpoint =3D E1>

        Candidate-path CP1 <protoc= ol-origin =3D 20, originator =3D

   100:1.1.1.1, discriminator =3D 1>

            = Preference 200

            = Priority 10

            = Weight W1, SID-List1 <SID11...SID1i>

            = Weight W2, SID-List2 <SID21...SID2j>

            =             ^^^^^^^^= ^

     &nb= sp;            =      

These are referred to as segment = lists in the main text, so maybe you should align the

terminology.

 

KT> Ack. Fixed.<= o:p>

 

 

Section 4: Segment Types.

Type A: SR-MPLS Label: "...A= dditionally, reserved labels..." These are now commonly

referred to in MPLS as "spec= ial purpose labels".

 

 

KT> Ack. Fixed.<= o:p>

 

Thanks,<= /span>

Ketan

 

--_000_VI1PR0701MB6991965C22626EAC6357478FEB279VI1PR0701MB6991_-- From nobody Wed Feb 2 05:26:14 2022 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 0668E3A0B25 for ; Wed, 2 Feb 2022 05:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXTLOl2RwAAr for ; Wed, 2 Feb 2022 05:26:07 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 77B633A0B30 for ; Wed, 2 Feb 2022 05:26:06 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr25.francetelecom.fr (ESMTP service) with ESMTPS id 4JpjHH0jW8zCrq3; Wed, 2 Feb 2022 14:26:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1643808363; bh=oBfQQq/GBUL+8PIagYiT320dNIEheVuv+Dbkz3kkFyE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=ZjBRdtP9gbfAJNVaI8h/SMWHmdnL/3SQDA8M2LfvbCHh0HlZ6fCUsn0bfq/ObJv3V YgHyYJlpDf+i8D4fygR3F4M/QLgFzP+wWXJTQeCfgVZ6xqKwwHvDS0bo2/6yiMkiqA bI8GQlCGExQOE7gUwOmyZ6epV83gRfsAp74UdP53QGYKNgKkWHhdfpT8LVtnvzDk0A zqym1UkDZQ9XTyQdDpfCT8sBdCRrD06QsvOGPM6GC/cv9cSMJZqdMzk/9YjXUB7463 uBsaYO/2no+T6TuorLaWM4MazQNLibtnybEE4kOEsN4brmfx/iXHqUpakmjImWBZUJ 80BlwRxfYBELQ== From: To: "slitkows.ietf@gmail.com" , 'SPRING WG' , Huzhibo Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AQGTpp/eCb7f3S6vK91CLjLoEGPYdaz80BrggAwX/8A= Date: Wed, 2 Feb 2022 13:26:02 +0000 Message-ID: <17040_1643808363_61FA866A_17040_245_14_bd3bfd409e6b45e38519a01045c163c9@orange.com> References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <069201d8120e$dff706a0$9fe513e0$@gmail.com> In-Reply-To: <069201d8120e$dff706a0$9fe513e0$@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-02T13:26:00Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-02T13:26:00Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 3666c460-48b0-4ec3-9735-195e5ba5dfab msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.26.52] Content-Type: multipart/alternative; boundary="_000_bd3bfd409e6b45e38519a01045c163c9orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 02 Feb 2022 13:26:12 -0000 --_000_bd3bfd409e6b45e38519a01045c163c9orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors of both documents, WG, [Speaking as individual contributor.] It's good to see technical discussions on the restoration of failed SIDs us= ed by SR policy. 1. From a functional point of view, can we summarize the benefit to sign= al the node proxy capability? e.g. - drop the traffic earlier if the PLR does not support proxy capability. (h= elps with congestion) - use another proxy off the shortest path (increase congestion but reduce l= oss) - possibly help identifying the proxy (nominal is not in the reachable topo= logy anymore) ... Or agree on the absence of significant benefits? 1. draft-ietf-spring-node-protection-for-sr-te-paths "If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires." * It's not crystal clear to me how it would work in reality, so I would= welcome more prescriptive text. In particular: * "node failure" is not an IGP message. IGP nodes sees multiple "adj= acency loss" messages which are not atomic and could be handled in multiple= SPFs. Hence different nodes will freeze their FIB based on a different top= ology (link1 for some, link2 for others) leading to inconsistent routing an= d forwarding loops. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. 1. draft-hu-spring-segment-routing-proxy-forwarding Rather than defining a new "Proxy Forwarding" capability in IGP why don't y= ou use the existing Mirroring Segment (from RFC https://datatracker.ietf.or= g/doc/html/rfc8402#section-5.1) whose signaling is already standardized? ht= tps://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1 1. What about the following solution: * Use mirror SID * Tunnel to the "proxy-forwarding" advertising mirror SID I would see the following benefits: * No new protocol extensions (cf "3)" * Consistent routing in case of multiple SPFs (cf "2)") * Benefit from the signaling of the proxy (cf "1)") Thanks, Regards, --Bruno Orange Restricted From: slitkows.ietf@gmail.com Sent: Tuesday, January 25, 2022 6:13 PM To: DECRAENE Bruno INNOV/NET ; 'SPRING WG' Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi, I'm NOT supporting this draft for the following reasons: 1. The WG already have a WG document which is dealing with this problem,= I don't think that WG should come with multiple documents/solutions for th= e same solution space as it may just confuse the industry and create deploy= ment issues as different vendors may pick different solutions. 1. Adding protocols extensions adds complexity in the solution without a= dding a strong value. The document claims that "[I-D.ietf-spring-segment-protection-sr-te-paths] = ... may not work for some cases such as some of nodes in the network not su= pporting this solution.". While this is true, the proposed solution in draf= t-hu-spring-segment-routing-proxy-forwarding has exactly the same caveat an= d requires all nodes in the network to support the solution. Considering the following straight line network: A -B -C -D - E - F - G -H = and an SR policy from A to H using SID_G, routers A to F have to support th= e extension to make the solution working, if one of the router doesn't supp= ort the extension, traffic will be dropped. Then, there is no value compared to the timer-based solution of [I-D.ietf-s= pring-segment-protection-sr-te-paths] Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G m= ay have multiple upstream neighbors let's say F and F' and the solution all= ows for F' to support the extension while F may not support, so the solutio= n will send the traffic to F'. Well yes, but this still requires all router= s upstream to F' to support this extension and maybe F is on the path to F'= . So, I don't think the argument is valid as it may possibly work tacticall= y depending on the network topology when we look at a small portion of the = network, but when we look at the whole network, operator will have to upgra= de all their nodes to support the extension to ensure the benefit is there. In addition, in term of traffic, forwarding traffic to a neighbor of the fa= iled node which wasn't initially on the path, could lead to traffic congest= ion or high traffic peaks on links that were not sized to carry this traffi= c. We could easily expect some traffic tromboning, where traffic goes to th= is non-natural neighbor of the failed node and then goes back over some par= t of the same path before reaching the destination. So these protocol extensions are bringing complexity for no value here. 1. Regarding BSID, I'm not fan of advertising BSIDs in IGP as there may = be hundreds or thousands of BSID on a node which again will create a lot of= burden in IGP. The proposed way will have to be discussed in LSR, not in S= PRING (see next comment). Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work = with BSIDs as long as BSID information of failed node is available in the c= ontrol-plane of PLRs by whatever mechanism. I think this BSID handling is o= rthogonal to the proxy-forwarding controlplane behavior. The forwarding ope= rations for BSID will have to be discussed more in details, we could not ex= pect all HW to be able to do 3 or 4 lookups without any perf degradation. 1. The document is currently a bit borderline between SPRING and LSR as = it talks in good details about IGP protocol extensions. If it's a SPRING do= c, it should detail reqs for protocols but nothing beyond. Brgds, Stephane From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: jeudi 13 janvier 2022 11:19 To: SPRING WG > Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote. If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_bd3bfd409e6b45e38519a01045c163c9orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors of both documents, WG,

 

[Speaking as individual contributor.]

 

It’s good to see technical discussions on the restoratio= n of failed SIDs used by SR policy.

 

  1. From= a functional point of view, can we summarize the benefit to signal the node proxy capability?

e.g.

- drop the traffic earlier if the PLR does not support proxy c= apability. (helps with congestion)

- use another proxy off the shortest path (increase congestion= but reduce loss)

- possibly help identifying the proxy (nominal is not in the r= eachable topology anymore)

…

Or agree on the absence of significant benefits?

 

  1. draf= t-ietf-spring-node-protection-for-sr-te-paths

 

“If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forwarding changes should not

   communicated to the forwarding planes on all configured routers=

   (including PLRs for the failed node) until the hold-timer expires.&#= 8221;

 

  • It&#= 8217;s not crystal clear to me how it would work in reality, so I would welcome more prescriptive text. In particular:
    • R= 20;node failure” is not an IGP message. IGP nodes sees multiple “adjacency loss” messages which are not atomic and could be ha= ndled in multiple SPFs. Hence different nodes will freeze their FIB based o= n a different topology (link1 for some, link2 for others) leading to incons= istent routing and forwarding loops.
    • How is the FIB modif= ied in cases of consecutives IGP events? (freezed on hold topology may lead to drops, updating entries would need t= o be specified.
  • On a side node, this text requires a global behavior of all IGP nodes. That seem a bit out of scope of a non-normative sentence, i= n an informational document, describing a local behavior on the PLR.

 

 

  1. draf= t-hu-spring-segment-routing-proxy-forwarding

Rather than defining a new “Proxy Forwarding” capa= bility in IGP why don’t you use the existing Mirroring Segment (from RFC https://datatracker.ietf.org/doc/html/rfc8402#section-5.1) whose = signaling is already standardized? htt= ps://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1

 

  1. What= about the following solution:
  • Use = mirror SID
  • Tunnel to the “proxy-forwarding” a= dvertising mirror SID

 

I would see the following benefits:

  • No n= ew protocol extensions (cf “3)”
  • Consistent ro= uting in case of multiple SPFs (cf “2)”)
    • =
  • Bene= fit from the signaling of the proxy (cf “1)”)=

 

Thanks,

Regards,

--Bruno

 

 

Orange Restricted

From: slitkows.ietf@gmail.com <slitkows.ietf@gmai= l.com>
Sent: Tuesday, January 25, 2022 6:13 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; 'SPR= ING WG' <spring@ietf.org>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi,

 

I’m NOT supporting this draft for the following reasons:

 

  1. The WG already have a WG document whi= ch is dealing with this problem, I don’t think that WG should come with multiple documents/solutions for the same solution spa= ce as it may just confuse the industry and create deployment issues as diff= erent vendors may pick different solutions.

 

  1. Adding protocols extensions adds comp= lexity in the solution without adding a strong value.

 

The document claims that “[I-D= .ietf-spring-segment-protection-sr-te-paths] … may not work for some = cases such as some of nodes in the network not supporting this solution.”. While this is true, the proposed solution in draft-= hu-spring-segment-routing-proxy-forwarding has exactly the same caveat and = requires all nodes in the network to support the solution.

 

Considering the following straight l= ine network: A -B -C -D – E – F - G -H and an SR policy from A = to H using SID_G, routers A to F have to support the extension to make the solution working, if one of the router doesn’t= support the extension, traffic will be dropped.

 

Then, there is no value compared to = the timer-based solution of [I-D.ietf-spring-segment-protection-sr-te-paths= ]

 

Authors of draft-hu-spring-segment-r= outing-proxy-forwarding argued that G may have multiple upstream neighbors = let’s say F and F’ and the solution allows for F’ to support the extension while F may not support, so the solu= tion will send the traffic to F’. Well yes, but this still requires a= ll routers upstream to F’ to support this extension and maybe F is on= the path to F’. So, I don’t think the argument is valid as it may possibly work tactically depending on the network topology= when we look at a small portion of the network, but when we look at the wh= ole network, operator will have to upgrade all their nodes to support the e= xtension to ensure the benefit is there.

 

In addition, in term of traffic, for= warding traffic to a neighbor of the failed node which wasn’t initial= ly on the path, could lead to traffic congestion or high traffic peaks on links that were not sized to carry this traffic. = We could easily expect some traffic tromboning, where traffic goes to this = non-natural neighbor of the failed node and then goes back over some part o= f the same path before reaching the destination.

 

So these protocol extensions are bri= nging complexity for no value here.

 

 

  1. Regarding BSID, I’m not fan of = advertising BSIDs in IGP as there may be hundreds or thousands of BSID on a node which again will create a lot of burden in IGP. The prop= osed way will have to be discussed in LSR, not in SPRING (see next comment)= .

 

Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could = also work with BSIDs as long as BSID information of failed node is availabl= e in the control-plane of PLRs by whatever mechanism. I think this BSID handling is orthogonal to the proxy-forwardin= g controlplane behavior. The forwarding operations for BSID will have to be= discussed more in details, we could not expect all HW to be able to do 3 o= r 4 lookups without any perf degradation.

 

  1. The document is currently a bit borde= rline between SPRING and LSR as it talks in good details about IGP protocol extensions. If it’s a SPRING doc, it should detai= l reqs for protocols but nothing beyond.

 

 

 

Brgds,

 

Stephane

 

 

From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decr= aene@orange.com
Sent: jeudi 13 janvier 2022 11:19
To: SPRING WG <spring@ietf.org= >
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,<= /o:p>

 

This message s= tarts a 2 week WG adoption call, ending 27/01/2022, for draft-hu-spring-seg= ment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-prox= y-forwarding/

 

After review o= f the document please indicate support (or not) for WG adoption of the docu= ment to the mailing list.

 

Please also pr= ovide comments/reasons for your support (or lack thereof) as this is a stro= nger way to indicate your (non) support as this is not a vote.     

 

If you are wil= ling to work on or review the document, please state this explicitly. This = gives the chairs an indication of the energy level of people in the working group willing to work on the document.=

 

Thanks!

Bruno, Jim, Joel

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_bd3bfd409e6b45e38519a01045c163c9orangecom_-- From nobody Wed Feb 2 11:33:30 2022 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 A95BC3A1D18; Wed, 2 Feb 2022 11:33:29 -0800 (PST) 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, 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 1W0Hqy-vbR1v; Wed, 2 Feb 2022 11:33:25 -0800 (PST) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08on2099.outbound.protection.outlook.com [40.107.101.99]) (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 CA05B3A1D54; Wed, 2 Feb 2022 11:33:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M4NjORrC5IXj7Z3Kp6Ja2Ky5a9LsnpDzbnEb/AxVDAEyfcRWtyMXrSEnalLhOPucj+aQ/QxnGslb7xXCUyqy1PhRHOebc7VVArEDmawBOVClo4QvvCfq+Ugz4FhMKv79NMHqBCeNb13n6tesDMZZ5VzuLk0WiDoNa/L2uD3UT/fOjTE8/kvU79PpqxY16kD7sIbPjHFLfOXyOuxh3N74QfL9ZMrgwxLr/YTGURPVUr5ZJKx6ZDQQ3v3baeX0Bne+NA3k4CVb6YTGzy/gYt/WomWZbnahtIVEnZ5YulL2qCvC5ygA8gY62cvwHI3S8jTKBGjsMrpVQJYmARfPXU+/1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7L9dOkuLYHsSLerUa6GZzNPOAIguoLzWy8DA0/0PvVM=; b=OYv4o3CslHn1tigunIEsKIgS7lrwGHcY2OSt623V+6KCf93pRKH+g22PlyD87upbrh7Vq6+roupu+IDKBRbJX3qx4HY2TW441uc4yO62KzKdxyy5Y3aaxIM6j2xtJEJVafQg0hntytOVCmOUkgH467H64YOkwmCIWCViBmflvMAmbMp6NjVRdAvgtxsmKUKjeRNvmR+oFGtLeeaUdTa4z/1WAqZHZeF5ODf04NQ4Sqxb0Kd+Kte4IZgMlAPApMhl1mXEvgKl9SkBiD3x2j2sTeRn42r4kmOdEwXY9uvmDUrjbpKlJLMYsqyWpvTnX8cWZYIHLphO23/wwFEHh0wI8g== 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=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7L9dOkuLYHsSLerUa6GZzNPOAIguoLzWy8DA0/0PvVM=; b=hXFcseOCgBK1K3SDZ0Ms4+ApRvYue/VBPvsAbjkS6bRJlRDyHocLYL67G15DNE/Iermv80tl0GgYskv2LxTLTutK5UotidBFlAERLjjvLbLAeZIPTMn1kXSS3Fz4rSKNq5ORyTvn9M/ZyyI3NOB4kQlpsD3E1c1UUMTZ1wmFUQk= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BY5PR13MB3587.namprd13.prod.outlook.com (2603:10b6:a03:194::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 2 Feb 2022 19:32:59 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 19:32:59 +0000 From: Haoyu Song To: "spring@ietf.org" , "draft-gandhi-spring-stamp-srpm@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-stamp-srpm-03.txt Thread-Index: AQHYF8qiGdS8xRtXrUipdNNxyfU0AqyApNNg Date: Wed, 2 Feb 2022 19:32:59 +0000 Message-ID: References: <164376115018.24067.5182634269610657627@ietfa.amsl.com> In-Reply-To: <164376115018.24067.5182634269610657627@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d339c34-0e8a-4d5e-132f-08d9e682d255 x-ms-traffictypediagnostic: BY5PR13MB3587:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zwIXTJbYxO0uxF0TOiHlP1kOIaGL+vtme1JiQJ+jmZiA+DgeDwHZBjJyzVJSw+uuX2Szvr5jU+LRp8M00N5eG55Lc/2OOrFjCCK3MvDbuIc9HeZK1LH4FD4hu5nJNTbDxXHWzZLsFXMnQ3o+ONsxReQaGjb05/ZxgdXCqsgqXqS+B6irnY2OX/TpQtTu7k0vQS0YDUA0il60v89Pu25Ejhj6RqmFVs82/fus3Vxnwzx28uy4xo2OUgYNtn9hTRt0y4PHbHEsg/+WHw/uwI9ccjrWacm9UwFd9gDoAlO526vS6pNQ7TZVjSXirdWyjid/CjpfibN42HXg9pXzVZ7+GDE2i58SbhVM2ELE0hUzeOSJQ0TTXy5uCIjAXf22ZzJPL0yEhtjhvpJaO2oZbUUB91d3YpvlAAahogCIFw9MnlQw5VlfkJpLMMvrcRc4X017oerYkGQ0EwKzox8wT/S6fpUuTudm16zVQKjp3pPhtf+VTn43DPvCTuQZGJiMQY0yWkd48ASN1khd+Jj4bnQkDVQnm9/43CRQPB+F1j6fY05Pbvp99ipW6NxqTO6jvTOhdD1uxgdLrDyF8qaiAo2++i5co77gkb2za30n7pt4LIhwY5GkxtJ/9BoqUz6IqkHy8x/SmZWT3gPvvyOEpnfX+VifZqksSymHbTp3Lw2JRRCNZ3o7sbw9aopkGqk1mBaMagZpNoKXWWNF+QJsw006MaASjbAJp2Au2iQQW3YT9oQzV0kGnwJuUgFeCNFputK4173Ykx82r2JYWWyHpWJIcf2xZXFybr/ecMn2OSAMYPKrot9a2XmzY2irRAOvALbe1s9VyS55Au2wUEBx9b0MRA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(44832011)(38100700002)(316002)(55016003)(966005)(122000001)(66946007)(26005)(53546011)(76116006)(9686003)(186003)(38070700005)(110136005)(2906002)(450100002)(8936002)(8676002)(45080400002)(64756008)(66556008)(83380400001)(71200400001)(6506007)(5660300002)(33656002)(7696005)(66476007)(66446008)(86362001)(52536014)(66574015)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?F5dTs30falP/uVjYUcMUGmp7+w2ZsSt+58KC4/xDT117SfkGTd/r/B4WZ1en?= =?us-ascii?Q?yYPXVP/cn0H0TmCYZO/ylKqEDLIGF8Wt1Il1jKGA+NnbdN7YdofcgSEjvtKf?= =?us-ascii?Q?ET8f63KsYNl3Sl3W3kYyJpTYtayWbnQ7wAK3qHGfIRah+eyFXHDoWwBEGXX+?= =?us-ascii?Q?XgwAQhWVKJ7j7iuBe8q/5vCWv5wSA/Ve5MxZJRxEt8QULQDjN/90Y5ufgTcB?= =?us-ascii?Q?IKcZqVtUfBnNsOXg1oNt8wsY3IS7AlwTV+wy615bz5JQMyDnONOSKd/FKN67?= =?us-ascii?Q?klhUBrKrDaDQhsI2JKR20Mhj0/Hiwz9whsmtp8Ti6MHq+pg2/4+xEhSsC5Md?= =?us-ascii?Q?YgQfsRDuwuLh9DEoRkXGr5H4bx4us5XZyx6dzsIEUE8OwxFWaYn93L46K7be?= =?us-ascii?Q?220Yijn8s7J/EKojzDrvqPYsAjqZkq6eZ4jXTExqRBx6UMh05OLYil6okta8?= =?us-ascii?Q?IjIyuzCY5mvBklaruZZRyWgcMyScTq/1q+FvDOHHeZVKlsH7TPd4lHUVXABi?= =?us-ascii?Q?z/6D2NNw7zdiAhp3KDhqN1rKvvnGSyQe6uB9zHK6W+fxAgidydZBlQY/Zjjg?= =?us-ascii?Q?IbmEmHkOtbEGWsMv2TTWFLguY+cq2CahIliMYmGKLolDkXoEFZXmOof09p3l?= =?us-ascii?Q?DYvEIJGgm0yuhRzCiNIuEHbfxhRnUPfhBYfIxz3ST8kbWW9BwapWJX5hf4NE?= =?us-ascii?Q?luGQRVf5MAcy6boUXNdZ+4tJZH6zDRJmJylV7KvdBq64nfIKvDcSbDG6kr5W?= =?us-ascii?Q?Z1Bv8TatOLP+KQgAHE2ALqVnEQJh6jLH3on/wnVtLal6fFDJCYqnGObDn7Vk?= =?us-ascii?Q?T+oiw1Kv9t2SkXHOs8Ps/5iJogCky+yvFCTMO+vtu9JBegJS7eiQexTBT0lt?= =?us-ascii?Q?pEt4xaelW4oTaGzcIhrOP+XROTWaiGfSm5mCUkEwwDGfY7Lxv4gM0EKZ8cbc?= =?us-ascii?Q?Oj+hoF7q/U4+pGpZNRp5t1l7RUX/vvBz3SA4Xja6sHl9UUhOMfAkficw9HkV?= =?us-ascii?Q?4j/xizAZQudHe0ZqcupcivLiLVOYIJKl71v7EP87BYcQoT93E583a1bKze98?= =?us-ascii?Q?JpPoQuzCNiQUEw71oOq5lU9qD4jgJ5LxEKQEKrCekQdus1gGD3glP2njPXEx?= =?us-ascii?Q?jRPmxBEKp7+xI5bN8f3RA2XPalZZkQr6h5x5xu1TgoEHtdyrxO8Zt2IIS/uM?= =?us-ascii?Q?+jxUGHRLJ8Xm2rpD+Ih+4esb6AOcxYUFOIxtSTDuQ18pg7cNLrI6C/zoMDfS?= =?us-ascii?Q?VwixRGvoPBGuwxv8S7yn3oHoSBKY2dR7hCsBkpXCcTuD5Xaabj5oS+lFqOa8?= =?us-ascii?Q?QU7ewmvBzcZQpK/zxxQdyC7iJXa4nmz+/isIFpgFKIkrH790cGpGzDltleXM?= =?us-ascii?Q?bwvn5MVjN56LBJ6Q1vMh5WZXIxHbq6jPewAxfeevpP8lk1Da+HlRWZuNuOWh?= =?us-ascii?Q?RJLNOp+Ku6gQXUd2j/BxoRaxuJNvuLOA2gCs3R519ILgxkNiCka0N9FC8tow?= =?us-ascii?Q?GRrIK979FMYHs6OX9E0k2nRIO3iOEMroTNufmhi6a6Eg4v6fF4nV80rWHWbr?= =?us-ascii?Q?mZvEQ6AH3zpYWojeM/f7WlibMKQ1x/HHR9zDqgnCpTLVQDkTE9jVhv84ZLf/?= =?us-ascii?Q?2Q=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d339c34-0e8a-4d5e-132f-08d9e682d255 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 19:32:59.7157 (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: q0AuaUFv41ogvN6vEDcnrBFEq3t056e0y9OhQoX9NUjBKHlbDZwdLDa2VtDFVZ5Bantze9dhl0pXEaAs5i+Ifw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3587 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-stamp-srpm-03.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: Wed, 02 Feb 2022 19:33:30 -0000 Hi Rakesh and the other authors, Since this draft also propose to use UDP for active measurement in SRv6, I'= d like to suggest that a flag bit in SRH is used to indicate that. The reas= ons are twofold: (1) routers may only look at L3 header for forwarding with= out examining the L4 header. So if a test packet can only be identified by = UDP port, it may be missed; (2) it's possible to use the same mechanism to = support other kinds of active measurements (e.g., HBH IOAM as proposed in o= ur draft https://datatracker.ietf.org/doc/html/draft-song-spring-siam-02.=20 Best, Haoyu -----Original Message----- From: spring On Behalf Of internet-drafts@ietf.or= g Sent: Tuesday, February 1, 2022 4:19 PM To: i-d-announce@ietf.org Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-stamp-srpm-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking WG of = the IETF. Title : Performance Measurement Using Simple TWAMP (STAMP= ) for Segment Routing Networks Authors : Rakesh Gandhi Clarence Filsfils Daniel Voyer Mach(Guoyi) Chen Bart Janssens Richard Foote Filename : draft-ietf-spring-stamp-srpm-03.txt Pages : 24 Date : 2022-02-01 Abstract: Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and its optional extensions defined in RFC 8972 and further augmented in draft-ietf-ippm-stamp-srpm. The procedure described is applicable to SR-MPLS and SRv6 data planes and is used for both links and end-to- end SR paths including SR Policies. The IETF datatracker status page for this draft is: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-spring-stamp-srpm%2F&data=3D04%7C01%7C= haoyu.song%40futurewei.com%7C9e9ebc01c8c942755a2d08d9e5e1c397%7C0fee8ff2a3b= 240189c753a1d5591fedc%7C1%7C1%7C637793580085471585%7CUnknown%7CTWFpbGZsb3d8= eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a= mp;sdata=3DuRFB7p9GlMVjo%2Ft9FOVR7Gg49Ah1Y79CbhzLWHPDFH0%3D&reserved=3D= 0 There is also an HTML version available at: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-ietf-spring-stamp-srpm-03.html&data=3D04%7= C01%7Chaoyu.song%40futurewei.com%7C9e9ebc01c8c942755a2d08d9e5e1c397%7C0fee8= ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637793580085471585%7CUnknown%7CTWFpbG= Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 3000&sdata=3D0m4WNO9jMptJw14nENpOaftEzNdQDqHUbRr5YJMaX8w%3D&reserve= d=3D0 A diff from the previous version is available at: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-ietf-spring-stamp-srpm-03&data=3D04%7C01= %7Chaoyu.song%40futurewei.com%7C9e9ebc01c8c942755a2d08d9e5e1c397%7C0fee8ff2= a3b240189c753a1d5591fedc%7C1%7C1%7C637793580085471585%7CUnknown%7CTWFpbGZsb= 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300= 0&sdata=3D4qPBxUc7x44ZFWzb3kM7tIVrYODE8iMw8xQD1eMC4zw%3D&reserved= =3D0 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts _______________________________________________ spring mailing list spring@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fspring&data=3D04%7C01%7Chaoyu.song%40futur= ewei.com%7C9e9ebc01c8c942755a2d08d9e5e1c397%7C0fee8ff2a3b240189c753a1d5591f= edc%7C1%7C1%7C637793580085471585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlaC%2B5= pQbD7tnmE34VUJRR0s19LoPnEipFQbPe0PwfqE%3D&reserved=3D0 From nobody Thu Feb 3 08:00:10 2022 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 525223A0BC4; Thu, 3 Feb 2022 07:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 gXgWYfIfDxCw; Thu, 3 Feb 2022 07:59:54 -0800 (PST) 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 C72743A0B91; Thu, 3 Feb 2022 07:59:53 -0800 (PST) Received: by mail-vk1-xa32.google.com with SMTP id 48so2043519vki.0; Thu, 03 Feb 2022 07:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uHHRmtzmzIE4RE/GOGD+5xfua1cRIXvlyhbaEvHXVVk=; b=lJluLwugr2KLaOeVmt9Lz4NEMY6h1wLDqZO++Jr6fCY/CxdRQJMhY70K00mPUoiefJ hbHQDBvqrCN+6gK7Vv196vkc7XXSoflchCokdm3JeuzO2CzFknU9f432caGmL3Yae2y1 GARWXOnklYTeBZHVCax57AXaBBj4PIkzdbF/jh0Gj1kdHesZC42eP5LIStJg0HtxLe0B eNZZqPwFWX7bfei14os4Z2FW1LLXHp/1IrcWjh4/ahEHa+RZlFgZF001xaVlxr/rTvz6 heWyLQTYgrV0Ka0DFbp0nKn3S1+99Y69McQMUe1YENpzYXnXQxWAt8p9yMIde5f+m2p/ w5Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uHHRmtzmzIE4RE/GOGD+5xfua1cRIXvlyhbaEvHXVVk=; b=y8i8r0qkgeqt/dtS9y0n4A++hSteKTEVnFjFrJWt//lsRTAx0NytZeBiZbh4KFh5Qe 87kT29NDeq/KPxHrOjnbcLA/KZ4w9um2uBTTxEHWlIAzbSJYuY7huER12UxfsSUqrAUw j1MKKqFcStxUoZ6Op4rUZ8w1jhasKmyzCm5crdOz6zfzU51BYSNcAnqA2XQ0t59CGA8B +kVao77SL2cpobDBjdiDIh2fJ1ZLUY+7nNm9BTAAdKGxQj9t8OA57yBHXucWOGyhdxnE 44tSR2irXNM8gfWcCBVk/hbSi54/ADGi0oqu2Td8qcvTq2fzgjJLk62ZkKMUmpbb2CzX 3LkA== X-Gm-Message-State: AOAM5324tEWJnK0nlLbBu6ZWdEjjOgVHYrpoKYFndbluUXyu6ORL5A/j 1oVyDLM6Zq8158oMq1EOxNxeGakbTIgCT+uPxPE= X-Google-Smtp-Source: ABdhPJzcf+1vHbplcM60Xh/oDGJ8rXZ2NEqKMZsIX5alteJdNuMwPMnpHp8CQFiFnpAeTJi+hrvUno8ddUZY3mgdzQc= X-Received: by 2002:a1f:908b:: with SMTP id s133mr14725475vkd.33.1643903992028; Thu, 03 Feb 2022 07:59:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ketan Talaulikar Date: Thu, 3 Feb 2022 21:29:38 +0530 Message-ID: To: "Bocci, Matthew (Nokia - GB)" Cc: "" , "rtg-dir@ietf.org" , "spring@ietf.org" , "last-call@ietf.org" , "draft-ietf-spring-segment-routing-policy.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007d662d05d71f3999" Archived-At: Subject: Re: [spring] RtgDir Last Call review: draft-ietf-spring-segment-routing-policy-14 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, 03 Feb 2022 15:59:59 -0000 --0000000000007d662d05d71f3999 Content-Type: text/plain; charset="UTF-8" Thanks Matthew On Wed, Feb 2, 2022 at 5:37 PM Bocci, Matthew (Nokia - GB) < matthew.bocci@nokia.com> wrote: > Hi Ketan > > > > Thanks for your quick response. > > > > Matthew > > > > *From: *Ketan Talaulikar > *Date: *Saturday, 29 January 2022 at 05:33 > *To: *Bocci, Matthew (Nokia - GB) > *Cc: *, rtg-dir@ietf.org , > spring@ietf.org , last-call@ietf.org , > draft-ietf-spring-segment-routing-policy.all@ietf.org < > draft-ietf-spring-segment-routing-policy.all@ietf.org> > *Subject: *Re: RtgDir Last Call review: > draft-ietf-spring-segment-routing-policy-14 > > Hi Matthew, > > > > Thanks for your detailed review and please find responses inline below. > > > > Also, we've posted an updated version to address your comments. Request > you to please check and let us know your feedback. > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-16 > > > > > > MB> Thanks. This looks good to me. See below for some additional responses. > > > > On Fri, Jan 28, 2022 at 5:21 PM Bocci, Matthew (Nokia - GB) < > matthew.bocci@nokia.com> wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related > > drafts as they pass through IETF last call and IESG review, and > > sometimes on special request. The purpose of the review is to provide > > assistance to the Routing ADs. For more information about the Routing > > Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > Although these comments are primarily for the use of the Routing ADs, it > > would be helpful if you could consider them along with any other IETF > > Last Call comments that you receive, and strive to resolve them through > > discussion or by updating the draft. > > > > Document: draft-ietf-spring-segment-routing-policy-14 > > Reviewer: Matthew Bocci > > Review Date: 28 January 2022 > > Intended Status: Standards Track > > > > Summary: > > > > In general, this is a well written document. Thank you. > > > > However, I have some minor concerns about this > > document that I think should be resolved before publication. This mostly > revolve around > > the clarity of the document and the use (or lack thereof) of RFC2119 > language. > > > > Comments: > > > > Major Issues: No major issues found > > > > Minor Issues: > > > > 1) This is a standards track document, but in general I found that clear > specification language > > is missing. For example, in section 2.3: "A headend may be.." Should this > be "A headend MAY be..."? > > There are many other cases like this where MUST/SHOULD/MAY would be better > used rather than > > 'is' or 'can'. > > > > KT> Ack. Fixed in some places and please let us know if we've missed any. > > > > > > 2) The references to control planes for provisioning and maintaining SR > Policies are only > > informational, but they are referred to in a manner in the text that I > read as normative > > (although the language is not always clear). For example, in section 2.5: > "When signaling > > is via PCEP..." and then the paragraph refers to an informative reference > to the > > PCE draft for the SR policy control plane. Given that this is a standards > track architecture > > document, it would be much better to be clear about what the normative > parts of the > > architecture are. If these parts are not normative (for example even if I > use BGP it is not > > mandatory to use it according to a particular specification) then please > be explicit > > and use 'MAY' or 'SHOULD'. > > > > KT> Given that this is an architecture document, it describes the > architecture and not really the protocol mechanisms. This is in line with > other SPRING documents. The normative language for the BGP mechanism is in > the IDR document. The informative references, in this document, to those > protocol mechanisms are only to give a better reference/info to the reader. > > > > MB> I agree you have followed the precedent of the SR architecture > (RFC8402), so I am OK with that. > > > > 3) Section 2.2: Candidate Path and Segment List. This section describes a > hierarchical > > relationship between composite candidate paths, SR Policies, candidate > paths, and segment lists. > > It would be much clearer if you could provide a diagram illustrating this > hierarchy. > > > > KT> The sec 2.13 illustrates this. We will add a forward reference to it > in Sec 2.2. > > > > MB> Thanks. That helps. > > > > 3) Terminology section. Since this draft > > is really the overall guide to all things SR Policy, it would really help > to include a > > terminology section summarising new terms and acronyms. > > > > KT> The document currently describes the constructs in the flow. A > terminology section would just end up repeating the text up front and > without proper context. I prefer to keep the current structure. If there is > any specific terminology that you believe is better dealt with in the > Terminology section, please let us know. > > MB> Accepted > > > > > > Nits: > > > > 1) The definite/indefinite article ('the', 'a', etc) is missing from the > text in many places. > > I would suggest going through the text carefully and correcting these > issues. > > > > KT> Ack. Fixed in a few places. Please let us know if any others were > missed out. > > > > > > 2) Section 2.13: > > > > In the information model: > > > > SR policy POL1 > > Candidate-path CP1 > 100:1.1.1.1, discriminator = 1> > > Preference 200 > > Priority 10 > > Weight W1, SID-List1 > > Weight W2, SID-List2 > > ^^^^^^^^^ > > > > These are referred to as segment lists in the main text, so maybe you > should align the > > terminology. > > > > KT> Ack. Fixed. > > > > > > Section 4: Segment Types. > > Type A: SR-MPLS Label: "...Additionally, reserved labels..." These are now > commonly > > referred to in MPLS as "special purpose labels". > > > > > > KT> Ack. Fixed. > > > > Thanks, > > Ketan > > > --0000000000007d662d05d71f3999 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Matthew


On Wed, Feb 2, 2022 at 5:37 P= M Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:

Hi Ketan

=C2=A0<= /span>

Thanks for your quick= response.

=C2=A0<= /span>

Matthew=

=C2=A0<= /span>

From: Ketan Talaulikar <= ketant.ietf@gmai= l.com>
Date: Saturday, 29 January 2022 at 05:33
To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>
Cc: <rtg-ad= s@ietf.org>, r= tg-dir@ietf.org <rtg-dir@ietf.org>, spring@ietf.org <spring@ietf.org>, last-call@ietf.org <last-call@ietf.org>, draft-ie= tf-spring-segment-routing-policy.all@ietf.org <draft= -ietf-spring-segment-routing-policy.all@ietf.org>
Subject: Re: RtgDir Last Call review: draft-ietf-spring-segment-rout= ing-policy-14

Hi Matthew,=

=C2=A0<= /span>

Thanks for your detai= led review and please find responses inline below.

=C2=A0<= /span>

Also, we've poste= d an updated version to address your comments. Request you to please check = and let us know your feedback.

=C2=A0<= /span>

=C2=A0<= /span>

MB> Thanks. This l= ooks good to me. See below for some additional responses.

=C2=A0<= /span>

On Fri, Jan 28, 2022 = at 5:21 PM Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:<= u>

Hello,<= /span>

=C2=A0<= /span>

I have been selected = as the Routing Directorate reviewer for this draft.

The Routing Directora= te seeks to review all routing or routing-related

drafts as they pass t= hrough IETF last call and IESG review, and

sometimes on special = request. The purpose of the review is to provide

assistance to the Rou= ting ADs. For more information about the Routing

Directorate, please s= ee

http://trac.t= ools.ietf.org/area/rtg/trac/wiki/RtgDir

=C2=A0<= /span>

Although these commen= ts are primarily for the use of the Routing ADs, it

would be helpful if y= ou could consider them along with any other IETF

Last Call comments th= at you receive, and strive to resolve them through

discussion or by upda= ting the draft.

=C2=A0<= /span>

Document: draft-ietf-= spring-segment-routing-policy-14

Reviewer: Matthew Boc= ci

Review Date: 28 Janua= ry 2022

Intended Status: Stan= dards Track

=C2=A0<= /span>

Summary:

=C2=A0<= /span>

In general, this is a= well written document. Thank you.

=C2=A0<= /span>

However, I have some = minor concerns about this

document that I think= should be resolved before publication. This mostly revolve around

the clarity of the do= cument and the use (or lack thereof) of RFC2119 language.

=C2=A0<= /span>

Comments:

=C2=A0<= /span>

Major Issues: No majo= r issues found

=C2=A0<= /span>

Minor Issues:<= u>

=C2=A0<= /span>

1) This is a standard= s track document, but in general I found that clear specification language<= u>

is missing. For examp= le, in section 2.3: "A headend may be.." Should this be "A h= eadend MAY be..."?

There are many other = cases like this where MUST/SHOULD/MAY would be better used rather than

'is' or '= can'.

=C2=A0<= /span>

KT> Ack. Fixed in = some places and please let us know if we've missed any.

=C2=A0<= /span>

=C2=A0<= /span>

2) The references to = control planes for provisioning and maintaining SR Policies are only

informational, but th= ey are referred to in a manner in the text that I read as normative<= u>

(although the languag= e is not always clear). For example, in section 2.5: "When signaling

is via PCEP..." = and then the paragraph refers to an informative reference to the<= /u>

PCE draft for the SR = policy control plane. Given that this is a standards track architecture<= /u>

document, it would be= much better to be clear about what the normative parts of the

architecture are. If = these parts are not normative (for example even if I use BGP it is not

mandatory to use it a= ccording to a particular specification) then please be explicit

and use 'MAY'= or 'SHOULD'.

=C2=A0<= /span>

KT> Given that thi= s is an architecture document, it describes the architecture and not really= the protocol mechanisms. This is in line with other SPRING documents. The = normative language for the BGP mechanism is in the IDR document. The informative references, in this document, to t= hose protocol mechanisms are only to give a better reference/info to the re= ader.=C2=A0

=C2=A0<= /span>

=C2=A0MB> I agree you have followed the precedent of th= e SR architecture (RFC8402), so I am OK with that.

=C2=A0<= /span>

3) Section 2.2: Candi= date Path and Segment List. This section describes a hierarchical=

relationship between = composite candidate paths, SR Policies, candidate paths, and segment lists.=

It would be much clea= rer if you could provide a diagram illustrating this hierarchy.

=C2=A0<= /span>

KT> The sec 2.13 i= llustrates this. We will add a forward reference to it in Sec 2.2.

=C2=A0<= /span>

MB> Thanks. That h= elps.

=C2=A0<= /span>

3) Terminology sectio= n. Since this draft

is really the overall= guide to all things SR Policy, it would really help to include a

terminology section s= ummarising=C2=A0 new terms and acronyms.

=C2=A0<= /span>

KT> The document c= urrently describes the constructs in the flow. A terminology section would = just end up repeating the text up front and without proper context. I prefe= r to keep the current structure. If there is any specific terminology that you believe is better dealt with in the T= erminology section, please let us know.

=C2=A0MB> Accepted=

=C2=A0<= /span>

=C2=A0<= /span>

Nits:

=C2=A0<= /span>

1) The definite/indef= inite article ('the', 'a', etc) is missing from the text in= many places.

I would suggest going= through the text carefully and correcting these issues.

=C2=A0<= /span>

KT> Ack. Fixed in = a few places. Please let us know if any others were missed out.

=C2=A0<= /span>

=C2=A0<= /span>

2) Section 2.13:

=C2=A0<= /span>

In the information mo= del:

=C2=A0<= /span>

SR policy POL1 <headend =3D H1, color =3D 1, endpoint =3D= E1>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Candidate-path CP= 1 <protocol-origin =3D 20, originator =3D

=C2=A0=C2=A0 100:1.1.1.1, discriminator =3D 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 Preference 200=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Priority 10

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Weight W1, SID-List1 <SID11...SID1i>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Weight W2, SID-List2 <SID21...SID2j>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ^^^^^^^^^

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

These are referred to= as segment lists in the main text, so maybe you should align the=

terminology.

=C2=A0<= /span>

KT> Ack. Fixed.=

=C2=A0<= /span>

=C2=A0<= /span>

Section 4: Segment Ty= pes.

Type A: SR-MPLS Label= : "...Additionally, reserved labels..." These are now commonly

referred to in MPLS a= s "special purpose labels".

=C2=A0<= /span>

=C2=A0<= /span>

KT> Ack. Fixed.=

=C2=A0<= /span>

Thanks,=

Ketan

=C2=A0<= /span>

--0000000000007d662d05d71f3999-- From nobody Thu Feb 3 09:05:01 2022 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 2018F3A0FB6 for ; Thu, 3 Feb 2022 09:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_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 kQW6z9vTuLdF for ; Thu, 3 Feb 2022 09:04:54 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2107.outbound.protection.outlook.com [40.107.243.107]) (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 21E503A0FB0 for ; Thu, 3 Feb 2022 09:04:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xb0zE8O83X/kgo0Ug09SiDvV9ST/lE1VNzogzyK+GvDGiw3ZKicgA3YtawhxXcwiCnNtrpWKdwxcKXnrPxkeX+T0r5azBNo5Ks1L0BfZJu2F0CWjfYs1w19Yfv8oJIiu28768Tr7XsYyBoc7UiNdO8Jsio5RnSqwnExW1UggVVcNebAW9cjDt7CG2XdalNDNFwOEm7irgL3KjA1fIUcLL/dt/Fcs8VF7Hh/BfQhZlJafAFTW1M5l6K4MxgDel419KrRs16rM9Ug3Or8h64met+RLK5XqiY7f5z0Y088fNiBmqxpaPr+S4dd/QJ/IgnkapapqrSeaWbHYWhYfYw286g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tkfrLid3FRXz++Pe52heXYQbFirTBxtultZlkoQeOH0=; b=JHlgwRqtcg+McsS2VIRz1ZJVk2u5y9GVWogXrbYQNk7+LoaM2HE+0zi1LQvsm9n+b5cTwOnDbB5CYDmCbOxm8aMr0mgnciP1dk0BY0zssZ999OBVtSo3M0aQv1T8+fEKfDfqoydYzxHAmpKnDjwHjIwXgupmSR9VK6AGxTUH5urGfo0UV4lpYl2lBpRU3++rdxLmNYTaAps9sL3LjLUvidWBlHaJr3bCUzmmdotfeVOyu7y1Fptuqm0Bf2lvnOedfCkrzO3D6YkyTiP65bpv+nTggMacXUVDMlyydwZHiB9zjaHN4tfnimb79d7dvE9qOPK4llIztGAHpVrLLjapCg== 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=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tkfrLid3FRXz++Pe52heXYQbFirTBxtultZlkoQeOH0=; b=FHTNmcdp7bP+cN1kQ6MVuL3UQx8Qu5sJ5xU3tDWZZjHwpiI8t404WvxoTQjzFyaOZgu632Alui7iBU+BFqosZrLL0pVakZyHgbpOBBBo4qgLAT4NI1YMmJqmVba98tr157AB8H2NMYEuZFyNZtfzZEt4znLJFJ3N0+5xrcFWHnA= Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by DM6PR13MB4345.namprd13.prod.outlook.com (2603:10b6:5:167::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.6; Thu, 3 Feb 2022 17:04:50 +0000 Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::edbc:f221:128b:3e27]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::edbc:f221:128b:3e27%9]) with mapi id 15.20.4975.005; Thu, 3 Feb 2022 17:04:49 +0000 From: Huaimo Chen To: "bruno.decraene@orange.com" , 'SPRING WG' Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAJp/J6AAYpjRAAAOTkY6w== Date: Thu, 3 Feb 2022 17:04:49 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <069201d8120e$dff706a0$9fe513e0$@gmail.com> <17040_1643808363_61FA866A_17040_245_14_bd3bfd409e6b45e38519a01045c163c9@orange.com> In-Reply-To: <17040_1643808363_61FA866A_17040_245_14_bd3bfd409e6b45e38519a01045c163c9@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-02T13:26:00Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; suggested_attachment_session_id: f77677a2-361b-ca26-ab48-f8c412b976b0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 11b5fd65-854f-4f51-07fa-08d9e73749cc x-ms-traffictypediagnostic: DM6PR13MB4345:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NnChBHKiXPWJhfLCBIOY0qq8JZECOkHHAKU9bhCOrq8PEBGO8O0G65j88lJNBABrpdF3id+tFWusgPFZr+1d50m4Y8FeUBPCdq/xO3OA+0DXOlJyPNtZUATNQ7YJ9ugc2YeEMJO+9F1n6Yz9iljf8lcw28/skChpRtMTYZfzx8xd7sv0rcd5Bh+vnDWVjIdQoOU+fu4ULp3juiv2mBAuZC82BAMPQeSCEJ2vXHW/dlFLfim5v221vx6lZDDmsOUltnPc4QcFwfRYv9XtHdqIvSE/0ro+3PUX3JOg3VidGBZsjSqDzyqq2xaF4iXOVSlV1OMEs9APbu6z4mRgBVsRCLnRVIFWOz9K7n1N1Wa7SQuMFla/fn+yaKAV1lF/Ybq4YJ6OqQCWCQ0ec4eeu85sd+YG/fL1m/fFWdykiRt8zVoFK4NxIfQAV/7Iv30eCWL2zLWC/HBP7ctITYkumst54EV3XTOuLQtK6HgUsaGgB0gVe7G8gcjPgtdxu6Ux4cNa+9l4QOvK4GjkyYFvJE11nJe3jN7LAyfqgeoUlKUqPKq99LmnbadGYszVOSJzUsWrt5AXJgI5FLd6uy1JKDqvov324y+fOCk7om5j1FNw50pqtKz4PMhfptPoTb6r4B6yFHd2oUExNt5hNfDWopwIVcaNEKeJIt4ohqVTYe+SEE5THU8H+X6UqQH2IKJBV4gDBRiqkWgX6TcjHSbSjU2WxkyNNQ5JeyDu6fafhTiiadmFfFZOJeqzBsg63DPp+CsYEt2T8SGYTcdzz01NM9BzFVjG9YHjqROzw0Cn0cLw7WhQ+yTpVUE6Eiw+VeoCgh7x37RzGI8pAFlnb53Ake30TCXeHzIGEOMijR/aLMafTSfO+wveWoE1bKA/AfWukp/p x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(19627405001)(5660300002)(66556008)(110136005)(76116006)(66446008)(966005)(66574015)(44832011)(66946007)(71200400001)(30864003)(52536014)(9686003)(66476007)(64756008)(508600001)(83380400001)(91956017)(2906002)(316002)(186003)(38100700002)(38070700005)(122000001)(86362001)(33656002)(6506007)(7696005)(8936002)(8676002)(55016003)(166002)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?sYuz/sRkLDcLhIzZ3QgiomXjYTR6R0CSIkbA6pkAMrFfFYBbZ1Jsfw0H?= =?Windows-1252?Q?POO8x2DvimUKpywGtbwgwFtzmXpuzglYYEgKy8VZhsdIgmE9Qder+6um?= =?Windows-1252?Q?UsjqYISpFWShVJRVj5kV8hVvvgcvylKTurDGFWQCd8pb+poZeJ32qxlG?= =?Windows-1252?Q?Y07cu9zN9CuinavK7HjOkTo6S+Fl43dwT1s2DNWlfN7D54u9rxpDcVB4?= =?Windows-1252?Q?7qHH3ziOu94SVkDet9QUyuNVizLs/TpSGtLAheC69SgZK7I65EdBUUMU?= =?Windows-1252?Q?QAQtZTXEMes4gBgp4afaGIr0vrdI3KIz2UzkSXSFQJE8twaVdmyw+tGv?= =?Windows-1252?Q?GZrlJ0YvRLrfrkZS6eFWrICYAIkTUrd4tMxjSBgP00Ewvzd1P9PbTWoD?= =?Windows-1252?Q?5XSlkA+dVOIVCefIz6nwGOrmdHP8TtFRybhVgjtuL7sHyyarulER3H8Q?= =?Windows-1252?Q?IqXJqSCaLBPlARRG69pS/qQQEHgk3v+5D0uZaV3V0djQ5276tVqPs54N?= =?Windows-1252?Q?swhVDRzztS/cyWyGSXjamPJlgUsbTL9tpTnS9gDp268iz3EYBOxECxWZ?= =?Windows-1252?Q?UvjmXoZyCccVwjMcuSkzOZQraBt1bBBQ8lOoM8g/Sz/uEWz75qqTBwaP?= =?Windows-1252?Q?+dOJlbWgU3apiDlzjtjb8pOrQj9e+G/SFxF2WC/4dolsHO+pxu6XM8Qd?= =?Windows-1252?Q?94tRIxZ2kCGokAwJGMHV5YCi5KuD26DDfo57fXpaOOhZU0erZygUYSSc?= =?Windows-1252?Q?Hz0ZVWbO+pcKaEsE/d67vhUMqPvrxLNkJEPUmMAqMrgCXH1wbd4hE9rw?= =?Windows-1252?Q?+RwFXKuHNI4JsFESe/hx9WCeDlWcdkvtz5C5fg5SNBZlKozPzSYZIvc7?= =?Windows-1252?Q?mq79KLQOCrwIbEw/Wt/splci4wDb75PexkMBSRgtFQGvjILCuh6fCuEK?= =?Windows-1252?Q?EcubpWeI3qMIcdpRJolX9TpLWn71ZrGpCQApA1ctfQ/UOqftvG0miuKP?= =?Windows-1252?Q?HAbSxqsIZ/BoR7xipzr7DJPVl5mYAmytTEtnJBukY+0oLM7suB9H8G4x?= =?Windows-1252?Q?NkufsywhHfI6RM4yWY8LnG54nfc1ODWitxDzxlkLSWcQbtTCy4SDVdEn?= =?Windows-1252?Q?EdIsI0N4LgCxPMvk42R+5MFiSVAm3ER14uDVQGY4fOeMKyjlj15vcF6g?= =?Windows-1252?Q?8kLY55HBpRfvf/+p8kPlcAJhoNe4pebyo14EjuWCIvUxcFE8RW1bXJzA?= =?Windows-1252?Q?PlJVdbwFoNLz8D+yI3nwrru1lhgFXz+gKTxyPQs+hmjcLeSitZhTCGQG?= =?Windows-1252?Q?msARziBnw91LweIr9zmOpCsnLn1jzV2xD2i6swH4tmhudYhWlROSVF3T?= =?Windows-1252?Q?/ZmcYHsSmcKsW4YQwCFe9j6/s+e0MPD0qVjk//cYWs+nGNyI6HrUgG97?= =?Windows-1252?Q?BmMAkS2CUxwYmkUIQ1IPL8IfCAnHT5YyTBC5RBoGl/+lEpD9fWZFhZC3?= =?Windows-1252?Q?/AKYm/+oRJHI3qhMGSs9DAJI2A+IMGHMSvPGCe/c7zLkT5CaTkJk56/y?= =?Windows-1252?Q?L2QbE3OWqsJHVnZMHBPghnxMKvjpbIhXKXqqR6Gze0RGv5XSOMn2KIyX?= =?Windows-1252?Q?9mzLdOOtKg92aq0GVXUaHy+bDDWkfwPYa7AqGTBXD/YzBPmtl0yLJyJc?= =?Windows-1252?Q?k7BfGf7ZLUj+8a9W1dp6EtjG3fIS6EMJf4mkoVk4kyb+BqrrPY3dfAA/?= =?Windows-1252?Q?WdXgXbr7i4tWwVFVaO3a56doghmkqAaZ8fw5N77SkqjcJxoautMGm0OT?= =?Windows-1252?Q?oIUygA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB504496207D9217C286A6D465F2289BY3PR13MB5044namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11b5fd65-854f-4f51-07fa-08d9e73749cc X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2022 17:04:49.3993 (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: Hu3Oj3dwp0LPEz69tqfPKsOypXla+zJfk9ll0TTobmTwH6bCB5pugJO3oD+b1WYGiCUbb5rALbSYxuCHODe7cg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB4345 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 03 Feb 2022 17:04:59 -0000 --_000_BY3PR13MB504496207D9217C286A6D465F2289BY3PR13MB5044namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thank you very much for your valuable comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: spring on behalf of bruno.decraene@orange.c= om Sent: Wednesday, February 2, 2022 8:26 AM To: slitkows.ietf@gmail.com ; 'SPRING WG' ; Huzhibo Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi authors of both documents, WG, [Speaking as individual contributor.] It=92s good to see technical discussions on the restoration of failed SIDs = used by SR policy. 1. From a functional point of view, can we summarize the benefit to sign= al the node proxy capability? e.g. - drop the traffic earlier if the PLR does not support proxy capability. (h= elps with congestion) [HC]: When the PLR supports proxy capability, it provides protection for the failure of its adjacent node with BSIDs. The BSIDs are protected. When the PLR does not support proxy capability, it provides protection for the failure of its adjacent node, but the BSIDs on the node are not protected. - use another proxy off the shortest path (increase congestion but reduce l= oss) [HC]: When there is a node on the shortest path not supporting proxy, another proxy capable node off the shortest path to a neighbor of the faile= d node is used. The traffic is sent to the neighbor, which re-routes the traf= fic around the failed node towards the destination. The traffic is protected. In fact, the failed node is a loose hop on the SR path with the SID of the = node. >From a upstream node to the failed node, there are a few hops in general. When any of these hops fails, the traffic will be re-routed around the failure. This should be considered by the controller that computes the SR path. This should not increase congestion. Using proxy capable node off the shortest path to a neighbor of the failed node to some extend should not increase congestion. Using another proxy capable node off the shortest path reduces traffic loss and should not increase congestion to some extend. - possibly help identifying the proxy (nominal is not in the reachable topo= logy anymore) [HC]: When a node failed and becomes unreachable, it helps identifying the proxy capable path to a neighbor of the failed node. =85 Or agree on the absence of significant benefits? [HC]: It provides more protection coverage in some cases as compared to the other existing draft. This improves the reliability of networks, and QoE. This should be a significant benefit. In addition, when a node fails, the nodes of the entire network converge to the latest state consistently in time. After a node failed, comparing to the other existing draft regarding to holding off the FIB during the HoldTimer period, when the network changes again, our solution continues to converge at any time. 1. draft-ietf-spring-node-protection-for-sr-te-paths =93If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires.=94 * It=92s not crystal clear to me how it would work in reality, so I wou= ld welcome more prescriptive text. In particular: * =93node failure=94 is not an IGP message. IGP nodes sees multiple = =93adjacency loss=94 messages which are not atomic and could be handled in = multiple SPFs. Hence different nodes will freeze their FIB based on a diffe= rent topology (link1 for some, link2 for others) leading to inconsistent ro= uting and forwarding loops. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. [HC]: In addition to the above, it seems better to describe procedures about link/node up and down events regarding to FIB entries such as those being held off (not to be changed) during the period from HoldTimer start to end. For example, after a node is down, some FIB entries are held off (not to be changed), then the node is up, but some of its links are up and the other links are still down (maybe for a long time). How to handle the FIB entries (hold off or change) in this case? 1. draft-hu-spring-segment-routing-proxy-forwarding Rather than defining a new =93Proxy Forwarding=94 capability in IGP why don= =92t you use the existing Mirroring Segment (from RFC https://datatracker.i= etf.org/doc/html/rfc8402#section-5.1) whose signaling is already standardized? https:/= /datatracker.ietf.org/doc/html/rfc8667#section-2.4.1 [HC]: =93Proxy Forwarding=94 capability of a node may be alternatively indicated by the mirror SIDs advertised by the node. Mirror SID for a failed node can be used as context to forward the traffic with the SID of the failed node to the next hop of the failed node. A node advertises a mirror SID for each of its neighbor nodes. When a node failed, its node SID is not reachable. A remote node of the failed node sends the traffic with the SID of the failed node to a neighbor of the failed node. The neighbor sends (i.e., re-route) the traffic to the next hop of the failed node when the neighbor advertises the mirror SID for the failed node. When the neighbor does not advertise the mirror SID for the failed node, it pushes the mirror SID advertised by another neighbor (say AN) and sends the traffic to AN. AN pops its mirror SID as context and uses the SID of the failed node to re-route the traffic to the next hop of the failed node. 1. What about the following solution: * Use mirror SID * Tunnel to the =93proxy-forwarding=94 advertising mirror SID [HC]: If tunnels are used, there may be tunnels from each of the remote nodes to each of the neighbors of a failed node. This may use some network resources. It seems that tunnels may be replaced by the shortest path to the neighbor along the nodes advertising mirror SIDs. I would see the following benefits: * No new protocol extensions (cf =933)=94 * Consistent routing in case of multiple SPFs (cf =932)=94) * Benefit from the signaling of the proxy (cf =931)=94) [HC]: We can see these. Thanks, Regards, --Bruno Orange Restricted From: slitkows.ietf@gmail.com Sent: Tuesday, January 25, 2022 6:13 PM To: DECRAENE Bruno INNOV/NET ; 'SPRING WG' Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi, I=92m NOT supporting this draft for the following reasons: 1. The WG already have a WG document which is dealing with this problem,= I don=92t think that WG should come with multiple documents/solutions for = the same solution space as it may just confuse the industry and create depl= oyment issues as different vendors may pick different solutions. 1. Adding protocols extensions adds complexity in the solution without a= dding a strong value. The document claims that =93[I-D.ietf-spring-segment-protection-sr-te-paths= ] =85 may not work for some cases such as some of nodes in the network not = supporting this solution.=94. While this is true, the proposed solution in = draft-hu-spring-segment-routing-proxy-forwarding has exactly the same cavea= t and requires all nodes in the network to support the solution. Considering the following straight line network: A -B -C -D =96 E =96 F - G= -H and an SR policy from A to H using SID_G, routers A to F have to suppor= t the extension to make the solution working, if one of the router doesn=92= t support the extension, traffic will be dropped. Then, there is no value compared to the timer-based solution of [I-D.ietf-s= pring-segment-protection-sr-te-paths] Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G m= ay have multiple upstream neighbors let=92s say F and F=92 and the solution= allows for F=92 to support the extension while F may not support, so the s= olution will send the traffic to F=92. Well yes, but this still requires al= l routers upstream to F=92 to support this extension and maybe F is on the = path to F=92. So, I don=92t think the argument is valid as it may possibly = work tactically depending on the network topology when we look at a small p= ortion of the network, but when we look at the whole network, operator will= have to upgrade all their nodes to support the extension to ensure the ben= efit is there. In addition, in term of traffic, forwarding traffic to a neighbor of the fa= iled node which wasn=92t initially on the path, could lead to traffic conge= stion or high traffic peaks on links that were not sized to carry this traf= fic. We could easily expect some traffic tromboning, where traffic goes to = this non-natural neighbor of the failed node and then goes back over some p= art of the same path before reaching the destination. So these protocol extensions are bringing complexity for no value here. 1. Regarding BSID, I=92m not fan of advertising BSIDs in IGP as there ma= y be hundreds or thousands of BSID on a node which again will create a lot = of burden in IGP. The proposed way will have to be discussed in LSR, not in= SPRING (see next comment). Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work = with BSIDs as long as BSID information of failed node is available in the c= ontrol-plane of PLRs by whatever mechanism. I think this BSID handling is o= rthogonal to the proxy-forwarding controlplane behavior. The forwarding ope= rations for BSID will have to be discussed more in details, we could not ex= pect all HW to be able to do 3 or 4 lookups without any perf degradation. 1. The document is currently a bit borderline between SPRING and LSR as = it talks in good details about IGP protocol extensions. If it=92s a SPRING = doc, it should detail reqs for protocols but nothing beyond. Brgds, Stephane From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: jeudi 13 janvier 2022 11:19 To: SPRING WG > Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_BY3PR13MB504496207D9217C286A6D465F2289BY3PR13MB5044namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Bruno,

    Thank you very much for your valuable comments.

    My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors


From: spring <spring-bou= nces@ietf.org> on behalf of bruno.decraene@orange.com <bruno.decraene= @orange.com>
Sent: Wednesday, February 2, 2022 8:26 AM
To: slitkows.ietf@gmail.com <slitkows.ietf@gmail.com>; 'SPRING= WG' <spring@ietf.org>; Huzhibo <huzhibo@huawei.com>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 

Hi authors of both documents, WG,

 

[Speaking as individual contributor.]

 

It=92s good to see technical discussions on the restoration = of failed SIDs used by SR policy.

 

  1. From a functional point of view, can we summarize the benefi= t to signal the node proxy capability?

e.g.

- drop the traffic earlier if the PLR does not support proxy= capability. (helps with congestion)

[HC]: When the PLR supports proxy capability, it provides pr= otection

for the failure of its adjacent node with BSIDs. The BSIDs are protect= ed.
When the PLR does not support proxy capability, it provides protection=
for the failure of its adjacent node, but the BSIDs on the node are not protected.

- use another proxy off the shortest path (increase congesti= on but reduce loss)

[HC]: When there is a node on the shortest path not supporti= ng proxy,

another proxy capable node off the shortest path to a neighbor of the = failed
node is used. The traffic is sent to the neighbor, which re-routes the= traffic
around the failed node towards the destination. The traffic is protect= ed.
In fact, the failed node is a loose hop on the SR path with the SID of= the node.
From a upstream node to the failed node, there are a few hops in gener= al.
When any of these hops fails, the traffic will be re-routed around
the failure. This should be considered by the controller that computes=
the SR path. This should not increase congestion.
Using proxy capable node off the shortest path to a neighbor of the fa= iled
node to some extend should not increase congestion.
Using another proxy capable node off the shortest path reduces traffic=
loss and should not increase congestion to some extend.

- possibly help identifying the proxy (nominal is not in the= reachable topology anymore)

[HC]: When a node failed and becomes unreachable, it helps i= dentifying
the proxy capable path to a neighbor of the failed node.

=85

Or agree on the absence of significant benefits?

[HC]: It provides more protection coverage in some cases as = compared to

the other existing draft. This improves the reliability of networks,
and QoE. This should be a significant benefit.
In addition, when a node fails, the nodes of the entire network conver= ge
to the latest state consistently in time.
After a node failed, comparing to the other existing draft regarding t= o
holding off the FIB during the HoldTimer period,
when the network changes again, our solution continues to converge at any time.


  1. draft-ietf-spring-node-protection-for-sr-te-paths

 

=93If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forwarding changes should not

   communicated to the forwarding planes on all configured routers

   (including PLRs for the failed node) until the hold-timer expires.= =94

 

  • It=92s not crystal clear to me how it would work in reality,= so I would welcome more prescriptive text. In particular:
    • =93node failure=94 is not an IGP message. IGP nodes sees mul= tiple =93adjacency loss=94 messages which are not atomic and could be handl= ed in multiple SPFs. Hence different nodes will freeze their FIB based on a different topology (link1 for some, link2 for others)= leading to inconsistent routing and forwarding loops.
    • How is the FIB modified in cases of consecutives IGP events?= (freezed on hold topology may lead to drops, updating entries would need t= o be specified.
  • On a side node, this text requires a global behavior of all = IGP nodes. That seem a bit out of scope of a non-normative sentence, in an = informational document, describing a local behavior on the PLR.

 [HC]: In addition to the above, it seems bett= er to describe procedures

about link/= node up and down events regarding to FIB entries such as
those being= held off (not to be changed) during the period from
HoldTimer s= tart to end. For example, after a node is down, some FIB
entries are= held off (not to be changed), then the node is up, but
some of its= links are up and the other links are still down (maybe
for a long = time). How to handle the FIB entries (hold off or change)
in this case?


  1. draft-hu-spring-segment-routing-proxy-forwarding
    2. =

Rather than defining a new =93Proxy Forwarding=94 capability= in IGP why don=92t you use the existing Mirroring Segment (from RFC https://datatracker.ietf.org/doc/html/rfc8402#section-5.1) whose signal= ing is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1

 [HC]: =93Proxy Forwarding=94 capability of a node may = be alternatively

indicated by the mirror SIDs advertised by the node.
Mirror SID for a failed node can be used as context to forward
the traffic with the SID of the failed node to the next hop of the
failed node. A node advertises a mirror SID for each of its neighbor <= /div>
nodes. When a node failed, its node SID is not reachable.
A remote node of the failed node sends the traffic with the SID of
the failed node to a neighbor of the failed node.
The neighbor sends (i.e., re-route) the traffic to the next hop of
the failed node when the neighbor advertises the mirror SID for the
failed node. When the neighbor does not advertise the mirror SID for <= /div>
the failed node, it pushes the mirror SID advertised by another
neighbor (say AN) and sends the traffic to AN. AN pops its mirror SID =
as context and uses the SID of the failed node to re-route the
traffic to the next hop of the failed node.


  1. What about the following solution:
  • Use mirror SID
  • Tunnel to the =93proxy-forwarding=94 advertising mirror SID<= /span>

[HC]: If tunnels are used, there may be tunnels from each of= the

remote nodes to each of the neighbors of a failed node. This may
use some network resources. It seems that tunnels may be replaced
by the shortest path to the neighbor along the nodes advertising
mirror SIDs.


I would see the following benefits:

  • No new protocol extensions (cf =933)=94
  • Consistent routing in case of multiple SPFs (cf =932)=94)
  • Benefit from the signaling of the proxy (cf =931)=94)=

 [HC]: We can see these.


Thanks,

Regards,

--Bruno

 

 

Orange Restricted

From: slitkows.ietf@gmail.c= om <slitkows.ietf@gmail.com>
Sent: Tuesday, January 25, 2022 6:13 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; 'SPR= ING WG' <spring@ietf.org>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi,

 

I=92m NOT supporting this draft for the fol= lowing reasons:

 

  1. The WG already have a WG document which is = dealing with this problem, I don=92t think that WG should come with multipl= e documents/solutions for the same solution space as it may just confuse th= e industry and create deployment issues as different vendors may pick different solutions.

 

  1. Adding protocols extensions adds complexity= in the solution without adding a strong value.

 

The document claims that =93[I-D.ietf-sprin= g-segment-protection-sr-te-paths] =85 may not work for some cases such as s= ome of nodes in the network not supporting this solution.=94. While this is= true, the proposed solution in draft-hu-spring-segment-routing-proxy-forwa= rding has exactly the same caveat and requires all nodes in the network to suppo= rt the solution.

 

Considering the following straight line net= work: A -B -C -D =96 E =96 F - G -H and an SR policy from A to H using SID_= G, routers A to F have to support the extension to make the solution workin= g, if one of the router doesn=92t support the extension, traffic will be dropped.

 

Then, there is no value compared to the tim= er-based solution of [I-D.ietf-spring-segment-protection-sr-te-paths]

 

Authors of draft-hu-spring-segment-routing-= proxy-forwarding argued that G may have multiple upstream neighbors let=92s= say F and F=92 and the solution allows for F=92 to support the extension w= hile F may not support, so the solution will send the traffic to F=92. Well yes, but this still requires all routers up= stream to F=92 to support this extension and maybe F is on the path to F=92= . So, I don=92t think the argument is valid as it may possibly work tactica= lly depending on the network topology when we look at a small portion of the network, but when we look at the whole n= etwork, operator will have to upgrade all their nodes to support the extens= ion to ensure the benefit is there.

 

In addition, in term of traffic, forwarding= traffic to a neighbor of the failed node which wasn=92t initially on the p= ath, could lead to traffic congestion or high traffic peaks on links that w= ere not sized to carry this traffic. We could easily expect some traffic tromboning, where traffic goes to this no= n-natural neighbor of the failed node and then goes back over some part of = the same path before reaching the destination.

 

So these protocol extensions are bringing c= omplexity for no value here.

 

 

  1. Regarding BSID, I=92m not fan of advertisin= g BSIDs in IGP as there may be hundreds or thousands of BSID on a node whic= h again will create a lot of burden in IGP. The proposed way will have to b= e discussed in LSR, not in SPRING (see next comment).

 

Note that [I-D.ietf-spring-segment-protecti= on-sr-te-paths] could also work with BSIDs as long as BSID information of f= ailed node is available in the control-plane of PLRs by whatever mechanism.= I think this BSID handling is orthogonal to the proxy-forwarding controlplane behavior. The forwarding operations f= or BSID will have to be discussed more in details, we could not expect all = HW to be able to do 3 or 4 lookups without any perf degradation.

 

  1. The document is currently a bit borderline = between SPRING and LSR as it talks in good details about IGP protocol exten= sions. If it=92s a SPRING doc, it should detail reqs for protocols but noth= ing beyond.

 

 

 

Brgds,

 

Stephane

 

 

From: spring <spring-bounc= es@ietf.org> On Behalf Of bruno.decr= aene@orange.com
Sent: jeudi 13 janvier 2022 11:19
To: SPRING WG <spring@ietf.org= >
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,

 

This message starts a 2 week WG adoption call, ending 27/01/= 2022, for draft-hu-spring-segment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/draft-hu-s= pring-segment-routing-proxy-forwarding/

 

After review of the document please indicate support (or not= ) for WG adoption of the document to the mailing list.

 

Please also provide comments/reasons for your support (or la= ck thereof) as this is a stronger way to indicate your (non) support as thi= s is not a vote.     

 

If you are willing to work on or review the document, please= state this explicitly. This gives the chairs an indication of the energy l= evel of people in the working group willing to work on the document.

=  

= Thanks!

= Bruno, Jim, Joel

______________________________________________________=
___________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisati=
on. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces joi=
ntes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confident=
ial 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 notif=
y the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for mes=
sages that have been modified, changed or falsified.
Thank you.
______________________________________________________=
___________________________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
--_000_BY3PR13MB504496207D9217C286A6D465F2289BY3PR13MB5044namp_-- From nobody Sun Feb 6 13:41:06 2022 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 B8C113A0DEF; Sun, 6 Feb 2022 13:40:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Cullen Jennings via Datatracker To: Cc: draft-ietf-spring-segment-routing-policy.all@ietf.org, last-call@ietf.org, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164418360967.24977.17268842252865901665@ietfa.amsl.com> Reply-To: Cullen Jennings Date: Sun, 06 Feb 2022 13:40:09 -0800 Archived-At: Subject: [spring] Artart last call review of draft-ietf-spring-segment-routing-policy-16 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: Sun, 06 Feb 2022 21:40:10 -0000 Reviewer: Cullen Jennings Review result: Ready This draft does not raise any issues specific to the ART area. The use of non UTF symbolic names is appropriate for this use case so I do not see any issues with strings. I view printable ascii as fairly well defined but if you want to be clearer, you could say 0x20 to 0x7E. As an outside reader not involved with the spring WG, this draft was relatively easy to understand. I do not see any problems with publication. From nobody Sun Feb 6 20:10:01 2022 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 59C663A1342 for ; Sun, 6 Feb 2022 20:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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=gnUDpzJL; dkim=pass (1024-bit key) header.d=juniper.net header.b=iZGKrjqH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cawd5hlW8U74 for ; Sun, 6 Feb 2022 20:09:42 -0800 (PST) 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 DB4B83A1340 for ; Sun, 6 Feb 2022 20:09:40 -0800 (PST) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 2170Nt0W027616; Sun, 6 Feb 2022 20:09:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=7tCsxxe2L2PUb8c6p5tKdP3S2V3XGHPgwIIWSuQ0or4=; b=gnUDpzJLRiyUVPdNwK74O7sc5QfVlRjNS4bevsRd+ds/molHkFBogfU76f8dgEIP0Bfy Im18YODIZ4yG/42siacYyrK3QsPhPjd3xhdFsIozW24hVwJn09CJ9ikiLLI0kDk3cbd/ fuwl0aQO9vBp0Zv6YtlhSBRmrkOdI4FQM+FVcBs/cURwqwKSXxKWh4cMxyBUNZ7cmzLy Gfc9FuPNfHAdPssMySbV9Anzsc0rlavSmqSOAoGdybooBX9xVRD60IB5lBtm5MWTllOs fAJItM3sxHMVBYTrI+/Dv3oO/UrGjeLg34QJltHRNwjuQFBf1wZZIY/kBqKh9HYTbsR+ jg== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3e2b9bh88q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 06 Feb 2022 20:09:29 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G5oqFHSmTidV5HJVekuKGFHUE3RB1O9HreSb/06e7SKRO1Kp2pNAm3gtdCEtrIgRgsVII4yTC1bZN+q/aXCeazCkSNPJhlDiwUUHtdZmol2k7O+2uU7UQI5tTfKaQQ7SOUmTD6wTmtG98NTqFOpM/6YUKM8BMae/T6nQepXhjJK7UfBoufcV86cvQi1jCNfhzcsjBk8PZ+xcfuyX4qNDRyA7n23YSUwvc/FGcPQdWdl4K+LHKIeJgNJNyI2IE7Esb09z/vK9eHqpP7w8Kp1uv4uCVO/JRV5DvBulyNCbzmsnSkwXpRhEqJjRNInjcpRS6GA9UJtp+9HGrXkFr093fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7tCsxxe2L2PUb8c6p5tKdP3S2V3XGHPgwIIWSuQ0or4=; b=ca3jUSHdClQnc7Vtfe+8CdesWFD/LNW34K0ITRAfMqfOhJhDFucBVjY6xr4KHS7EmycaCNJdv34cM7jB5AdR0PmDgfeU56mIk8B/+wNjH/LkBUgUTssyS/Us/g1kiVvgkcE4eBGaVoO/P4jCc1jBsRhEdGOU+Sp2Y7OYjqDmmwpiWH5L7TUFj6TcGz7GelWNKjA4xN/qtSbN1XpHaFlx7Y+YhlI+C/aIAMExJNu7VfdgGlqyP0P/7vULOSRPaaZ90vsdcIwOKb7Px1V/8PoS07WwyDdWb2V6uxAStI82xluY/XUcM92mJ5VQ++p/QtOnoIvPkvcy7b9PuxDLQhOIPQ== 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=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7tCsxxe2L2PUb8c6p5tKdP3S2V3XGHPgwIIWSuQ0or4=; b=iZGKrjqHAGkms+Mxdhr/kNXfhS8ZlJAoMcdmo9DWOxiTGl5xRObMM1gVuSBXiAtwThJgFJJfFt2NJXiy5+qoaHcl9e01zEjj7zNlnf7/yb0AYqoH4fDeC/TbZTjtKZLx0ZuiCs083iOahJDl1zQ6+IQ58IpvNOSmS7b6t0e9Cws= Received: from CO1PR05MB8314.namprd05.prod.outlook.com (2603:10b6:303:fd::13) by SN2PR05MB2782.namprd05.prod.outlook.com (2603:10b6:804:16::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.14; Mon, 7 Feb 2022 04:09:26 +0000 Received: from CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::857e:c814:a640:6153]) by CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::857e:c814:a640:6153%5]) with mapi id 15.20.4951.014; Mon, 7 Feb 2022 04:09:26 +0000 From: Shraddha Hegde To: "bruno.decraene@orange.com" , "slitkows.ietf@gmail.com" , 'SPRING WG' , Huzhibo Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAJp/J6AAYpjRAAA587S8A== Date: Mon, 7 Feb 2022 04:09:26 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <069201d8120e$dff706a0$9fe513e0$@gmail.com> <17040_1643808363_61FA866A_17040_245_14_bd3bfd409e6b45e38519a01045c163c9@orange.com> In-Reply-To: <17040_1643808363_61FA866A_17040_245_14_bd3bfd409e6b45e38519a01045c163c9@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.400.34 dlp-reaction: no-action msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-02T13:26:00Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-02-07T04:03:25Z; 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=7ff81c66-cd98-4efc-88a5-f1e7875fdcc9; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2022-02-07T04:09:18Z 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: 5823eb1e-10e7-471c-aed8-76072e41d983 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f86b259-85a2-410f-f367-08d9e9efa1a2 x-ms-traffictypediagnostic: SN2PR05MB2782:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qupSZvobyAdcqIxM1t1Qe3CVNQDDZuVeqkP9scrOiStIX6pUoyb3KWB+ftbQ31nVu0ErL3rMjimfJ9Kkk7LRVOfXdFGQm6Uk6Z7xFf3ZO9UvUVJy2IALLkQLg0Izc2k/+r++pdlHKwkkrcSz8Jh2tTEwpifZsd2nltrkWO64X/zckZtxCzbfRiQ//w2Gm+fugBurJcCkb/DS+8cGyfgdq9JmgH7UvOtW3I+ZO5eVXuZ/DRUosft+RKMgezc4fcwHv/yQ0zKg77ykK6WevDZCelE7fhsnvICm5nfkxnhE+J5Ta7f/EgGP0xoUwEVDXFIVmqHo7LkGlelzIaOZCi+21fAlQsmim8t4lhnCuPd4kqcZjNfMbr8UY6EAYYLWLo/8yoPx2jRn5wHihQhSDXwyy+H6yRosXms8cqwB3vd4W24Gts2XASwE5AMsgdU0lJEOGuHRmg29YO0PI6oTgVwDqqUciLqdyz3PwgsI+CePTkyL4cOdHZJ/jLdPuJ4JmLUmyaqDXmE9yex5XCrPvTliST7tlf9aJWNCtWly2MM4Nut2KygNxAYDT2vQY6qvhJGm1mVajMDWYAHVqHqju8g5SPsyMyRvGmWlPMYDT/cu8jxd+8JeegMcP7Q+LYLpMY/B8uO2Unk/xRtg6qgVBC95d3XUQT+dKee/lW72ONOXDcZuQNPmMbUqiBrrMi76a+usy+kH2Fosya0m7oAmWW4tCj50DaVeRcMPsZ5eaOX7kciQjCNM66T+NCZRm0Se2ydLCLNOGgn5hhFmw+B2g6OtElB4CdjA/9rlJDycPGInQp+xzo7ynREN/T7WzhwZ+CqVadlSTa18kA3/igeRohdbIw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR05MB8314.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38100700002)(53546011)(122000001)(5660300002)(6506007)(71200400001)(38070700005)(26005)(7696005)(83380400001)(30864003)(55016003)(186003)(8936002)(64756008)(76116006)(9686003)(316002)(66476007)(33656002)(966005)(66446008)(508600001)(2906002)(66574015)(166002)(8676002)(86362001)(110136005)(52536014)(66556008)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?tlVbYkxc/z4Og3hn1Aq6t1dk1F1PyxD3xqNI24ydayDokF090RPlKrVhR6Wx?= =?us-ascii?Q?6lFZ/BqCxjqwV5c8EWRZVYSx1vz4ASoKjfRayF/QgoMa4IaBoboXydNo2PQT?= =?us-ascii?Q?buflUci/r8pjO7lQRfnkA4J8UFtVd5f6G29XoFv6loXJji46sryqONjeUwWJ?= =?us-ascii?Q?aKN4cw9CkenVpn8dXO6n7E3HMUx7PpItXCRsvvxEI03MjUsi9CIue5bZusVB?= =?us-ascii?Q?EOwoY7mIyXO7DyrK76OErS0gIpF7bSQp7x8+4DpThmYaaxGOMgk77F3uFj58?= =?us-ascii?Q?N8QxXvo+qYENhkfwLNO2CbhxltHA+Dmp4zPFISVWxBtFqm7oYbWr0ihIJ5PH?= =?us-ascii?Q?pUAWqDQ0o8qCHK/XBf/4GgIWaUzJR81Edjf/bJrUNoAZpPNLN7oPlLf+gWUw?= =?us-ascii?Q?KmQ9KdhtaONFWME32F3h+B85Rw2tBArWCW8Q/jPY4ggrTnmHOSDEtKNFdwti?= =?us-ascii?Q?JVzLdrOgD9rp++l6HoZ3TWFnwVjvyjBrhdOQRj8kdyUVNWtCSXyRP2AGnolA?= =?us-ascii?Q?019Yqkxa8ezeCDwCKTFuZr2eME7zt5DnVFBSFLi/Npvk86uQ+Y8t3XtpbEr0?= =?us-ascii?Q?K23GG1lE8ckfjEVmkI6MWJweDyuqGCyIu131lrIAlyLU0YngYz4paYoXhFt8?= =?us-ascii?Q?N2SBVFZYsBe2Nors4k3yTlOidlAGPYGEOQPzQtyHZ/AFicmqculM+VeW9jvn?= =?us-ascii?Q?UduKcVfB9lMrKdw/1S4c/gsIOtC6DT7uXZPzwxJNIlwWVQFZphtr1CgtwhBJ?= =?us-ascii?Q?5YH+fQ6ZB18mTsfHonBw5ezuSm5KnuRZLuWz8oXKXV0S1zVLEZi3ZCC/ST+v?= =?us-ascii?Q?hpDvLy6nJWDGz2k2mq7lqJ9wPjK+SmUwsY7e1J5f8zVSlvTDE3HWIF8P1WkV?= =?us-ascii?Q?w1UzJUhcEdKvk3v3YhzypqPMKMmwymwFA3YAArA5llYkDFiTux0mU9x1ecuX?= =?us-ascii?Q?fTpG5f/PaFCqD3R3PAMGfLcaYz/zpB/La5u1bmMeBx2G1oF8/q1+QFSyK7sd?= =?us-ascii?Q?hAG3eUVQ2Zstnu+DvHjdosUNAMnkG9EyomV77rzIaJfFwUtrNokufCq/vuQx?= =?us-ascii?Q?WoRcFVJbCE/WPPYAuCg/gw3eDEh7u8I1X0p2NdS6AzKCry4dsu5ymvyF7HIG?= =?us-ascii?Q?MiHrU1+fqLDOZbxzLNdR/HjkEYTxG5D+AGCkvlbJcGsdV5KLahaJM500buLB?= =?us-ascii?Q?IMPrN68QCb25jJY/kpnNTDzLnNEelnGdqdoNqyq4pbAJQApSmXoCrKMirsBJ?= =?us-ascii?Q?6qJFIq1l9tRMUNqBpXutIdfZl6OHrQIDS6ZI6ozneHKgG/+nUv9UCQ4JnZCP?= =?us-ascii?Q?/gPvOjTyJ7Q5i36qUWSlpmB7w/M62vMOG5w5EO7T6skoblr3JvfRBjDpRUPm?= =?us-ascii?Q?AKHHNEzPrUJW+a7QNzs5B3J97Fy4ynPkeVqR5d9rqQtVSI4kACpACrmfuaNj?= =?us-ascii?Q?BeMFKuE5vllbnSuTBmyeM9kEv893qWYw6K0Dd2H2euCAn1f6GuagsBSsKsFe?= =?us-ascii?Q?xDzPXKTf+BjEsQ6btlyE0CahdvTF6UG7z9LoBOONn4v1814ZLBR1Fa1YZjJF?= =?us-ascii?Q?xa55tr3DYZ8fXtY1N0PYCXe5e033oR2gjwn4Bq60sXIVZzUhxFkD2xAqaaO9?= =?us-ascii?Q?Yabg9uZ28rLUW8480lkIASg=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR05MB8314C64BFB8C342F3174E9BAD52C9CO1PR05MB8314namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR05MB8314.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f86b259-85a2-410f-f367-08d9e9efa1a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2022 04:09:26.6808 (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: VW6gg8wYqwoKtiJ6EJumWzANK7Gm5XmKxsnD8lB+uOccEbOK5k/5sEQGOwKhQvRrZuhcXF1SU3foromX0eWu6A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2782 X-Proofpoint-GUID: npfl-qw-m9W-XGLcugv_103AXX9v7XPM X-Proofpoint-ORIG-GUID: npfl-qw-m9W-XGLcugv_103AXX9v7XPM X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-07_01,2022-02-03_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 suspectscore=0 spamscore=0 clxscore=1011 adultscore=0 bulkscore=0 impostorscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202070024 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 07 Feb 2022 04:09:54 -0000 --_000_CO1PR05MB8314C64BFB8C342F3174E9BAD52C9CO1PR05MB8314namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruno, Snipped... 1. draft-ietf-spring-node-protection-for-sr-te-paths "If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires." * It's not crystal clear to me how it would work in reality, so I would= welcome more prescriptive text. In particular: * "node failure" is not an IGP message. IGP nodes sees multiple "adj= acency loss" messages which are not atomic and could be handled in multiple= SPFs. Hence different nodes will freeze their FIB based on a different top= ology (link1 for some, link2 for others) leading to inconsistent routing an= d forwarding loops. I will add text to capture this point and also add detailed text on po= ssible solutions. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. Agreed. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. I don't think we need any protocol extension for solutions described i= n this document but if WG thinks it should be a standard rather than infor= mational we should upgrade this document status IMO. Rgds Shraddha Juniper Business Use Only From: spring On Behalf Of bruno.decraene@orange.c= om Sent: Wednesday, February 2, 2022 6:56 PM To: slitkows.ietf@gmail.com; 'SPRING WG' ; Huzhibo Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding [External Email. Be cautious of content] Hi authors of both documents, WG, [Speaking as individual contributor.] It's good to see technical discussions on the restoration of failed SIDs us= ed by SR policy. 1. From a functional point of view, can we summarize the benefit to sign= al the node proxy capability? e.g. - drop the traffic earlier if the PLR does not support proxy capability. (h= elps with congestion) - use another proxy off the shortest path (increase congestion but reduce l= oss) - possibly help identifying the proxy (nominal is not in the reachable topo= logy anymore) ... Or agree on the absence of significant benefits? 1. draft-ietf-spring-node-protection-for-sr-te-paths "If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires." * It's not crystal clear to me how it would work in reality, so I would= welcome more prescriptive text. In particular: * "node failure" is not an IGP message. IGP nodes sees multiple "adj= acency loss" messages which are not atomic and could be handled in multiple= SPFs. Hence different nodes will freeze their FIB based on a different top= ology (link1 for some, link2 for others) leading to inconsistent routing an= d forwarding loops. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. 1. draft-hu-spring-segment-routing-proxy-forwarding Rather than defining a new "Proxy Forwarding" capability in IGP why don't y= ou use the existing Mirroring Segment (from RFC https://datatracker.ietf.or= g/doc/html/rfc8402#section-5.1) whose signaling is alre= ady standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4= .1 1. What about the following solution: * Use mirror SID * Tunnel to the "proxy-forwarding" advertising mirror SID I would see the following benefits: * No new protocol extensions (cf "3)" * Consistent routing in case of multiple SPFs (cf "2)") * Benefit from the signaling of the proxy (cf "1)") Thanks, Regards, --Bruno Orange Restricted From: slitkows.ietf@gmail.com > Sent: Tuesday, January 25, 2022 6:13 PM To: DECRAENE Bruno INNOV/NET >; 'SPRING WG' > Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi, I'm NOT supporting this draft for the following reasons: 1. The WG already have a WG document which is dealing with this problem,= I don't think that WG should come with multiple documents/solutions for th= e same solution space as it may just confuse the industry and create deploy= ment issues as different vendors may pick different solutions. 1. Adding protocols extensions adds complexity in the solution without a= dding a strong value. The document claims that "[I-D.ietf-spring-segment-protection-sr-te-paths] = ... may not work for some cases such as some of nodes in the network not su= pporting this solution.". While this is true, the proposed solution in draf= t-hu-spring-segment-routing-proxy-forwarding has exactly the same caveat an= d requires all nodes in the network to support the solution. Considering the following straight line network: A -B -C -D - E - F - G -H = and an SR policy from A to H using SID_G, routers A to F have to support th= e extension to make the solution working, if one of the router doesn't supp= ort the extension, traffic will be dropped. Then, there is no value compared to the timer-based solution of [I-D.ietf-s= pring-segment-protection-sr-te-paths] Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G m= ay have multiple upstream neighbors let's say F and F' and the solution all= ows for F' to support the extension while F may not support, so the solutio= n will send the traffic to F'. Well yes, but this still requires all router= s upstream to F' to support this extension and maybe F is on the path to F'= . So, I don't think the argument is valid as it may possibly work tacticall= y depending on the network topology when we look at a small portion of the = network, but when we look at the whole network, operator will have to upgra= de all their nodes to support the extension to ensure the benefit is there. In addition, in term of traffic, forwarding traffic to a neighbor of the fa= iled node which wasn't initially on the path, could lead to traffic congest= ion or high traffic peaks on links that were not sized to carry this traffi= c. We could easily expect some traffic tromboning, where traffic goes to th= is non-natural neighbor of the failed node and then goes back over some par= t of the same path before reaching the destination. So these protocol extensions are bringing complexity for no value here. 1. Regarding BSID, I'm not fan of advertising BSIDs in IGP as there may = be hundreds or thousands of BSID on a node which again will create a lot of= burden in IGP. The proposed way will have to be discussed in LSR, not in S= PRING (see next comment). Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work = with BSIDs as long as BSID information of failed node is available in the c= ontrol-plane of PLRs by whatever mechanism. I think this BSID handling is o= rthogonal to the proxy-forwarding controlplane behavior. The forwarding ope= rations for BSID will have to be discussed more in details, we could not ex= pect all HW to be able to do 3 or 4 lookups without any perf degradation. 1. The document is currently a bit borderline between SPRING and LSR as = it talks in good details about IGP protocol extensions. If it's a SPRING do= c, it should detail reqs for protocols but nothing beyond. Brgds, Stephane From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: jeudi 13 janvier 2022 11:19 To: SPRING WG > Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CO1PR05MB8314C64BFB8C342F3174E9BAD52C9CO1PR05MB8314namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruno,

 

Snipped…

  1. draft-ietf-spring-node-protection-for-sr-te-paths

 

“If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forwardi= ng changes should not

   communicated to the forwarding planes on all = configured routers

   (including PLRs for the failed node) until th= e hold-timer expires.”

 

  • It’s not crystal clear to me how it would work in reality, so I = would welcome more prescriptive text. In particular: <= o:p>
    • “node failure” is not an IGP message. IGP nodes sees multi= ple “adjacency loss” messages which are not atomic and could be handled in multiple SPFs. Hence different nodes will freeze their FIB b= ased on a different topology (link1 for some, link2 for others) leading to = inconsistent routing and forwarding loops.

<SH> I will add text to capture this point and = also add detailed text on possible solutions.

 

    • How is the FIB modified in cases of consecutives IGP events? (freezed = on hold topology may lead to drops, updating entries would need to be specified.

<SH> Agreed.

  • On a side node, this text requires a global behavior of all IGP nodes.= That seem a bit out of scope of a non-normative sentence, in an informational document, describing a local behavior on the= PLR.

<SH> I don’t think we need any protocol = extension for solutions described in this document but if  WG thinks i= t should be a standard rather than informational

we should upgrade this document status IMO.

 

Rgds

Shraddha

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, February 2, 2022 6:56 PM
To: slitkows.ietf@gmail.com; 'SPRING WG' <spring@ietf.org>; Hu= zhibo <huzhibo@huawei.com>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

<= span lang=3D"FR" style=3D"font-size:10.5pt;font-family:"Lato",san= s-serif;color:black">[External Email. Be cautious of content]

 

Hi authors of both documents, WG,

 

[Speaking as individual contributor.]

 

It’s good to see technical discussions on the r= estoration of failed SIDs used by SR policy.

 

  1. From a functional point of view, can we summarize the benefit to signa= l the node proxy capability?

e.g.

- drop the traffic earlier if the PLR does not suppor= t proxy capability. (helps with congestion)

- use another proxy off the shortest path (increase c= ongestion but reduce loss)

- possibly help identifying the proxy (nominal is not= in the reachable topology anymore)

…

Or agree on the absence of significant benefits?=

 

  1. draft-ietf-spring-node-protection-for-sr-te-paths

 

“If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forwardi= ng changes should not

   communicated to the forwarding planes on all = configured routers

   (including PLRs for the failed node) until th= e hold-timer expires.”

 

  • It’s not crystal clear to me how it would work in reality, so I = would welcome more prescriptive text. In particular: <= o:p>
    • “node failure” is not an IGP message. IGP nodes sees multi= ple “adjacency loss” messages which are not atomic and could be handled in multiple SPFs. Hence different nodes will freeze their FIB b= ased on a different topology (link1 for some, link2 for others) leading to = inconsistent routing and forwarding loops.
    • How = is the FIB modified in cases of consecutives IGP events? (freezed on hold t= opology may lead to drops, updating entries would need to be specified.
  • On a side node, this text requires a global behavior of all IGP nodes.= That seem a bit out of scope of a non-normative sentence, in an informational document, describing a local behavior on the= PLR.

 

 

  1. draft-hu-spring-segment-routing-proxy-forwarding

Rather than defining a new “Proxy Forwarding= 221; capability in IGP why don’t you use the existing Mirroring Segme= nt (from RFC https://datatracker.ietf.org/doc/html/rfc8402#section-5.1) whose signal= ing is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1<= /span>

 

  1. What about the following solution:
  • Use mirror SID
  • Tunnel to the “proxy-f= orwarding” advertising mirror SID

 

I would see the following benefits:=

  • No new protocol extensions (cf “3)”
    • =
  • Consistent routing in case of multiple SPFs (cf “2)”)=
  • Benefit from the signaling of the proxy (cf “1= )”)

 

Thanks,

Regards,

--Bruno

 

 

Orange Restricted

From: slitkows.ietf@gmail.com <= slitkows.ietf@gmail.com>
Sent: Tuesday, January 25, 2022 6:13 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; 'SPRING WG' <spring@ietf.org>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi,

 

I’m NOT supporting this draft for the followin= g reasons:

 

  1. The WG already have a WG document which is dealing with this problem,= I don’t think that WG should come with multiple documents/solutions = for the same solution space as it may just confuse the industry and create deployment issues as different vendors may= pick different solutions.

 

  1. Adding protocols extensions adds complexity in the solution without a= dding a strong value.

 

The document clai= ms that “[I-D.ietf-spring-segment-protection-sr-te-paths] … may= not work for some cases such as some of nodes in the network not supportin= g this solution.”. While this is true, the proposed solution in draft-hu-spring-segment-routing-proxy-forwarding has exactly t= he same caveat and requires all nodes in the network to support the solutio= n.

 =

Considering the f= ollowing straight line network: A -B -C -D – E – F - G -H and a= n SR policy from A to H using SID_G, routers A to F have to support the ext= ension to make the solution working, if one of the router doesn’t support the extension, traffic will be dropped. =

 =

Then, there is no= value compared to the timer-based solution of [I-D.ietf-spring-segment-pro= tection-sr-te-paths]

 =

Authors of draft-= hu-spring-segment-routing-proxy-forwarding argued that G may have multiple = upstream neighbors let’s say F and F’ and the solution allows f= or F’ to support the extension while F may not support, so the solution will send the traffic to F’. Well yes, but this stil= l requires all routers upstream to F’ to support this extension and m= aybe F is on the path to F’. So, I don’t think the argument is = valid as it may possibly work tactically depending on the network topology when we look at a small portion of the network, but when = we look at the whole network, operator will have to upgrade all their nodes= to support the extension to ensure the benefit is there.

 =

In addition, in t= erm of traffic, forwarding traffic to a neighbor of the failed node which w= asn’t initially on the path, could lead to traffic congestion or high= traffic peaks on links that were not sized to carry this traffic. We could easily expect some traffic tromboning, whe= re traffic goes to this non-natural neighbor of the failed node and then go= es back over some part of the same path before reaching the destination.

 =

So these protocol= extensions are bringing complexity for no value here.

 =

 

  1. Regarding BSID, I’m not fan of advertising BSIDs in IGP as ther= e may be hundreds or thousands of BSID on a node which again will create a = lot of burden in IGP. The proposed way will have to be discussed in LSR, not in SPRING (see next comment).<= /li>

 

Note that [I-D.ietf-spring-segment-protection= -sr-te-paths] could also work with BSIDs as long as BSID information of fai= led node is available in the control-plane of PLRs by whatever mechanism. I= think this BSID handling is orthogonal to the proxy-forwarding controlplane behavior. The forwarding operations f= or BSID will have to be discussed more in details, we could not expect all = HW to be able to do 3 or 4 lookups without any perf degradation.=

 

  1. The document is currently a bit borderline between SPRING and LSR as = it talks in good details about IGP protocol extensions. If it’s a SPR= ING doc, it should detail reqs for protocols but nothing beyond.

 

 

 

Brgds,

 

Stephane

 

 

From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decr= aene@orange.com
Sent: jeudi 13 janvier 2022 11:19
To: SPRING WG <spring@ietf.org= >
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,

 

This message starts a 2 week WG adoption call, ending= 27/01/2022, for draft-hu-spring-segment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-for= warding/

 

After review of the document please indicate support = (or not) for WG adoption of the document to the mailing list.

 

Please also provide comments/reasons for your support= (or lack thereof) as this is a stronger way to indicate your (non) support= as this is not a vote.     

 

If you are willing to work on or review the document,= please state this explicitly. This gives the chairs an indication of the e= nergy level of people in the working group willing to work on the document.

 

Thanks!

Bruno, Jim, Joel

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.
--_000_CO1PR05MB8314C64BFB8C342F3174E9BAD52C9CO1PR05MB8314namp_-- From nobody Sun Feb 6 20:33:44 2022 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 026213A1389 for ; Sun, 6 Feb 2022 20:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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_DNSWL_BLOCKED=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=A8I6vD5o; dkim=pass (1024-bit key) header.d=juniper.net header.b=AqpUSeDp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_bWQl3BdD8a for ; Sun, 6 Feb 2022 20:33:31 -0800 (PST) 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 C134C3A138A for ; Sun, 6 Feb 2022 20:33:29 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 216JtExJ000885; Sun, 6 Feb 2022 20:33:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=4oJ2leoU/JK7GmEFVfOul2Pt4qovQeB5UBy8ZE+Y60I=; b=A8I6vD5oPH5gMBKIYRVpwMa7fu2j3PXEPmU6rReWprJgSjAYCkg9CVcLd5CXNhUrjx89 F3AVsCCkKUcJpsf7SAXK5hsdY0mc4u5jJItzGfOoUUKv7Og9vfpYewUl29ku2ES5IzsA Vt4LQQfVwaGVIvS0yPZrlvWOBSy9jo6WFgTolnt9R79I0YTPjVE5b0OQBsaURQfMaCMF NjkynRb0yYbJpEzf4z+n7gv1nkDt1aiJKeFIAjRsBMxdG9vk24SxwFjm5pN2jlBohLK0 JYUw6Da9l9XCgwV0SoK8boMtoSQkZyITPnIZY0s5xtmzrBET4oOHD8n5+E95rp+ppV39 NQ== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2104.outbound.protection.outlook.com [104.47.55.104]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3e2j6k0prd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 06 Feb 2022 20:33:25 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OLDNY7L9rTkTJ2NYT/umQBoeIP84Ik+t1Q6CeuMK6S8eHIxPpUYnB7YCcaDr9r3CdzjTjfPaRMzCHDB805thqSo5eKIdVP0VPkHBwdig+s8+rk7AySfwo+nY+IDw+Fkzx+JkrCtbkZi1Uuu2TdopjDECrExrnYhp0sJE52Zb1/xsetwfqgxQU/wR5Yn6uoORzsc6l65rTgyNcwX+pgvlG0RlChfEUeMqHvJFf2EMqq042VVtlzMy77EMs04jzKI8L0sqzsHGqaCkr6uFA8Hmg4MPKtdUjKQo/BVYTkVxFCnDXiBPUbgWNOzEIufwou1ic6239wCxB5mKVHTW23Wb6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4oJ2leoU/JK7GmEFVfOul2Pt4qovQeB5UBy8ZE+Y60I=; b=NqqLHPEDljh458/s2JVJDemHSIBD3GY0Nh/CJPeogC1E6h2v974rW9zaa/3IBzGkBNdg3BVLZIlZamH4wXDjI7ovRVEraQXbsKr3JRhBsPsUUsio0Jhll754PsN0kplLK6W3Wxb5V61iFmByZHHXzAT6s/in/bIGQEmMBkHU3ljXDzwp/7jwvXIZVqv+rYwmdd/OuSqjig3AhDO6CW1hBX4XJOrnU44+ZHzhM0xP6MnLo8Yv0+xaaBJ4N6AhqR7J4IL//dDngCObbV44fe3WeegHbqAZGY6vy5z+fIgTohAJa5TSp2aWVBQkfKpKO+UZB2TexiuwXom3qTMnnBsf6Q== 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=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4oJ2leoU/JK7GmEFVfOul2Pt4qovQeB5UBy8ZE+Y60I=; b=AqpUSeDp3akcrg27jpWzJIzGFj10tZksfcE8zzwfnCd9jGPJtlFM4xhjieife4abNznx6k+Boh6+ZdVhHopQ4Dcf5YZy3qmm3mq35jDk4/OKcbARmYzZDaTcuI2KGMe1jXzauFjAJHUH3PyJFNK7hzjGpceiI8CuJMNV6XJoECc= Received: from CO1PR05MB8314.namprd05.prod.outlook.com (2603:10b6:303:fd::13) by BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.9; Mon, 7 Feb 2022 04:33:23 +0000 Received: from CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::857e:c814:a640:6153]) by CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::857e:c814:a640:6153%5]) with mapi id 15.20.4951.014; Mon, 7 Feb 2022 04:33:23 +0000 From: Shraddha Hegde To: Huaimo Chen , "bruno.decraene@orange.com" , 'SPRING WG' Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAJp/J6AAYpjRAAAOTkY6wCvnFrQ Date: Mon, 7 Feb 2022 04:33:22 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <069201d8120e$dff706a0$9fe513e0$@gmail.com> <17040_1643808363_61FA866A_17040_245_14_bd3bfd409e6b45e38519a01045c163c9@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.400.34 dlp-reaction: no-action msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-02T13:26:00Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-02-07T04:32:47Z; 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=70a5057f-c9c3-45d3-b117-6e599bcae5ab; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2022-02-07T04:33: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: 15b12541-4367-4a97-88a2-ca9bdeec3bea msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ccad8da-e07f-457c-0789-08d9e9f2f9cb x-ms-traffictypediagnostic: BY3PR05MB8081:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zLh0E7vHZ/CbiWUu7/9BDn4XgD/hAmGiqGe1nbGzE7NbX3eTWeNgWKyWV11m0ql/Tj5ZV89cLp75w4P6uDHpOcmgdWNF7a4FzekmeU39e0b4om0DjEovTmiTpBGDab+yOJbGh47+uNQgFz9o/ngz6g4RChjh/gjdT87QzTwrbdYtsE3f4JMw1w8vTUZtTlaeeWW3HQa9TxQOGGqvC8yPDgpLW7cag9dSqCyONoKG0FaM4aAWVWEDpA+Jg23q2pcwj2qOTvLDY5H0myDdkwjtZjCrL0Yh7/KSpT1bx4lWoQZTH2rbGqFg/Q2x67kQVCrbUvwKkqS/6s0Qka4oRvNw8WadRrdh48Sf3WckdE88/+FX3EzcfkPBeWWuIOR2AtddrxaAvRc1q3DshAkOtXXSfZnica338iZJv19w3kEv4C4yX69EDLVwREGi1BlXfvYjEbdFESD8ZdA+XeKItWq9qq1E8Qp6dlWB1J9LmXjn2Z9QAyhGJyGd6TEWUAc4mI7CyHZS1FYiRmuRaq6Ilu4BEUwV736yMV+QP/39AJs61xS/R4c7ebIW3SaFbK5zRlYcOS85jhJgvG5H48wtLd7BGSe/a7jKLwmjnTLvmehY6lWHnIRRZUVslvWqsaKk7Xc72aGIU5W0PzaTBJB2OmJSpuqWGmBrxQNHJMV2zJgv7u604Xt0ELZVdIPz9iu3dpmr2qunoH1qG0yjZ9jDa93rNWgNmVjNMeFtXIllrinWtNh6Z92SuWWy8XDRKoJL6fbuNH+9fFmFznEUengTN9JVVd26nZKt3UG+trdh1Ar4fE6NuuzK3sGe9cyHFPIXfZdE9kT+0S3YP+qqgPuW6zPwq6HFMp8m3cZFCYkp9ZRsfZvDjIqU/EeMqDWKEDhTPM2m x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR05MB8314.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66476007)(66556008)(5660300002)(8676002)(71200400001)(66446008)(508600001)(8936002)(30864003)(6506007)(7696005)(53546011)(33656002)(316002)(66946007)(76116006)(55016003)(2906002)(86362001)(52536014)(64756008)(38100700002)(966005)(110136005)(186003)(26005)(9686003)(166002)(38070700005)(66574015)(83380400001)(122000001)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?hyhJeBN3oFbwJMT2qsjt2KYSFEGRWrFB3r+9XlETPQb9JeDJ+9tlt+T6YDbF?= =?us-ascii?Q?miPmTwrUDGwAsvnSeQM9VSCHizpJVD7PEOyoKY4POnej4PzrffeX7iYwe27L?= =?us-ascii?Q?cOB0igsVl4qepjgQrPTCllSjWg3Oqd8m+4j2j685IKc3JOBa/GOO0YhR2Y5C?= =?us-ascii?Q?zaN5JB72udZBbwJ2r+PetnHEBOMciAlWGXFu/eIV7oBt2zKDwxHRzJZGaiaj?= =?us-ascii?Q?sYkR/SQiSNrdB8P9myTPwTYaeeCRL9zt+xo7gJGjBbInP5ZHN/vS854+wIMW?= =?us-ascii?Q?PoLc2731OTG4mBnu+YrFCdaPSxnqH7glTUOQY8EbeSp6d02di+RaRPQjEFNt?= =?us-ascii?Q?wTYN49kqRSZsMwh80zVtfZprLZAmuQ8sh+2MUyWTBmR7kFh9AvETAFINe9C9?= =?us-ascii?Q?r9WML/cGTWjWQ0R5LTNiEgEvUg/OnLbGlWme84Zm30fAVaSLUr/E39sbCyzw?= =?us-ascii?Q?DF8RIl1QIgqbfgb6djUSEXhCEMfJbXQafEc3m5zY6ZhAn5A64qEYVOqEtM5R?= =?us-ascii?Q?17x8VA+yVG7I6axN1WtvcYafNrvOKpxjwM9YarlTA50nDziFrbXQdyiP5N+x?= =?us-ascii?Q?dtaANz7gLwaRxizprC5h1Xulz5Iv/YO1Y/44xt76L3oax/EczKudDStdF4tK?= =?us-ascii?Q?4JSLj1fTHP6UEhlitntxpOCzsVBpCcRde2J6WHoHoqn+zwjQ1LbVfxrV8YeU?= =?us-ascii?Q?DCQfO3YoC7SUBeEg+u4fsUqjGORemouODl27k6YlFlnO8bD7RpEowCKosihV?= =?us-ascii?Q?Q+lG4qycfIumVAnuo/nG4ad0DPEZA6MIkM4VpRsnGlofmK4g2p+7u7BrKVSw?= =?us-ascii?Q?wkY+JzJs2bHacqDq8CpvTF/k7dJXitbLFXXqa5KlEWEzGrOuqEeg5y1biw7y?= =?us-ascii?Q?Ye7J51UqRPl3145mS5n0XFTW6ObW/DEE/yKYhWePJoyhwpfTTfWwL+5EzTLC?= =?us-ascii?Q?JIGxDSceyI8WdBa8e5Ond/s7xpvXDhJtvqMOf0N+iVyu8PS3B2k1rXyRz9Yo?= =?us-ascii?Q?Bn1XqrLCoR/dug7gl5cyu6jFPHH7V/OVsP7gxIToAJPgXxkEJeEYH1mhlx1Y?= =?us-ascii?Q?WUlyiu9dBevKrOB1pvV3WMITLo3j5ZJuX6F8qS9g4swv69ZOXYea5Q/S2l7D?= =?us-ascii?Q?Ou+JtfK1lAo5Aohx+PDQMmXuRaxDSY0P3BE/fPVh8XF7OkiqzM0zWrJC3Ilt?= =?us-ascii?Q?GyGDfute2RtVDz3iOjHIDNpOUVM9XDFRS9PnS/VUTe3Baqpe/iAdF1aQINAN?= =?us-ascii?Q?ykL769podd2F40VQZZxHSzgmhdFsfDBRoHYm6hPoFdZ7ioWqsaruk4U36u03?= =?us-ascii?Q?FoTpIsLuMCWwukouTewmQ/oW82nnGxA+uuBoP1Io/Bx2RG1az9Gm66bBiABZ?= =?us-ascii?Q?Ec2RHOPs/1kMXq0jAk0RyiZa7SMBerx3Z9ofSZ+jtij0Pyx65VH5u4UmEqBG?= =?us-ascii?Q?zYXg+y6IpmiZgHoqkydD1Cow2CMkwoGr1FaFMAYzfz7Q2aVN6RCyMzhK5nOi?= =?us-ascii?Q?h65pyEUTJ0L65gcCsYt4yexiHtPyivpTtYj1JbDxDDp7iV9LqL8xnmwzOeZ5?= =?us-ascii?Q?Ej22dFchu3AsXszD7VePiN8Ih3t1gAy3VEKYy+EpftwsCDVdZubKFYQIIWRC?= =?us-ascii?Q?uYx1mmX5BktAuicEBvpN1j0=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR05MB8314EFFE41B64D7D1CF37ACDD52C9CO1PR05MB8314namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR05MB8314.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ccad8da-e07f-457c-0789-08d9e9f2f9cb X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2022 04:33:22.9951 (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: HHGFiFxbSS295r2G6TDHl0haCR5kuK+gZEa/s4himpG/lbYhNN5Um+yZXycBh6bA3wZH9PmGKah1CI4P0E50Wg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR05MB8081 X-Proofpoint-ORIG-GUID: Tn3mw7tqmFyIG1Ewi4JOMDr-p1lLoyVB X-Proofpoint-GUID: Tn3mw7tqmFyIG1Ewi4JOMDr-p1lLoyVB X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-07_01,2022-02-03_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 suspectscore=0 clxscore=1015 spamscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202070027 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 07 Feb 2022 04:33:42 -0000 --_000_CO1PR05MB8314EFFE41B64D7D1CF37ACDD52C9CO1PR05MB8314namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. draft-ietf-spring-node-protection-for-sr-te-paths "If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires." * It's not crystal clear to me how it would work in reality, so I would= welcome more prescriptive text. In particular: * "node failure" is not an IGP message. IGP nodes sees multiple "adj= acency loss" messages which are not atomic and could be handled in multiple= SPFs. Hence different nodes will freeze their FIB based on a different top= ology (link1 for some, link2 for others) leading to inconsistent routing an= d forwarding loops. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. [HC]: In addition to the above, it seems better to describe procedures about link/node up and down events regarding to FIB entries such as those being held off (not to be changed) during the period from HoldTimer start to end. For example, after a node is down, some FIB entries are held off (not to be changed), then the node is up, but some of its links are up and the other links are still down (maybe for a long time). How to handle the FIB entries (hold off or change) in this case? Good point. Will add more details in the next revision. Juniper Business Use Only From: spring On Behalf Of Huaimo Chen Sent: Thursday, February 3, 2022 10:35 PM To: bruno.decraene@orange.com; 'SPRING WG' Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding [External Email. Be cautious of content] Hi Bruno, Thank you very much for your valuable comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: spring > on b= ehalf of bruno.decraene@orange.com > Sent: Wednesday, February 2, 2022 8:26 AM To: slitkows.ietf@gmail.com >; 'SPRING WG' >; Huzhibo > Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi authors of both documents, WG, [Speaking as individual contributor.] It's good to see technical discussions on the restoration of failed SIDs us= ed by SR policy. 1. From a functional point of view, can we summarize the benefit to sign= al the node proxy capability? e.g. - drop the traffic earlier if the PLR does not support proxy capability. (h= elps with congestion) [HC]: When the PLR supports proxy capability, it provides protection for the failure of its adjacent node with BSIDs. The BSIDs are protected. When the PLR does not support proxy capability, it provides protection for the failure of its adjacent node, but the BSIDs on the node are not protected. - use another proxy off the shortest path (increase congestion but reduce l= oss) [HC]: When there is a node on the shortest path not supporting proxy, another proxy capable node off the shortest path to a neighbor of the faile= d node is used. The traffic is sent to the neighbor, which re-routes the traf= fic around the failed node towards the destination. The traffic is protected. In fact, the failed node is a loose hop on the SR path with the SID of the = node. >From a upstream node to the failed node, there are a few hops in general. When any of these hops fails, the traffic will be re-routed around the failure. This should be considered by the controller that computes the SR path. This should not increase congestion. Using proxy capable node off the shortest path to a neighbor of the failed node to some extend should not increase congestion. Using another proxy capable node off the shortest path reduces traffic loss and should not increase congestion to some extend. - possibly help identifying the proxy (nominal is not in the reachable topo= logy anymore) [HC]: When a node failed and becomes unreachable, it helps identifying the proxy capable path to a neighbor of the failed node. ... Or agree on the absence of significant benefits? [HC]: It provides more protection coverage in some cases as compared to the other existing draft. This improves the reliability of networks, and QoE. This should be a significant benefit. In addition, when a node fails, the nodes of the entire network converge to the latest state consistently in time. After a node failed, comparing to the other existing draft regarding to holding off the FIB during the HoldTimer period, when the network changes again, our solution continues to converge at any time. 1. draft-ietf-spring-node-protection-for-sr-te-paths "If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires." * It's not crystal clear to me how it would work in reality, so I would= welcome more prescriptive text. In particular: * "node failure" is not an IGP message. IGP nodes sees multiple "adj= acency loss" messages which are not atomic and could be handled in multiple= SPFs. Hence different nodes will freeze their FIB based on a different top= ology (link1 for some, link2 for others) leading to inconsistent routing an= d forwarding loops. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. [HC]: In addition to the above, it seems better to describe procedures about link/node up and down events regarding to FIB entries such as those being held off (not to be changed) during the period from HoldTimer start to end. For example, after a node is down, some FIB entries are held off (not to be changed), then the node is up, but some of its links are up and the other links are still down (maybe for a long time). How to handle the FIB entries (hold off or change) in this case? 1. draft-hu-spring-segment-routing-proxy-forwarding Rather than defining a new "Proxy Forwarding" capability in IGP why don't y= ou use the existing Mirroring Segment (from RFC https://datatracker.ietf.or= g/doc/html/rfc8402#section-5.1) whose signaling is already standardized? https://datatracker.ietf.o= rg/doc/html/rfc8667#section-2.4.1 [HC]: "Proxy Forwarding" capability of a node may be alternatively indicated by the mirror SIDs advertised by the node. Mirror SID for a failed node can be used as context to forward the traffic with the SID of the failed node to the next hop of the failed node. A node advertises a mirror SID for each of its neighbor nodes. When a node failed, its node SID is not reachable. A remote node of the failed node sends the traffic with the SID of the failed node to a neighbor of the failed node. The neighbor sends (i.e., re-route) the traffic to the next hop of the failed node when the neighbor advertises the mirror SID for the failed node. When the neighbor does not advertise the mirror SID for the failed node, it pushes the mirror SID advertised by another neighbor (say AN) and sends the traffic to AN. AN pops its mirror SID as context and uses the SID of the failed node to re-route the traffic to the next hop of the failed node. 1. What about the following solution: * Use mirror SID * Tunnel to the "proxy-forwarding" advertising mirror SID [HC]: If tunnels are used, there may be tunnels from each of the remote nodes to each of the neighbors of a failed node. This may use some network resources. It seems that tunnels may be replaced by the shortest path to the neighbor along the nodes advertising mirror SIDs. I would see the following benefits: * No new protocol extensions (cf "3)" * Consistent routing in case of multiple SPFs (cf "2)") * Benefit from the signaling of the proxy (cf "1)") [HC]: We can see these. Thanks, Regards, --Bruno Orange Restricted From: slitkows.ietf@gmail.com > Sent: Tuesday, January 25, 2022 6:13 PM To: DECRAENE Bruno INNOV/NET >; 'SPRING WG' > Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi, I'm NOT supporting this draft for the following reasons: 1. The WG already have a WG document which is dealing with this problem,= I don't think that WG should come with multiple documents/solutions for th= e same solution space as it may just confuse the industry and create deploy= ment issues as different vendors may pick different solutions. 1. Adding protocols extensions adds complexity in the solution without a= dding a strong value. The document claims that "[I-D.ietf-spring-segment-protection-sr-te-paths] = ... may not work for some cases such as some of nodes in the network not su= pporting this solution.". While this is true, the proposed solution in draf= t-hu-spring-segment-routing-proxy-forwarding has exactly the same caveat an= d requires all nodes in the network to support the solution. Considering the following straight line network: A -B -C -D - E - F - G -H = and an SR policy from A to H using SID_G, routers A to F have to support th= e extension to make the solution working, if one of the router doesn't supp= ort the extension, traffic will be dropped. Then, there is no value compared to the timer-based solution of [I-D.ietf-s= pring-segment-protection-sr-te-paths] Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G m= ay have multiple upstream neighbors let's say F and F' and the solution all= ows for F' to support the extension while F may not support, so the solutio= n will send the traffic to F'. Well yes, but this still requires all router= s upstream to F' to support this extension and maybe F is on the path to F'= . So, I don't think the argument is valid as it may possibly work tacticall= y depending on the network topology when we look at a small portion of the = network, but when we look at the whole network, operator will have to upgra= de all their nodes to support the extension to ensure the benefit is there. In addition, in term of traffic, forwarding traffic to a neighbor of the fa= iled node which wasn't initially on the path, could lead to traffic congest= ion or high traffic peaks on links that were not sized to carry this traffi= c. We could easily expect some traffic tromboning, where traffic goes to th= is non-natural neighbor of the failed node and then goes back over some par= t of the same path before reaching the destination. So these protocol extensions are bringing complexity for no value here. 1. Regarding BSID, I'm not fan of advertising BSIDs in IGP as there may = be hundreds or thousands of BSID on a node which again will create a lot of= burden in IGP. The proposed way will have to be discussed in LSR, not in S= PRING (see next comment). Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work = with BSIDs as long as BSID information of failed node is available in the c= ontrol-plane of PLRs by whatever mechanism. I think this BSID handling is o= rthogonal to the proxy-forwarding controlplane behavior. The forwarding ope= rations for BSID will have to be discussed more in details, we could not ex= pect all HW to be able to do 3 or 4 lookups without any perf degradation. 1. The document is currently a bit borderline between SPRING and LSR as = it talks in good details about IGP protocol extensions. If it's a SPRING do= c, it should detail reqs for protocols but nothing beyond. Brgds, Stephane From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: jeudi 13 janvier 2022 11:19 To: SPRING WG > Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CO1PR05MB8314EFFE41B64D7D1CF37ACDD52C9CO1PR05MB8314namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
  1. draft-ietf= -spring-node-protection-for-sr-te-paths=

 

“If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forward= ing changes should not

   communicated to the forwarding planes on all= configured routers

   (including PLRs for the failed node) until t= he hold-timer expires.”

 

  • It’s= not crystal clear to me how it would work in reality, so I would welcome m= ore prescriptive text. In particular:
    • “nod= e failure” is not an IGP message. IGP nodes sees multiple “adja= cency loss” messages which are not atomic and could be handled in multiple SPFs. Hence different nodes will freeze their FIB based on a diff= erent topology (link1 for some, link2 for others) leading to inconsistent r= outing and forwarding loops.
    • How is th= e FIB modified in cases of consecutives IGP events? (freezed on hold topolo= gy may lead to drops, updating entries would need to be specified.
  • On a side = node, this text requires a global behavior of all IGP nodes. That seem a bi= t out of scope of a non-normative sentence, in an informational document, describing a local behavior on the PLR.

 [HC]: In addition to the above, it seems better to describe procedure= s

about link/node up and down events regarding to FIB e= ntries such as

those being held off (not to be changed) during the p= eriod from

HoldTimer start to end. For example, after a node is = down, some FIB

entries are held off (not to be changed), then the no= de is up, but

some of its links are up and the other links are stil= l down (maybe

for a long time). How to handle the FIB entries (hold= off or change)

in this case?

<SH> Good point. Will add more details in the = next revision.

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of Huaimo Chen
Sent: Thursday, February 3, 2022 10:35 PM
To: bruno.decraene@orange.com; 'SPRING WG' <spring@ietf.org> Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

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

 

Hi Brun= o,

&n= bsp;

  =   Thank you very much for your valuable comments.

&n= bsp;

  =   My responses/explanations are inline below with [HC].

&n= bsp;

Best Re= gards,

Huaimo =

on beha= lf of co-authors

&n= bsp;

&n= bsp;

From: spring <spring-bounces@ietf.org> on behalf of bruno.decraene@orange.com = <bruno.decraene@orange.com<= /a>>
Sent: Wednesday, February 2, 2022 8:26 AM
To: slitkows.ietf@gmail.c= om <slitkows.ietf@gmail.c= om>; 'SPRING WG' <spring@ietf.= org>; Huzhibo <huzhibo@huaw= ei.com>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi authors of both documents, WG,

 

[Speaking as individual contributor.]

 

It’s good to see technical discussions on the = restoration of failed SIDs used by SR policy.=

 

  1. From a fun= ctional point of view, can we summarize the benefit to signal the node prox= y capability?

e.g.

- drop the traffic earlier if the PLR does not suppo= rt proxy capability. (helps with congestion)<= /o:p>

[HC]: When the PLR supports proxy capability, it pro= vides protection

for the failure of its adjacent node with BSIDs. The = BSIDs are protected.

When the PLR does not support proxy capability, it pr= ovides protection

for the failure of its adjacent node, but the BSIDs o= n the node are

not protected.

- use another proxy off the shortest path (increase = congestion but reduce loss)

[HC]: When there is a node on the shortest path not = supporting proxy,

another proxy capable node off the shortest path to a= neighbor of the failed

node is used. The traffic is sent to the neighbor, wh= ich re-routes the traffic

around the failed node towards the destination. The t= raffic is protected.

In fact, the failed node is a loose hop on the SR pat= h with the SID of the node.

From a upstream node to the failed node, there are a = few hops in general.

When any of these hops fails, the traffic will be re-= routed around

the failure. This should be considered by the control= ler that computes

the SR path. This should not increase congestion.

Using proxy capable node off the shortest path to a n= eighbor of the failed

node to some extend should not increase congestion.

Using another proxy capable node off the shortest pat= h reduces traffic

loss and should not increase congestion to some exten= d.

- possibly help identifying the proxy (nominal is no= t in the reachable topology anymore)

[HC]: When a node failed and becomes unreachable, it= helps identifying
the proxy capable path to a neighbor of the failed node.

…

Or agree on the absence of significant benefits?

[HC]: It provides more protection coverage in some c= ases as compared to

the other existing draft. This improves the reliabili= ty of networks,

and QoE. This should be a significant benefit.

In addition, when a node fails, the nodes of the enti= re network converge

to the latest state consistently in time.

After a node failed, comparing to the other existing = draft regarding to

holding off the FIB during the HoldTimer period,

when the network changes again, our solution continue= s to converge

at any time.

 

  1. draft-ietf= -spring-node-protection-for-sr-te-paths=

 

“If the Node-SID or Prefix-SID becomes

   unreachable, the event and resulting forward= ing changes should not

   communicated to the forwarding planes on all= configured routers

   (including PLRs for the failed node) until t= he hold-timer expires.”

 

  • It’s= not crystal clear to me how it would work in reality, so I would welcome m= ore prescriptive text. In particular:
    • “nod= e failure” is not an IGP message. IGP nodes sees multiple “adja= cency loss” messages which are not atomic and could be handled in multiple SPFs. Hence different nodes will freeze their FIB based on a diff= erent topology (link1 for some, link2 for others) leading to inconsistent r= outing and forwarding loops.
    • How is th= e FIB modified in cases of consecutives IGP events? (freezed on hold topolo= gy may lead to drops, updating entries would need to be specified.
  • On a side = node, this text requires a global behavior of all IGP nodes. That seem a bi= t out of scope of a non-normative sentence, in an informational document, describing a local behavior on the PLR.

 [HC]: In addition to the above, it seems better to describe procedure= s

about link/node up and down events regarding to FIB e= ntries such as

those being held off (not to be changed) during the p= eriod from

HoldTimer start to end. For example, after a node is = down, some FIB

entries are held off (not to be changed), then the no= de is up, but

some of its links are up and the other links are stil= l down (maybe

for a long time). How to handle the FIB entries (hold= off or change)

in this case?

 

  1. draft-hu-s= pring-segment-routing-proxy-forwarding<= /span>

Rather than defining a new “Proxy Forwarding&#= 8221; capability in IGP why don’t you use the existing Mirroring Segm= ent (from RFC https://datatracker.ietf.org/doc/html/rfc8402#section-5.1) whose signal= ing is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1

 [HC]: “Proxy Forwarding” capabilit= y of a node may be alternatively

indicated by the mirror SIDs advertised by the node.<= o:p>

Mirror SID for a failed node can be used as context t= o forward

the traffic with the SID of the failed node to the ne= xt hop of the

failed node. A node advertises a mirror SID for each = of its neighbor

nodes. When a node failed, its node SID is not reacha= ble.

A remote node of the failed node sends the traffic wi= th the SID of

the failed node to a neighbor of the failed node.

The neighbor sends (i.e., re-route) the traffic to th= e next hop of

the failed node when the neighbor advertises the mirr= or SID for the

failed node. When the neighbor does not advertise the= mirror SID for

the failed node, it pushes the mirror SID advertised = by another

neighbor (say AN) and sends the traffic to AN. AN pop= s its mirror SID

as context and uses the SID of the failed node to re-= route the

traffic to the next hop of the failed node.

 

  1. What about= the following solution:
    • Use mirro= r SID
    • Tunnel to the “proxy-forw= arding” advertising mirror SID

    [HC]: If tunnels are used, there may be tunnels from= each of the

    remote nodes to each of the neighbors of a failed nod= e. This may

    use some network resources. It seems that tunnels may= be replaced

    by the shortest path to the neighbor along the nodes = advertising

    mirror SIDs.

     

    I would see the following benefits:

    • No new pro= tocol extensions (cf “3)”
    • = Consistent routing in case of multiple SPFs (cf “2)”)
    • Benefit from the signaling of the proxy (cf = 220;1)”)

     [HC]: We can see thes= e.

 

Thanks,

Regards,<= /p>

--Bruno

 

 

Orange Restricted

From: slitkows.ietf@gmail.com <= slitkows.ietf@gmail.com>
Sent: Tuesday, January 25, 2022 6:13 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; 'SPRING WG' <spring@ietf.org>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi,

 

I’m NOT supporting this draft for the followi= ng reasons:

 

  1. The WG al= ready have a WG document which is dealing with this problem, I don’t = think that WG should come with multiple documents/solutions for the same so= lution space as it may just confuse the industry and create deployment issues as different vendors may pick different solut= ions.

 

  1. Adding p= rotocols extensions adds complexity in the solution without adding a strong= value.

 

The document cla= ims that “[I-D.ietf-spring-segment-protection-sr-te-paths] … ma= y not work for some cases such as some of nodes in the network not supporti= ng this solution.”. While this is true, the proposed solution in draft-hu-spring-segment-routing-proxy-forwarding has exactly t= he same caveat and requires all nodes in the network to support the solutio= n.

 

Considering the = following straight line network: A -B -C -D – E – F - G -H and = an SR policy from A to H using SID_G, routers A to F have to support the ex= tension to make the solution working, if one of the router doesn’t support the extension, traffic will be dropped. <= span lang=3D"FR">

 

Then, there is n= o value compared to the timer-based solution of [I-D.ietf-spring-segment-pr= otection-sr-te-paths]

 

Authors of draft= -hu-spring-segment-routing-proxy-forwarding argued that G may have multiple= upstream neighbors let’s say F and F’ and the solution allows = for F’ to support the extension while F may not support, so the solution will send the traffic to F’. Well yes, but = this still requires all routers upstream to F’ to support this extens= ion and maybe F is on the path to F’. So, I don’t think the arg= ument is valid as it may possibly work tactically depending on the network topology when we look at a small portion of the network, bu= t when we look at the whole network, operator will have to upgrade all thei= r nodes to support the extension to ensure the benefit is there.

 

In addition, in = term of traffic, forwarding traffic to a neighbor of the failed node which = wasn’t initially on the path, could lead to traffic congestion or hig= h traffic peaks on links that were not sized to carry this traffic. We could easily expect some traffic tromboning, whe= re traffic goes to this non-natural neighbor of the failed node and then go= es back over some part of the same path before reaching the destination.

 

So these protoco= l extensions are bringing complexity for no value here.

 

 

  1. Regardi= ng BSID, I’m not fan of advertising BSIDs in IGP as there may be hund= reds or thousands of BSID on a node which again will create a lot of burden= in IGP. The proposed way will have to be discussed in LSR, not in SPRING (see next comment).=

 

Note that [I-D.ie= tf-spring-segment-protection-sr-te-paths] could also work with BSIDs as lon= g as BSID information of failed node is available in the control-plane of P= LRs by whatever mechanism. I think this BSID handling is orthogonal to the proxy-forwarding controlplane behavior.= The forwarding operations for BSID will have to be discussed more in detai= ls, we could not expect all HW to be able to do 3 or 4 lookups without any = perf degradation.

 

  1. The docu= ment is currently a bit borderline between SPRING and LSR as it talks in go= od details about IGP protocol extensions. If it’s a SPRING doc, it sh= ould detail reqs for protocols but nothing beyond.

 

 

 

Brgds,

 

Stephane

 

 

From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decr= aene@orange.com
Sent: jeudi 13 janvier 2022 11:19
To: SPRING WG <spring@ietf.org= >
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,<= /p>

 

This message starts a 2 week WG adoption call, endin= g 27/01/2022, for draft-hu-spring-segment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/d= raft-hu-spring-segment-routing-proxy-forwarding/

 

After review of the document please indicate support= (or not) for WG adoption of the document to the mailing list.

 

Please also provide comments/reasons for your suppor= t (or lack thereof) as this is a stronger way to indicate your (non) suppor= t as this is not a vote.     

 

If you are willing to work on or review the document= , please state this explicitly. This gives the chairs an indication of the = energy level of people in the working group willing to work on the document.

 

Thanks!

Bruno, Jim, Joel

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


____________________________________________________=
_____________________________________________________________________<=
/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_CO1PR05MB8314EFFE41B64D7D1CF37ACDD52C9CO1PR05MB8314namp_-- From nobody Mon Feb 7 01:42:50 2022 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 0AAB93A0A62 for ; Mon, 7 Feb 2022 01:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=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 48vn8k-hXFhh for ; Mon, 7 Feb 2022 01:42:38 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692033A0A55 for ; Mon, 7 Feb 2022 01:42:38 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Jsh582TDpz8PxDZ for ; Mon, 7 Feb 2022 17:42:36 +0800 (CST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4Jsh4Y3759z7qq0l; Mon, 7 Feb 2022 17:42:05 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id 2179feAY046885; Mon, 7 Feb 2022 17:41:40 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn) Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Mon, 7 Feb 2022 17:41:40 +0800 (CST) Date: Mon, 7 Feb 2022 17:41:40 +0800 (CST) X-Zmail-TransId: 2afc6200e9540b0fa529 X-Mailer: Zmail v1.0 Message-ID: <202202071741403841025@zte.com.cn> In-Reply-To: References: 164223793434.20409.9148647733388794281@ietfa.amsl.com, ZRAP278MB017654891F056AEF03D3B0C289559@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM, 202201201722410433187@zte.com.cn, ZRAP278MB0176B7C7CAED15D977AC0EBE895C9@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM, 202201251727190560534@zte.com.cn, ZRAP278MB017675ADFDABEBC49D9BF02D89249@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM Mime-Version: 1.0 From: To: Cc: Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl2.zte.com.cn 2179feAY046885 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 6200E98C.000 by FangMail milter! X-FangMail-Envelope: 1644226956/4Jsh582TDpz8PxDZ/6200E98C.000/192.168.251.13/[192.168.251.13]/mxct.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 6200E98C.000/4Jsh582TDpz8PxDZ Archived-At: Subject: Re: [spring] =?utf-8?q?New_Version_Notification_for_draft-tgraf-opsa?= =?utf-8?q?wg-ipfix-srv6-srh-00=2Etxt?= 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, 07 Feb 2022 09:42:48 -0000 Hi Thomas, Sorry for the late reply. Please see inline [Yao2]. > [Yao] Segments left is one of the elements to identify an SRH. For example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also useful when exporting SRv6 information. Would you agree that ipv6SRHSegmentList at node egress would be equal to Segments left? Or in other words segments left would only differ at ingress to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would you please describe me what kind of use case you have in mind. [Yao2] I mean without segment left, it's difficult to distinguish between packets of the same segment list in some cases. Below is one scenario I can think of. The corresponding segment list of path 1--A--2--3--1--A--4 is . 3 / \ / \ 1 2 \ / \ / A-----4 The flow passes node A twice. The first time, the packet is (SA,DA=SID-A). The second time, the packet is (SA,DA=SID-A). If one wants to collect the info of these two traffic separately, the segment left element is needed. But to be honest, I'm not sure whether this requirement is strong. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined. What if the user want to export the SRH TLV info of the packets? You mean the entire SRH header without disassemble the dimensions into IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes a lot of sense and I consider this to the -01 version of the document. [Yao2] Yes, that's what I mean. Best Regards, Yao ------------------原始邮件------------------ å‘件人：Thomas.Graf@swisscom.com 收件人：刘尧00165286; 抄é€äººï¼šspring@ietf.org; æ—¥ 期 ：2022å¹´01月30æ—¥ 14:17 主 题 ：Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Yao Thanks a lot for your input. > [Yao] Segments left is one of the elements to identify an SRH. For example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also useful when exporting SRv6 information. Would you agree that ipv6SRHSegmentList at node egress would be equal to Segments left? Or in other words segments left would only differ at ingress to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would you please describe me what kind of use case you have in mind. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined. What if the user want to export the SRH TLV info of the packets? You mean the entire SRH header without disassemble the dimensions into IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes a lot of sense and I consider this to the -01 version of the document. Looking forward to your clarifications. Best wishes Thomas -----Original Message----- From: liu.yao71@zte.com.cn Sent: Tuesday, January 25, 2022 10:27 AM To: Graf Thomas, INI-NET-TCZ-ZH1 Cc: spring@ietf.org Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, Please see inline [Yao]. Best Regards, Yao ------------------原始邮件------------------ å‘件人：Thomas.Graf@swisscom.com 收件人：刘尧00165286; 抄é€äººï¼šspring@ietf.org; æ—¥ 期 ：2022å¹´01月23æ—¥ 01:16 主 题 ：Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Yao, Many thanks for the review and feedback. > 1) But this draft describes the routing protocol where the last SRv6 segment has been learned from, instead of the SRv6 segment to be processed by the current hop. I am going to rephrase the sentences to refer to the active segment. Which should make it less ambiguous. > 2) but in SRv6, segment list and segments left(currently not defined in the draft) are both needed to provide the similar information. Could you elaborate the use case for segments left in this context. This document covers all dimensions being present in the SRv6 segment routing header described in section of RFC8754 (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8754%23section-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pTL80QujKtnQbO4768IYqYtLOQ9ntmd3MGKwNmdmL68%3D&reserved=0) with the exception of "Last Entry". [Yao] Segments left is one of the elements to identify an SRH. For example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also useful when exporting SRv6 information. > 3) Element for SRH TLV is not defined in the draft, what's the consideration about that? Could you elaborate further please. The document refers to RFC 8754 where the SRH TLV is being described. [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined. What if the user want to export the SRH TLV info of the packets? Best wishes Thomas -----Original Message----- From: liu.yao71@zte.com.cn Sent: Thursday, January 20, 2022 10:23 AM To: Graf Thomas, INI-NET-TCZ-ZH1 Cc: spring@ietf.org Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, I've read the draft and have some questions. 1) RFC 9160 introduces new protocol types for SR-MPLS top label. Considering that the MPLS top label is always the label to be processed, the user can know which protocol the SR-MPLS SID to be processed is learned from. But this draft describes the routing protocol where the last SRv6 segment has been learned from, instead of the SRv6 segment to be processed by the current hop. As for my understanding, the current draft is inconsistent with RFC 9160 in this aspect. 2) Related to point 1，in SR-MPLS, exporting the top label can provide the information of the segment to be processed, but in SRv6, segment list and segments left(currently not defined in the draft) are both needed to provide the similar information. 2) Element for SRH TLV is not defined in the draft, what's the consideration about that? Best Regards, Yao ------------------原始邮件------------------ å‘件人：Thomas.Graf@swisscom.com 收件人：spring@ietf.org; æ—¥ 期 ：2022å¹´01月15æ—¥ 17:27 主 题 ：[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Dear SPRING working group, Following up on just released RFC 9160 (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9160&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3ddjRtYSBRRhYWL%2BvNSQgfXMyVgo4Cf2MePjS9vACuA%3D&reserved=0), IPFIX code points for MPLS Segment Routing, https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4zkY3wyX8iuYLYOdIGqpXMimh6ndTv3rT5au5jbjjnc%3D&reserved=0 has been submitted for the SRV6 data-plane. The document aims to be on par with MPLS-SR. Describe the routing protocol or PCEP extension where the last SRv6 segment has been learned from, the SRv6 segment list and all other properties from the Segment Routing header. I would appreciate your document review and feedback. I aim to present at IETF 113 at OPSAWG and SPRING and request adoption at OPSAWG. Best wishes Thomas -----Original Message----- From: internet-drafts@ietf.org Sent: Saturday, January 15, 2022 10:12 AM To: Graf Thomas, INI-NET-TCZ-ZH1 Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-00.txt has been successfully submitted by Thomas Graf and posted to the IETF repository. Name: draft-tgraf-opsawg-ipfix-srv6-srh Revision: 00 Title: Export of Segment Routing IPv6 Information in IP Flow Information Export (IPFIX) Document date: 2022-01-15 Group: Individual Submission Pages: 9 URL: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-00.txt&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rH4778Kz%2BBppjs7H8r4pReWqB1wu6amfhgAxCwXFBTA%3D&reserved=0 Status: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CtVBGFg0phEAf9omIt7w%2BVzS5YtFu9mKIua9Gyc6W2c%3D&reserved=0 Htmlized: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4zkY3wyX8iuYLYOdIGqpXMimh6ndTv3rT5au5jbjjnc%3D&reserved=0 Abstract: This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded with which Segemnt Routing Header dimensions based on which SRv6 control plane protocol. The IETF Secretariat _______________________________________________ spring mailing list spring@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=H5DssKNneFtZ21DLI6%2FvX8muGs86a09FS2Aps0HYLpI%3D&reserved=0 _______________________________________________ spring mailing list spring@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C14c186c508634e952ba108d9dfe4eead%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637786996622388083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=H5DssKNneFtZ21DLI6%2FvX8muGs86a09FS2Aps0HYLpI%3D&reserved=0 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Tue Feb 8 03:01:36 2022 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 2CF033A0C69; Tue, 8 Feb 2022 03:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aeaWXA63mdn; Tue, 8 Feb 2022 03:01:29 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 AFD0E3A0C06; Tue, 8 Feb 2022 03:01:28 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr26.francetelecom.fr (ESMTP service) with ESMTPS id 4JtKnf1gjQzycn; Tue, 8 Feb 2022 12:01:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1644318086; bh=elEd0i5VzrHcslFIn1Sizo+WPD8J0kqIADcpEMB3CzU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=O5gj46nMDlpex22u7PBsXhglQC1C3pqxA4hJmgDsi7Cvp3J9XFUALBdRNrOweXT2C vnZu+ifLWl5S8FND9cNsj/xIIJfWkD0n2teX5sI0z0bg81q/hFLykL8T3j9HcxLqT/ peH8HvDHh7A8H2zKXi7bderBpQ0LpanVOiRSKzmm5HOCktQIV/GlZ5Ot34P4L6prgo j99xdwftVcGvf77IELQXB1zR+6IfrWjM2TM+3TapL2vUH70Ye5VV3KrzZynbfMD+WT RMyX7Qqth4w2KFTD/z4RdxPObB0h7wE3s5qaPJtHhcHL2egNkrbx3yEV0aJhhgQt2J tS+PeS1pn9rRw== From: To: "draft-hu-spring-segment-routing-proxy-forwarding@ietf.org" CC: SPRING WG Thread-Topic: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAUck9gg Date: Tue, 8 Feb 2022 11:01:25 +0000 Message-ID: <17506_1644318086_62024D86_17506_388_1_25c99d808d0f4185a9d9005debbbab5b@orange.com> References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> In-Reply-To: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-08T11:01:23Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-08T11:01:23Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 4a8f353c-254d-4c5d-b820-b7449b42e0ab msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.26.51] Content-Type: multipart/alternative; boundary="_000_25c99d808d0f4185a9d9005debbbab5borangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 08 Feb 2022 11:01:35 -0000 --_000_25c99d808d0f4185a9d9005debbbab5borangecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [speaking as WG contributor] Hi authors, all I have some comments specific to the binding SID aspect. =A72 " For a binding segment of a possible failed node, the node advertises the information about the binding segment, including the binding SID and the list of SIDs associated with the binding SID, to its direct neighbors only. Note that the information is not advertised in the network domain. =BB =A73.2.2 "For supporting binding SID proxy forwarding, a new IS-IS TLV, called Binding Segment TLV, is defined. It contains a binding SID and a list of segments (SIDs). This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. =BB >From an IS-IS standpoint, it seems to me that: - Advertising it in the LSP PDU would flood the information in the whole= area/level, hence does not match the goal stated in =A72 - Advertising it in the Hello PDU is not a reliable way to sync informat= ion (except if duplicated in all hello which implies others issues such as = lack of space) and adding the reliability seem like a major change to IS-IS In all cases, as already raised by St=E9phane, this is a subject for the LS= R WG. More importantly, the binding SIDs are probably coming from "somewhere" suc= h as configuration, PCE, BGP, BGP-LS... Why not using the exact same signal= ing to duplicate it on the neighbors? (this may probably require some exten= sions for some protocols but a priori light ones and would not impact the I= GP with information which may not belong to the IGP.) Thanks, Regards, --Bruno Orange Restricted From: spring On Behalf Of bruno.decraene@orange.c= om Sent: Thursday, January 13, 2022 11:19 AM To: SPRING WG Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote. If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_25c99d808d0f4185a9d9005debbbab5borangecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[speaking as W= G contributor]

 

Hi authors, al= l

 

I have some co= mments specific to the binding SID aspect.

 

=A72

“&= nbsp;  For a binding segment of a possible failed node, the node advertises=

 &n= bsp; the information about the binding segment, including the binding SID=

 &n= bsp; and the list of SIDs associated with the binding SID, to its direct<= o:p>

 &n= bsp; neighbors only.  Note t= hat the information is not advertised in the

 &n= bsp; network domain. =BB

=  

=A73.2.2

   “For supporting binding SID pro=
xy forwarding, a new IS-IS TLV, called
   Binding Segment TLV, is defined.  It contains a binding SID and a
   list of segments (SIDs).  This TLV may be advertised in IS-IS Hel=
lo
   (IIH) PDUs, LSPs, or in Circuit Scope=
d Link State PDUs (CS-LSP)
   [RFC7356]. =BB
 
From an IS-IS standpoi=
nt, it seems to me that:
-    Advertising it in the LSP PDU would=
 flood the information in the whole area/level, hence does not match the go=
al stated in =A72
-    Advertising it in the Hello PDU is =
not a reliable way to sync information (except if duplicated in all hello w=
hich implies others issues such as lack of space) and adding the reliabilit=
y seem like a major change to IS-IS
In all cases, as alrea=
dy raised by St=E9phane, this is a subject for the LSR WG.
 
 

More important= ly, the binding SIDs are probably coming from “somewhere” such = as configuration, PCE, BGP, BGP-LS… Why not using the exact same signaling to duplicate it on the neighbors? (this may probably requir= e some extensions for some protocols but a priori light ones and would not = impact the IGP with information which may not belong to the IGP.)

 

Thanks,

Regards,<= /o:p>

--Bruno

 

 

Orange Restricted

Fro= m: spring <spring-bounces@ietf.org> On Behalf Of bruno.decraene@= orange.com
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <spring@ietf.org>
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,<= /o:p>

 

This message s= tarts a 2 week WG adoption call, ending 27/01/2022, for draft-hu-spring-seg= ment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-prox= y-forwarding/

 

After review o= f the document please indicate support (or not) for WG adoption of the docu= ment to the mailing list.

 

Please also pr= ovide comments/reasons for your support (or lack thereof) as this is a stro= nger way to indicate your (non) support as this is not a vote.    &nbs= p; 

 

If you are wil= ling to work on or review the document, please state this explicitly. This = gives the chairs an indication of the energy level of people in the working group willing to work on the document.=

 

Thanks!

Bruno, Jim, Joel

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_25c99d808d0f4185a9d9005debbbab5borangecom_-- From nobody Tue Feb 8 13:38:46 2022 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 5946E3A11FB for ; Tue, 8 Feb 2022 13:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 Y9J3oRYE5f2u for ; Tue, 8 Feb 2022 13:38:40 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDBA3A11E9 for ; Tue, 8 Feb 2022 13:38:39 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id fy20so1703510ejc.0 for ; Tue, 08 Feb 2022 13:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dObgKiOAy3btXQEhU6wgvLI9g0jrUUjEFYJwrJoUmMs=; b=dCPOLJDZXcuX0Obw7EEbGcBU4QdSemUzJxEdTfja+VKXogKrLODXx7GPIJ770Tzg9x a8o7q4o/rkultNedHuCUg+pgz17J24e2d2U9pIqEYpowF82hfiVsXYi2Rb11TZZ0kI1r Vx26OAr7gNmUuyoYfJKyNRgB3cXqVvtuLiQgY1iLqqE5YDd0aVeJw35/TYeS46UlmUZW 63cFOtpWkDJLu+vygkgLUZ6aXLFybN4LYmEKrh32TUCJsfjLT5QFtj0LiVC1StcOAhnh Iy4QYxsqds2dzMAg5/yu3Uum8OIS09ssGm5dcFcPGInseIPPilL03s9OMXdpWJQn2slo BLIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dObgKiOAy3btXQEhU6wgvLI9g0jrUUjEFYJwrJoUmMs=; b=foBeySUMfDO8yVoadVU1cdcW0OEp9AYGijE5TYyOno8s5E7AmjhMnGE/LdJo3Csg5W rdpjN78MBfMtbVI7f49Mw4j9OIKV939MP9BrFT4nFl2P+EKwsgEE7FdM68WYE/COPFtR eGdSMiAyPSrZwJ3Xeu5UGQeFBWC84vlrc6zk+v3fHAaFvzEg2OubbOWqqHDhoqHTXaVM 6H0gbP3aU7Q7mUHqwrHfWZGtbB6XEjpToBcItOnhvLYfd5bw/SE/hh+XekULH+eFacEa /dxkPQ07V1hyX7zask0WqhYXNb+MGO9QYdZbbq0qN2DTpnN06OtO/R3TqjZvmVjCgL1F G7Pg== X-Gm-Message-State: AOAM530ue/YDwUdsuluIHE2Bz4vMzpZTE5lvn1lI7N2evf97Gxj8OqGR 7ls4HqWRznntCU/ARMr/wiTfey5oKfIZgDd1ty+HjwLALGo= X-Google-Smtp-Source: ABdhPJwxSIXX/RTnriEVDQDnEnR2wJ3afMe8AGU9hp/SbKe85wO/Gao10pNUKGzizoFR3DBieyBb1VMOMvkAczlG0/8= X-Received: by 2002:a17:907:72d0:: with SMTP id du16mr5258049ejc.506.1644356316960; Tue, 08 Feb 2022 13:38:36 -0800 (PST) MIME-Version: 1.0 References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> In-Reply-To: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> From: Greg Mirsky Date: Tue, 8 Feb 2022 13:38:25 -0800 Message-ID: To: Bruno Decraene Cc: SPRING WG Content-Type: multipart/alternative; boundary="000000000000281f1305d7888a75" Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 08 Feb 2022 21:38:44 -0000 --000000000000281f1305d7888a75 Content-Type: text/plain; charset="UTF-8" Dear Authors, et al., I've read the draft and would appreciate it if the authors can clarify one question: - What do you consider as the significant advantage of the mechanism defined in your draft compared with the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths? As I've compared the two solutions, I couldn't find any significant advantage of the proxy forwarding to have two standardized mechanisms for SR path e2e protection. It might be reasonable to have one standard while other proposals get experimental status? Regards, Greg On Thu, Jan 13, 2022 at 2:19 AM wrote: > Dear WG, > > > > This message starts a 2 week WG adoption call, ending 27/01/2022, for > draft-hu-spring-segment-routing-proxy-forwarding > > > https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/ > > > > After review of the document please indicate support (or not) for WG > adoption of the document to the mailing list. > > > > Please also provide comments/reasons for your support (or lack thereof) as > this is a stronger way to indicate your (non) support as this is not a vote. > > > > > If you are willing to work on or review the document, please state this > explicitly. This gives the chairs an indication of the energy level of > people in the working group willing to work on the document. > > > > Thanks! > > Bruno, Jim, Joel > > _________________________________________________________________________________________________________________________ > > 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 > --000000000000281f1305d7888a75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
I've read t= he draft and would appreciate it if the authors can clarify one question:
  • What do you consider as the significant advantage of the m= echanism defined=C2=A0in your draft compared with the mechanism defined=C2= =A0in draft-ietf-spring-segment-protection-sr-te-paths?
As I'v= e compared the two solutions, I couldn't find any significant advantage= of the proxy forwarding to have two standardized mechanisms for SR path e2= e protection. It might be reasonable to have one standard while other propo= sals get experimental=C2=A0status?

Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <bruno.decraene@orange.com> wrote:
<= /div>

Dear WG,

=C2=A0

This message starts a 2 week WG adoption call, endin= g 27/01/2022, for draft-hu-spring-segment-routing-proxy-forwarding

https://datatr= acker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/=

=C2=A0

After review of the document please indicate support= (or not) for WG adoption of the document to the mailing list.

=C2=A0

Please also provide comments/reasons for your suppor= t (or lack thereof) as this is a stronger way to indicate your (non) suppor= t as this is not a vote.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

If you are willing to work on or review the document= , please state this explicitly. This gives the chairs an indication of the = energy level of people in the working group willing to work on the document.<= /u>

=C2=A0

Thanks!<= /u>

Bruno, Jim, Joel

______________________________________________________________________=
___________________________________________________

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
--000000000000281f1305d7888a75-- From nobody Tue Feb 8 17:48:15 2022 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 7AE403A132F; Tue, 8 Feb 2022 17:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_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 xUzYftjugJK3; Tue, 8 Feb 2022 17:48:07 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2128.outbound.protection.outlook.com [40.107.92.128]) (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 099923A1044; Tue, 8 Feb 2022 17:48:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wyu7JxcX3HD7uzgiKgNuJs80+aVohpXZKdz5jJkwGpqpcJAE6jxRud2haAg5V1MqFpzESS+Wo7ZzPgk6jDJ5+HuxXxL4k3DayP+l7ZgaSeMcfVZY39TzOj1vjLodXYfTbXnaTQvIUd+ArQGsYTwOI/UkDVcRjp0SRY1iPElUq96PQ0RRy+iMiKP+FWlHpV3cqdce9T4+mUNUjc8GLwVEYdyjT8qkmIURfAUzDNTlFtPHVwplbGEMzAuozT/OEBmO8spH7Fgqyspyje3P3i8KtH03X9jGIk0h9xTpH6pNO8h5hDE/pGsN82Nz9Op1DO8ovdV27qcfmEiZthiX4p8OLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fahm0vktwlWmhy4pK0B9lCasP5/Pf7QY52sdt8FqO7o=; b=bIBcR80QxBu1VyqgB4Q+5Vz5l9JsbEdZL+uMkqYNO92c/tbmN2sxEvJvs1TvOnNACaSRKFPEP+2rO+SaoYulHAstHtQQJACtmq4ukkrYr0qKwQLoeYVqofMtoJr8PEuVlTYiHu7d0Vi6Kaxix7KW2dGagAn9nbGr0A/sRcVxU6ZMvDRI45yN8GVJ7U3QvEVaadVAn3/7P1IzVcb7YiteUy0d2oIEUU4FQi06dr1/ksrvd+rhsXngv35FutRwnM16stgaDRtwAFWL+FGHZzitdU/d16uJpyCI2lyDH5bTP2xc2LIFh4W51RccPfx3NaegjjtdIueJYZH5UXzsztcvgg== 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=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fahm0vktwlWmhy4pK0B9lCasP5/Pf7QY52sdt8FqO7o=; b=G+gtUvyO60PfTD43PRewAqLlW1/Rs+1IDt4rYWTPayWT3td38TSJIZjA5L5Tls7hzMSV+p+PMAbCSdTqSYga15fENEm38iGsyQQ+jUyKq9aiJRq06eDiZjME0dpyomodqGsjm3gyl7IAYEvSBwn9YJosF3JTwxJARS7bNFPelQE= Received: from CO1PR13MB5045.namprd13.prod.outlook.com (2603:10b6:303:d5::19) by BN8PR13MB2625.namprd13.prod.outlook.com (2603:10b6:408:8b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Wed, 9 Feb 2022 01:48:00 +0000 Received: from CO1PR13MB5045.namprd13.prod.outlook.com ([fe80::e83d:7449:38e:4cff]) by CO1PR13MB5045.namprd13.prod.outlook.com ([fe80::e83d:7449:38e:4cff%4]) with mapi id 15.20.4975.011; Wed, 9 Feb 2022 01:48:00 +0000 From: Huaimo Chen To: "bruno.decraene@orange.com" , "draft-hu-spring-segment-routing-proxy-forwarding@ietf.org" CC: SPRING WG Thread-Topic: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAUck9ggAB9Smyg= Date: Wed, 9 Feb 2022 01:48:00 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <17506_1644318086_62024D86_17506_388_1_25c99d808d0f4185a9d9005debbbab5b@orange.com> In-Reply-To: <17506_1644318086_62024D86_17506_388_1_25c99d808d0f4185a9d9005debbbab5b@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-08T11:01:23Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; suggested_attachment_session_id: 8c320f7a-8656-761f-b50c-be952cd7db45 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bbbbdb4a-d2c6-4452-2cd0-08d9eb6e3444 x-ms-traffictypediagnostic: BN8PR13MB2625:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6BfvL+yfypV2Xyl8qEnkAt3YuDFLAST3zcXB3U/FBzQRFbBiM6C6gC26ewnuTKzsBBiRK+kNk5qh18wFFJ3CsLgZMqXvdcL3Bou+CCAHnw+JPavMRgmtGzdJrKbVJfVbATsy/9bhRT4pON0EMYlmIkCsJMxdT2EXLFssfgG1XiAThDNBzK0MxIXibW2FB6t1heZmhu3Fzq9zcNdOsw77Jd27h1sIvDRMwsEYc2RfbjE6YJ5IOzvnqU0GDnXW4M5ea+yx0Ea28EA23IifFtawK3NUbTV1YCe3KHrKNC1IZj0v4ddKl8S+eJ8vNUe0fsf4o/kEd//NdH4qWFggnZDKPTuFRZt23ISS82NsQGFECTBAAbHbI3DJnBL+zIWftsq+x2SrdAdRNhL8kS5uck22GbajsGee8kwdgNprND6eGe7MRaTnnYDH8wTB7lDwMGFH29X+q5t+TK8WIWPM2BOjKpuLryrijzB/5GhfkDZZEv5Eo19Py0sC3nx2UoVjDh4PY7spPAua2RZWcJDDUDtid/p/zEpe1wMEqQXxClewFQoFrntUKe7nn157OJLBAxiEOAfCtfSDZQ5CGY5elcyNscYr1sNbDl5m65Efuf9MzAAP7DRXNP/UF5OuBqiTaVICmxP+m9FGCf9h21Zd4Wd3SHclhA3sJoEyZg26CLwPcHZ3mMIZ+opVY/RMjySHr3h92iDubdiuDHXyS5ephWROBF+v+UxZhDxI0TMz2s96pu8V/uftaSJXya3QaJFLw2FH+k4hRHrl14DZ5x8BIRhx9Zbzhd4ukZf+2R82PHfDCQ+PixgManrJuLrxYWbjlKSNLKpiiRjo9KzEKTcoa8qSs+AtQzcSK8Oiy0w5hGB1TVmei4PNfLVlxgtUuUXh10d1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR13MB5045.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(19627405001)(8676002)(33656002)(122000001)(8936002)(4326008)(5660300002)(166002)(44832011)(66946007)(508600001)(91956017)(66556008)(64756008)(38100700002)(66446008)(76116006)(66476007)(966005)(53546011)(9686003)(86362001)(7696005)(83380400001)(6506007)(316002)(55016003)(186003)(2906002)(26005)(71200400001)(52536014)(110136005)(66574015); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?aaLYRTYEGQB9r3Cu1NYyfsyJ0qPTlUH1rCSH3Va+9FfN7xDFXNWQtuMS?= =?Windows-1252?Q?Mdg2ewZOXeKQK/nsuviVACWC3/fWMLr8bjCODy4tojy1jDRYFQxtjUgG?= =?Windows-1252?Q?Yl/ies8uXFAFzqUVutEYInctckykg2iMEJ4MuFkz8BR4VbSvtQ0Bnbnx?= =?Windows-1252?Q?br/KCOTAILSHPcfMzmtuB3XeaSDyPmAXhDgtbsuyfn9X6RTdU7d9VVk2?= =?Windows-1252?Q?0DoHUYB+1AQ2ZfZdNAXboDUJv8Vf/DvbML++7HyyG8bWEzwrd0F9ad7F?= =?Windows-1252?Q?uxfBXl9XJ83xJDQ//Y4lyorH+jxCSeg8uk9ZPyZ5hIqOyc7Oosq0F5pv?= =?Windows-1252?Q?NhxDKruqz23JDFauXLqzPVCRHur//Lur0ybfC1GN79v1O3Q7zQIptH21?= =?Windows-1252?Q?qYuft/3RJpoOYLkn5L05ror1N1r90XjCdGaHKJIZuZvL4e/G0KFQyeaN?= =?Windows-1252?Q?JKtcOHWGejOiWjtnBVzgtanHKNDQ9irqcf7X0Wok411tVNeaya4pvXhP?= =?Windows-1252?Q?s1VUaUhMIJEOJ70nz5VbVv9lxj9ACpDkdeDmbOzMg9OnGqbTM2mcbZKR?= =?Windows-1252?Q?wuEYrYLJRo5f/pPJJzACVXMLyITLBtTmQCNkpAUckMu8GGMHmxIhveMd?= =?Windows-1252?Q?+BIgB1fYk8VJxKxKGzzA56JwuAWzOZ0vChetFmoqSYDdr5TXMAUZ9nE9?= =?Windows-1252?Q?RVHfORyICCcO23VW6TZwxh/i1Zua818VkTtON9uPE0u7x6bLFUhv29wv?= =?Windows-1252?Q?r0OL1TsRvCWdZQnM97AP7Kg55CrUlrzK+sv8nLb+7YV6XFnpD2QJG3bX?= =?Windows-1252?Q?9yyL+fT0y6FCCcIm7FOifdZNEJftjEA3MwVTmmN/3mtKXvRK2/tEwS0Y?= =?Windows-1252?Q?ANFEJTJW3Bw+u43Is/o+YJ2J1AB9tr/v2QOvR+BrzrrNEcHtbz1gyNO4?= =?Windows-1252?Q?f4LXyPpjIuwiCgKaWAvB0QSXHfc0J1PNAnfQN8ju5dby8hIvjuRNq1VR?= =?Windows-1252?Q?YvTDa7wA2EotS++r+0VQooWFb/IKscXhNkl/VNe29b4n4tUf5qx79w2B?= =?Windows-1252?Q?oQ9HH7ZN0k34lVc7csYOi5xsERxgpH9l/UYHQhOpZIrbeFROIba+oeV9?= =?Windows-1252?Q?piVh59EbpgErdAiNVfTEGAy3AeE3vN9rG2Gbgi9/eXOJmApyGKqEkkLB?= =?Windows-1252?Q?1kAbO1Hgm1gXZ8EWlQm5CF/fdslxI+M0NuaaF3AXjfq/qOWBq3mNyOGF?= =?Windows-1252?Q?lbpnOQe4F/gLTpm/P63MzfMd6reqRcomm94dUEt3EL+PAXdmK2GgYfMK?= =?Windows-1252?Q?f5VpS/tT4hev9tBweynx/EgDXpbSrY3o1Iqedq6nhXbs2bafapnuisCM?= =?Windows-1252?Q?JSuHeZqhB+BnVwt5rUpLAXYLKs38iceONn1F1f8oK7/mW603qZ8spPcx?= =?Windows-1252?Q?TYkDv2xo7lb2PmBGDgaBflnjjXuSgfOW+4R5MXgsoAZE7wrqmNhDAXsX?= =?Windows-1252?Q?KKJXNELpRM6fPzElIhv4b9u75iwea5Rqi5lVa7iC5aQIA0jPzc+Wr5QT?= =?Windows-1252?Q?g1BFFVJqDsjmiqmA1mo3oYtFeuYOi3cVXgaLaZzzEWQyLUziojf/Gnfe?= =?Windows-1252?Q?TbrVWrFzktEnE9gJSqfUPNINMyNH6z0UkBy9Su9SIQ5CIOOS0PGtEskL?= =?Windows-1252?Q?/XJonHGX+ffW6DecipA1P5m5xafg2jUf/mKGaF4SW9RlWiDxMGdhIg?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR13MB5045102B8C322C7AE67BEF07F22E9CO1PR13MB5045namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR13MB5045.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bbbbdb4a-d2c6-4452-2cd0-08d9eb6e3444 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2022 01:48:00.3872 (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: twjD+uDQfUnz247HggLBL38WBaUonAOikfLmkvmJ+P3BCvcrYklTqJborXetekBJRfw0118mPwzKQ2xkkrLHNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR13MB2625 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 09 Feb 2022 01:48:13 -0000 --_000_CO1PR13MB5045102B8C322C7AE67BEF07F22E9CO1PR13MB5045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thank you very much for your valuable comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: bruno.decraene@orange.com Sent: Tuesday, February 8, 2022 6:01 AM To: draft-hu-spring-segment-routing-proxy-forwarding@ietf.org Cc: SPRING WG Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwa= rding [speaking as WG contributor] Hi authors, all I have some comments specific to the binding SID aspect. =A72 =93 For a binding segment of a possible failed node, the node advertises the information about the binding segment, including the binding SID and the list of SIDs associated with the binding SID, to its direct neighbors only. Note that the information is not advertised in the network domain. =BB =A73.2.2 =93For supporting binding SID proxy forwarding, a new IS-IS TLV, called Binding Segment TLV, is defined. It contains a binding SID and a list of segments (SIDs). This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. =BB >From an IS-IS standpoint, it seems to me that: - Advertising it in the LSP PDU would flood the information in the whole= area/level, hence does not match the goal stated in =A72 - Advertising it in the Hello PDU is not a reliable way to sync informat= ion (except if duplicated in all hello which implies others issues such as = lack of space) and adding the reliability seem like a major change to IS-IS In all cases, as already raised by St=E9phane, this is a subject for the LS= R WG. [HC]: We will remove IS-IS Hello (IIH) PDUs and LSPs, and update the related text accordingly. More importantly, the binding SIDs are probably coming from =93somewhere=94= such as configuration, PCE, BGP, BGP-LS=85 Why not using the exact same si= gnaling to duplicate it on the neighbors? (this may probably require some e= xtensions for some protocols but a priori light ones and would not impact t= he IGP with information which may not belong to the IGP.) [HC]: Using the same signaling (configuration, PCE, or BGP, ...) to duplicate it on the neighbors works well if there are sessions between the neighbors and PCE, or BGP, ... Thanks, Regards, --Bruno Orange Restricted From: spring On Behalf Of bruno.decraene@orange.c= om Sent: Thursday, January 13, 2022 11:19 AM To: SPRING WG Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CO1PR13MB5045102B8C322C7AE67BEF07F22E9CO1PR13MB5045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Bruno,

    Thank you very much for your valuable comments.

    My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors
From: bruno.decraene@orange= .com <bruno.decraene@orange.com>
Sent: Tuesday, February 8, 2022 6:01 AM
To: draft-hu-spring-segment-routing-proxy-forwarding@ietf.org <dr= aft-hu-spring-segment-routing-proxy-forwarding@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-prox= y-forwarding
 

[speaking as WG contributor]

 

Hi authors, all

 

I have some comments specific to the binding SID aspect.

 

=A72

=93   For a binding segment of a possible failed node, the node advertises=

   the information about the binding segment, including the binding SID=

   and the list of SIDs associated with the binding SID, to its direct<= /span>

   neighbors only.  Note that the informat= ion is not advertised in the

   network domain. =BB

 = ;

=A73.2.2

 =
;  =93For supporting binding SID proxy forwarding, a new IS-IS =
TLV, called
 =
;  Binding Segment TLV, is defined.  It contains a binding SID and a
 =
;  list of segments (SIDs).  This =
TLV may be advertised in IS-IS Hello
 =
;  (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-L=
SP)
 =
;  [RFC7356]. =BB
 
From an IS-IS standpoint, it seems to me that:

-    Advertis=
ing it in the LSP PDU would flood the information in the whole area/level, =
hence does not match the goal stated in =A72


-    Advertis=
ing it in the Hello PDU is not a reliable way to sync information (except i=
f duplicated in all hello which implies others issues such as lack of space=
) and adding the reliability seem like a major change to IS-IS


In all cases, as already raised by St=E9phane, this is a =
subject for the LSR WG.


[HC]: We will remove IS-IS Hello (IIH) PDUs and LSPs, a=
nd update the
related tex=
t accordingly. 


 



More importantly, the binding SIDs are probably coming from =
=93somewhere=94 such as configuration, PCE, BGP, BGP-LS=85 Why not using th=
e exact same signaling to duplicate it on the neighbors?
 (this may probably require some extensions for some protocols but a priori=
 light ones and would not impact the IGP with information which may not bel=
ong to the IGP.)



[HC]: Using the same signaling (configuration, PCE, or BGP, =
...) to



duplicate it on the neighbors works well if there are sessions between=
 

the neighbors and PCE, or BGP, ...






 



Thanks,



Regards,



--Bruno



 



 



Orange Restricted









From: spring <spring-bou=
nces@ietf.org>
On Behalf Of bruno.decraene@orange.com

Sent: Thursday, January 13, 2022 11:19 AM

To: SPRING WG <spring@ietf.org>

Subject: [spring] WG adoption call - draft-hu-spring-segment-routing=
-proxy-forwarding







 



Dear WG,



 



This message starts a 2 week WG adoption call, ending 27/01/=
2022, for draft-hu-spring-segment-routing-proxy-forwarding



https://datatracker.ietf.org/doc/draft-hu-s=
pring-segment-routing-proxy-forwarding/



 



After review of the document please indicate support (or not=
) for WG adoption of the document to the mailing list.



 



Please also provide comments/reasons for your support (or la=
ck thereof) as this is a stronger way to indicate your (non) support as thi=
s is not a vote.      




 



If you are willing to work on or review the document, please=
 state this explicitly. This gives the chairs an indication of the energy l=
evel of people in the working group willing to
 work on the document.



=
 



=
Thanks!



=
Bruno, Jim, Joel


______________________________________________________=
___________________________________________________________________


 


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


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


a l'expediteur et le detruire ainsi que les pieces joi=
ntes. Les messages electroniques etant susceptibles d'alteration,


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


 


This message and its attachments may contain confident=
ial 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 notif=
y the sender and delete this message and its attachments.


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


Thank you.




______________________________________________________=
___________________________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
--_000_CO1PR13MB5045102B8C322C7AE67BEF07F22E9CO1PR13MB5045namp_-- From nobody Tue Feb 8 18:35:35 2022 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 60B113A053E for ; Tue, 8 Feb 2022 18:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_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 F7ErmFSiOchB for ; Tue, 8 Feb 2022 18:35:28 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2108.outbound.protection.outlook.com [40.107.244.108]) (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 798933A04BB for ; Tue, 8 Feb 2022 18:35:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D8uz1ApHTKikaIoGUXUefk5w5A4osddNnKbnYKM8uHGgPDBDLFkjxvL1IODWCbfY54TLjqfoPB4S+YGVDMQ5OLwJpnRpIHx3UG5ujJnjkzDaxWIv35DgMunP9ixBSm60PAvqjnTzBWX06m6s0u/wCjBYZS8SnLrS9TW1wdAn0MDMMSk7HqkO9i8Y7anH9fGN+7Q+5FTMLpmDHcEXgvLJLpIFfITRZU+Q5Jke3xO9fqXjh18NmKuhIvlG9eOlYH/4nIFTDBVcqgeB6jsbFDsgOwS26GgvdITGTqOfPW/ceUcPk4v/CNvgTAjSe7JHixwZNsHynfy8ism77bIOaeCKYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Wk0c4j/N3MRYcwYP+P/HnaD6bpypW6xYkZVHDNVzyDE=; b=PDUEwpuI2Skkmg8yvVZw5dYrLPXmg/oyeBFfK9IQvTjRRSupirrlpQole5x7s53JQ948MFtvtdy/b6irLO7DfTiZXXHWt/mZkgLI0i8x71NHUrO33qgtnHvStYb0PDfUykiPn8KmpfZ29uBO5MdSIkMxh4X35jXNHWdsBUIfqVVt8jSLv7h2JT/UDhBcyVF1/9iW/s264zLAIWqBdW37kIt/hF0GTlzofowimEjfiLng7VAi2sK3M1tYGe3x8cESAILUVnNZuG7gzK+/NutV0Auhui3jUaEzRW0xpRBFog/bZNSZ5Ta368kLh3VbeGYXlotQUbFVEyk/sebOYkyErA== 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=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wk0c4j/N3MRYcwYP+P/HnaD6bpypW6xYkZVHDNVzyDE=; b=BvZOMlhDKKsI/pQ8oVaRvRR7dJMSUtpVaROQCho6GMUJZtIRkwJIyjrGHdqcoUCeoduVcWU5bE2Uh8AcMQjP0VyroBlhMZR4gDUgXw54vnrnLTsmz8bScY4ZHEVtRIQGAYJZIMr54r5G4kMRFMPNS3EwvM/6JHRUER+HyjeAoyk= Received: from CO1PR13MB5045.namprd13.prod.outlook.com (2603:10b6:303:d5::19) by DM4PR13MB5906.namprd13.prod.outlook.com (2603:10b6:8:4c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.3; Wed, 9 Feb 2022 02:35:24 +0000 Received: from CO1PR13MB5045.namprd13.prod.outlook.com ([fe80::e83d:7449:38e:4cff]) by CO1PR13MB5045.namprd13.prod.outlook.com ([fe80::e83d:7449:38e:4cff%4]) with mapi id 15.20.4975.011; Wed, 9 Feb 2022 02:35:23 +0000 From: Huaimo Chen To: Greg Mirsky , Bruno Decraene CC: SPRING WG Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAUzUcCAAApCg5k= Date: Wed, 9 Feb 2022 02:35:23 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: cfe7a896-42f8-93f2-2dab-c0b1f6bf497e authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6392a6f7-e18d-4f9b-700c-08d9eb74d2f4 x-ms-traffictypediagnostic: DM4PR13MB5906:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N79DC1e/WrYPIgw/1irJzqUSLYb6c0ZelduXNlHfe7ryndH4K1Yhv6skd7gZffzazuWv3DsprKE7GCzT4+a+/VCQhMEaeeZ5gxiX20tTWFKXzSc+1EJzv0OKMsYl9kqjCQ7uOEjTpu/4fh4SPhmFI7pISuO2o7TDPcc1BORl5TrRKvcqh6n6Xto0JrCZqhD1v1kRJW2Tcp9zgqXU4t/aDkizc5sOHDKX6DUIPOcfVC/LqHBgR/1b/NfT8mZ6CDpPzCsFpIdpsDqPVjvUIDPL5iq7gk1t1gwg+kMWiBm1cnQCu3oLPrFY1NWG+9eNHrbFNEV8Nw2fRichD568xleKKu4cU++4edl7Q5kDWltFUPBv77GDw+ak6CRhcRsQLECmKVnU5/ph1G1G7+jTGwXKIyzSTJD/d0H7D+GAgJnhGIPm9u6SmKjakwF4N7kJ7wagJJUbwxfKiqNlLqXeb+KA7hx/4Wv93E6KOj1TZem7TnbctCMdqh09KUIvcfgThVjDg9Evb7v0vC89J670TYT544nbx98pfWFsuS8L6CldGIh1CIrJhPqhUjIGJd2xPq+WYVsrbVbiP0Hl4oNESrKo157afa5YdSKb+PNLKQcvGqF9xHxAitrlvYGGWvxZvL2m4rj00JWmeITmz7YSPzgTFfgMfEgnwVpCWKgBheLKNM3VnpnRXT80fnEU0waVwI2biY9/cejL+xvTndsL/2+F3VPJjXFQSayKqSG7xmXcXgGNK8dUw6erAzk6EVvPe03lB4J9851zjCzpbM/UI6803x1mgjL/7XGSxQtyY8p3L4oLYw1JQzYiCK8e9gMTXmyN0i+KqzZFwDCVKHo9YnDFOQvjTKMJX0yG+AGuveNt71F8hYgemJMKBTrvphmnwR7f x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR13MB5045.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(53546011)(91956017)(6506007)(508600001)(19627405001)(26005)(166002)(83380400001)(86362001)(7696005)(966005)(64756008)(55016003)(66476007)(33656002)(110136005)(66556008)(66446008)(8936002)(316002)(44832011)(76116006)(52536014)(38070700005)(122000001)(8676002)(5660300002)(4326008)(9686003)(66946007)(71200400001)(186003)(38100700002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?xsNzIa365hq+gxKp7a2z1zfcpBT3K8wNmiNWfHOuo9q1ddFrm//HAwwKsF?= =?iso-8859-1?Q?tfmcEjfBR3UeZ0dQLiY42BsgZ2pCzGOdvSXjBT8Gz/QWWFuWNOTq2P5nEu?= =?iso-8859-1?Q?LFeFf0RC/sQB2Rwi0xpBatO0kb5tMeBHqgg8wTQmIMUcNafq09M+Orjphv?= =?iso-8859-1?Q?cCRRWBa+6bjcXWleEivRfb3jt+JR62u6b28TXRydMWtaq7e3pGxOE2F5Lu?= =?iso-8859-1?Q?E6lfrCrM9vKjgd2/AYRg9spoczEo62dB5JH9MnJqxI7AddREJ9KABgOCUb?= =?iso-8859-1?Q?aWRTY2P6H2lODYt1bCDlJmLbeFVxn1NH8Fty/YwC4ufuxUrPOj63eVWTXT?= =?iso-8859-1?Q?PjxXi4iuiWrTxZQeJbImMvTDbQttyZ2zOwc0bTpq02JLk6H2844xlHHRCU?= =?iso-8859-1?Q?2l8wuLc1MUHk7L3amE5l34+d+TPeUl1yv8LvYgagNkLVlPWPJqTrd6Z4iR?= =?iso-8859-1?Q?En2fM4J7sD5v4DtvTCQ0PtTMDtAKJVGjs+eBwpcvFUNqN3wFXRGeTGNB5p?= =?iso-8859-1?Q?JFSCaVZsupr0rcaR+c/TXqf5+Thomp1L0VJxmhXOK5kqzQxKOeQ3TulhAy?= =?iso-8859-1?Q?vzHSLOtTMjME6re7/U24/C7WD7CN7M5EBwCUWz6JM6tOFw23ZzsNYa4W2A?= =?iso-8859-1?Q?ZDkNnqvTVYlmCY7RZxfmD0AyfE/EywSz/cc1llmVUmKsx2LnBSbcZ8q5Ax?= =?iso-8859-1?Q?Qudyx+e3ER9vBu4jI9QA6dX7BoAX/McSQcJ8CiVm41uyXnJAibqQV2OkC+?= =?iso-8859-1?Q?95wt03JR4QCVPEDg6HfaDhTa6Cx/tlFog3PzxXdAvy6zeNSyj1Hk3P52EE?= =?iso-8859-1?Q?FeimReT2OVclg/YlZ6CqD8u2sjhjs1HXo4pk4JhKSotFcAUIitqML6V0pO?= =?iso-8859-1?Q?meuVDP4Yxb75YZLHnWfa2sVPEdfyJ06eLpkSYAca6GEzQag1DMHFURopew?= =?iso-8859-1?Q?1UbcnES+AW/OwjPJN5uFvhxv6ojrgeUyDsJsDsZPT2KFOw+fzy6hoEEnS9?= =?iso-8859-1?Q?w8TomfPMb70L4Be866pSHEr+25A6JCb5OUMDNus01FDYdZf9GqvADBttGn?= =?iso-8859-1?Q?I95anqLwUldeTtXwMByGUCaLWyrVduMHKR1/jixY9dDRsqbmiaWDWxVeJy?= =?iso-8859-1?Q?RvDzfyIhLRJG8LshM93cFXoXpQGdiJYh5fQH099p90nY026xpOU+HRq4Ev?= =?iso-8859-1?Q?oRxLktOENUv3ghqdm0Aqj3l6hKk5AZfeLobHdcFSV1lEu0urt+cmZCCxo6?= =?iso-8859-1?Q?wH88HReRfZeseFjQ+ZEEIO+82JmHUFSSU+UVDAE9kK4lbh2PkTHt9dVE72?= =?iso-8859-1?Q?oRP8RyS3VVFsXTtKFdt/9aZBoEhoUH/4yYmXWK6kOnEvlkwFmTiQ4IJXli?= =?iso-8859-1?Q?V5wPnomv2AxGoIxoIOVlmmegWev1P5EEUKsghqGDYKng/QXP0WhRVcBSce?= =?iso-8859-1?Q?qDvzsm7Rk/ipt5bd5k6YMIWrvFfOkni+C4VYOyfWtLh/Zru0I7U6y4mC0M?= =?iso-8859-1?Q?DcG0LjUc4yk3sJTpxKz9ijPCHcfzqjhgDdqFfS6nSzcex5SgMd7Mw0Ify/?= =?iso-8859-1?Q?Cw2sCYB+YwQHlKYXjxTF6TBiiLhl9hXWp4EtZC8QIzYCUOm6ns/V9egcVC?= =?iso-8859-1?Q?nQesQbZucozn8t2RRjWtrDjMhhXid0n2tX++p9/GWUOFlTYS8ZdqVitQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR13MB5045EE24CD43901962E178F6F22E9CO1PR13MB5045namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR13MB5045.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6392a6f7-e18d-4f9b-700c-08d9eb74d2f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2022 02:35:23.5729 (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: EV5nZa2kFPyvvNMuFGs9sW113M16l6J3poR9AoelhzlLe8BzBtlfEcsS87ssIsGHZWqyXH2vzwje5gh2AiFKfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR13MB5906 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 09 Feb 2022 02:35:34 -0000 --_000_CO1PR13MB5045EE24CD43901962E178F6F22E9CO1PR13MB5045namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you very much for your comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: spring on behalf of Greg Mirsky Sent: Tuesday, February 8, 2022 4:38 PM To: Bruno Decraene Cc: SPRING WG Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Dear Authors, et al., I've read the draft and would appreciate it if the authors can clarify one = question: * What do you consider as the significant advantage of the mechanism de= fined in your draft compared with the mechanism defined in draft-ietf-sprin= g-segment-protection-sr-te-paths? As I've compared the two solutions, I couldn't find any significant advanta= ge of the proxy forwarding to have two standardized mechanisms for SR path = e2e protection. It might be reasonable to have one standard while other pro= posals get experimental status? [HC]: It provides more protection coverage in some cases as compared to the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths. This improves the reliability of networks, and QoE. This should be a significant advantage. There is no solution for BSID protection in the other existing draft. The solution for BSID protection in our draft has been there for a few years. In addition, after a node failed, in our solution, the nodes of the entire network converge to the latest state consistently in time. After a node failed, the mechanism defined in the other existing draft holds off the FIB during the HoldTimer period configured, when the network changes again, our solution continues to converge at any time. The mechanisms in two drafts are different. It seems ok and reasonable to have the two drafts to be adopted in the WG. Regards, Greg On Thu, Jan 13, 2022 at 2:19 AM > wrote: Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ 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_CO1PR13MB5045EE24CD43901962E178F6F22E9CO1PR13MB5045namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greg,

    Thank you very much for your comments.

    My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors

From: spring <spring-bou= nces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com> Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 
Dear Authors, et al.,
I've read the draft and would appreciate it if the authors can clarify= one question:
  • What do you consider as the significant advantage of the mechanism defi= ned in your draft compared with the mechanism defined in draft-ie= tf-spring-segment-protection-sr-te-paths?
As I've compared the two solutions, I couldn't find any significant advanta= ge of the proxy forwarding to have two standardized mechanisms for SR path = e2e protection. It might be reasonable to have one standard while other pro= posals get experimental status?
[HC]: It provides more protection coverage in some cases as compared t= o
the mechanism defined in draft-ietf-spring-segment-protection-sr-te-pa= ths.
This improves the reliability of networks, and QoE. This should be a <= /div>
significant advantage. There is no solution for BSID protection in the=
other existing draft. The solution for BSID protection in our draft ha= s
been there for a few years. In addition, after a node failed, in
our solution, the nodes of the entire network converge to the latest <= /div>
state consistently in time. After a node failed, the mechanism defined=
in the other existing draft holds off the FIB during the HoldTimer
period configured, when the network changes again, our solution contin= ues
to converge at any time.
The mechanisms in two drafts are different. It seems ok and reasonable=
to have the two drafts to be adopted in the WG.

Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <= ;bruno.decraene@orange.com= > wrote:

Dear WG,

 

This message starts a 2 week WG adoption call, en= ding 27/01/2022, for draft-hu-spring-segment-routing-proxy-forwarding

https://data= tracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<= u>

 

After review of the document please indicate supp= ort (or not) for WG adoption of the document to the mailing list.=

 

Please also provide comments/reasons for your sup= port (or lack thereof) as this is a stronger way to indicate your (non) sup= port as this is not a vote.     

 

If you are willing to work on or review the docum= ent, please state this explicitly. This gives the chairs an indication of t= he energy level of people in the working group willing to work on the document.

 

Thanks!

Bruno, Jim, Joel

______________________________________________________________________=
___________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/m= ailman/listinfo/spring
--_000_CO1PR13MB5045EE24CD43901962E178F6F22E9CO1PR13MB5045namp_-- From nobody Tue Feb 8 20:26:06 2022 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 F2DD03A0A71 for ; Tue, 8 Feb 2022 20:26:02 -0800 (PST) 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=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 0Qy9g6hCCJM1 for ; Tue, 8 Feb 2022 20:25:58 -0800 (PST) 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 28D263A0A67 for ; Tue, 8 Feb 2022 20:25:58 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id y17so720498edd.10 for ; Tue, 08 Feb 2022 20:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q1q7aDppFN24pelcSN2TeLlSUfK4Xkrxd+W7ZRqH2GI=; b=jrJkM8Pr/WxUkf1fY0xYX2RwAsQzpmjv2g2pfyISop1SSAG5CqkR+diCaGpcB5PaM5 Wd9oTmkKxGQwPma0S3+ERwxmuVE2tOhjfxXngEntR/Gl57t09DWDNxnOAqlvJWQ3L8hP HH/Axdry+fbwOFltMVJUJHEBfwdlhNaSIqP/Oex6W6EU9eJjM/IYBj8tiF3DzS9y0WmT AOg9nnX2wUITE1xpzlWm6hJf6hgM15Fz8Vcpx+/+o5ZajYFyJ66xiK732dxfpBHm1+Hc lVS5h6qrKCcPtfjtf+EqeztXOUsIhHTC9K8StbMwullEBAQNool6qJVO/w2ojvIklmzI AAWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q1q7aDppFN24pelcSN2TeLlSUfK4Xkrxd+W7ZRqH2GI=; b=mI20wrGMkv+QEOJW417d/4NvqdktNONcSUoFwgoMqa/uf/YFxxmMIOnsH/m8UwX9kR neIrD6O5APlQra8FXSke85rxkBw+G2O1XKRSnX8N+Fyp9ThRG2GvnJfDvNkxgUF67aS7 9HRxjAmw2g9J8YGCIYr5zxVviYLjdvsIg1OZyvYFPC+L97tbcPFbZDZtZj+Pg0NrOmz6 4oiouOeY5hGOd8/dB6v+8M0YEJiW2+6V1hJi7fCueuuLgs9AGjKoPuLDjGvpcPRJmxI/ PLKHpxx8S+9Uxa+orWIPzwsR2pKfDYmPWgpbfH3tyFwRtOOqCMqRU5qZ+NcQ2J7R9TKf Eq8g== X-Gm-Message-State: AOAM5327LY/3DWCGPS594Xwf0Fc0Mf5jYQtJUU2VAT2Ldvx/cfOHA5TN gxbh0tojIObNUOaMInoB3dWkgojPgIWpToPsxPcjHtLl4zc= X-Google-Smtp-Source: ABdhPJyvEgW3wTyNPs2ORqt4Go90wh2T95mhYH3fhJ7XKpGco4LU+BuG0QaAfdFKvJYEwqAG/1pPOMhyxu3vlX9pa3M= X-Received: by 2002:a05:6402:31f9:: with SMTP id dy25mr553987edb.190.1644380755589; Tue, 08 Feb 2022 20:25:55 -0800 (PST) MIME-Version: 1.0 References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> In-Reply-To: From: Greg Mirsky Date: Tue, 8 Feb 2022 20:25:43 -0800 Message-ID: To: Huaimo Chen Cc: Bruno Decraene , SPRING WG Content-Type: multipart/alternative; boundary="000000000000cffb6305d78e3ae8" Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 09 Feb 2022 04:26:03 -0000 --000000000000cffb6305d78e3ae8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Huaimo, thank you for the expedient response. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen wrote: > Hi Greg, > > Thank you very much for your comments. > > My responses/explanations are inline below with [HC]. > > Best Regards, > Huaimo > on behalf of co-authors > > ------------------------------ > *From:* spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Sent:* Tuesday, February 8, 2022 4:38 PM > *To:* Bruno Decraene > *Cc:* SPRING WG > *Subject:* Re: [spring] WG adoption call - > draft-hu-spring-segment-routing-proxy-forwarding > > Dear Authors, et al., > I've read the draft and would appreciate it if the authors can clarify on= e > question: > > - What do you consider as the significant advantage of the mechanism > defined in your draft compared with the mechanism defined in > draft-ietf-spring-segment-protection-sr-te-paths? > > As I've compared the two solutions, I couldn't find any significant > advantage of the proxy forwarding to have two standardized mechanisms for > SR path e2e protection. It might be reasonable to have one standard while > other proposals get experimental status? > [HC]: It provides more protection coverage in some cases as compared to > the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths= . > GIM>> I find it hard to quantify your characterization. I imagine that if an operator uses the protection mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths it designs the network with that in mind and thus minimizes if not completely avoids any possible limitation the protection mechanism may have. Perhaps you can help with some more specific scenarios. > This improves the reliability of networks, and QoE. This should be a > significant advantage. There is no solution for BSID protection in the > other existing draft. > GIM>> Though BSID may be used inside the network, I find such use case questionable making no significant impact on the usefulness of the protection mechanism. > The solution for BSID protection in our draft has > been there for a few years. In addition, after a node failed, in > our solution, the nodes of the entire network converge to the latest > state consistently in time. After a node failed, the mechanism defined > in the other existing draft holds off the FIB during the HoldTimer > period configured, when the network changes again, > GIM>> I consider that property of the protection defined in draft-ietf-spring-segment-protection-sr-te-paths as a benefit that allows better control for the proper coordination between protection mechanisms that operate on different network layers. > our solution continues > to converge at any time. > The mechanisms in two drafts are different. It seems ok and reasonable > to have the two drafts to be adopted in the WG. > GIM>> I agree with you, drafts are fundamentally different and, in my opinion, merging them would not change the situation. But I don't see that as the justification for producing two standards. It seems to me, releasing two standard-based specifications might be detrimental and I propose the authors consider taking this draft onto the experimental track. I'd support the adoption of it as the experimental track document. > > > Regards, > Greg > > On Thu, Jan 13, 2022 at 2:19 AM wrote: > > Dear WG, > > > > This message starts a 2 week WG adoption call, ending 27/01/2022, for > draft-hu-spring-segment-routing-proxy-forwarding > > > https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-fo= rwarding/ > > > > > After review of the document please indicate support (or not) for WG > adoption of the document to the mailing list. > > > > Please also provide comments/reasons for your support (or lack thereof) a= s > this is a stronger way to indicate your (non) support as this is not a vo= te. > > > > > If you are willing to work on or review the document, please state this > explicitly. This gives the chairs an indication of the energy level of > people in the working group willing to work on the document. > > > > Thanks! > > Bruno, Jim, Joel > > _________________________________________________________________________= ________________________________________________ > > 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 > > > --000000000000cffb6305d78e3ae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2= =A0Huaimo,
thank you for the expedient response. Please find my follow-= up notes in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen &l= t;huaimo.chen@futurewei.com> wrote:
Hi Greg,

=C2=A0 =C2=A0 Thank you very much for your comments.

=C2=A0 =C2=A0 My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors

From= : spring <spring-bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com&g= t;
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
=C2=A0
Dear Authors, et al.,
I've read the draft and would appreciate it if the authors can cla= rify one question:
  • What do you consider as the significant advantage of the mechanism defi= ned=C2=A0in your draft compared with the mechanism defined=C2=A0in draft-ie= tf-spring-segment-protection-sr-te-paths?
As I've compared the two solutions, I couldn't find any significant= advantage of the proxy forwarding to have two standardized mechanisms for = SR path e2e protection. It might be reasonable to have one standard while o= ther proposals get experimental=C2=A0status?
[HC]: It provides more protection coverage in some cases as compared t= o
the mechanism defined in draft-ietf-spring-segment-protection-sr-te-pa= ths.
GIM>>= I find it hard to quantify your characterization. I imagine that if an ope= rator uses the protection mechanism defined in draft-ietf-spring-segment-pr= otection-sr-te-paths it designs the network with that in mind and thus mini= mizes if not completely avoids any possible limitation the protection mecha= nism may have. Perhaps you can help with some more specific scenarios.=C2= =A0
This improves the reliability of networks, and QoE. This should be a <= /div>
significant advantage. There is no solution for BSID protection in the=
other existing draft.
GIM>> Though BSID may be used inside the network, I find = such use case questionable making no significant impact on the usefulness o= f the protection mechanism.=C2=A0
=
The solution for BSID protection in our draft has
been there for a few years. In addition, after a node failed, in
our solution, the nodes of the entire network converge to the latest <= /div>
state consistently in time. After a node failed, the mechanism defined=
in the other existing draft holds off the FIB during the HoldTimer
period configured, when the network changes again,
<= /div>
GIM>> I consider that proper= ty of the protection defined in draft-ietf-spring-segment-protection-sr-te-= paths as a benefit that allows better control for the proper coordination b= etween protection mechanisms that operate on different network layers.=C2= =A0
our solution continu= es
to converge at any time.
The mechanisms in two drafts are different. It seems ok and reasonable=
to have the two drafts to be adopted in the WG.
GIM>> I agree with you, d= rafts are fundamentally different and, in my opinion, merging them would no= t change the situation. But I don't see that as the justification for p= roducing two standards. It seems to me, releasing two standard-based=C2=A0s= pecifications might be detrimental and I propose the authors consider takin= g this draft onto the experimental track. I'd support the adoption of i= t as the experimental=C2=A0track document.


Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <bruno.decraene@orange.com> = wrote:

Dear WG,

=C2=A0

This message starts a 2 week WG adoption call, ending 27/01/2022, for dr= aft-hu-spring-segment-routing-proxy-forwarding

https://datatracker= .ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<= u>

=C2=A0

After review of the document please indicate support (or not) for WG ado= ption of the document to the mailing list.

=C2=A0

Please also provide comments/reasons for your support (or lack thereof) = as this is a stronger way to indicate your (non) support as this is not a v= ote.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

If you are willing to work on or review the document, please state this = explicitly. This gives the chairs an indication of the energy level of peop= le in the working group willing to work on the document.

=C2= =A0

Thanks= !=

Bruno, Jim, = Joel

______________________________________________________________________=
___________________________________________________

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/spr= ing
--000000000000cffb6305d78e3ae8-- From nobody Wed Feb 9 05:53:35 2022 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 4AFB13A089D for ; Wed, 9 Feb 2022 05:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 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_H5=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI7mfw8m2KmK for ; Wed, 9 Feb 2022 05:53:28 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 6BD6F3A08FD for ; Wed, 9 Feb 2022 05:52:57 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar27.francetelecom.fr (ESMTP service) with ESMTPS id 4Jv1Y36ctnz2xlX; Wed, 9 Feb 2022 14:52:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1644414775; bh=mdhNGvNnaLGV6MFvt6pLSEVl8IBB965QFk8Zyt+A8Ao=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=MpBEQ69y1WknWfRrrsj560kQovs/jDUL8AnX80vZ/0MFSlOFhPyJnmI9RpOKcOw1x TrDOJdKhvoz1XvqaXOYatEWlsjkNgJbnFRjIvKlZuztu+afKedt9belSYegbaN5ecf fyAcVGhQVb8n/ENg+PMnzAUtuN8HBWCCUlTfPJp7/d7lLD5WNDeMLEAAEgl6ZXqElp 5BbH8OZbbzO3WMCxJHrRkY+WMUaWYbujzhL9ZFJ60mfeW0AgGlrDMg9pr6SYZiVyCJ cVwwNcK7407V2STyUUCXwdUlDWPuCIx14CDAPjpG23szgT9gK0hYUeGifZfSPVLTY0 AUWbpL4V5zdYw== From: To: Shraddha Hegde , "slitkows.ietf@gmail.com" , 'SPRING WG' , Huzhibo Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAJp/J6AAYpjRAAA587S8AB4oaLw Date: Wed, 9 Feb 2022 13:52:55 +0000 Message-ID: <22694_1644414775_6203C737_22694_159_24_cda1f000052240bba7ba3f8aefab7c4c@orange.com> References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <069201d8120e$dff706a0$9fe513e0$@gmail.com> <17040_1643808363_61FA866A_17040_245_14_bd3bfd409e6b45e38519a01045c163c9@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-09T13:52:53Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-09T13:52:53Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 2dff74b9-faef-4aec-be36-2e449b144d6d msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.26.53] Content-Type: multipart/alternative; boundary="_000_cda1f000052240bba7ba3f8aefab7c4corangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 09 Feb 2022 13:53:33 -0000 --_000_cda1f000052240bba7ba3f8aefab7c4corangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Speaking as individual contributor.] Shraddha, Many thanks for your replies. Some minor follow up inline [Bruno] Orange Restricted From: Shraddha Hegde Sent: Monday, February 7, 2022 5:09 AM To: DECRAENE Bruno INNOV/NET ; slitkows.ietf@gma= il.com; 'SPRING WG' ; Huzhibo Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Bruno, Snipped... 1. draft-ietf-spring-node-protection-for-sr-te-paths "If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires." * It's not crystal clear to me how it would work in reality, so I would= welcome more prescriptive text. In particular: * "node failure" is not an IGP message. IGP nodes sees multiple "adj= acency loss" messages which are not atomic and could be handled in multiple= SPFs. Hence different nodes will freeze their FIB based on a different top= ology (link1 for some, link2 for others) leading to inconsistent routing an= d forwarding loops. I will add text to capture this point and also add detailed text on po= ssible solutions. [Bruno] Good. Thanks. Looking forward for the revised draft. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. Agreed. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. I don't think we need any protocol extension for solutions described i= n this document but if WG thinks it should be a standard rather than infor= mational we should upgrade this document status IMO. [Bruno] To clarify, I had in mind the implementation/roadmap and deployabil= ity aspects: the FRR/context table feature might not be implemented by some= vendors/platforms, including for some hardware dataplane capability limita= tions; while the IGP restoration part would need to be implemented by all I= GP nodes. So as a network operator, for the latter (IGP restoration) I woul= d need to ask for the support of the RFC on all nodes, while for the former= (FRR) some vendors could not be able to implement the RFC. This would resu= lt in a blocked situation preventing deployment. In one way, that's an edit= orial point. In another way, in a FRR feature which is local by nature, one= can't ask for a new behavior on other nodes (not to mention all other node= s in the IGP). Thanks, Regards, --Bruno Rgds Shraddha Juniper Business Use Only From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: Wednesday, February 2, 2022 6:56 PM To: slitkows.ietf@gmail.com; 'SPRING WG' >; Huzhibo > Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding [External Email. Be cautious of content] Hi authors of both documents, WG, [Speaking as individual contributor.] It's good to see technical discussions on the restoration of failed SIDs us= ed by SR policy. 1. From a functional point of view, can we summarize the benefit to sign= al the node proxy capability? e.g. - drop the traffic earlier if the PLR does not support proxy capability. (h= elps with congestion) - use another proxy off the shortest path (increase congestion but reduce l= oss) - possibly help identifying the proxy (nominal is not in the reachable topo= logy anymore) ... Or agree on the absence of significant benefits? 1. draft-ietf-spring-node-protection-for-sr-te-paths "If the Node-SID or Prefix-SID becomes unreachable, the event and resulting forwarding changes should not communicated to the forwarding planes on all configured routers (including PLRs for the failed node) until the hold-timer expires." * It's not crystal clear to me how it would work in reality, so I would= welcome more prescriptive text. In particular: * "node failure" is not an IGP message. IGP nodes sees multiple "adj= acency loss" messages which are not atomic and could be handled in multiple= SPFs. Hence different nodes will freeze their FIB based on a different top= ology (link1 for some, link2 for others) leading to inconsistent routing an= d forwarding loops. * How is the FIB modified in cases of consecutives IGP events? (free= zed on hold topology may lead to drops, updating entries would need to be s= pecified. * On a side node, this text requires a global behavior of all IGP nodes= . That seem a bit out of scope of a non-normative sentence, in an informati= onal document, describing a local behavior on the PLR. 1. draft-hu-spring-segment-routing-proxy-forwarding Rather than defining a new "Proxy Forwarding" capability in IGP why don't y= ou use the existing Mirroring Segment (from RFC https://datatracker.ietf.or= g/doc/html/rfc8402#section-5.1) whose signaling is alre= ady standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4= .1 1. What about the following solution: * Use mirror SID * Tunnel to the "proxy-forwarding" advertising mirror SID I would see the following benefits: * No new protocol extensions (cf "3)" * Consistent routing in case of multiple SPFs (cf "2)") * Benefit from the signaling of the proxy (cf "1)") Thanks, Regards, --Bruno Orange Restricted From: slitkows.ietf@gmail.com > Sent: Tuesday, January 25, 2022 6:13 PM To: DECRAENE Bruno INNOV/NET >; 'SPRING WG' > Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi, I'm NOT supporting this draft for the following reasons: 1. The WG already have a WG document which is dealing with this problem,= I don't think that WG should come with multiple documents/solutions for th= e same solution space as it may just confuse the industry and create deploy= ment issues as different vendors may pick different solutions. 1. Adding protocols extensions adds complexity in the solution without a= dding a strong value. The document claims that "[I-D.ietf-spring-segment-protection-sr-te-paths] = ... may not work for some cases such as some of nodes in the network not su= pporting this solution.". While this is true, the proposed solution in draf= t-hu-spring-segment-routing-proxy-forwarding has exactly the same caveat an= d requires all nodes in the network to support the solution. Considering the following straight line network: A -B -C -D - E - F - G -H = and an SR policy from A to H using SID_G, routers A to F have to support th= e extension to make the solution working, if one of the router doesn't supp= ort the extension, traffic will be dropped. Then, there is no value compared to the timer-based solution of [I-D.ietf-s= pring-segment-protection-sr-te-paths] Authors of draft-hu-spring-segment-routing-proxy-forwarding argued that G m= ay have multiple upstream neighbors let's say F and F' and the solution all= ows for F' to support the extension while F may not support, so the solutio= n will send the traffic to F'. Well yes, but this still requires all router= s upstream to F' to support this extension and maybe F is on the path to F'= . So, I don't think the argument is valid as it may possibly work tacticall= y depending on the network topology when we look at a small portion of the = network, but when we look at the whole network, operator will have to upgra= de all their nodes to support the extension to ensure the benefit is there. In addition, in term of traffic, forwarding traffic to a neighbor of the fa= iled node which wasn't initially on the path, could lead to traffic congest= ion or high traffic peaks on links that were not sized to carry this traffi= c. We could easily expect some traffic tromboning, where traffic goes to th= is non-natural neighbor of the failed node and then goes back over some par= t of the same path before reaching the destination. So these protocol extensions are bringing complexity for no value here. 1. Regarding BSID, I'm not fan of advertising BSIDs in IGP as there may = be hundreds or thousands of BSID on a node which again will create a lot of= burden in IGP. The proposed way will have to be discussed in LSR, not in S= PRING (see next comment). Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could also work = with BSIDs as long as BSID information of failed node is available in the c= ontrol-plane of PLRs by whatever mechanism. I think this BSID handling is o= rthogonal to the proxy-forwarding controlplane behavior. The forwarding ope= rations for BSID will have to be discussed more in details, we could not ex= pect all HW to be able to do 3 or 4 lookups without any perf degradation. 1. The document is currently a bit borderline between SPRING and LSR as = it talks in good details about IGP protocol extensions. If it's a SPRING do= c, it should detail reqs for protocols but nothing beyond. Brgds, Stephane From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: jeudi 13 janvier 2022 11:19 To: SPRING WG > Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote. If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_cda1f000052240bba7ba3f8aefab7c4corangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Speaking as i= ndividual contributor.]

 

Shraddha,

 

Many thanks for your replies.

Some minor follow up inline [Bruno]

 

 

 

Orange Restricted

From: Shraddha Hegde <shraddha@juniper.net>
Sent: Monday, February 7, 2022 5:09 AM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; slit= kows.ietf@gmail.com; 'SPRING WG' <spring@ietf.org>; Huzhibo <huzhi= bo@huawei.com>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Bruno,

 

Snipped…

  1. draft-ietf-spring-node-protection-for-sr-te-paths=

 

“If the Node-= SID or Prefix-SID becomes

   unreac= hable, the event and resulting forwarding changes should not

   commun= icated to the forwarding planes on all configured routers=

   (inclu= ding PLRs for the failed node) until the hold-timer expires.”

 

  • It’s not crystal clear to me how it would work in reality, so I would welcome more prescriptive text. In particular:=
    • “node failure” is not an IGP message. IGP nodes sees multiple “adjacency loss” messages which are not at= omic and could be handled in multiple SPFs. Hence different nodes will free= ze their FIB based on a different topology (link1 for some, link2 for other= s) leading to inconsistent routing and forwarding loops.

<SH> I w= ill add text to capture this point and also add detailed text on possible s= olutions.

 

[Bruno] Good. Thanks. Looking forward for the revised draft.

 

    • How is the FIB modified in cases of consecutives IGP events? (freezed on hold topology may lead to drops, updating entries = would need to be specified.

<SH> Agr= eed.

  • On a side node, this text requires a global behavior of all IGP nodes. That seem a bit out of scope of a non-normative= sentence, in an informational document, describing a local behavior on the= PLR.

<SH> I don’t think we need any protocol extension for soluti= ons described in this document but if  WG thinks it should be a standa= rd rather than informational

we should upgrade this document status IMO.

 

[Bruno] To clarify, I had in mind the implementation/roadmap and deploya= bility aspects: the FRR/context table feature might not be implemented by s= ome vendors/platforms, including for some hardware dataplane capability limitations; while the IGP restoration part = would need to be implemented by all IGP nodes. So as a network operator, fo= r the latter (IGP restoration) I would need to ask for the support of the R= FC on all nodes, while for the former (FRR) some vendors could not be able to implement the RFC. This would resu= lt in a blocked situation preventing deployment. In one way, that’s a= n editorial point. In another way, in a FRR feature which is local by natur= e, one can’t ask for a new behavior on other nodes (not to mention all other nodes in the IGP).=

 

Thanks,

Regards,

--Bruno

 

Rgds

Shraddha

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, February 2, 2022 6:56 PM
To: slitkows.ietf@gmail.c= om; 'SPRING WG' <spring@ietf.org<= /a>>; Huzhibo <huzhibo@huawei.c= om>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

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

 

Hi authors of = both documents, WG,

 

[Speaking as i= ndividual contributor.]

 

It’s goo= d to see technical discussions on the restoration of failed SIDs used by SR= policy.

 

  1. From a functional point of view, can we summarize the benefit to signal the node proxy capability?

e.g.

- drop the tra= ffic earlier if the PLR does not support proxy capability. (helps with cong= estion)

- use another = proxy off the shortest path (increase congestion but reduce loss)

- possibly hel= p identifying the proxy (nominal is not in the reachable topology anymore)<= o:p>

…

Or agree on th= e absence of significant benefits?

 

  1. draft-ietf-spring-node-protection-for-sr-te-paths=

 

“If the Node-= SID or Prefix-SID becomes

   unreac= hable, the event and resulting forwarding changes should not

   commun= icated to the forwarding planes on all configured routers=

   (inclu= ding PLRs for the failed node) until the hold-timer expires.”

 

  • It’s not crystal clear to me how it would work in reality, so I would welcome more prescriptive text. In particular:=
    • “node failure” is not an IGP message. IGP nodes sees multiple “adjacency loss” messages which are not at= omic and could be handled in multiple SPFs. Hence different nodes will free= ze their FIB based on a different topology (link1 for some, link2 for other= s) leading to inconsistent routing and forwarding loops.
    • How is the FIB modified = in cases of consecutives IGP events? (freezed on hold topology may lead to drops, updating entries = would need to be specified.
  • On a side node, this text requires a global behavior of all IGP nodes. That seem a bit out of scope of a non-normative= sentence, in an informational document, describing a local behavior on the= PLR.

&n= bsp;

 

  1. draft-hu-spring-segment-routing-proxy-forwarding<= /o:p>

Rather than de= fining a new “Proxy Forwarding” capability in IGP why don’= ;t you use the existing Mirroring Segment (from RFC https://datatracker.ietf.org/doc/html/rfc8402#section-5.1) whose signal= ing is already standardized? https://datatracker.ietf.org/doc/html/rfc8667#section-2.4.1<= /span>

 

  1. What about the following solution:
  • Use mirror SID
  • Tunnel to the “proxy-forwarding” advertising mirror SID

 

I would see th= e following benefits:

  • No new protocol extensions (cf “3)”
  • Consistent routing in case of multiple SPFs (cf “2)”)
  • Bene= fit from the signaling of the proxy (cf “1)”)

 

Thanks,

Regards,<= /o:p>

--Bruno

 

 

Orange Restricted

From: slitkows.ietf@gmail.com <= slitkows.ietf@gmail.com>
Sent: Tuesday, January 25, 2022 6:13 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; 'SPRING WG' <spring@ietf.org>
Subject: RE: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi,

 

I’m NOT supporting this draft for the following reasons:

 

  1. The WG already have a WG document whi= ch is dealing with this problem, I don’t think that WG should come with multiple documents/solutions for the same solution spa= ce as it may just confuse the industry and create deployment issues as diff= erent vendors may pick different solutions.

 

  1. Adding protocols extensions adds comp= lexity in the solution without adding a strong value.

 

The document claims that “[I-D= .ietf-spring-segment-protection-sr-te-paths] … may not work for some = cases such as some of nodes in the network not supporting this solution.”. While this is true, the proposed solution in draft-= hu-spring-segment-routing-proxy-forwarding has exactly the same caveat and = requires all nodes in the network to support the solution.

 

Considering the following straight l= ine network: A -B -C -D – E – F - G -H and an SR policy from A = to H using SID_G, routers A to F have to support the extension to make the solution working, if one of the router doesn’t= support the extension, traffic will be dropped.

 

Then, there is no value compared to = the timer-based solution of [I-D.ietf-spring-segment-protection-sr-te-paths= ]

 

Authors of draft-hu-spring-segment-r= outing-proxy-forwarding argued that G may have multiple upstream neighbors = let’s say F and F’ and the solution allows for F’ to support the extension while F may not support, so the solu= tion will send the traffic to F’. Well yes, but this still requires a= ll routers upstream to F’ to support this extension and maybe F is on= the path to F’. So, I don’t think the argument is valid as it may possibly work tactically depending on the network topology= when we look at a small portion of the network, but when we look at the wh= ole network, operator will have to upgrade all their nodes to support the e= xtension to ensure the benefit is there.

 

In addition, in term of traffic, for= warding traffic to a neighbor of the failed node which wasn’t initial= ly on the path, could lead to traffic congestion or high traffic peaks on links that were not sized to carry this traffic. = We could easily expect some traffic tromboning, where traffic goes to this = non-natural neighbor of the failed node and then goes back over some part o= f the same path before reaching the destination.

 

So these protocol extensions are bri= nging complexity for no value here.

 

 

  1. Regarding BSID, I’m not fan of = advertising BSIDs in IGP as there may be hundreds or thousands of BSID on a node which again will create a lot of burden in IGP. The prop= osed way will have to be discussed in LSR, not in SPRING (see next comment)= .

 

Note that [I-D.ietf-spring-segment-protection-sr-te-paths] could = also work with BSIDs as long as BSID information of failed node is availabl= e in the control-plane of PLRs by whatever mechanism. I think this BSID handling is orthogonal to the proxy-forwardin= g controlplane behavior. The forwarding operations for BSID will have to be= discussed more in details, we could not expect all HW to be able to do 3 o= r 4 lookups without any perf degradation.

 

  1. The document is currently a bit borde= rline between SPRING and LSR as it talks in good details about IGP protocol extensions. If it’s a SPRING doc, it should detai= l reqs for protocols but nothing beyond.

 

 

 

Brgds,

 

Stephane

 

 

From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decr= aene@orange.com
Sent: jeudi 13 janvier 2022 11:19
To: SPRING WG <spring@ietf.org= >
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,<= /o:p>

 

This message s= tarts a 2 week WG adoption call, ending 27/01/2022, for draft-hu-spring-seg= ment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/dr= aft-hu-spring-segment-routing-proxy-forwarding/

 

After review o= f the document please indicate support (or not) for WG adoption of the docu= ment to the mailing list.

 

Please also pr= ovide comments/reasons for your support (or lack thereof) as this is a stro= nger way to indicate your (non) support as this is not a vote.     

 

If you are wil= ling to work on or review the document, please state this explicitly. This = gives the chairs an indication of the energy level of people in the working group willing to work on the document.=

 

Thanks!

Bruno, Jim, Joel

_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_cda1f000052240bba7ba3f8aefab7c4corangecom_-- From nobody Wed Feb 9 19:41:24 2022 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 7FDAD3A1352 for ; Wed, 9 Feb 2022 19:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_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 SC80FnHJpT0H for ; Wed, 9 Feb 2022 19:41:16 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2130.outbound.protection.outlook.com [40.107.237.130]) (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 A3F023A1354 for ; Wed, 9 Feb 2022 19:41:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WkDA3Mo0BbY8NLQyJpGL92/nvtGls2dV8JZ/zfE5i/IGCYeMfedPMCNB1dSXpETqVqOYpKFdjQvLVtocfhotA3u5Jk7R4SsongGL2dJhGFKR7T5WWOlY7MD0RwFb4sR581oVzShMwDUlPOvPUHvv9WWT9mpPMMosjTpU5EvjV4caLD8tifa37vxtL+h7oAlSJ835TWs2g2rK3XefwqtGDYTsnQuVSazHLPTx6gECeLpFUg++8Zg/E+3RFxgrvEtw6tSMYLfC6gnE4Z3MK8ejzCUZWx48wUu7n5qFTPTrJ5L5CBzLMVyvaPsMkrIuE/O3PPW4ocvFXPYZbkhgKzqmIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zAN4NpjfG36zuWYVxq1Dk49Nv1aCttPWOph5wVy/NZw=; b=N0zBXdfv4FTY0iyndTbi2th4B8m5snbqJEwA+fBwAOK2dUjNTauC408HYf2Xkzr5GYWZ/nOK4+mpAihiPFvovd6ovFIY1NZ4hgm4s+qSpovgsxhD8QkDuOW/uNd9ZB72xuR1Bey/fMjTrP+hnBHqSbzZlqc40L/bwCGgPyfclVRJcZetLVkSC8kU/ojL5knYFOsRx0CZokpPSvp6NlOQoK1SfQAzkEmFQUnzMze0TFtLMCnyO8oVSFF6/nZqQEgDV8uTChp0obVuMxsBK+BihqqOvB/BF/qGaXbFO0VVtAgUzrAEiw/9hVtuPCEFbVPwolUBFTP9sndcbpCRH76qHQ== 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=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zAN4NpjfG36zuWYVxq1Dk49Nv1aCttPWOph5wVy/NZw=; b=sD1gmuK1YHRjBN8S9wN14UHppTR+5dW1nZorWcXZedaJ9BdMFOF1ymdC9Aw7b4reGgrMfuonlRyNvo95FtmneJkrgr+kto8UJ87PVwYHO5Xr4aXSKqr9yf4LqodsPOs4vGr7nOuVnSJV3ihSIFMj7GFuncabDK06JNZFnQ5U4YY= Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by MW4PR13MB5601.namprd13.prod.outlook.com (2603:10b6:303:180::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.9; Thu, 10 Feb 2022 03:41:10 +0000 Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059%6]) with mapi id 15.20.4995.006; Thu, 10 Feb 2022 03:41:10 +0000 From: Huaimo Chen To: Greg Mirsky CC: Bruno Decraene , SPRING WG Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAUzUcCAAApCg5kAA/cJgAAwZGo8 Date: Thu, 10 Feb 2022 03:41:10 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: e47b5c29-99c6-b69f-b7d5-10dd996380de authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 653266de-915d-4111-11b3-08d9ec472e0b x-ms-traffictypediagnostic: MW4PR13MB5601:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gW6ek4WPlPjLK2bHmKRhS2jZskacRKxP7MIUVAFfEEZPfD7gkgQ2ojYxJ7HSaZgAPU9S5m0aGaM4bMhiXtBlN7mcv5Var0QRv8rH1F+vzPfuX+QoKJ94+/k82fPwD4XVtx41nX+Tgzf4tP3JMoLbVwptkP/TwFibpeg9QVbDkr8kj2x09bj9UYxQXlZ92driazODI5eNA3XxdvifxqrV9KD5abxJpZsf8LRWseAndIyoQlCkg8+S9IAgBRwr/MU+EckQEVoSWhwsnR42EzJjTHxtxCITbYX1m+rA3zt4cbUSQqDgSggzPpapbL52qWapwidXc4lNqua1jPUZQkunKWilGagGoqWukHAEEpJWdGF8kjVBIuNwWsmgFPT5u+oDmqcdr0uhrwxT1skl1g7/CYiwe24B0LdhFIsBh7F8s4mnXY2dM6gyVd4BkopGNjorWeVj/1jY5yQp/oBUIlqQP4pCR0hJTWgR2V3Krtmw35gM6ptup12aKwKzmNMLnOhzPuvZoWvsB8dZocrO4HE/urVl+DwVxIB1OKEYO7BIzXf8Nep5RmxmNRAQytWGofxs5wxJbnXdRB8tqx2ua134GnLZLpQCaxXFSPcHXSOlR4k9U7nPS6XMmK8s6Mb0quteArB/YoeucvcZ3+TcgNWxPao7yZslLi2i8XFUk5mJ99rINEdsKUHT9/7TFSdy9MRUMrEmVO0eVeQN9Wb4O4rCyvHYeMibbm1OozonjU1rEVrNnB1BvJzJ6J75YRy7hJCc2dvWaQi1HStMD1/hTdUbaiH9VFYuEVbXWOxaGqJJ4FVk4SgnD0paq8kAR3VHxzGRzSdHyZNMxgK0TEJlYZcFDg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(4326008)(2906002)(38100700002)(6916009)(76116006)(54906003)(71200400001)(166002)(38070700005)(33656002)(9686003)(66946007)(316002)(122000001)(7696005)(508600001)(6506007)(966005)(26005)(86362001)(8676002)(52536014)(5660300002)(19627405001)(66476007)(64756008)(66556008)(44832011)(53546011)(8936002)(55016003)(186003)(66446008)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?9bRmVYt8xLFK3xPjhzCF9Za6dWMF7OVZQz/PrjulNiN7nWhXLmUFzyJase?= =?iso-8859-1?Q?jkiNciBxyIBOjIy+BkvrjitnKccJl+NGhcnriHSgRdrhi79sKqpR/MI446?= =?iso-8859-1?Q?FpJIFB/6AGNtzAlF9uP68LYDlciPl/ojXy1pIeOw0vuAmxv4nbNfkg8u00?= =?iso-8859-1?Q?Y3E5UGe+jPaXwZNQBRDh2In111hCyYz1n2byvzcZq08MFUuO1ViMDB6yeW?= =?iso-8859-1?Q?D2s0M64JTbXOAp0tfP+U8sPo9V6yR7ZoMAg6WWHurvR84yGVDVKNV+/xdV?= =?iso-8859-1?Q?Sm+1jnfKiGGILX+h744gKnfs6TS2tJxwSJO0dNrw7Ax/jJbP+Skem7yW6r?= =?iso-8859-1?Q?OO5ntoj6r0wdMldKuUlgUrMmdmDBDC9IoxSjg/T0XLnFMFU75/0Hmi450Y?= =?iso-8859-1?Q?27b9d28dLFks4W1NvZEzQrbnvo8AgFtAYqo9XsemUQ/om92uxZ7r2PBzGN?= =?iso-8859-1?Q?M0ygyLf4ASNS9gXPELHYtPaxoMINtbM7MownmP49MM4K+EdKVD75uVnQnn?= =?iso-8859-1?Q?ZLHED2cJEi1yUe7eUY22wLeInOuvkAqAcQEz3MQBBi5Mo06p34GZ2ohROr?= =?iso-8859-1?Q?iqanhv8qkyu2aU1DEGyf175tQ6V3GaBB8HKWMcAGabJg5SaDS9QIo7gbUd?= =?iso-8859-1?Q?TAMF7pULrZghR75Qa8t+4QH4AtkUWF2usgQPbTytPa+Tsn3xJOdWe7mKGn?= =?iso-8859-1?Q?beN8wAHj7m/m3PhtKWa6IdqJXORBplbFwAghcagcuDzzYEFwuVfPfVMXkT?= =?iso-8859-1?Q?T9zVWnVpqkRAIJDzBkq+HW+8dPRhnm0QZ5HnqDTclRIrwjoQ2nFy7KpTvO?= =?iso-8859-1?Q?mc6HCB9hwmH3vv/YRJInEBAwx5zN4Rgk4bP3fNHWKCFXQbKfj+XHvtcRVt?= =?iso-8859-1?Q?dOAQ6jJeAX5ri4FyzUa+oCXn2pj+ayH4rGRJ4CgUEC6mjcec9L1pshj9oC?= =?iso-8859-1?Q?oKvI1CHZDAZciPKbq9K6jKfj/ifrcDXLrZIh0hcGLL3hLP4/C0yPFl9JxK?= =?iso-8859-1?Q?pURnNZgyWv0O8LNDQHU0rMc0ch5uk1Hq8tFdCGOl/3bak4cIM/Jg1/Oyjf?= =?iso-8859-1?Q?A8q5gxHOOQpjTMMH84/NXJs6qn+xnhIMwVXvIFCkiNi7TDhcSDkGmYgZAN?= =?iso-8859-1?Q?J9sQHb87lw5UkKmFTGnQJ71aINmDlmggDh0uQwMIemNKDdvIhPII5IlebK?= =?iso-8859-1?Q?3WSqOwJeyjHL6y+Ej2J/RQSxhJOyZc9ea+cWi3NOB/e21bcJ/ArSG5W1W9?= =?iso-8859-1?Q?ZQUvnxf66TnikuEub5sRbTdVK59YG/EstINaJ9qiX+PT+x251XyYx+az1x?= =?iso-8859-1?Q?g6Yrlb+iaMcC+yOseYipJjcpMSFqZ+wP3apR8avVls3WoQnGKp94d9RoQA?= =?iso-8859-1?Q?ZbFDXrYfWUNqke+ecbRhlg52lW0Mv3lWvTgwMl5bGkBxk+kqWOTxYUMgrd?= =?iso-8859-1?Q?wA9fOkw/+Ug84KmoNttaIdHuFL+eg64KMbpEbqASVkp0Eh7aXvlVuj4dB1?= =?iso-8859-1?Q?93ntKrRCaFefCwHeaqWgQXxBMqbNal95cxlZsWMBfsf0liCQ0BZnl6PPUz?= =?iso-8859-1?Q?y453d0xxcgFTaIBK448fena9rQ7obr0iyAZM2VqTX1Ezq+ZrFSy7MRD6XD?= =?iso-8859-1?Q?6apceueAWonODj2oEU0qEQBoMrLHVB6LPwGU9qLRVjyz51L29cySiZnA?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB50446E07FEB636C3F93BD210F22F9BY3PR13MB5044namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 653266de-915d-4111-11b3-08d9ec472e0b X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 03:41:10.7540 (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: mfYHv+5Jdb4i4Mnkc3kYhndR2PvBFE8rOXpjIQRLOSsSpsjlE9LhV/7pZFNrEV5ael7Lrz0/vVQCAun1kQG3jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR13MB5601 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 10 Feb 2022 03:41:22 -0000 --_000_BY3PR13MB50446E07FEB636C3F93BD210F22F9BY3PR13MB5044namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you very much for your notes. My responses/explanations are inline below with [HC2]. Best Regards, Huaimo ________________________________ From: Greg Mirsky Sent: Tuesday, February 8, 2022 11:25 PM To: Huaimo Chen Cc: Bruno Decraene ; SPRING WG Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi Huaimo, thank you for the expedient response. Please find my follow-up notes in-lin= ed below under the GIM>> tag. Regards, Greg On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen > wrote: Hi Greg, Thank you very much for your comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: spring > on b= ehalf of Greg Mirsky > Sent: Tuesday, February 8, 2022 4:38 PM To: Bruno Decraene > Cc: SPRING WG > Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Dear Authors, et al., I've read the draft and would appreciate it if the authors can clarify one = question: * What do you consider as the significant advantage of the mechanism de= fined in your draft compared with the mechanism defined in draft-ietf-sprin= g-segment-protection-sr-te-paths? As I've compared the two solutions, I couldn't find any significant advanta= ge of the proxy forwarding to have two standardized mechanisms for SR path = e2e protection. It might be reasonable to have one standard while other pro= posals get experimental status? [HC]: It provides more protection coverage in some cases as compared to the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths. GIM>> I find it hard to quantify your characterization. I imagine that if a= n operator uses the protection mechanism defined in draft-ietf-spring-segme= nt-protection-sr-te-paths it designs the network with that in mind and thus= minimizes if not completely avoids any possible limitation the protection = mechanism may have. Perhaps you can help with some more specific scenarios. [HC2]: Assume that a SR path has the SID of a node N and node N failed. For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths, if a node X on the shortest path from a upstream node to N does not support the mechanism, node X drops the traffic transported by the path. For the solution in our draft, proxy capable nodes off node X on the shorte= st path to a neighbor of N are used. The neighbor re-routes the traffic around failed node N towards the destination. The traffic is protected. This improves the reliability of networks, and QoE. This should be a significant advantage. There is no solution for BSID protection in the other existing draft. GIM>> Though BSID may be used inside the network, I find such use case ques= tionable making no significant impact on the usefulness of the protection m= echanism. [HC2]: Considering two drafts A and B. Draft A supports protection of a SR path, which contains two types of components, say C1 and C2. If the path contains a third type of components, say, C3, then protection of the path for C3 is not supported. Draft B supports protection of a SR path, containing C1, C2 and C3. In this case, draft B seems having a significant advantage over draft A. The solution for BSID protection in our draft has been there for a few years. In addition, after a node failed, in our solution, the nodes of the entire network converge to the latest state consistently in time. After a node failed, the mechanism defined in the other existing draft holds off the FIB during the HoldTimer period configured, when the network changes again, GIM>> I consider that property of the protection defined in draft-ietf-spri= ng-segment-protection-sr-te-paths as a benefit that allows better control f= or the proper coordination between protection mechanisms that operate on di= fferent network layers. our solution continues to converge at any time. The mechanisms in two drafts are different. It seems ok and reasonable to have the two drafts to be adopted in the WG. GIM>> I agree with you, drafts are fundamentally different and, in my opini= on, merging them would not change the situation. But I don't see that as th= e justification for producing two standards. It seems to me, releasing two = standard-based specifications might be detrimental and I propose the author= s consider taking this draft onto the experimental track. I'd support the a= doption of it as the experimental track document. Regards, Greg On Thu, Jan 13, 2022 at 2:19 AM > wrote: Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ 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_BY3PR13MB50446E07FEB636C3F93BD210F22F9BY3PR13MB5044namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greg,

    Thank you very much for your notes.

    My responses/explanations are inline below with [HC2].

Best Regards,
Huaimo

From: Greg Mirsky <gregi= mirsky@gmail.com>
Sent: Tuesday, February 8, 2022 11:25 PM
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>; SPRING WG <= spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 
Hi Huaimo,
thank you for the expedient response. Please find my follow-up notes i= n-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Feb 8, 2022 at 6:35 PM Huai= mo Chen <huaimo.chen@future= wei.com> wrote:
Hi Greg,

    Thank you very much for your comments.

    My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors

Fr= om: spring <spring-bounces@ietf.org> on behalf of Greg Mirsky <greg= imirsky@gmail.com>
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 
Dear Authors, et al.,
I've read the draft and would appreciate it if the authors can clarify= one question:
  • What do you consider as the significant advantage of the mechanism defi= ned in your draft compared with the mechanism defined in draft-ie= tf-spring-segment-protection-sr-te-paths?
As I've compared the two solutions, I couldn't find any significant advanta= ge of the proxy forwarding to have two standardized mechanisms for SR path = e2e protection. It might be reasonable to have one standard while other pro= posals get experimental status?
[HC]: It provides more protection coverage in some cases as compared t= o
the mechanism defined in draft-ietf-spring-segment-protection-sr-te-pa= ths.
GIM>> I find it hard to quantify your characterization. I imagin= e that if an operator uses the protection mechanism defined in draft-ietf-s= pring-segment-protection-sr-te-paths it designs the network with that in mi= nd and thus minimizes if not completely avoids any possible limitation the protection mechanism may have. Perhaps = you can help with some more specific scenarios. 
[HC2]: Assume that a SR path has the SID of a node N and node N failed= .
For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths,=
if a node X on the shortest path from a upstream node to N does not
support the mechanism, node X drops the traffic transported by the pat= h.
For the solution in our draft, proxy capable nodes off node X on the s= hortest
path to a neighbor of N are used. The neighbor re-routes the traffic a= round
failed node N towards the destination. The traffic is protected.
This improves the reliability of networks, and QoE. This should be a <= /div>
significant advantage. There is no solution for BSID protection in the=
other existing draft.
GIM>> Though BSID may be used inside the network, I find such us= e case questionable making no significant impact on the usefulness of the p= rotection mechanism. 
[HC2]: Considering two drafts A and B. Draft A supports protection
of a SR path, which contains two types of components, say C1 and C2. <= /div>
If the path contains a third type of components, say, C3, then  <= /div>
protection of the path for C3 is not supported.
Draft B supports protection of a SR path, containing C1, C2 and C3. In this case, draft B seems having a significant advantage over draft= A.
The solution for BSID protection in our draft has
been there for a few years. In addition, after a node failed, in
our solution, the nodes of the entire network converge to the latest <= /div>
state consistently in time. After a node failed, the mechanism defined=
in the other existing draft holds off the FIB during the HoldTimer
period configured, when the network changes again,
GIM>> I consider that property of the protection defined in draf= t-ietf-spring-segment-protection-sr-te-paths as a benefit that allows bette= r control for the proper coordination between protection mechanisms that op= erate on different network layers. 
our solution continues
to converge at any time.
The mechanisms in two drafts are different. It seems ok and reasonable=
to have the two drafts to be adopted in the WG.
GIM>> I agree with you, drafts are fundamentally different and, = in my opinion, merging them would not change the situation. But I don't see= that as the justification for producing two standards. It seems to me, rel= easing two standard-based specifications might be detrimental and I propose the authors consider taking this draft = onto the experimental track. I'd support the adoption of it as the experime= ntal track document.


Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <bruno.decraene@orange.com> = wrote:

Dear WG,

 

This message starts a 2 week WG adoption call, ending 27/01/2022, for d= raft-hu-spring-segment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/d= raft-hu-spring-segment-routing-proxy-forwarding/

 

After review of the document please indicate support (or not) for WG ad= option of the document to the mailing list.

 

Please also provide comments/reasons for your support (or lack thereof)= as this is a stronger way to indicate your (non) support as this is not a = vote.     

 

If you are willing to work on or review the document, please state this= explicitly. This gives the chairs an indication of the energy level of peo= ple in the working group willing to work on the document.

&nbs= p;

Thank= s!

Bruno, Jim,= Joel

______________________________________________________________________=
___________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.o= rg/mailman/listinfo/spring
--_000_BY3PR13MB50446E07FEB636C3F93BD210F22F9BY3PR13MB5044namp_-- From nobody Thu Feb 10 02:40:47 2022 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 66E5C3A0C86; Thu, 10 Feb 2022 02:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07xLSlH7LByR; Thu, 10 Feb 2022 02:40:38 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 C30063A0C9D; Thu, 10 Feb 2022 02:40:37 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr23.francetelecom.fr (ESMTP service) with ESMTPS id 4JvYDf2CQrz5w7K; Thu, 10 Feb 2022 11:40:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1644489634; bh=G14dQxqsz+UqvcpdMMeKo20j4HdQ1d8x8CXRKLoZeGk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=mEjJnAYZ//+E8FgPM+eXnpMTd3aqIeXz7IxxAYWxMNUPis9BjneNdM72IukPb3uWb hfq4vB+NMa2kSYH4ARSnCYkgEBWIyk9fb3U7kMf4QY2JgvK7qIVkmof9k+4Q65KT2h Ny0McbJLggb7hk9uMtCYXcSf1HVTz/MGX+fHVRTEd4iQin2tMTl+v5mwzwV6GTU+PW BorbvcK3CzgOe39J1a3Sm/iVgUCSIHNgSle2jDiG/EuGz4QtozyPtSeHxkzDrc2gx5 eyp1Bh/UvjubrCjtOiG/ATAJ9r8j8cm0e1n6hKvoucbUZNv+KlXdkH8pl71ZTzqYL8 N3eYFf7tUW6qA== From: To: Huaimo Chen , "draft-hu-spring-segment-routing-proxy-forwarding@ietf.org" CC: SPRING WG Thread-Topic: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAUck9ggAB9SmygARHZLMA== Date: Thu, 10 Feb 2022 10:40:33 +0000 Message-ID: <12661_1644489634_6204EBA2_12661_22_4_c455becb2c3d432eab5081694ba5c4b4@orange.com> References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <17506_1644318086_62024D86_17506_388_1_25c99d808d0f4185a9d9005debbbab5b@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-10T10:40:32Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-10T10:40:32Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: a8b82573-e276-498e-a189-c0ad8bae4911 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.26.53] Content-Type: multipart/alternative; boundary="_000_c455becb2c3d432eab5081694ba5c4b4orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 10 Feb 2022 10:40:44 -0000 --_000_c455becb2c3d432eab5081694ba5c4b4orangecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [speaking as WG contributor] Hi Huaimo, Thanks for the follow up. Please see one point inline [Bruno] Orange Restricted From: spring On Behalf Of Huaimo Chen Sent: Wednesday, February 9, 2022 2:48 AM To: DECRAENE Bruno INNOV/NET ; draft-hu-spring-s= egment-routing-proxy-forwarding@ietf.org Cc: SPRING WG Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi Bruno, Thank you very much for your valuable comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: bruno.decraene@orange.com > Sent: Tuesday, February 8, 2022 6:01 AM To: draft-hu-spring-segment-routing-proxy-forwarding@ietf.org > Cc: SPRING WG > Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwa= rding [speaking as WG contributor] Hi authors, all I have some comments specific to the binding SID aspect. =A72 " For a binding segment of a possible failed node, the node advertises the information about the binding segment, including the binding SID and the list of SIDs associated with the binding SID, to its direct neighbors only. Note that the information is not advertised in the network domain. =BB =A73.2.2 "For supporting binding SID proxy forwarding, a new IS-IS TLV, called Binding Segment TLV, is defined. It contains a binding SID and a list of segments (SIDs). This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. =BB >From an IS-IS standpoint, it seems to me that: - Advertising it in the LSP PDU would flood the information in the whole= area/level, hence does not match the goal stated in =A72 - Advertising it in the Hello PDU is not a reliable way to sync informat= ion (except if duplicated in all hello which implies others issues such as = lack of space) and adding the reliability seem like a major change to IS-IS In all cases, as already raised by St=E9phane, this is a subject for the LS= R WG. [HC]: We will remove IS-IS Hello (IIH) PDUs and LSPs, and update the related text accordingly. More importantly, the binding SIDs are probably coming from "somewhere" suc= h as configuration, PCE, BGP, BGP-LS... Why not using the exact same signal= ing to duplicate it on the neighbors? (this may probably require some exten= sions for some protocols but a priori light ones and would not impact the I= GP with information which may not belong to the IGP.) [HC]: Using the same signaling (configuration, PCE, or BGP, ...) to duplicate it on the neighbors works well if there are sessions between the neighbors and PCE, or BGP, ... [Bruno] Indeed, signaling session would be needed. That seems doable =E0 pr= iori (especially if we assume that BSID may already be needed on other node= s) My point is that _today_, using BSID requires configuration/signaling of th= is BSID on the BSID node itself and on all ingress nodes using it. None of = these signaling involves the IGP. So it's not clear to me that IGP would be= the obvious choice specifically for the neighbors of the protected node, w= hile a different protocol would be used for the BSID on the protected and i= ngress nodes. Theoretically feasible but, IMHO as a network operator subjec= t, subject to a risk of lack of feature parity in short and long term. At m= inimum I would expect the document to (also) explore how this could be perf= ormed using the protocols signaling the BSID on the protected node and ingr= ess (e.g. PCE, BGP, configuration). Also in my experience, the LSR WG is us= ually not that found of using the IGP for configuration/signaling. Thanks, Regards, --Bruno Orange Restricted From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: Thursday, January 13, 2022 11:19 AM To: SPRING WG > Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote. If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_c455becb2c3d432eab5081694ba5c4b4orangecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[speaking as = WG contributor]

 

Hi Huaimo,

 

Thanks for the follow up.

Please see one point inline [Bruno]

 

 

Orange Restricted

From: spring <spring-bounces@ietf.org> On Behalf Of Huaimo Chen
Sent: Wednesday, February 9, 2022 2:48 AM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; draf= t-hu-spring-segment-routing-proxy-forwarding@ietf.org
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi Bruno,

 

    Thank you very m= uch for your valuable comments.

 

    My responses/exp= lanations are inline below with [HC].

 

Best Regards,

Huaimo

on behalf of co-authors

[speaking as = WG contributor]

 =

Hi authors, a= ll

 =

I have some c= omments specific to the binding SID aspect.

 = 

=A72

“   For a binding segment = of a possible failed node, the node advertises

   the information about the bin= ding segment, including the binding SID

   and the list of SIDs associat= ed with the binding SID, to its direct

   neighbors only.  Note th= at the information is not advertised in the

   network domain. =BB

 =

=A73.2.2

   &#=
8220;For supporting binding SID proxy forwarding, a new IS-IS TLV, called
   Bi=
nding Segment TLV, is defined.  It contains a binding SID and a=

   li=
st of segments (SIDs).  This TLV may be advertised in IS-IS Hello
   (I=
IH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP)
   [R=
FC7356]. =BB
 
From an IS-IS standpoint, it seems to me that:
-    Advertising it in t=
he LSP PDU would flood the information in the whole area/level, hence does =
not match the goal stated in =A72
-    Advertising it in t=
he Hello PDU is not a reliable way to sync information (except if duplicate=
d in all hello which implies others issues such as lack of space) and addin=
g the reliability seem like a major change to IS-IS
In all cases, as already raised by St=E9phane, th=
is is a subject for the LSR WG.
[HC]: We will remove IS-IS Hello (IIH) PDUs and L=
SPs, and update the
related text accordingly. 
 

More importantly, the binding SIDs ar= e probably coming from “somewhere” such as configuration, PCE, = BGP, BGP-LS… Why not using the exact same signaling to duplicate it on the neighbors? (this may probably require some extensions for some p= rotocols but a priori light ones and would not impact the IGP with informat= ion which may not belong to the IGP.)

[HC]: Using the same signaling (confi= guration, PCE, or BGP, ...) to

duplicate it on the neighbors works well if there are sessio= ns between

the neighbors and PCE, or BGP, ...

 =

[Bruno] In= deed, signaling session would be needed. That seems doable =E0 priori (espe= cially if we assume that BSID may already be needed on other nodes)

My point i= s that _today_, using BSID requires configuration/signaling of this = BSID on the BSID node itself and on all ingress nodes using it. None of these signaling involves the IGP. So it’s no= t clear to me that IGP would be the obvious choice specifically for the nei= ghbors of the protected node, while a different protocol would be used for = the BSID on the protected and ingress nodes. Theoretically feasible but, IMHO as a network operator subject, sub= ject to a risk of lack of feature parity in short and long term. At minimum= I would expect the document to (also) explore how this could be performed = using the protocols signaling the BSID on the protected node and ingress (e.g. PCE, BGP, configuration). Als= o in my experience, the LSR WG is usually not that found of using the IGP f= or configuration/signaling.

 

 

Thanks,

Regards,

--Bruno

 

 

Orange Restricted

From: spring <spring-b= ounces@ietf.org> On Behalf Of bruno.decr= aene@orange.com
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <spring@ietf.org= >
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,

 

This message starts a 2 week WG adopt= ion call, ending 27/01/2022, for draft-hu-spring-segment-routing-proxy-forw= arding

http= s://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwardi= ng/

 

After review of the document please i= ndicate support (or not) for WG adoption of the document to the mailing lis= t.

 

Please also provide comments/reasons = for your support (or lack thereof) as this is a stronger way to indicate yo= ur (non) support as this is not a vote.      

 

If you are willing to work on or revi= ew the document, please state this explicitly. This gives the chairs an ind= ication of the energy level of people in the working group willing to work on the document.

&= nbsp;

T= hanks!

B= runo, Jim, Joel

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_c455becb2c3d432eab5081694ba5c4b4orangecom_-- From nobody Thu Feb 10 05:52:08 2022 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 7A5F73A09DD; Thu, 10 Feb 2022 05:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, 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 hZ4QDRayYlM8; Thu, 10 Feb 2022 05:51:58 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20724.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e89::724]) (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 A32A53A0969; Thu, 10 Feb 2022 05:51:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=idYAj/vki0gMuJ5/+Wbz+uHyCLOwRKhoDwcHZ9raEreDH9xyiOfU4F/Jj2Th7CXbKzxJRLnkPmqjEvrQQguUP2WZu+WjA7y+xnUmXEKB/Yof0UR3qUOVyWKgPW3IjM/RNUtpLM64e2T/u9ripOIR9jYlR6hcDw/HfJ6wjzDSNnAW8bdT3VP/ISQ4wQkY5Wak3BSpbew3bWLPsFx98pbDjBv7K18zjOgr7kYVxC8oe5FSt13NJdiZ/vbWvsMGstkg6WW7UFvsUBq4xnxvIQN+SyZEgYcEGTIajbiL9Zkwd3CPF2N1U33VQNcM08WDEB7NjJfbGzJJtnQLudLa9LnupQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ovonP0Im9jPi8XSN6YV1BBByXWXVNe5hHWFbI6oJg2I=; b=OKVIltgB1fDuK0eb2lFSwRCpEWLQLos4hGE9wQG/ORNr+AEgKZ2Gms7fkrccaltxVZMZncHIXmEqhBrD7Ddnjz8Z2Stzy/M6CIEJEhgZOu3mdAnbrzk3fFhfGzj79uLXiSwir3FtOzadpssRgxc7wQPP0SasWoXJnSIRik2iWF2d55ZBI827jJzjG22T6joPX4HwTmY1OPOzyy5afzaa/6q3Bg5VpcQwIPAcyoRWYqstFJQ6kvqtrpKdMzGu0B4If5ZHrtTJHRY1F8MTkqpx8CaOKClf3wke7fzyS3YzWmZ4VEfek9Myje9xeJPZ8OS4XneYytsThW0T8B5Fm3DnRg== 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=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ovonP0Im9jPi8XSN6YV1BBByXWXVNe5hHWFbI6oJg2I=; b=uTINk3d08fFwqTIC/afC2PrCa240TrV6t7yG9SZ+OSEakQgHVIiFKLqPlabsOJZ1Wrzz4EpOF8ImVwHddFDR3eot9SDxpfEw3QFFefecifpHcl/t4bm6VNPQm8TT0J+1zBri89greNlShF2UT6BJkVFx4swmYRY0k/rXRl/5OBQ= Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by SA1PR13MB5612.namprd13.prod.outlook.com (2603:10b6:806:233::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Thu, 10 Feb 2022 13:51:51 +0000 Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059%6]) with mapi id 15.20.4995.007; Thu, 10 Feb 2022 13:51:51 +0000 From: Huaimo Chen To: "bruno.decraene@orange.com" , "draft-hu-spring-segment-routing-proxy-forwarding@ietf.org" CC: SPRING WG Thread-Topic: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAUck9ggAB9SmygARHZLMAAHJDRP Date: Thu, 10 Feb 2022 13:51:51 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <17506_1644318086_62024D86_17506_388_1_25c99d808d0f4185a9d9005debbbab5b@orange.com> <12661_1644489634_6204EBA2_12661_22_4_c455becb2c3d432eab5081694ba5c4b4@orange.com> In-Reply-To: <12661_1644489634_6204EBA2_12661_22_4_c455becb2c3d432eab5081694ba5c4b4@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-10T10:40:32Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; suggested_attachment_session_id: 07b1bc08-68ba-d2a9-29af-7b5877b07a5e authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15478935-8a12-43fc-2118-08d9ec9c7d6c x-ms-traffictypediagnostic: SA1PR13MB5612:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KzoVlAcreUOTnQWAuvS7IuHJVEtYO7ZlQfTrcPWoYk80xyjrz7hxrmvI3/QV5rcSxutQrV7dIZnTBFBs2sHKDcqPaq6Y5AD30wjvo5mlN3LPBsBDnPRZJa/X3oo29zgB+ps0xq2DK+xUhmHaifygCUjxH9MzahzLo5JKU5P2vEXcpssGSJ42I3FX2D21A1W8AWUSQk40q+AYtnYbT686Qgoh0VnadnN0b5+i3lW3vGD2OuwJJWsWXweh2bzllApsROb2axrgUHqbjyg+d3dyevJYCx+6I/832KiOiFJW7cR3YPtuIR4ot89qp1TiEh2N+j4c5iBj2kL1+OJLtns+LF3nSFnLvGXCbx87pTT0X2GhdLjmc0cJ/39JwXvUIT0t1bClmLHd3N/U+GJMAxAh9sfCL8ClIKX+O8KmHiwRMYe7t8BHc722Jj4iUZkE8r1Mo6tZMeCggT4bfAZ9W/WPW58w2y7YrlPnBNHB0m8RCZUPupmbQQOh/soG5mxLrX6T+v5a7u9GNTLWtpk3lgG586oCbVcSr3v6l1hxqpKR7UuaRLboKJorViMHpDOnfppzblvldVfrmdo3cWDyXT8+3B8EPnoXiloMA3/1JTauDYQ97Y0lZWf03ajX5mUgIeMwBSX15T4NFxBs7YEx1ARdhqmdfGUFC873XCX/isjYEB4whsw2QMnmmIFJciwYVIP4yAUU7ugVtbogXdVNqwQNJ1OChWpw4ViOrPX5hKzANIzPnOjZ8Rq6vJTj5exPEl0R18sqg/S7K94BkBrvJ29nSQvmbJjdl+NvX5DYV/PcIVx3MGhAulw4qZpTGFI+GcA5R7KzEWN6iI/nCku/rqh1mb4UiEcE6gRK0AEpHvdw8CwaKZ4uEn8L82vRweXgPzqf x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(122000001)(5660300002)(44832011)(55016003)(19627405001)(66574015)(53546011)(966005)(9686003)(508600001)(86362001)(66556008)(38070700005)(38100700002)(33656002)(66446008)(64756008)(186003)(66476007)(166002)(8676002)(4326008)(83380400001)(71200400001)(52536014)(26005)(6506007)(7696005)(316002)(2906002)(8936002)(66946007)(110136005)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?ph//BXOj8OuVN0jgpRaanAwvIhsNqqvBA/AA9sGG5cY5h9LYBSEIn0aa?= =?Windows-1252?Q?w5ylvW39ICqIdAsp6xlnA41JLSH39Np3Wo+DrOMQhqJdbrUprFtB8AFt?= =?Windows-1252?Q?tneOkpNXLD51HUAU8du5g1F1duCwaE4wgpWOYJSCvndyc7P8JelsxyiS?= =?Windows-1252?Q?kF+JF6MdNc5FzGB12h4F3tR4ZUOX3pUiNYwWzGCDyXHhPRQlcnfM2Quv?= =?Windows-1252?Q?pCoBPABPe3b0hTJ9tErT+AUMTr5/4V4wUjj8DGDd1a+6XwUsnMqOafHi?= =?Windows-1252?Q?61xlQv1sR60aXger/3owaGYFEnkTSB3iSdEj83+M9jCpAi4tid5lMAwv?= =?Windows-1252?Q?PvoNzzJosBFLSS/K9gOoo9Vml3760Jn3bfQlmFF4SIvqv2r0vzSThUcP?= =?Windows-1252?Q?B0TOjGusLj3jBUUSWrs1iXFLjPipiRms72IAFsNs5CofNPmtGe1SXS5C?= =?Windows-1252?Q?ZRBQjfo/NtLtUJijJaeUCVwh2JUu3eSPojv/m5kqtV6SIaslD4QNm0oT?= =?Windows-1252?Q?6JuA/n7BTeifscYMX3Xl4kppS5xuEbIfCPmk2u26PEJ3gkQitwGqAKiY?= =?Windows-1252?Q?w/LSbaYzOcvN9ErdPlqpEs8pOKlyrhbS1YspPnvsj1EZoqosNV7Ic9vx?= =?Windows-1252?Q?BFzIWJOuEYH1tSIB3MSRAhiPuVaD363ZFxN8kLsDfQcIX7IINAN3eroS?= =?Windows-1252?Q?cdgV6F7IxMlj+MSuCX6Uc6+zsdkRSo4MWOkG7kJXtPJC1sDXuJteVv+Z?= =?Windows-1252?Q?B3TZi4dbiKDzx231xB0ZoZ3Mp7w4WTLXn0eLGPRaT7vzSQGK0+4U6ELW?= =?Windows-1252?Q?BBd2PG/7kUOU/Y/ccmWjgCxGDyfCTM9CIx8HYH9QkNDXqV5IgLznUwFn?= =?Windows-1252?Q?Mj7/t7tfbmc8TeLoX2aq61shX6MGcvuqmBaHzpzyCnn6G4bN8EwZApTq?= =?Windows-1252?Q?HrHKk/Tw/ZHWt7XD2Fl95WFG5W/fHt5sJEnCerX/yRcYyR/XVDwvwMht?= =?Windows-1252?Q?rPytYUv8xeYeDTIF2+m2uNgHlGPt3VQMMh3pqO36gBdvNWteSZvZsDEK?= =?Windows-1252?Q?49Mo8IqnytCIhFN4IbaCAEL1cDZGdxxFCaIwfcl9JhUzHrWBzP02UViC?= =?Windows-1252?Q?zTC3GPdt68NzBnPF1qSiRUQAA0eRbHKuJxNclWtduOv76w6RQ5vT4O7j?= =?Windows-1252?Q?1Inm4/3eEKZc8RyWKgnG4YjfO4WThL65Rim/MMYLGgYEzXNCyUGPZ7eY?= =?Windows-1252?Q?ZVQCkFhyZ9PluYMNHN3badnqE6Twg9N1gxq+ogwOpn4aONl8bfGsL+Z9?= =?Windows-1252?Q?OTRgniKAo6ULl0dkpODFoF0YNjgS9Fj5W9EX6dnEhGY0S6mhxCbSz3FI?= =?Windows-1252?Q?DbrTIO9+bz//IMQXvVTrgDthB710uX1TnriwD1mT0tJI2mT5toa3jOWA?= =?Windows-1252?Q?vSW1PdbpWvfGX+U0eF5w/7Dq2ORBWfJfFHPpEMvItz/Z3uTDoakfA+JR?= =?Windows-1252?Q?FOFRHzEQm2JR/WH26KMd8IMw1PbGFgogEuU0/asVEYIfpSqn188/bgha?= =?Windows-1252?Q?blJMXLbkAfJuQa7P86NL7yrPZ2GnHZ5XANskyjZ50Q3DNF47eYgKA6Qk?= =?Windows-1252?Q?IhXklalm5/z0sHpV9F8oMJguqnasp/wskK3jf3KWyTKWUyu5JrVvuGi2?= =?Windows-1252?Q?gu/eoldXNrxMe84/Mz4InUMTDXrcTEEFQEjNBw3y18777G4Eqc8VBg?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB5044178C7EF79509551CBAAEF22F9BY3PR13MB5044namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15478935-8a12-43fc-2118-08d9ec9c7d6c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 13:51:51.1820 (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: c7ysBxAEmMcUWRrsffVaXrThvAW9XBeoNO41wrRp3Nft4r2PCrBFOHfj8AzcdUsJht00KdxsDexyKqZLe5BMcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR13MB5612 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 10 Feb 2022 13:52:05 -0000 --_000_BY3PR13MB5044178C7EF79509551CBAAEF22F9BY3PR13MB5044namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thank you very much for your valuable point. We have updated the draft to address it. Best Regards, Huaimo ________________________________ From: bruno.decraene@orange.com Sent: Thursday, February 10, 2022 5:40 AM To: Huaimo Chen ; draft-hu-spring-segment-routin= g-proxy-forwarding@ietf.org Cc: SPRING WG Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwa= rding [speaking as WG contributor] Hi Huaimo, Thanks for the follow up. Please see one point inline [Bruno] Orange Restricted From: spring On Behalf Of Huaimo Chen Sent: Wednesday, February 9, 2022 2:48 AM To: DECRAENE Bruno INNOV/NET ; draft-hu-spring-s= egment-routing-proxy-forwarding@ietf.org Cc: SPRING WG Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi Bruno, Thank you very much for your valuable comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: bruno.decraene@orange.com > Sent: Tuesday, February 8, 2022 6:01 AM To: draft-hu-spring-segment-routing-proxy-forwarding@ietf.org > Cc: SPRING WG > Subject: RE: WG adoption call - draft-hu-spring-segment-routing-proxy-forwa= rding [speaking as WG contributor] Hi authors, all I have some comments specific to the binding SID aspect. =A72 =93 For a binding segment of a possible failed node, the node advertises the information about the binding segment, including the binding SID and the list of SIDs associated with the binding SID, to its direct neighbors only. Note that the information is not advertised in the network domain. =BB =A73.2.2 =93For supporting binding SID proxy forwarding, a new IS-IS TLV, called Binding Segment TLV, is defined. It contains a binding SID and a list of segments (SIDs). This TLV may be advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP) [RFC7356]. =BB >From an IS-IS standpoint, it seems to me that: - Advertising it in the LSP PDU would flood the information in the whole= area/level, hence does not match the goal stated in =A72 - Advertising it in the Hello PDU is not a reliable way to sync informat= ion (except if duplicated in all hello which implies others issues such as = lack of space) and adding the reliability seem like a major change to IS-IS In all cases, as already raised by St=E9phane, this is a subject for the LS= R WG. [HC]: We will remove IS-IS Hello (IIH) PDUs and LSPs, and update the related text accordingly. More importantly, the binding SIDs are probably coming from =93somewhere=94= such as configuration, PCE, BGP, BGP-LS=85 Why not using the exact same si= gnaling to duplicate it on the neighbors? (this may probably require some e= xtensions for some protocols but a priori light ones and would not impact t= he IGP with information which may not belong to the IGP.) [HC]: Using the same signaling (configuration, PCE, or BGP, ...) to duplicate it on the neighbors works well if there are sessions between the neighbors and PCE, or BGP, ... [Bruno] Indeed, signaling session would be needed. That seems doable =E0 pr= iori (especially if we assume that BSID may already be needed on other node= s) My point is that _today_, using BSID requires configuration/signaling of th= is BSID on the BSID node itself and on all ingress nodes using it. None of = these signaling involves the IGP. So it=92s not clear to me that IGP would = be the obvious choice specifically for the neighbors of the protected node,= while a different protocol would be used for the BSID on the protected and= ingress nodes. Theoretically feasible but, IMHO as a network operator subj= ect, subject to a risk of lack of feature parity in short and long term. At= minimum I would expect the document to (also) explore how this could be pe= rformed using the protocols signaling the BSID on the protected node and in= gress (e.g. PCE, BGP, configuration). Also in my experience, the LSR WG is = usually not that found of using the IGP for configuration/signaling. Thanks, Regards, --Bruno Orange Restricted From: spring > On B= ehalf Of bruno.decraene@orange.com Sent: Thursday, January 13, 2022 11:19 AM To: SPRING WG > Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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_BY3PR13MB5044178C7EF79509551CBAAEF22F9BY3PR13MB5044namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

    Thank y= ou very much for your valuable point.


    We have= updated the draft to address it.


Best Regards,
Huaimo
From: bruno.decraene@orange= .com <bruno.decraene@orange.com>
Sent: Thursday, February 10, 2022 5:40 AM
To: Huaimo Chen <huaimo.chen@futurewei.com>; draft-hu-spring-s= egment-routing-proxy-forwarding@ietf.org <draft-hu-spring-segment-routin= g-proxy-forwarding@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-prox= y-forwarding
 

[speaking as WG contributor]

=  

= Hi Huaimo,

=  

Thanks for the follow up.

Please see one point inline [Bruno]

 

 

Orange Restricted

From: spring <spring-bou= nces@ietf.org> On Behalf Of Huaimo Chen
Sent: Wednesday, February 9, 2022 2:48 AM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; draf= t-hu-spring-segment-routing-proxy-forwarding@ietf.org
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding

 

Hi Bruno,

 

    Thank you very = much for your valuable comments.

 

    My responses/ex= planations are inline below with [HC].

 

Best Regards,

Huaimo

on behalf of co-authors

From:= bruno.decraene@orange.com <bruno.decraene@orange.com>
Sent: Tuesday, February 8, 2022 6:01 AM
To: draft-hu-spring-segment-routing-proxy-forwarding@ietf.org <draft= -hu-spring-segment-routing-proxy-forwarding@ietf.org>
Cc: SPRING WG <spring@ietf.org= >
Subject: RE: WG adoption call - draft-hu-spring-segment-routing-prox= y-forwarding

 

[speaking as WG contributor]

 

Hi authors, all

 

I have some comments specific to the binding SID aspect.

 

=A72

=93   For a binding segment of a possible failed node, = the node advertises

   the information about the binding segment, including= the binding SID

   and the list of SIDs associated with the binding SID= , to its direct

   neighbors only.  Note that the information is n= ot advertised in the

   netwo= rk domain. =BB

 = ;

=A73.2.2

   =93For su=
pporting binding SID proxy forwarding, a new IS-IS TLV, called
   Binding S=
egment TLV, is defined.  It contains a binding SID and a
   list of s=
egments (SIDs).  This TLV may be advertised in IS-IS Hello

   (IIH) PDU=
s, LSPs, or in Circuit Scoped Link State PDUs (CS-LSP)


   [<=
a href=3D"https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F=
%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7356&data=3D04%7C01%7Chuaimo.=
chen%40futurewei.com%7Cee4806bcfe6143e86bba08d9ec81c58f%7C0fee8ff2a3b240189=
c753a1d5591fedc%7C1%7C0%7C637800864401143210%7CUnknown%7CTWFpbGZsb3d8eyJWIj=
oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sda=
ta=3DocQIQa5Qz0PwS5iKYOgW7WL9pCTnSrAEH%2BtYIVVoLmo%3D&reserved=3D0" ori=
ginalsrc=3D"https://datatracker.ietf.org/doc/html/rfc7356" shash=3D"gL5CHYp=
MuAOeM0w4k4/y2wEFlu7HlXvPW9MUwenQG34s0yFdck4ZQgvDQV0OiMEoYWRIN953xylN39Ubmm=
8RXhUdaD2qW7t3e/X/YLkKGUdC5oEBCeYLkWrSLgHLxUOvcQpIo9tUIxso1UaxI72+B3dvY80u8=
LlS9fNXs0CfHIw=3D" title=3D""IS-IS Flooding Scope Link State PDUs (LSP=
s)"">RFC7356]. =BB


 


From an IS-IS standpoint, it seems to me that:

-    Advertis=
ing it in the LSP PDU would flood the information in the whole area/level, =
hence does not match the goal stated in =A72


-    Advertis=
ing it in the Hello PDU is not a reliable way to sync information (except i=
f duplicated in all hello which implies others issues such as lack of space=
) and adding the reliability seem like a major change to IS-IS


In all cases, as already raised by St=E9phane, this is a =
subject for the LSR WG.


[HC]: We will remove IS-IS Hello (IIH) PDUs and LSPs, and=
 update the
related text acco=
rdingly. 


 



More importantly, the binding SIDs are probably coming from =
=93somewhere=94 such as configuration, PCE, BGP, BGP-LS=85 Why not using th=
e exact same signaling to duplicate it on the neighbors?
 (this may probably require some extensions for some protocols but a priori=
 light ones and would not impact the IGP with information which may not bel=
ong to the IGP.)



[HC]: Using the same signaling (configuration, PCE, or BGP, =
...) to






duplicate it on the neighbors works well if there are sessio=
ns between






the neighbors and PCE, or BGP, ...



=
 



[Bruno] Indeed, signaling session would be needed. That seem=
s doable =E0 priori (especially if we assume that BSID may already be neede=
d on other nodes)



My point is that _today_, using BSID requires configu=
ration/signaling of this BSID on the BSID node itself and on all ingress no=
des using it. None of these signaling involves
 the IGP. So it=92s not clear to me that IGP would be the obvious choice sp=
ecifically for the neighbors of the protected node, while a different proto=
col would be used for the BSID on the protected and ingress nodes. Theoreti=
cally feasible but, IMHO as a network
 operator subject, subject to a risk of lack of feature parity in short and=
 long term. At minimum I would expect the document to (also) explore how th=
is could be performed using the protocols signaling the BSID on the protect=
ed node and ingress (e.g. PCE, BGP,
 configuration). Also in my experience, the LSR WG is usually not that foun=
d of using the IGP for configuration/signaling.



 



 



Thanks,



Regards,



--Bruno



 



 



Orange Restricted









From: spring <spring-b=
ounces@ietf.org>
On Behalf Of bruno.decr=
aene@orange.com

Sent: Thursday, January 13, 2022 11:19 AM

To: SPRING WG <spring@ietf.org=
>

Subject: [spring] WG adoption call - draft-hu-spring-segment-routing=
-proxy-forwarding







 



Dear WG,



 



This message starts a 2 week WG adoption call, ending 27/01/=
2022, for draft-hu-spring-segment-routing-proxy-forwarding



https://datatracker.ietf.org/doc/draft-=
hu-spring-segment-routing-proxy-forwarding/



 



After review of the document please indicate support (or not=
) for WG adoption of the document to the mailing list.



 



Please also provide comments/reasons for your support (or la=
ck thereof) as this is a stronger way to indicate your (non) support as thi=
s is not a vote.      




 



If you are willing to work on or review the document, please=
 state this explicitly. This gives the chairs an indication of the energy l=
evel of people in the working group willing to
 work on the document.



=
 



=
Thanks!



=
Bruno, Jim, Joel


______________________________________________________=
___________________________________________________________________


 


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


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


a l'expediteur et le detruire ainsi que les pieces joi=
ntes. Les messages electroniques etant susceptibles d'alteration,


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


 


This message and its attachments may contain confident=
ial 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 notif=
y the sender and delete this message and its attachments.


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


Thank you.




______________________________________________________=
___________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisati=
on. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces joi=
ntes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confident=
ial 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 notif=
y the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for mes=
sages that have been modified, changed or falsified.
Thank you.
______________________________________________________=
___________________________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
--_000_BY3PR13MB5044178C7EF79509551CBAAEF22F9BY3PR13MB5044namp_-- From nobody Thu Feb 10 06:51:49 2022 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 D6C473A0891 for ; Thu, 10 Feb 2022 06:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 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, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-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 7RqkxEuUCIY4 for ; Thu, 10 Feb 2022 06:51:44 -0800 (PST) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01olkn2140.outbound.protection.outlook.com [40.92.62.140]) (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 7D2303A0882 for ; Thu, 10 Feb 2022 06:51:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VcQIBSWhLcTuip7rngOA6Ttu5l2UUh3ODUFxBWigbfnBKaGN8PiTMZzx8R1Y2E9M0gHhKj/szREEefboEYmFXJbhA+No049vz8O0CpVLuiFS5S5C+VsS4EOxUCqiTgeQ7BFS9iVAtc215seLjCXLDot9+IvavW6RgLQb68twWkI/1EYbFRWm61DNncYdp+NWAjaYLueNvCuiWASf3EUGhOyvADj0uU5b4/JDd9hSzd5MEcsiQvQjmmTJmDYM8Y5lSt0+AMQV4naa574IFYfeuGpgS9F3V9M8CkCBefv4VCwrar8KkN1hHPe896BlE2k+u12mmm3YkaeA1FCTuKOFMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lDsXg0homI+l8X2SqC/RdB4GjyMq5LaTPrKkyyup4S8=; b=YhSUSxruZdF28wfRsnnn4AfaBXkXDawA960oh/7rFKHIwrH14fqtFzn6jw+KbhAHitIDZHtFh1yeiR80SNFjgsPBQVM87saoPi1SOLx9fNsMiSwB6Vp+gyRMnMfoTbHroTZJGe1Uh+3a6EN2WBvGkj60GOJiyw7MJzMcWgpRPXvYRTUWj2dRC6TJQsE2Vr+mVfIT0Y22LAaOF3GT3oDHLFSNR8Wj59/L3QlBhETuZzm3U7O3nibBrFSiHI0oox+V/sbNSvZkTKVuVHtRCBkGX39hMgJ2IavRtU4W+f1Byz/YCi3ZPHrzYKybkbcciJimlbErFeg3K7VfmTz/JpabVQ== 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=lDsXg0homI+l8X2SqC/RdB4GjyMq5LaTPrKkyyup4S8=; b=XOP+o0JX+A/c3D6OLQtRvwmPcbPRIh1ZPAzUnLtb0EtnpbrapnZ2e8hIjwX1AMlfdXrVBfk24c3vmDryLFXlgz4OxTex2vhpwZ1/El3vNK/6CHFzXKQaFIjSwZNXsRoW9SmpoGwTAIt4Gt7LVyDy6P9RIzhBC025WkxR4pYwOx0KlYhzJ5azNh7FR9O18W7UvmeOx23ZKOKldmqdTyDyjChwtQkAGwR0wQKakXZG3S8ia1OZOhB9weC8pz9uWnCpRo0Mesz5mqz0I2tJ1+FJdvcHgsYmJGRygVVp3dLeI/y3G+IUW9goCEBdOYWZuHMlC7dVFNTEDM4HK6epYP2yoQ== Received: from MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:157::9) by MEAP282MB0391.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:67::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.18; Thu, 10 Feb 2022 14:51:40 +0000 Received: from MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM ([fe80::bd6f:5b76:dc38:e4e6]) by MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM ([fe80::bd6f:5b76:dc38:e4e6%6]) with mapi id 15.20.4975.014; Thu, 10 Feb 2022 14:51:40 +0000 From: li zhenqiang To: "spring@ietf.org" Thread-Topic: SRv6 SID allocation Thread-Index: AQHYHotjb8stQhujqU6sWM0ky0vWLA== Date: Thu, 10 Feb 2022 14:51:40 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 59036697-9723-6263-b21a-2e76e6110ebf x-tmn: [0i+Dl1EhECY7b29ArxL5WqnIdtuOO2/t] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe7b77b1-5695-4185-2f96-08d9eca4d8a9 x-ms-traffictypediagnostic: MEAP282MB0391:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dDpY2WiHRL2A/7RipXD+tx/p4pbUtBZUQZQPUvBj/lym26AhX/Shleuo0PSDp9JYXvuOcm2rM2e1vFR4H9lfdkBGza9mr6w+yxHkNXltQ9J1YcmYjfOaMD+TpvgV0ppMJDnZ7AHj2AyN1bYk8Ml5uI0cQtFRHoOCTcb1quQB6Rprs198qNroc8IYjLYBh7IX5KMTsQVV9cMP26G8glR7DUa0DPkVh4pP+5TsqVPA00au+MtP+twtTKsuHmxeH51fiom9BQm2fga20k83GI6dQwyCcSUtoVafFC1IH4VPpZD/gZk/vWcloFIn+Q5yeKLEK8AoUDyiv049zTla1E6HRyqotpXeX9CXH3IaMXWJ0YZaMX8QTWFG3Zvm+VI86e8fXr//hCcwTXJpTm134qxwAWcJ+RqxXlZ1K038oMNxLlrk74Fp3ZmfYbQ0/HhDm/F2nCkfPJ6rHg5G2/4elYICgtE26ECMIBocAoS3SY7G/awIsY5dClkJ11P2wh51J1G+KmuMIj5W9v9m5uFGRUVNiV1dtoothwLFWPzEzqDelKZlp+vMgZfz2mREKtH7ieHlU7gqQBYmA9dqsVzcuYFMHQ== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: Blc3zfOPl4Uoihw+fKsrOy+RVi9QNqz6UvvdemKhdMWPf728pHklr7HchRLDfWKvFaVlpD2YuDXi2utdXKrl4jGY3jIrHvskghNKnaXplDfkcmhSbNXbuskXw3zzIhDZ2bh3qJ7DErPFO8sHry6yys43J3hnxnXczuEYvPPLk9G6XnCNZDigwvSa5IaEhxZXdYVbd563QmWBaU1DoYrMZnDon3HbccUEOAvFTfDc0niMyyHCNDaLJ2vsV3pCGcsyykNMq8YOGnoQDTjQFUpjhL8mk9nc9/Pfe5+bye7FG5iN/dSTXJGuKEdyqwt2qOZdxpIzaLvdSvXp8iulhK9M5V2Pg7JsovtzPcVddrya9e2wjbn4u9KY/B/uZ0z9IM+42bwUz97eLbwQFjzXfUpnoaeJ2CTeXhjGJJRTvP6GL7Yo7wYae4yMeM5ia2WaSDy+NyNPbQfTmy6jv4lfTI7+/T4ZgtPK0WQlcwAGQ8q3+2H5wZKjqzwKO9rhxcoxkZ2wXsh3vh5/4jSRfdEatTaI+/JCNMoI2lglA/5WQr+336b6DFMNSBzEW7u7doAXGn7Ch7c79AHO2/r9AFQcFZA3HYHaVY6K02B0igBvQIxPa9G1DRaqpVsvDKYMY4rZWR6+2lyaIeJfluY5eAue0+/tBuqd86E9bfqqeQyWoMJC+tSHkkYu6t9lMTyX+p/5fBAKpuU+Q8TrE0One49Xyd6aqvES3LZEtYOlCf9WFIHj8fTVcN8ALtHutvd/R5vx/5EVE1u8k9hAnaR3FGMuJ9KgTNeBmaVO4zAVPObvWEAj9HXtAhDSaQemrZW+uYRWf2zKuLSER/AEWdRMLsxkOCWqVV7EgLJZe1o2PXAxk9LY0t0SWyduFotd1BW2SUGVkP5UpMh/KM1a5CVo894xglBHuhugf+YHkfRnDoTf7nyHZTaPYbHPvwGEWRtGZdAj5vZA Content-Type: multipart/alternative; boundary="_000_ME3P282MB2940C59A9E807B1E5830B74FFC2F9ME3P282MB2940AUSP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-746f3.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: fe7b77b1-5695-4185-2f96-08d9eca4d8a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 14:51:40.2613 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAP282MB0391 Archived-At: Subject: [spring] SRv6 SID allocation 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, 10 Feb 2022 14:51:47 -0000 --_000_ME3P282MB2940C59A9E807B1E5830B74FFC2F9ME3P282MB2940AUSP_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gU1BSSU5HIGV4cGVydHMsDQoNCkFjY29yZGluZyB0byB0aGUgYXJjaGl0ZWN0dXJlIHNw ZWNpZmljYXRpb24gUkZDODQwMiwgYWRqIHNpZHMsIGVuZC54IGluIFNSdjYsIGNhbiBiZSBkeW5h bWljIG9yIHBlcnNpc3RhbnQuIEhvdyBhYm91dCBlbmQgc2lkcyBhbmQgc2VydmljZSBzaWRzIHN1 Y2ggYXMgRFQ0LCBEVDYgZXRjPyBUaGV5IGFyZSBub3Qgc3BlY2lmaWVkIGV4cGxpY2l0bHkgaW4g dGhlIHNwZWNpZmljYXRpb24uIERvZXMgdGhhdCBtZWFuIG90aGVyIHNpZHMgdGhhbiBlbmQueCBh cmUgZHluYW1pYz8gSW4gc29tZSBzaXR1YXRpb25zLCBuZXR3b3JrIG9wZXJhdGlvbiBtYXkgYmVu aWZpdCBmcm9tIHBlcnNpc3RhbnQgZW5kIHNpZHMsIGVudmVuIHNlcnZpY2Ugc2lkcy4gQW55IHN1 Z2dlc3Rpb25zLCBjb25zaWRlcmF0aW9ucyBvciBleHBlcmllbmNlcyBhYm91dCBpdD8gVGhhbmsg eW91IHZlcnkgbXVjaC4NCg0KQmVzdCBSZWdhcmRzLA0KWmhlbnFpYW5nIExpDQpDaGluYSBNb2Jp bGUNCg== --_000_ME3P282MB2940C59A9E807B1E5830B74FFC2F9ME3P282MB2940AUSP_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hello SPRING experts,

According to the architecture specification RFC8402, adj sids, end.x in SRv= 6, can be dynamic or persistant. How about end sids and service sids such a= s DT4, DT6 etc? They are not specified explicitly in the specification. Doe= s that mean other sids than end.x are dynamic? In some situations, network operation may benifit from persis= tant end sids, enven service sids. Any suggestions, considerations or exper= iences about it? Thank you very much.

Best Regards,
Zhenqiang Li
China Mobile
--_000_ME3P282MB2940C59A9E807B1E5830B74FFC2F9ME3P282MB2940AUSP_-- From nobody Thu Feb 10 12:41:10 2022 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 CA5073A0C01 for ; Thu, 10 Feb 2022 12:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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] 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 R8cicqs5bhUI for ; Thu, 10 Feb 2022 12:41:02 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21093A0B6B for ; Thu, 10 Feb 2022 12:41:01 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id a8so18150283ejc.8 for ; Thu, 10 Feb 2022 12:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=41BBzFyMSQLVjfF5E+dfpu4KTX19MEmBX7cmmCyziNI=; b=pVJ0FJQOPotshMTum9JZ+6JUKKBZl0nLCNvdNrIsJ4jzPoJgIdolZPFpGRDoqyApuE 3rkqsHCko9Mdnhu+JaqD92Rx3I/3eIJ4SptOm0NZb6Yiy3AtDgviObyj7zF1+5GfQJTO 871bOTOXbRYyh2aGYWVxxPVs8udkiteobnxUQaY+0YCoisiquNort4BrBMwFECuhRsTc /g+jaRhX0Eh7Oc79Hc/W9dscdpmFCasCXVTLKmScN6e2qhnu2Id5+cJG0FL3GGPNxsK7 1yTF+TdMm1XxtwjS8G+jObqIQ/MOSG93Ngh/l/aT5Iqb3+yUnCqAiO/tqnrBu3l2QulK /8gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=41BBzFyMSQLVjfF5E+dfpu4KTX19MEmBX7cmmCyziNI=; b=A9dR0V1mOKu9i6gph87XMBmjQv70+6c5TyOr/PNCFhkMA8rdoV34MjJQpvZblODrff mNXdkCpvrW31l1FGnDRIIxbrDeNqc4UA80eV287d6nTHFB0wGjmK0NlBDdU131Igk8kN eVsNiEJYSHWjGUFIfg3/sn1QVEUO6X790+vd7MINXIO9zXpeagX909uePhrJGpaHV4iV bXY04rg8sFUbD+nFvk7aS4E4Xbm4tCy5tRfeyvQinN/h7uSX2g9p/C5bcpMnhgQ7Egmu 9BW+DrsKYwbQqDBJSdsQCpZhs+E41s4lBqFaKgoDisrNCfkXMXeomSpdeQTKIArUU2sc snTg== X-Gm-Message-State: AOAM5316SF7jF4ezTuBCPy4dtcNYdzTzocyGAr+gxrdUJgS5K3LXCfeh Ow2DmP6qNS3dMBUc41Bi7tno75QPkCYJhpjQqdg= X-Google-Smtp-Source: ABdhPJwdwaYzSn5MQ4s8k1iWuq+QWFi4QuYLESorIhyUIuNfaXGKY+vzI8a2/7BXV5ryIg8DQ57oRbLwrzjlpyqlM3s= X-Received: by 2002:a17:906:dfd5:: with SMTP id jt21mr7924333ejc.235.1644525656532; Thu, 10 Feb 2022 12:40:56 -0800 (PST) MIME-Version: 1.0 References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> In-Reply-To: From: Greg Mirsky Date: Thu, 10 Feb 2022 12:40:45 -0800 Message-ID: To: Huaimo Chen Cc: Bruno Decraene , SPRING WG Content-Type: multipart/alternative; boundary="00000000000094f20a05d7aff74c" Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 10 Feb 2022 20:41:08 -0000 --00000000000094f20a05d7aff74c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Huaimo, thank you for responding to my notes and questions. I wanted to highlight one issue (top-posting): For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths, if a node X on the shortest path from a upstream node to N does not support the mechanism, node X drops the traffic transported by the path. For the solution in our draft, proxy capable nodes off node X on the shortest path to a neighbor of N are used. >From reading your response, it seems that you compare how different solutions behave not in identical environments. I don't see that as a fair comparison. Regards, Greg On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen wrote: > Hi Greg, > > Thank you very much for your notes. > > My responses/explanations are inline below with [HC2]. > > Best Regards, > Huaimo > > ------------------------------ > *From:* Greg Mirsky > *Sent:* Tuesday, February 8, 2022 11:25 PM > *To:* Huaimo Chen > *Cc:* Bruno Decraene ; SPRING WG < > spring@ietf.org> > *Subject:* Re: [spring] WG adoption call - > draft-hu-spring-segment-routing-proxy-forwarding > > Hi Huaimo, > thank you for the expedient response. Please find my follow-up notes > in-lined below under the GIM>> tag. > > Regards, > Greg > > On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen > wrote: > > Hi Greg, > > Thank you very much for your comments. > > My responses/explanations are inline below with [HC]. > > Best Regards, > Huaimo > on behalf of co-authors > > ------------------------------ > *From:* spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Sent:* Tuesday, February 8, 2022 4:38 PM > *To:* Bruno Decraene > *Cc:* SPRING WG > *Subject:* Re: [spring] WG adoption call - > draft-hu-spring-segment-routing-proxy-forwarding > > Dear Authors, et al., > I've read the draft and would appreciate it if the authors can clarify on= e > question: > > - What do you consider as the significant advantage of the mechanism > defined in your draft compared with the mechanism defined in > draft-ietf-spring-segment-protection-sr-te-paths? > > As I've compared the two solutions, I couldn't find any significant > advantage of the proxy forwarding to have two standardized mechanisms for > SR path e2e protection. It might be reasonable to have one standard while > other proposals get experimental status? > [HC]: It provides more protection coverage in some cases as compared to > the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths= . > > GIM>> I find it hard to quantify your characterization. I imagine that if > an operator uses the protection mechanism defined in > draft-ietf-spring-segment-protection-sr-te-paths it designs the network > with that in mind and thus minimizes if not completely avoids any possibl= e > limitation the protection mechanism may have. Perhaps you can help with > some more specific scenarios. > [HC2]: Assume that a SR path has the SID of a node N and node N failed. > For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths, > if a node X on the shortest path from a upstream node to N does not > support the mechanism, node X drops the traffic transported by the path. > For the solution in our draft, proxy capable nodes off node X on the > shortest > path to a neighbor of N are used. The neighbor re-routes the traffic > around > failed node N towards the destination. The traffic is protected. > > This improves the reliability of networks, and QoE. This should be a > significant advantage. There is no solution for BSID protection in the > other existing draft. > > GIM>> Though BSID may be used inside the network, I find such use case > questionable making no significant impact on the usefulness of the > protection mechanism. > [HC2]: Considering two drafts A and B. Draft A supports protection > of a SR path, which contains two types of components, say C1 and C2. > If the path contains a third type of components, say, C3, then > protection of the path for C3 is not supported. > Draft B supports protection of a SR path, containing C1, C2 and C3. > In this case, draft B seems having a significant advantage over draft A. > > The solution for BSID protection in our draft has > been there for a few years. In addition, after a node failed, in > our solution, the nodes of the entire network converge to the latest > state consistently in time. After a node failed, the mechanism defined > in the other existing draft holds off the FIB during the HoldTimer > period configured, when the network changes again, > > GIM>> I consider that property of the protection defined in > draft-ietf-spring-segment-protection-sr-te-paths as a benefit that allows > better control for the proper coordination between protection mechanisms > that operate on different network layers. > > our solution continues > to converge at any time. > The mechanisms in two drafts are different. It seems ok and reasonable > to have the two drafts to be adopted in the WG. > > GIM>> I agree with you, drafts are fundamentally different and, in my > opinion, merging them would not change the situation. But I don't see tha= t > as the justification for producing two standards. It seems to me, releasi= ng > two standard-based specifications might be detrimental and I propose the > authors consider taking this draft onto the experimental track. I'd suppo= rt > the adoption of it as the experimental track document. > > > > Regards, > Greg > > On Thu, Jan 13, 2022 at 2:19 AM wrote: > > Dear WG, > > > > This message starts a 2 week WG adoption call, ending 27/01/2022, for > draft-hu-spring-segment-routing-proxy-forwarding > > > https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-fo= rwarding/ > > > > > After review of the document please indicate support (or not) for WG > adoption of the document to the mailing list. > > > > Please also provide comments/reasons for your support (or lack thereof) a= s > this is a stronger way to indicate your (non) support as this is not a vo= te. > > > > > If you are willing to work on or review the document, please state this > explicitly. This gives the chairs an indication of the energy level of > people in the working group willing to work on the document. > > > > Thanks! > > Bruno, Jim, Joel > > _________________________________________________________________________= ________________________________________________ > > 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 > > > --00000000000094f20a05d7aff74c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000094f20a05d7aff74c-- From nobody Thu Feb 10 13:19:11 2022 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 D57683A11FE; Thu, 10 Feb 2022 13:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 BkXXLD72HqtU; Thu, 10 Feb 2022 13:19:02 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123423A11BB; Thu, 10 Feb 2022 13:18:43 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21ALIflN030507; Thu, 10 Feb 2022 21:18:41 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 724E54604B; Thu, 10 Feb 2022 21:18:41 +0000 (GMT) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5C0004603D; Thu, 10 Feb 2022 21:18:41 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS; Thu, 10 Feb 2022 21:18:41 +0000 (GMT) Received: from LAPTOPK7AS653V ([85.255.237.13]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21ALIdYG013406 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Feb 2022 21:18:40 GMT Reply-To: From: "Adrian Farrel" To: Cc: Date: Thu, 10 Feb 2022 21:18:38 -0000 Organization: Old Dog Consulting Message-ID: <15a601d81ec3$c6589620$5309c260$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adgew299vviUatAyTi+cBPePOlId/Q== Content-Language: en-gb X-Originating-IP: 85.255.237.13 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26708.003 X-TM-AS-Result: No--7.828-10.0-31-10 X-imss-scan-details: No--7.828-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26708.003 X-TMASE-Result: 10--7.827900-10.000000 X-TMASE-MatchedRID: XafQxseY2BoOwAmmWH5kBGKYf8urrAmQ3AJrtcannrbWXfwzppZ8SBxa WBB0ymAAlnTp5rmebe/xgPhmH7qVhI4kk6s2eLUqrMcMK3Nm8dkBqNb4Qv6Vo3Y04sukLWz6krI 9/WPu3jdorcscbwxtx4X4yNDFzWWE7ns6Ai0dhJmVOwZbcOalS792t/Q6R4L/Ofpf+mAZMCFdeo 0SmBLMi95eTZKO6G7QFHOQutlZTPkdpNb7ZdqI995x7RpGJf1aDpDqNyhH7mnZCmb4VMeP0yuh0 LN7/qaj4nEuQySeQX+y6U8OhaA+VIt55Ou5Qz3gjoyKzEmtrEeHnrXtAg8lI/z8/tFdCtAAGSE9 W8wHt0YSj4q/tneg2m7kamKGhf/8+88MtxwefuJDlKXa97ejTxiDIOPlOJG1YxDgISSqWZ6Cnce LUCNweEuaH2lspx+3y/bRptJBlDO2F9mW29B7smvOwg12ikVSGKTU+n7puzWMEc2I6XQW8YpbwG 9fIuITUBJNYDtxTduqxeF6rW3Jo00xWB8Q2zWq547kEFZFT00MhHBU2puWzrkiJ/BgvX6rBoGhV 1TduQHhzuIC6VXp1yM1cPjzClQa2gDqaB5TWu2jGOtqnkAZCxfJTYLG2XFvK4YqHgCSopXbzMkN iKUuYN6Oe25X9ITZUtfSROZsTg1dml91vlljGfDrY9Cr30dZDm+4joeL+f1x3jx5KhY39aohvsT Ml9uo8uX9tF7/jHrUozMO2sWb4Y0wxO7oO8Fj+NCQDut0K4UX705dnYk+LOCbuVI7hVbL0gyLcC 2OOiWVFPeRyDaGxMOqitBVtx389Zm06PS0lgCeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqtI41Z+VjGWyyqPJg2zyprLQmB/h8phyd1D9ry+ZUbM7jubWbEqufA1g== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: Subject: [spring] Some comments on draft-ietf-spring-srv6-path-segment 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, 10 Feb 2022 21:19:07 -0000 Hi, This is a bit of a "fly-by" review. I happened to need to read the draft to check on the use of SRH flags, so here are a few quick comments. I hope they are useful. Best, Adrian ==Medium== General Some of my points below are cleared up when I finally got to Section 7 and discovered that you are asking for a new Endpoint Behavior to be assigned. I think that means it *is* possible to detect that a PSID is present at the wrong place in the stack *if* the processing node knows enough to look at the endpoint behaviour and understand it. However, the only (clear) mention of the new endpoint behaviour is in Section 7: TBA1 should be mentioned in the text somewhere! --- 4.1 Here you are attempting to state which bit is used as the P-flag. But there is a registry for the SRH Header flags (at https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segme nt-routing-header-flags) so you should leave this as bit number TBD, and specifically ask IANA to assign *a* bit. You do actually do this in Section 7 but it is in conflict with 4.1. Note that the registry is IETF review which does allow early assignment if you want to get the flag agreed for early implementation and interop etc. ==Minor== Section 1 In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped, so no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node can not determine from which ingress node or SR path the packet came from. Therefore, to identify an SR-MPLS path, a Path Segment is defined in [I-D.ietf-spring-mpls-path-segment]. Likewise, a path needs to be identified in an SRv6 network for several use cases such as binding bidirectional paths [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement [I-D.gandhi-spring-udp-pm]. This all reads like the main use case in SR-MPLS is source identification, and that bidirectional path binding and PM are special for SRv6. I suggest reversing the order of the paragraphs so... In SR, a path needs to be identified for several use cases such as binding bidirectional paths [I-D.ietf-pce-sr-bidir-path] and end-to- end performance measurement [I-D.gandhi-spring-udp-pm]. Additionally, in an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped, so no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node can not determine from which ingress node or SR path the packet came from. To identify an SR-MPLS path, a Path Segment is defined in [I-D.ietf-spring-mpls-path-segment]. --- 1. An SRv6 Path Segment MUST NOT be copied to the IPv6 destination address, so it is not routable. I think this is back-to-front... An SRv6 Path Segment is not routable (it is just an abstract 128 bit identifier) so it MUST NOT be copied to the IPv6 destination address. --- Usually, we don't use BCP 14 language (you have MAY and MUST NOT) in the Introduction. It is supposed to be introducing the concepts not defining behaviour. There are ways around this: - use lower case (and sometimes reword) - reduce the Introduction and move the normative language to later --- 4.1 o P-bit: set when SRv6 Path Segment is inserted. It MUST be ignored when a node does not support SRv6 Path Segment processing. Well, some nodes not supporting SRv6 Path Segment processing don't understand the P flag and have never read this document. So you can't tell them in this document what to do! You have to refer them back to 8754 with something like o P-bit: set when SRv6 Path Segment is inserted. A node that does not understand the P-bit will ignore it as described in [RFC8754]. A node that understands the P-flag but does not support SRv6 Path Segment processing MUST ignore the P-bit. However, what is missing, I think is what happens at an egress node when the P-flag is set and the egress either doesn't understand or doesn't support SRv6 Path Segments. In this case, the P-flag will be ignored, but what will happen to the PSID? Will processing be attempted? You might argue that "A Path Segment is a local segment allocated by an egress node, so this situation cannot happen." But I would say that is "should not happen" because there are ingress errors, and there are timing windows. So you need to describe this edge case. --- 5. When a Path Segment is allocated by the egress, it MUST be distributed to the ingress node of the path that identified by the path segment. In this case, only the egress will process the Path Segment, and other nodes specified by SIDs in the segment list do not know how to process the Path Segment. Depending on the use case, a Path Segment may be distributed to the SRv6 nodes along the SRv6 path. In this case, the SRv6 nodes that learned the Path Segment may process the Path Segment depending on the use case. This is pretty unclear about how the distribution happens. I think you either need to describe or reference the mechanisms, or you have to be clear that the distribution mechanisms are for future study (although, in that case, it is debatable whether there is any value to this document!) --- 6. An SRv6 Path Segment that appears at any other location in the SID list will be treated as an error. Will it, though? Or will an attempt be made to treat it as some other form of SID causing unpredictable behaviour? That is, regardless of the P-flag, if a PSID is inserted into the middle of a SID stack, an attempt will be made to process it (possibly resulting in an error, or possibly resulting in the packet being forwarded on an address that should not be treated as routable). But is there any way to know that the PSID is at the wrong location (or present multiple times)? So, I think you are fine to say "MUST be bottom of stack" and "MUST NOT appear at other locations." But all that you can say beyond that is that "placing a PSID at any location in the SID list will result in unpredictable forwarding behavior." --- ==Nits== Section 1 OLD from which ingress node or SR path the packet came from. NEW from which ingress node or SR path the packet came. END --- 1. s/called "SRv6 Path Segment"/called the "SRv6 Path Segment"/ --- 1.2 You don't need to include terms that appear at in the RFC Editor's list at https://www.rfc-editor.org/materials/abbrev.expansion.txt marked with an asterisk (*). In this case, that's "MPLS" --- 3.1 This document proposes two types of SRv6 Path Segment format. Be future-proof! "This document defines..." --- 3.1.1 Here you appear to say that the SRv6 Path Identifier can be routable (i.e., is built with as LOC:FUNCT), but in the Introduction you are adamant that it is not routable. --- 4.1 Nothing wrong with Figure 1 (except the alignment of the bit counters) but it seems overkill to draw what the text says. --- Please decide "P-flag" or "P-bit". Probably flag. --- From nobody Thu Feb 10 19:41:31 2022 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 6D2793A0919 for ; Thu, 10 Feb 2022 19:41:27 -0800 (PST) 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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 LnOtPHpJqoCe for ; Thu, 10 Feb 2022 19:41:21 -0800 (PST) Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam07on20713.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e83::713]) (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 BA5E63A08FF for ; Thu, 10 Feb 2022 19:41:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jT4qVVmXSFZshPfTpJSFqYRxyb8vufzm+jQKJvH9g+/IwR79aegfnM+xdw93JGnakJW39NBI7vTcGVpxLK+Kq1h1NSc11e+qwzAF1O52TGHeKgZpioxBZVU0FG9iTp199mTXRWcNdljuQT+1RrCSPxNJlUoxLxxH7oPGsFBqy9DzY+POuD5nNCXHm9pfedfDAuzHAyeyqstxemD1IdXOJp7K7x7PfqjdU1chF/bYXmgbgTnfO7lXXGOVAK/YMD2D5NBO7GZeXX+L+GPSBetidz5FC9WaRxJQEpPFKmoFRjCWgeb2+Mf3YC4MN23Y77hAXkOP8XwOVGAhHouZwXXj6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gB02qFdWcDvhAJJJe5gqILGrnyO9cdu6vHvaNxncsgo=; b=YaeDXaA2UDY98qN/r03QwezNsKGSDuoQlHDSrABq5OX9/dytWA8yaOvOlH3MpTNxgrLKqKgdnzuXfrxvuX/Qsy01PCym38sLOLFEIyd61hJ9jdL3Mn02rqgnm9/WSUi+L8Tvg7GXItJqBJVUPc25diDzWpGQktL6qvL68BIzJY9CFRTk8fXGqIjePJOrJNAhRPAQWdI0Qx5JpJ1SzeUx6OcKkNuI0pCypjmW9p6UgSiGTsH1jfkNby3DlGxHYesjjB50JTGiNHZrASNs8oB6jozVcAEjZ5v3PIht6RiIPj0bNps2uvs2430axx/wjGArq/qSsXXHpwlj5xygHbzmrQ== 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=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gB02qFdWcDvhAJJJe5gqILGrnyO9cdu6vHvaNxncsgo=; b=IVxyeHq41K7omW+aropt8Bb0ShfeM7pWlj1AJ01gwUXIrqXU0k+UbeGca7FZ95diAcb8/b+FcgAVCvBilePWXMtzDk6b/MvBDelP6bE43CaTBxDXAnN68ZfOY8ym7WeEe5KKV15RXHZrpqFbUbS4OrCjWOgnRYEmDjCsSIWTGQU= Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by CH0PR13MB4667.namprd13.prod.outlook.com (2603:10b6:610:d9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.9; Fri, 11 Feb 2022 03:41:13 +0000 Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059%6]) with mapi id 15.20.4995.007; Fri, 11 Feb 2022 03:41:13 +0000 From: Huaimo Chen To: Greg Mirsky CC: Bruno Decraene , SPRING WG Thread-Topic: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAUzUcCAAApCg5kAA/cJgAAwZGo8ACPzq4AADjcfZA== Date: Fri, 11 Feb 2022 03:41:13 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 745c2681-81d6-a0ff-8918-a84b883ba04c authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 519be5e6-1dbc-4462-92fb-08d9ed105a09 x-ms-traffictypediagnostic: CH0PR13MB4667:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0puEnxAI09VuIiywpxSCqyRqOOnE90zzTL7Fuwj8wJCSz756iymjYE+pEgDKkJoRqsLbMADph9x4pxPlLYJmsppm/GTxayy5hk/gLhwsUbV0K5ESiYlq/Yg3s6tti69EeyeL/g6JP6YNqS8ZcsS7wMvdvmhtd/x1gewURPgEXJFTY3os++9WJjS4aE0DMieweXF53n/5cREKs1pDLrtalHKKZvFEFQ6eaWgtb/LKKCTO0T0jErW8d4uqlnQ3KdslpR4XY4hbEUO2WY3iedwPEXpv0ddeOLD1C8Oma+sbJo4T7KocCMwm0HYSxXXW8nrUb9B2oKlJFNCU4MviZ5xGd+xpED0cfuPnU993/7iZ8nUAlUNPOrV93Ov5oQQnsIFEfj99DZSLdxm25thjX+SZf1YjSAnwkhXT3UdWsw78xGsl2fU1cXW/l1VPqqATuGPItwmvY+HVaP3dWMrzbsf1ofFvaWtoRrT7csp94xdDwCtuV7HqGf4uLN+G5ZcHRJNGZbkQeHIUKuMXcDsxGX99L8xV7s6nYoVpVqa/NqDNzwtRH1XEaVLcE3nVGkYWwRT/chgA/CVsPylPRg8s95tSCXFmlrKkZ+ytE3H0MVt1tf6pwrLR83uobD+pEb3kDNtmu7w4YTBcz40lmA7PfnUQMqP8Bqbyx8Yhi7TuRL3pFGYGaxBW0Ut93k9Og+dRBzv6yMOkHAW152+z34EWRbq01Z2DYEjKlqCJLZc8ZKtML+LrpCrb2mpEQi1Yy+oBycJaVMUUvj/XoThkpP88CJpd1PN9iHNKuBQU5rCX8UUVsiW8oVQ5oLb/ir83RdVQj4EzqvYbXp1apXgek+imMTclgZxJ8AT1gfYqCXz+yjlkkRJ46FVEyGcz9ezOO052wJzz x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66556008)(122000001)(55016003)(52536014)(8936002)(38070700005)(86362001)(44832011)(66446008)(186003)(2906002)(38100700002)(8676002)(166002)(66476007)(76116006)(66946007)(54906003)(64756008)(71200400001)(33656002)(508600001)(53546011)(83380400001)(6506007)(9686003)(5660300002)(7696005)(19627405001)(26005)(966005)(4326008)(316002)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Wmro7f3VTbY6pEEqMiB68pMwdROjUL6MG2RezrgTq4UhIoct63Vhpgcsrx?= =?iso-8859-1?Q?eXJ86+EUbjRlrQidBtqC0FiOkxOissZwurNHOcrYpM870cGyA2IIMcPCx4?= =?iso-8859-1?Q?3sXPctna0dY41+nLbzLUxXhSXo+RUQLKSALg/yIA6nrr0CIol4Czkwq1Yb?= =?iso-8859-1?Q?q8j9eqpO6ykZviy+01AYIeuM8lmu8mkS1cPqmrUDofNB0zOSWuURpIszvK?= =?iso-8859-1?Q?kzZHyA0x+v5RPzFCH7ExI20+3RojFMeViXpT+XqXZQhcDEkpjci6zToQi5?= =?iso-8859-1?Q?EFzCnsD5fLboFn7CYVtzjMctTjSg81UFAZmVohcMwD5i0w7XCxJSTgOrPD?= =?iso-8859-1?Q?uFh7Ngui/ia7APTFJhCZdZJQi7weTWqxjDC5dbF7jLBzHOPLfSsvTIt3CQ?= =?iso-8859-1?Q?bhDavleSW3OvHM5dkFU67qlLO5Xdp2B6ya4GbFiVdwLi/k4VX+voauuVI3?= =?iso-8859-1?Q?8f3TQhutKpTmqijrLfupcv2jGJP24vGIchreOtY5AAQOpELsY+GILX6HTG?= =?iso-8859-1?Q?W953+7TNpFqm/+vLw8siH1bpAX/rp7Qs8CxRrrRrcNVAXIHHWW9TvoYujW?= =?iso-8859-1?Q?VCyxPQBSSkT70NCDgQlo8xFJGEVUWFP12CqmX7g1zJo5hHKZpXDUo8Wwxi?= =?iso-8859-1?Q?OfN8fQbisozkN6SsI3meqxbn9Hpc/7gQg0QZh/OuoDIKXLQyrUd1soHAFN?= =?iso-8859-1?Q?yWf93GalbguXnxqs59gb2aBTO0C11i99op5gQ30CsKlEARxY2YoPn5gRHm?= =?iso-8859-1?Q?r6S/l86iMLCqhOTRLI5jYCVXjCi+EL3m0LwCVz0rFjF0Wg7EQF0eMRgHPb?= =?iso-8859-1?Q?s28UWNfmJr7HxAtEsgFL3uy9HtHuMPvpsfeV5kX+5Vq8w2hmjUNtR279aS?= =?iso-8859-1?Q?ywaKm9f9NU94GWhWe98/2sdg25SMD6DZmwxTn9BurobH4pXAD5cUXAp2A2?= =?iso-8859-1?Q?OQFk+/XIbgJkLXHhyb7JA0C8FQ22dNJU6kVuyA2loLLGPy135VUQkkGKge?= =?iso-8859-1?Q?XcuuDtDMiCnu95qNKCHNuUFeGEKNEilsTmvW83m02IycBhxoxIHl109TJ1?= =?iso-8859-1?Q?iGbQ15NiXeM4LntrTgL6JokA5uiVNzZSR1QzdaW1N/4pJm0rMW/ZMEcbrn?= =?iso-8859-1?Q?HizRK1CFM9yPEOrFD541JJPPLnAGU2JcSbvKti60fT5mk9Elj6f0QGm0GL?= =?iso-8859-1?Q?qWStdC6++9wLWyHtuLIdqJDi1d10W3f+I5ek8cYAl288K9TrkvBGHnMZi9?= =?iso-8859-1?Q?/EodZxwK+BKIfh+ZPwryLpIcJC+HHG7Rz7eIcNDdAayLgTdQRo07Vdu1wp?= =?iso-8859-1?Q?l2efnSfvEAATwvXpSC6KYUuZ2buLQvYQPFdQDaKhXSVlgn07+R/gJJFK7Q?= =?iso-8859-1?Q?rP4PlRXVI7JuETEvPG8eC7N4Wg2m7tcJ55S5twr0XzN0ckWu9S4MnBaRDx?= =?iso-8859-1?Q?J1OVWumSkxNkH6MTpqhRNshoAcRGIRQuFYzFqRWCRaiNeP1vt4Qa+0ISif?= =?iso-8859-1?Q?59jU3JJQWq46gD+wNPS624Wq98+uXyBcJMeaPCQlKzM23DHE5n7oXihnSA?= =?iso-8859-1?Q?RJRLkuPPAvcYyDq9/oLxTuvdeJVvHhF+P4mwpB/JsFsn/QjYI5t4tBvWuo?= =?iso-8859-1?Q?ixOqdELtP9LAB5fJ471Wt46SmdhEps/smBFIYReZcWk5ZNGYpvmijbgw?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB504425F93AB21C0A18B1A0E9F2309BY3PR13MB5044namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 519be5e6-1dbc-4462-92fb-08d9ed105a09 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2022 03:41:13.3910 (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: GPr5Qo11Ma9d1bzZ7ffsv9kv9JqxZIgUzHa8Y/J3X28d0hjQ7Cdb62e2SIQkn0Dk0cnON08v6Dz0eDAIkKQRiQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR13MB4667 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 11 Feb 2022 03:41:28 -0000 --_000_BY3PR13MB504425F93AB21C0A18B1A0E9F2309BY3PR13MB5044namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you very much for your comments. My responses/explanations are inline below with [HC3]. Best Regards, Huaimo ________________________________ From: Greg Mirsky Sent: Thursday, February 10, 2022 3:40 PM To: Huaimo Chen Cc: Bruno Decraene ; SPRING WG Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi Huaimo, thank you for responding to my notes and questions. I wanted to highlight o= ne issue (top-posting): For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths, if a node X on the shortest path from a upstream node to N does not support the mechanism, node X drops the traffic transported by the path. For the solution in our draft, proxy capable nodes off node X on the shorte= st path to a neighbor of N are used. >From reading your response, it seems that you compare how different solutio= ns behave not in identical environments. I don't see that as a fair compari= son. [HC3]: The environments are the same for two different solutions. That is that the same environment for two different solutions. A node X on the shortest path from a upstream node to N does not support any protection/solution. That is that node X does not support the mechanism in draft-ietf-spring-segment-protection-sr-te-paths or our solution. Other nodes support the protection/solution. That is that they support the mechanism in draft-ietf-spring-segment-protection-sr-te-pa= ths or our solution. Regards, Greg On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen > wrote: Hi Greg, Thank you very much for your notes. My responses/explanations are inline below with [HC2]. Best Regards, Huaimo ________________________________ From: Greg Mirsky > Sent: Tuesday, February 8, 2022 11:25 PM To: Huaimo Chen > Cc: Bruno Decraene >; SPRING WG > Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Hi Huaimo, thank you for the expedient response. Please find my follow-up notes in-lin= ed below under the GIM>> tag. Regards, Greg On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen > wrote: Hi Greg, Thank you very much for your comments. My responses/explanations are inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: spring > on b= ehalf of Greg Mirsky > Sent: Tuesday, February 8, 2022 4:38 PM To: Bruno Decraene > Cc: SPRING WG > Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Dear Authors, et al., I've read the draft and would appreciate it if the authors can clarify one = question: * What do you consider as the significant advantage of the mechanism de= fined in your draft compared with the mechanism defined in draft-ietf-sprin= g-segment-protection-sr-te-paths? As I've compared the two solutions, I couldn't find any significant advanta= ge of the proxy forwarding to have two standardized mechanisms for SR path = e2e protection. It might be reasonable to have one standard while other pro= posals get experimental status? [HC]: It provides more protection coverage in some cases as compared to the mechanism defined in draft-ietf-spring-segment-protection-sr-te-paths. GIM>> I find it hard to quantify your characterization. I imagine that if a= n operator uses the protection mechanism defined in draft-ietf-spring-segme= nt-protection-sr-te-paths it designs the network with that in mind and thus= minimizes if not completely avoids any possible limitation the protection = mechanism may have. Perhaps you can help with some more specific scenarios. [HC2]: Assume that a SR path has the SID of a node N and node N failed. For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths, if a node X on the shortest path from a upstream node to N does not support the mechanism, node X drops the traffic transported by the path. For the solution in our draft, proxy capable nodes off node X on the shorte= st path to a neighbor of N are used. The neighbor re-routes the traffic around failed node N towards the destination. The traffic is protected. This improves the reliability of networks, and QoE. This should be a significant advantage. There is no solution for BSID protection in the other existing draft. GIM>> Though BSID may be used inside the network, I find such use case ques= tionable making no significant impact on the usefulness of the protection m= echanism. [HC2]: Considering two drafts A and B. Draft A supports protection of a SR path, which contains two types of components, say C1 and C2. If the path contains a third type of components, say, C3, then protection of the path for C3 is not supported. Draft B supports protection of a SR path, containing C1, C2 and C3. In this case, draft B seems having a significant advantage over draft A. The solution for BSID protection in our draft has been there for a few years. In addition, after a node failed, in our solution, the nodes of the entire network converge to the latest state consistently in time. After a node failed, the mechanism defined in the other existing draft holds off the FIB during the HoldTimer period configured, when the network changes again, GIM>> I consider that property of the protection defined in draft-ietf-spri= ng-segment-protection-sr-te-paths as a benefit that allows better control f= or the proper coordination between protection mechanisms that operate on di= fferent network layers. our solution continues to converge at any time. The mechanisms in two drafts are different. It seems ok and reasonable to have the two drafts to be adopted in the WG. GIM>> I agree with you, drafts are fundamentally different and, in my opini= on, merging them would not change the situation. But I don't see that as th= e justification for producing two standards. It seems to me, releasing two = standard-based specifications might be detrimental and I propose the author= s consider taking this draft onto the experimental track. I'd support the a= doption of it as the experimental track document. Regards, Greg On Thu, Jan 13, 2022 at 2:19 AM > wrote: Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ 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_BY3PR13MB504425F93AB21C0A18B1A0E9F2309BY3PR13MB5044namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greg,

    Thank you very much for your comments.

    My responses/explanations are inline below with [HC3].

Best Regards,
Huaimo

From: Greg Mirsky <gregi= mirsky@gmail.com>
Sent: Thursday, February 10, 2022 3:40 PM
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>; SPRING WG <= spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 
Hi Huaimo,
thank you for responding to my notes and questions. I wanted to highli= ght one issue (top-posting):
For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths,=
if a node X on the shortest path from a upstream node to N does not
support the mechanism, node X drops the traffic transported by the pat= h.
For the solution in our draft, proxy capable nodes off node X on the s= hortest
path to a neighbor of N are used.
From reading your response, it seems that you compare how = different solutions behave not in identical environments. I don't see = that as a fair comparison.
[HC3]: The environments are the same for two different solutions.=  
That is that the same environment for two different solutions.
A node X on the shortest path from a upstream node to N does not
support any protection/solution. That is that node X does not support
the mechanism in draft-ietf-spring-segment-protection-sr-te-paths or
our solution. Other nodes support the protection/solution. That is = that
they support the mechanism in draft-ietf-spring-segment-protecti= on-sr-te-paths or
our solution.

Regards,
Greg

On Wed, Feb 9, 2022 at 7:41 PM Huai= mo Chen <huaimo.chen@future= wei.com> wrote:
Hi Greg,

    Thank you very much for your notes.

    My responses/explanations are inline below with [HC2].

Best Regards,
Huaimo

F= rom: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, February 8, 2022 11:25 PM
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>; SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 
Hi Huaimo,
thank you for the expedient response. Please find my follow-up notes i= n-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen <huaimo.chen@futurewei.c= om> wrote:
Hi Greg,

    Thank you very much for your comments.

    My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors

From: spring <spring-bounces@ietf.org> on behalf of Greg Mirsky <<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com>
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 
Dear Authors, et al.,
I've read the draft and would appreciate it if the authors can clarify= one question:
  • What do you consider as the significant advantage of the mechanism defi= ned in your draft compared with the mechanism defined in draft-ie= tf-spring-segment-protection-sr-te-paths?
As I've compared the two solutions, I couldn't find any significant advanta= ge of the proxy forwarding to have two standardized mechanisms for SR path = e2e protection. It might be reasonable to have one standard while other pro= posals get experimental status?
[HC]: It provides more protection coverage in some cases as compared t= o
the mechanism defined in draft-ietf-spring-segment-protection-sr-te-pa= ths.
GIM>> I find it hard to quantify your characterization. I imagin= e that if an operator uses the protection mechanism defined in draft-ietf-s= pring-segment-protection-sr-te-paths it designs the network with that in mi= nd and thus minimizes if not completely avoids any possible limitation the protection mechanism may have. Perhaps = you can help with some more specific scenarios. 
[HC2]: Assume that a SR path has the SID of a node N and node N failed= .
For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths,=
if a node X on the shortest path from a upstream node to N does not
support the mechanism, node X drops the traffic transported by the pat= h.
For the solution in our draft, proxy capable nodes off node X on the s= hortest
path to a neighbor of N are used. The neighbor re-routes the traffic a= round
failed node N towards the destination. The traffic is protected.
This improves the reliability of networks, and QoE. This should be a <= /div>
significant advantage. There is no solution for BSID protection in the=
other existing draft.
GIM>> Though BSID may be used inside the network, I find such us= e case questionable making no significant impact on the usefulness of the p= rotection mechanism. 
[HC2]: Considering two drafts A and B. Draft A supports protection
of a SR path, which contains two types of components, say C1 and C2. <= /div>
If the path contains a third type of components, say, C3, then  <= /div>
protection of the path for C3 is not supported.
Draft B supports protection of a SR path, containing C1, C2 and C3. In this case, draft B seems having a significant advantage over draft= A.
The solution for BSID protection in our draft has
been there for a few years. In addition, after a node failed, in
our solution, the nodes of the entire network converge to the latest <= /div>
state consistently in time. After a node failed, the mechanism defined=
in the other existing draft holds off the FIB during the HoldTimer
period configured, when the network changes again,
GIM>> I consider that property of the protection defined in draf= t-ietf-spring-segment-protection-sr-te-paths as a benefit that allows bette= r control for the proper coordination between protection mechanisms that op= erate on different network layers. 
our solution continues
to converge at any time.
The mechanisms in two drafts are different. It seems ok and reasonable=
to have the two drafts to be adopted in the WG.
GIM>> I agree with you, drafts are fundamentally different and, = in my opinion, merging them would not change the situation. But I don't see= that as the justification for producing two standards. It seems to me, rel= easing two standard-based specifications might be detrimental and I propose the authors consider taking this draft = onto the experimental track. I'd support the adoption of it as the experime= ntal track document.


Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <bruno.decraene@orange.com> = wrote:

Dear WG,

 

This message starts a 2 week WG adoption call, ending 27/01/2022, for d= raft-hu-spring-segment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/d= raft-hu-spring-segment-routing-proxy-forwarding/

 

After review of the document please indicate support (or not) for WG ad= option of the document to the mailing list.

 

Please also provide comments/reasons for your support (or lack thereof)= as this is a stronger way to indicate your (non) support as this is not a = vote.     

 

If you are willing to work on or review the document, please state this= explicitly. This gives the chairs an indication of the energy level of peo= ple in the working group willing to work on the document.

&nbs= p;

Thank= s!

Bruno, Jim,= Joel

______________________________________________________________________=
___________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf= .org/mailman/listinfo/spring
--_000_BY3PR13MB504425F93AB21C0A18B1A0E9F2309BY3PR13MB5044namp_-- From nobody Thu Feb 10 20:36:18 2022 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 6F2E33A0C4F; Thu, 10 Feb 2022 20:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 ssNvf2tkPyEn; Thu, 10 Feb 2022 20:35:47 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 ED8053A0C4E; Thu, 10 Feb 2022 20:35:46 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id h9so7452234qvm.0; Thu, 10 Feb 2022 20:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:mime-version:subject:date:references:cc:to:message-id; bh=Z2rGt2jhm729K1bmoWPIMZEvCYzoaJRqyRhf7j4aMU8=; b=PsOkqX7aZW3FZFEl64gVsaCInOt7Z2VI6wOUEAJhTah7wNHdyRtDnZqSRrKO3jTh9Q OtsAmWSyjNBG9qSW45BYjEWlKPPFOoBGtoZn51Lhfb5sLJ4iBzSeN1mnGEeu3cmm50YB F8cDaRWPBFJ6VkYop/cYweLgmoJoB2vhn+EIR0lbM2aZ6438+hW5DMRVif+l5dAQdZDY 3SDFgirMtqPM1bauTHsehnbfFufyuDRj7ixqlJO0LQ1JdfboV0Ccj8In0QQZBkA1AsHi m38J47tQ9O0mWHYV1RbKLZColRqP6YDGA5ykquY+76jnaJ1E+/kWV37PGhGEk6bvL45S gCAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=Z2rGt2jhm729K1bmoWPIMZEvCYzoaJRqyRhf7j4aMU8=; b=xQM91orrCDfNZ3q4zq0J6LyLc3t71biE7C4ExU9CIMFhJBciGJFIn9fYN5xz7qzjVW trap3VV7ch/+ekV04o2JuVrrULuqaDpDD46NPjzFe2MCbh1xwwwNBY6u0iAcEPviDWVc JxP2hMYVOkVv91L2hzWNq8S126p8MkaFStZ04iRpkya3LYO4hYOIe/vSA15UYIch2hba 3TVcHLKniejubFdDEgGxG0nBciRrnf6ffVFk8YMgK8WP3a465R/jD36GP2buhQO0ME1t shYj6haOjY3sM55uyhUbhqM/0jFPZZ03QXVvkqptsY0sZUk+7PkZpBGAxVL4h7F8cIX6 yqDA== X-Gm-Message-State: AOAM5338lOZ5rTK3vWdZWmC9qy/tjFQfyLITUKHmpJChPramexF7xgGQ MWKTAZrmyv9tZSP2UsL9wSVO4eJFG3U= X-Google-Smtp-Source: ABdhPJyUkNwTIEppnjsbZ+ab1/g2mC2zVjS9qgia7+wY50DuoTm0AgfFwlMJopVk9sE3gd+mlQjp9w== X-Received: by 2002:a05:6214:2b0f:: with SMTP id jx15mr7417785qvb.72.1644554144461; Thu, 10 Feb 2022 20:35:44 -0800 (PST) Received: from smtpclient.apple (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id y15sm10942181qko.133.2022.02.10.20.35.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Feb 2022 20:35:44 -0800 (PST) From: Suresh Krishnan Content-Type: multipart/alternative; boundary="Apple-Mail=_09271364-33A4-4C28-9D82-6DAE3B6A9146" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Thu, 10 Feb 2022 23:35:43 -0500 References: <164455296624.22420.8697444414967128483@ietfa.amsl.com> Cc: spring@ietf.org To: IPv6 List Message-Id: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: [spring] Requesting comments on draft-krishnan-6man-sids-00.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: Fri, 11 Feb 2022 04:35:49 -0000 --Apple-Mail=_09271364-33A4-4C28-9D82-6DAE3B6A9146 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, As discussed during the IETF112 6man working group meeting I have = written a short draft that describes the characteristics of SRv6 SIDs = and attempts to clarify the relationship of SRv6 SIDs to the IPv6 = Addressing Architecture [RFC4291]. Comments are welcome and greatly = appreciated. Text: https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt = Html: https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids = Thanks Suresh --Apple-Mail=_09271364-33A4-4C28-9D82-6DAE3B6A9146 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,
  As discussed during the IETF112 6man working = group meeting I have written a short draft that describes the = characteristics of SRv6 SIDs and attempts to clarify the relationship of = SRv6 SIDs to the IPv6 Addressing Architecture [RFC4291]. Comments are = welcome and greatly appreciated.

Text: https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt=
Html: https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids<= /a>

Thanks
Suresh

= --Apple-Mail=_09271364-33A4-4C28-9D82-6DAE3B6A9146-- From nobody Thu Feb 10 21:11:06 2022 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 6A6B43A0E91; Thu, 10 Feb 2022 21:10:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <164455623041.12781.18152236454430932692@ietfa.amsl.com> Date: Thu, 10 Feb 2022 21:10:30 -0800 Archived-At: Subject: [spring] Erik Kline's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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: Fri, 11 Feb 2022 05:10:31 -0000 Erik Kline has entered the following ballot position for draft-ietf-spring-segment-routing-policy-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [S1; nit] * The sentence starting with "While" appears to be sentence fragment. perhaps just: ". While" -> ", while" [S2.1; nit] * s/null address/unspecified address/ * s/comprising of/comprising/ (though see UTF-8 comment below) [S2.1, 2.6; comment] * It seems unnecessarily restrictive to require names be in ASCII. How about RFC 5198/UTF-8? If these names are purely for human consumption anyway, I wonder if isn't best to allow the humans to name things in their native language(s)... (I'm not sure if BCP 18 applies here.) [S4; question] * For each of the uses of "IPv4 Prefix" and "IPv6 Global Prefix" should there be an additional "Unicast" qualifier before "Prefix"? If multicast prefixes are acceptable or understand (somehow) to be out of scope, then no worries. [S8; nit] * s/of where come/of which some/? From nobody Thu Feb 10 22:15:17 2022 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 0D4F03A1134; Thu, 10 Feb 2022 22:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 makwU0d1I2Nc; Thu, 10 Feb 2022 22:15:05 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 75A973A1130; Thu, 10 Feb 2022 22:15:04 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id v6so9066134vsp.11; Thu, 10 Feb 2022 22:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=apRb2khT0sgBfCCcKs+pXY0kiQh0nQ5FUjHOsT/psjY=; b=BQwSnI38X238711uv4OHYnCiqTGYkcwpCEh4RSkIeAxH5NXtg14tvYDxvWLrcpxMnD uYL2Kjc3WD8Yuwt3WZoyQDegoP5VqaE62mv0JWET9I15oQPMTK0oLmqjUoGWe+m7aJrQ QaWhhO9+w8M5dfyEp5qNSMWK/+CIDWwS9pFWgWN+wH42pJ+fBvcaKlUgL3dbUM044Y6b /bxPHSJhtzv/7SVciMBKSuo5ge8tMaWqZoIivfzpjbILU+cKtrH6fBtEd63Y0B5eHEp+ JmZO3RLpFf8F/1cEL8/UsWU+yPlm8FQw3o8QWJsPru7RgF1zSnPmzTly/oBMfPGpbB8V H9UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=apRb2khT0sgBfCCcKs+pXY0kiQh0nQ5FUjHOsT/psjY=; b=fbZd1ZPxnfu1N3aek0zJIOW/ulItCAjc/XGjqi6uXVufcu8yUE3ZqC5RyAMxpNacvt qZiH07i2XLdouK4xiW/ORyI24yFuQImJuXeHY2Vcej1cE7BSbM0/sGPT/tJiJbAfkcro sMzL7lkZbXY0m1dT2axx52aCJ9nYpo7g92oo/REmu+pHCsjDEaCEXLRe3AF+7K3R2Vne JZKkj+tykgJTEQpllo+n5EFLMRvKTopaVWJzHKGJ/jiev4HZ5LDfrbvk55xa0jj8IDIw eLz+HlL3r0GZit6Rat1ywim+rRgNo5HlRFKGmiNKrFNP002bWgppMdx/t06dTqANlcKX fcGw== X-Gm-Message-State: AOAM530qd6AEaU/CgU5vOyqzyKHbYRqC/PWMccEjdzVQvsunU15hxxbI XOfSM46kZxZR0M2YRfPqNrkTMG6hUGx/z3b4vfA= X-Google-Smtp-Source: ABdhPJy/oyw9lkovwxbEA0Jz5lAqv25crRLcE2kr8cNM/XKlbaiDe52CuMK2GtxGVb1WMLWBQKHy3rCoGKOH6zBG110= X-Received: by 2002:a05:6102:c8d:: with SMTP id f13mr52881vst.33.1644560101767; Thu, 10 Feb 2022 22:15:01 -0800 (PST) MIME-Version: 1.0 References: <164455623041.12781.18152236454430932692@ietfa.amsl.com> In-Reply-To: <164455623041.12781.18152236454430932692@ietfa.amsl.com> From: Ketan Talaulikar Date: Fri, 11 Feb 2022 11:44:49 +0530 Message-ID: To: Erik Kline Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000ad7d9b05d7b7fc21" Archived-At: Subject: Re: [spring] Erik Kline's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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, 11 Feb 2022 06:15:11 -0000 --000000000000ad7d9b05d7b7fc21 Content-Type: text/plain; charset="UTF-8" Hi Erik, Thanks for your review and please check inline below for responses. We will include these changes in the next update. On Fri, Feb 11, 2022 at 10:40 AM Erik Kline via Datatracker < noreply@ietf.org> wrote: > Erik Kline has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [S1; nit] > > * The sentence starting with "While" appears to be sentence fragment. > > perhaps just: ". While" -> ", while" > KT> Ack > > [S2.1; nit] > > * s/null address/unspecified address/ > > * s/comprising of/comprising/ (though see UTF-8 comment below) > KT> Ack > > [S2.1, 2.6; comment] > > * It seems unnecessarily restrictive to require names be in ASCII. How > about RFC 5198/UTF-8? If these names are purely for human consumption > anyway, I wonder if isn't best to allow the humans to name things in > their native language(s)... (I'm not sure if BCP 18 applies here.) > KT> These names are also signaled via routing protocols such as BGP and PCEP. This point did come up for discussion in the WGs ( https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/) and it was decided to stick to printable ASCII for consistency between the protocols and architecture specs. > > [S4; question] > > * For each of the uses of "IPv4 Prefix" and "IPv6 Global Prefix" should > there be an additional "Unicast" qualifier before "Prefix"? If multicast > prefixes are acceptable or understand (somehow) to be out of scope, then > no worries. > > KT> The types defined in the document are all unicast since all of them are either associated with a node (i.e. Prefix Segment) or associated with a link address (i.e. Adjacency Segment). This does not preclude future documents from introducing new types that use multicast addresses. > [S8; nit] > > * s/of where come/of which some/? > KT> Ack Thanks, Ketan --000000000000ad7d9b05d7b7fc21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,

Thanks for yo= ur review and please check inline below for responses. We will include thes= e changes in the next update.


On Fri, Feb 11, 2022 at 1= 0:40 AM Erik Kline via Datatracker <= noreply@ietf.org> wrote:
Erik Kline has entered the following ballot position for draft-ietf-spring-segment-routing-policy-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[S1; nit]

* The sentence starting with "While" appears to be sentence fragm= ent.

=C2=A0 perhaps just: ".=C2=A0 While" -> ", while"

KT> Ack
=C2=A0

[S2.1; nit]

* s/null address/unspecified address/

* s/comprising of/comprising/=C2=A0 (though see UTF-8 comment below)

KT> Ack
=C2=A0

[S2.1, 2.6; comment]

* It seems unnecessarily restrictive to require names be in ASCII.=C2=A0 Ho= w
=C2=A0 about RFC 5198/UTF-8?=C2=A0 If these names are purely for human cons= umption
=C2=A0 anyway, I wonder if isn't best to allow the humans to name thing= s in
=C2=A0 their native language(s)... (I'm not sure if BCP 18 applies here= .)

KT> These names are also signaled= via routing protocols such as BGP and PCEP. This point did come up for dis= cussion in the WGs (https://mailarchive.ietf.org/arch/msg/spring= /Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/) and it was decided to stick to printable= ASCII for consistency between the protocols and architecture specs.
<= div>=C2=A0

[S4; question]

* For each of the uses of "IPv4 Prefix" and "IPv6 Global Pre= fix" should
=C2=A0 there be an additional "Unicast" qualifier before "Pr= efix"?=C2=A0 If multicast
=C2=A0 prefixes are acceptable or understand (somehow) to be out of scope, = then
=C2=A0 no worries.


KT> The types defined in the docume= nt are all unicast since all of them are either associated with a node (i.e= . Prefix Segment) or associated with a link address (i.e. Adjacency Segment= ). This does not preclude future documents from introducing new types that = use multicast addresses.=C2=A0
=C2=A0
[S8; nit]

* s/of where come/of which some/?

KT>= ; Ack

Thanks,
Ketan

=
=C2=A0
--000000000000ad7d9b05d7b7fc21-- From nobody Thu Feb 10 22:17:06 2022 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 C18153A1157; Thu, 10 Feb 2022 22:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUJXXMxpflb5; Thu, 10 Feb 2022 22:17:01 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 64B143A1148; Thu, 10 Feb 2022 22:17:01 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id c36so4183098uae.13; Thu, 10 Feb 2022 22:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ua75oev1GP8riaB98r9zqYvFf91XUIQ+lSQJ3YmSV00=; b=MnJagC/Y0EExUz1TZjh9oOATABEKPr6FvliMdbvps8p6xHH0VY/LKY2uZywcO97nXr f3oxJc8DjhAsYcJ6qA9CE+akm2UhR1dpIF1D6pNdgpTg5sqHT0XvPzxVngli8Fsp737f 2wzKYF0iq3QW9PBmdsKdDSR8v4463td8Bs4E5h7k/CWxfy92SkAcwXy6Lw1tT8MYF6VM zyUDU5dO2S6XaFYWc0OWtf0A8HRltnGOCFaV6jRfDokhcj4s2eH8EbwwsKJT0h5HsMV2 JWNojhgmQ/21bj1t1ucxzCajFJQEwsJhcVCWr5qGOuCSLNNlXkbDnWWk1ke15tv31erg XDWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ua75oev1GP8riaB98r9zqYvFf91XUIQ+lSQJ3YmSV00=; b=TgbvJ10+sO/db+ig2o1STDvsw5oByWphPq+PecA9XG3ae60t4o6LuMO28l3tFQboqL WW/nGKVX35rd8VGJujOKNGABZRiQTnsSkaulT9bUqJarvRApnjYxHKAzeuD67HHE9IS6 Pp/FnwSos8WqQbOrwEMxSyP65GJ/5WfoesZmncRDRSoQmQQL7Hz6wcANgGOUHBsCi8Q7 FYCYNNyDX+ELgI+3lWaNxmjcoYclRbANAr3YzRZr0xxjb/rqT0bHAxyfIGuyG4NmVRGt OmXrydemzT387ESRh7wzws8MznqJQSsAGj7XcjOTLbxHaALRvFn1fITppztdiy3AbXI0 uGSQ== X-Gm-Message-State: AOAM530g5eKbIuAYbj52JzyW0VS3+4Si3PTj5peRJ1iLKvqhcjLRnv7K 9DY7acFaKZh4KdSlj9TOGOBgDIA0laoWdgj4TAlLJAFv X-Google-Smtp-Source: ABdhPJyXBSCoWfgAiHUTYAlrdjarKtXl7XybTEKfNA8olX3GzXgqRuC6pn4YtCxPilG8aE6z5G9ohholcyrNSO+9Z7k= X-Received: by 2002:ab0:2117:: with SMTP id d23mr83800ual.28.1644560218348; Thu, 10 Feb 2022 22:16:58 -0800 (PST) MIME-Version: 1.0 References: <164418360967.24977.17268842252865901665@ietfa.amsl.com> In-Reply-To: <164418360967.24977.17268842252865901665@ietfa.amsl.com> From: Ketan Talaulikar Date: Fri, 11 Feb 2022 11:46:46 +0530 Message-ID: To: Cullen Jennings Cc: art@ietf.org, draft-ietf-spring-segment-routing-policy.all@ietf.org, last-call@ietf.org, SPRING WG Content-Type: multipart/alternative; boundary="000000000000a05e1a05d7b803f2" Archived-At: Subject: Re: [spring] Artart last call review of draft-ietf-spring-segment-routing-policy-16 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, 11 Feb 2022 06:17:05 -0000 --000000000000a05e1a05d7b803f2 Content-Type: text/plain; charset="UTF-8" Hi Cullen, Thanks for your review. We will include the range 0x20-0x7E in the spec and this was also what Benjamin Kaduk had suggested. We will incorporate this in the next version of the document. Thanks, Ketan On Mon, Feb 7, 2022 at 3:10 AM Cullen Jennings via Datatracker < noreply@ietf.org> wrote: > Reviewer: Cullen Jennings > Review result: Ready > > This draft does not raise any issues specific to the ART area. > > The use of non UTF symbolic names is appropriate for this use case so I do > not > see any issues with strings. I view printable ascii as fairly well defined > but > if you want to be clearer, you could say 0x20 to 0x7E. > > As an outside reader not involved with the spring WG, this draft was > relatively > easy to understand. I do not see any problems with publication. > > > > --000000000000a05e1a05d7b803f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Cullen,

Thanks for your review.=C2= =A0

We will include the range 0x20-0x7E in the spe= c and this was also what Benjamin Kaduk had=C2=A0suggested. We will incorpo= rate this in the next version of the document.

Tha= nks,
Ketan


On Mon, Feb 7, 2022 at 3:10 AM Cul= len Jennings via Datatracker <norepl= y@ietf.org> wrote:
Reviewer: Cullen Jennings
Review result: Ready

This draft does not raise any issues specific to the ART area.

The use of non UTF symbolic names is appropriate for this use case so I do = not
see any issues with strings. I view printable ascii as fairly well defined = but
if you want to be clearer, you could say=C2=A0 0x20 to 0x7E.

As an outside reader not involved with the spring WG, this draft was relati= vely
easy to understand. I do not see any problems with publication.



--000000000000a05e1a05d7b803f2-- From nobody Thu Feb 10 22:36:36 2022 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 421F83A07AD; Thu, 10 Feb 2022 22:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWkmTXhgONce; Thu, 10 Feb 2022 22:35:02 -0800 (PST) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 272963A0768; Thu, 10 Feb 2022 22:35:02 -0800 (PST) Received: by mail-oo1-xc31.google.com with SMTP id u25-20020a4ad0d9000000b002e8d4370689so9184433oor.12; Thu, 10 Feb 2022 22:35:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TY9kCoWf2DONkDKpps7WcGNxLrCyMCFTjzyciEvC8ig=; b=Ta9L1ZLq5EvFraXNfABKJdEf9n0bJijI4jrghOVxLyuNXO81PBQOdJUuDpIWiJhnD1 90pLGPCAZx61B5ePYju5UMVHI7c08YTn7elEPqVlGXJc8tKCSJJIx/nWV//usb0zZovF HDv7dfrd537XhfMr0twMnbQGLeIxKRFbPo4UKshwP9XD0oZAfUhDHR1IJrCxQHfRT1nQ oYPcgBSlKz55wOD+5bcNVnP5EchkpnjzXAw8XHXheTbC9zOxxXxa9MXORppQVnVWwp5t 6+hGLEt6omcbHmy6TYE2jEP89gPPYGzIHwJoHrN82RkGR/7ROVp6THF62TuQXjgwjP4e TWzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TY9kCoWf2DONkDKpps7WcGNxLrCyMCFTjzyciEvC8ig=; b=zlMSueBfSCiyTCf1lPwOL/aa//At5NH/5L/0GTXmdAYIl2IMLf8YxZp1/cy72vJ7Nf AFzbw/eNqSA/dkpHjI4ULzUIFpEOuz123mSy6mKBlzCATRj1865ItgCosSEI3u1n3YzE JWQiA2jM0RMV0j/3slnN2sCFQbZ1XWoaXbixYsmYAwUWktcP77cDErYK/shcD1/Ds+oA NePo0RDzznXFnJsmCfIREsC0KWQqlUEoDUDd3MM21N2kFHm7PUddgLixC5pW86mzS45t EfVIYVOvzSqcfraVT1SQTjOcooxqj7pQIyteUzJpnmFIHs8F3FVhbnyd1+C8HcQ9Ru+1 /sjw== X-Gm-Message-State: AOAM532ECvw/k3/PtgPP0l1G0t7wHh90MKvWtfikzReq+aAkFJwHseLz 5d6mXeaxVxEPtpftXF4qCIGQSlUWVxE6JWtaBYw= X-Google-Smtp-Source: ABdhPJy1Auu0zbXbGSPbZjbtan+qh2GFQotNltuIBEAhYMa08K+ijDKMOmzP6wp9b9TnOA6TWxcoV99TvdqweoPiCdQ= X-Received: by 2002:a05:6870:814:: with SMTP id fw20mr48127oab.5.1644561299392; Thu, 10 Feb 2022 22:34:59 -0800 (PST) MIME-Version: 1.0 References: <164455296624.22420.8697444414967128483@ietfa.amsl.com> <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> In-Reply-To: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> From: Erik Kline Date: Thu, 10 Feb 2022 22:34:48 -0800 Message-ID: To: Suresh Krishnan Cc: IPv6 List , spring@ietf.org Content-Type: multipart/alternative; boundary="0000000000000fcd5205d7b844e3" Archived-At: Subject: Re: [spring] Requesting comments on draft-krishnan-6man-sids-00.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: Fri, 11 Feb 2022 06:35:08 -0000 --0000000000000fcd5205d7b844e3 Content-Type: text/plain; charset="UTF-8" Thanks Suresh! On Thu, Feb 10, 2022 at 20:36 Suresh Krishnan wrote: > Hi all, > As discussed during the IETF112 6man working group meeting I have > written a short draft that describes the characteristics of SRv6 SIDs and > attempts to clarify the relationship of SRv6 SIDs to the IPv6 Addressing > Architecture [RFC4291]. Comments are welcome and greatly appreciated. > > Text: https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt > Html: https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids > > Thanks > Suresh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000000fcd5205d7b844e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Suresh!

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 10, 2022 at 20:36 Suresh K= rishnan <suresh.krishnan@gm= ail.com> wrote:
Hi all,
=C2=A0 As discussed duri= ng the IETF112 6man working group meeting I have written a short draft that= describes the characteristics of SRv6 SIDs and attempts to clarify the rel= ationship of SRv6 SIDs to the IPv6 Addressing Architecture [RFC4291]. Comme= nts are welcome and greatly appreciated.


Than= ks
Suresh

-------------------------= -------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--0000000000000fcd5205d7b844e3-- From nobody Fri Feb 11 07:44:47 2022 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 C23D83A12C1 for ; Fri, 11 Feb 2022 07:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.1 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, 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 nc4oE4Ju1afI for ; Fri, 11 Feb 2022 07:44:41 -0800 (PST) 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 A3B603A122F for ; Fri, 11 Feb 2022 07:44:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4JwHx52lWvz6G8x7 for ; Fri, 11 Feb 2022 07:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1644594281; bh=fMXfWW9BnbBN/sVaa0Qe7LURDpYj9bihpDQlAfDp+DE=; h=Date:Subject:References:To:From:In-Reply-To:From; b=joSu2oOOmKkft3JRmvUKMSAL2qx7HED1+RkcqcsDiaLwWpyEDTWKlVQ7+tUnzVsRQ NUVCENYgz/UN2H+Ma6pEuyk1Ps36D0haHVhHbTrDxFnZMven9FCCfUQzCGJOdWKFL6 IuhbNuu+/ZZzsNsU8VJmXc4vS/LsHgH+q0aeT+HY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4JwHx46l7pz6G7nW for ; Fri, 11 Feb 2022 07:44:40 -0800 (PST) Content-Type: multipart/mixed; boundary="------------9l8VN0avXRYQOgtpXv0PdRw7" Message-ID: Date: Fri, 11 Feb 2022 10:44:39 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 References: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> Content-Language: en-US To: "spring@ietf.org" From: "Joel M. Halpern" In-Reply-To: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> X-Forwarded-Message-Id: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> Archived-At: Subject: [spring] Moving forward with draft-filsfilscheng-spring-srv6-srh-compression 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, 11 Feb 2022 15:44:46 -0000 This is a multi-part message in MIME format. --------------9l8VN0avXRYQOgtpXv0PdRw7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit As you can see, Suresh has published an Internet Draft about SRv6 SIDs. As described in https://mailarchive.ietf.org/arch/msg/spring/VjVIxo7fZFhsIHJ5wFQXIBvvtNM/ which concluded the adoption call on draft-filsfilscheng-spring-srv6-srh-compression, we can now move on to the next steps. Authors, please submit draft-ietf-spring-srv6-srh-compression with the content being what was presented to the WG, with the changes called for in the conclusion message above. I will be creating the issue tracker, and seeding it with the two issues called out for identification in the draft. I look forward to working group discussion of the draft. I will do my best to identify and record specific issues. Participants are welcome to create issues directly in the issue tracker. When you do so, please also send the issue to the list as a basis for on list discussion. Similarly, if you choose to put a comment in the issue tracker, please also make sure your comment goes to the list. Note that changing the status of issues is a chair responsibility. I will do my best to do so promptly. Yours, Joel -------- Forwarded Message -------- Subject: [spring] Requesting comments on draft-krishnan-6man-sids-00.txt Date: Thu, 10 Feb 2022 23:35:43 -0500 From: Suresh Krishnan To: IPv6 List CC: spring@ietf.org Hi all,   As discussed during the IETF112 6man working group meeting I have written a short draft that describes the characteristics of SRv6 SIDs and attempts to clarify the relationship of SRv6 SIDs to the IPv6 Addressing Architecture [RFC4291]. Comments are welcome and greatly appreciated. Text: https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt Html: https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids Thanks Suresh --------------9l8VN0avXRYQOgtpXv0PdRw7 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Disposition: attachment; filename="Attached Message Part" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmlu ZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K --------------9l8VN0avXRYQOgtpXv0PdRw7-- From nobody Fri Feb 11 09:53:06 2022 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 33F283A091C; Fri, 11 Feb 2022 09:52:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164460197712.11990.5830809850738145285@ietfa.amsl.com> Date: Fri, 11 Feb 2022 09:52:57 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-srh-compression-00.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: Fri, 11 Feb 2022 17:52:59 -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 : Compressed SRv6 Segment List Encoding in SRH Authors : Weiqiang Cheng Clarence Filsfils Zhenbin Li Bruno Decraene Dennis Cai Daniel Voyer Francois Clad Shay Zadok James N Guichard Liu Aihua Robert Raszuk Cheng Li Filename : draft-ietf-spring-srv6-srh-compression-00.txt Pages : 20 Date : 2022-02-11 Abstract: This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-00 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Feb 11 10:19:21 2022 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 699A43A08A5 for ; Fri, 11 Feb 2022 10:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 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, NICE_REPLY_A=-0.714, 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 pIDrIoR6idnG for ; Fri, 11 Feb 2022 10:19:15 -0800 (PST) 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 0633C3A08C3 for ; Fri, 11 Feb 2022 10:19:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4JwMMQ5Q46z6G9KS for ; Fri, 11 Feb 2022 10:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1644603554; bh=VAt5Iptqycqd2ODRZSa1O6ZoYroEB76X9J83xukbP8k=; h=Date:Subject:From:To:References:In-Reply-To:From; b=eP7aEHIEHZ2lO/oUYuw+qPUpWBLbdUqd3BuI6+cZUEtJCOSNsSdsgUBrg5t1fkovv gQQBWZGSE6sma8eFkG23BVdX34X/Pmv3fyYjkv5UnVHsFhmLjUTQwK/NtVH2frPmE5 h56lDLiKWVkeVCsyYhIhEkrTW0DCEl20YBRqe7LM= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4JwMMQ2Bsdz6G99D for ; Fri, 11 Feb 2022 10:19:14 -0800 (PST) Message-ID: <3b13f790-d9a7-6da3-8b40-0641eab0e2a3@joelhalpern.com> Date: Fri, 11 Feb 2022 13:19:13 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US From: "Joel M. Halpern" To: "spring@ietf.org" References: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Moving forward with draft-filsfilscheng-spring-srv6-srh-compression 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, 11 Feb 2022 18:19:20 -0000 The authors have submitted the draft, and I have approved it to become a working group draft: https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-00 The issue tracker is also up, and has the two issues copied from the email. I did add a reference to Suresh's draft in the second issue. https://github.com/JoelHalpern/draft-ietf-spring-srv6-srh-compression/issues Yours, Joel PS: Looking at this, it seems to have put the repository in the wrong place. If someone can help me fix that, or tell me what I did wrong so that I recreate it in the spring tree, I would be grateful. It is not supposed to be in my personal github space. On 2/11/2022 10:44 AM, Joel M. Halpern wrote: > As you can see, Suresh has published an Internet Draft about SRv6 SIDs. > > As described in > https://mailarchive.ietf.org/arch/msg/spring/VjVIxo7fZFhsIHJ5wFQXIBvvtNM/ which > concluded the adoption call on > draft-filsfilscheng-spring-srv6-srh-compression, we can now move on to > the next steps. > > Authors, please submit draft-ietf-spring-srv6-srh-compression with the > content being what was presented to the WG, with the changes called for > in the conclusion message above. > > I will be creating the issue tracker, and seeding it with the two issues > called out for identification in the draft. > > I look forward to working group discussion of the draft.  I will do my > best to identify and record specific issues.  Participants are welcome > to create issues directly in the issue tracker.  When you do so, please > also send the issue to the list as a basis for on list discussion. > Similarly, if you choose to put a comment in the issue tracker, please > also make sure your comment goes to the list. > > Note that changing the status of issues is a chair responsibility.  I > will do my best to do so promptly. > > Yours, > Joel > > -------- Forwarded Message -------- > Subject:     [spring] Requesting comments on > draft-krishnan-6man-sids-00.txt > Date:     Thu, 10 Feb 2022 23:35:43 -0500 > From:     Suresh Krishnan > To:     IPv6 List > CC:     spring@ietf.org > > > > Hi all, >    As discussed during the IETF112 6man working group meeting I have > written a short draft that describes the characteristics of SRv6 SIDs > and attempts to clarify the relationship of SRv6 SIDs to the IPv6 > Addressing Architecture [RFC4291]. Comments are welcome and greatly > appreciated. > > Text: https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt > > Html: https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids > > > Thanks > Suresh > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Sat Feb 12 00:09:57 2022 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 1BF873A0A7D for ; Sat, 12 Feb 2022 00:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyohRFHbXo3c for ; Sat, 12 Feb 2022 00:09:50 -0800 (PST) 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 D33A43A0A73 for ; Sat, 12 Feb 2022 00:09:49 -0800 (PST) Received: by mail.swisscom.com; Sat, 12 Feb 2022 09:09:46 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_4586038_1076914602.1644653385974" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PkFWq5gjruoigXVISH2xYX0ZbVjjWVcGo5mYbzGkRp0pvo61DaYFKxTK8qB36JgFXerNNndAy8Z8Bc6a597uLlr2zBj+LA2sRvBMtAmFj5iCgmNOdsKpHTKxWuGTbO4V/mfLEdngEMhjXKsRU+ffTvtq05dMHuj4+dFnCeWUku53cvD8YC3FUFsq80KsBSHqaxgxdYxko4eV34HPSNT2QDTuFVLXyemV/NL6+kCGaX7Cmv85mLwioqyp0Cw/ZhSDVCeQWQO0hg0kNxat9AhLjIkqqlYqvZuKt5zBx57sZz26NrsIhZi13hrjas5jxyTI/S6xwFN80UIIhxYTaMlZlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W52L2iSApcyqGOwfqn8b+2C7QNSGqgXlbNIHChefa38=; b=MeOyIWd9+rGBnpctlRZpYLEcutxJneclOdEFlOF6qDRWC67AAvFL+xfkJuvj0c/zIgbLtK6Z8xhvWhIUj97WqY0UZoS9S1pDh7nBNtsUXzDS8rO3w2Ve39WjMQPG7Mtt+MbW6xn57/kVIec1FqwXTsZnwwnADUnCG0QOZlNuTSxFvVnvoDACs1YoQTi4Ts4qGLbDdzELinZFy7ky7EWnRC45fogdTdgWEmJLdd7wpULKQPn9Or4AvPLT2mKz4WmpaUqwM+81Mafd/U/CZZ0EUsoEsVlCZX/v6AILbAI8nQ6WDA04OTnR1V+xd4ijEz2/QZucLJFUb6bVYUKzhngiRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none From: To: CC: Thread-Topic: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Thread-Index: AQHYCfAABwTttaDoTEmhxYgNDpcTxqxjz1dwgAfbVICAA6NfwIAEOZWAgAejGnCADM83AIAHrs9w Date: Sat, 12 Feb 2022 08:09:41 +0000 Message-ID: References: 164223793434.20409.9148647733388794281@ietfa.amsl.com, ZRAP278MB017654891F056AEF03D3B0C289559@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM, 202201201722410433187@zte.com.cn, ZRAP278MB0176B7C7CAED15D977AC0EBE895C9@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM, 202201251727190560534@zte.com.cn, ZRAP278MB017675ADFDABEBC49D9BF02D89249@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM <202202071741403841025@zte.com.cn> In-Reply-To: <202202071741403841025@zte.com.cn> 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_SetDate=2022-02-12T08:09:39Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=fa965ff1-5d0b-49db-923e-4736dcfd5398; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 771bf1da-6da1-4580-f247-08d9edff05a6 x-ms-traffictypediagnostic: GV0P278MB0337:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5yRGkEt3x1bgLvccxaNfNfqWXAsJfi29VKymQwvurPOyOgu3yTkQMJpsdV0MYUruYO8fKDtTYNQUpzZiBTaSeyV6ou1phQS65/AzBORGny4fIANCHNozK+WNsmk9uMp8lQWBw/XAHpimgbj92RswMuKdfWlMNx00AeRRQGRgb6v0JDnnH8/JDzSVJD4UTkWh4EFeEpPX18J7Ptiyf35kTBKrrhBuPNTQLW1nJ0a6BnDmcIusfmVtOCU2yStHBtW9CRorQKRdo2/TcsB+yhz/cZPBdka6vl6R+vwwoSiWRjmnp/QRBwuH37JRdgNVicP52nHznG0VjaGonjdnEnMOntpJ0/vqIZRrqqYtZqXRj/P33Ro/lyflP0w1wTDQ87DfjcrbEj2sx9BMcAwJHoj6gBf4tQ7i4MlNC5KWUytHBaYZJmZ1m2yMUO3hdOA3Nkt77LKnIs6QtZUHDoot9UfIM7lGcFil+jGHnpnGTLR6u5XDTFXMHaVt04rlVp2NLUhKAZtdOe/uMiaBWhMoqWuzHE3k+I0iy60c9ZCS/86JWHB8zoHdye5+e0fjQWgHNso+/QWpQmtJeLQjeCAeEm0OSokhBAkxzjcJPC07Rh11y4BOG28i+Y1G3m5jVA8nSDU4YzrELQOe4O68HZLCMjr6I4MFZyQ/KFkX4uCb97m61ZGKALiQsZidrb9RBT3lKkl8cHkHHM41l33qRu5RYuhVzC+zEF2eEyxYl3g6dZmYtfLv+Gxn+Vyi/QjfWVpHkKxdwEEatLAGYPrEji7gqCE3hXCFkF40gHarl6Tb2AFCzS8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(83380400001)(38070700005)(6506007)(7696005)(55016003)(30864003)(10290500003)(66574015)(10300500001)(2906002)(508600001)(45080400002)(966005)(71200400001)(76116006)(6916009)(316002)(82960400001)(38100700002)(122000001)(5660300002)(66476007)(66556008)(66946007)(66446008)(15650500001)(9686003)(86362001)(52536014)(8676002)(4326008)(26005)(64756008)(186003)(19627235002)(33656002)(53546011)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SFc4U0QzMFNaVTZESEVORXZ1SC9waXhrRlZoYjh2dGIwVnZaUkdYejNscWtr?= =?utf-8?B?OU55WkJRV0xyVlMvLzFsTllCTDgzeWRHVHpLVkM4ZHZra1lIY2w5TTU5L090?= =?utf-8?B?NTRvOWErUlVyNXVTbWZ0TFpoNEg0alBKb25GY1k3aytqMDkyem5WcHVkR2ww?= =?utf-8?B?OThUSmdiS0ZLWjkvSDVLTVhlQThsc29sMHJRRE1EM09kWHlsME1UNmJQZ1FF?= =?utf-8?B?OVphdkE5ODhSYnFmakpqVllQNVZyUXhEcDN1YUIxWWU3Kzh1Q283RlBMSTY0?= =?utf-8?B?U2V2anJudVdpQnFtL2ZISGlTc1lWeWxGNWwzUEtJVVNXclJ3NkRWeUtnT2NV?= =?utf-8?B?OW5jeFNPTC9Jbm9IaHVvSFllSVlxSktwUHVuSlkvSEgwTFNyb1c4YTMvQkR4?= =?utf-8?B?aEJkNGNVdzJGY0E5Mkc2a3BxR3RpdnpBTzJWa3JSSUdvVkRpQjJqRmpQVUZa?= =?utf-8?B?MHJWZDE3YnpnSWNDR0FGWGlxWGZscnpGUFNLeWJlbzlIbDdOYTlRSURaemtD?= =?utf-8?B?NlR4MG5uQ3YvMmw5aFZGQW9BMnlQQVdvR290cFU4ZHJtRVVWOVZiQVhzbG9R?= =?utf-8?B?Q0R6L3BBSlpRS3VHQ2ExdnJYbUdkZ1V3V0V6dUNieHF3bGdadDR6NGcxVlZj?= =?utf-8?B?QmlWWld3OTExc1FhMVEvKzFLS2ZJYlBFRDlVeHFQUU1sUkwzVmtoNlZIUm1G?= =?utf-8?B?eGliQ2xHUGRPRjdVcUVkN2I0SDN6Y1VIZUtmOXhmV1NnMWVlOTYyN2JBZTlR?= =?utf-8?B?cjFKK1Bwd1RUeWdCNUw3K2xrVjZDWGswUWdKV3Y0UHhpNTNmMFNVZ2JnVFo2?= =?utf-8?B?RUNOZWVaNkZ0VDltaTIwSGozeUowR1BzWXdraHphTFpONng4ekJCSmUvT3ZL?= =?utf-8?B?TUx1WDZJSXdqTTl4Qm42UzNZVURNcTVsZUlUSHc2NUY1a1ljVGE1WFB3ZFF6?= =?utf-8?B?bnV6VUM1R0t1RmtTbG9SYlp1Zk9ILzU4RVBRWWF6QmVUS1pYY3NCZ2IydUtD?= =?utf-8?B?WE11YmFvblZzMmRRYXBhcE5jQ0paUWdlTjh4aVlqWmNxazBBN25zMWlZOVJO?= =?utf-8?B?aXA5SDVFeUdLLzhPZjFFZDhCZDA1a29VK0lHc083SUxQLzczYkpaZWxMMFYx?= =?utf-8?B?dStxUjJsMytTMmpNVVQwQTJ0UHJUbnF1Sm0vbHAyVG1SVGtMMTdkZHYvTm4r?= =?utf-8?B?MDhPZi9hNnBETW5NUC8xQ1pTWjYxVnFNQ2dhK2lxVXhjcHY3a0tSeTNzNS9M?= =?utf-8?B?WTJ5NHBMcFk0OXZhNEt6S0lESjNVeW5leWIzWThQaGxZbDlnVzRldE16ekZT?= =?utf-8?B?cnA2aDhMbFBsenNHaWR3dVpMeU5qM2ExZ01jQmpiT2lhTGFuRk9DOFJpQTlM?= =?utf-8?B?QVZ0VGNPdVZDTVp4NnVkRFZNWFB6a1JDY2N2RFUzVy93Z0xWdXRGbmZTQVpp?= =?utf-8?B?SnZodGZYR3hZdGRUck1EVHZUcDBlczZkOEIwdFlaeEVDWldOMGJhaVBac3lv?= =?utf-8?B?VWdTaklEMHZGNHdZdlFCVEU3N3JwaGJUeDVEaXV1RkZSY1FtYjJNZUhtS2xZ?= =?utf-8?B?dStuQ25xNVh2bFFTNkRrY1JpZ0pNRnc4WTlQTDBvWmZqZ25qbHoyWE85Umc3?= =?utf-8?B?L3BHaXEvZnFRNGkzMGVhK0x4dTQvam1DRGV1Q3ZoTWk3SnIzaWUybXhNYU1W?= =?utf-8?B?OUJPaWV3SGk5UWhqTGJnNUxXUnMwM1hyYTdjUU92bkJVdEpTb25ETjF0SFlU?= =?utf-8?B?dDlCdGNPOEc1NWZpZUhkY2ZyeHNrV3FzYUVVaDhHUWtpZkFNdytBZ1A3eG10?= =?utf-8?B?WDZueG4ya1o5aG5SUFhBTHpJaTBBOUFVcWZscTdqZVJMRk9MZFdSQzZLWEJM?= =?utf-8?B?MlB3VE8vcmo0NHRKaFZGcUUzWktmWXJ6L1RoSzhJeGNCY2ZLeklmdWlEVU4z?= =?utf-8?B?b2tzOERLWHlERjdLbkVOc0hGMm9VYVM5MXAyL2NuTExwcDFuck83NHZSOVhO?= =?utf-8?B?WGJ4QW1pK210eTRoL01Ob0lNZHltdFRvRjRPWlBNMklHUGhjZVdLMXhnZ3g3?= =?utf-8?B?YSs3ZktzWkpIbC90Vzh4UXdmMDlXL3N4WkRVeW1YZDBPWFRobk9NU05wc2w5?= =?utf-8?B?U0JUNGlxckI2YVJOZzVtRjJhZUl6enJaUUNjZjF0S1NkbnllV3NzMGp6ak5l?= =?utf-8?B?UW1ySjA4MXBWWmZCRlFUeEcvakRVdUtrM091L3FkN0dsNCtMRDVlMzBMOGlH?= =?utf-8?B?d005TTBSQW5INlpjcGVKWE1KV2tBPT0=?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 771bf1da-6da1-4580-f247-08d9edff05a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2022 08:09:41.5656 (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: OACtqyVxjx3Bkd9q/nmqGiu04HcF0bAfuWBKAOx2we9VCoii662d6HV0rZyBs3ogNBdb2yt32IufJwdytidv7ni5KJ9UyNKCsOP/Hf9aOuk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV0P278MB0337 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Mailer: Totemo_TrustMail_(Notification) X-Trustmail: processed Archived-At: Subject: Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.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: Sat, 12 Feb 2022 08:09:55 -0000 ------=_Part_4586038_1076914602.1644653385974 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Language: en-US RGVhciBZYW8sDQoNClRoYW5rcyBhIGxvdCBmb3IgdGhlIGRldGFpbGVkIGRlc2NyaXB0aW9uLiBC b3RoIHVuZGVyc3Rvb2QsICBhY2tub3dsZWRnZWQgYW5kIGJlaW5nIG1lcmdlZCB0byB0aGUgLTAx IHZlcnNpb24uIEZlZWRiYWNrIHdlbGNvbWUuDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMT1odHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vZ3JhZjNuZXQvZHJhZnQt dGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoL21haW4vZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4 LXNydjYtc3JoLTAwLnR4dCZ1cmwyPWh0dHBzOi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9n cmFmM25ldC9kcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgvbWFpbi9kcmFmdC10Z3Jh Zi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDEudHh0DQoNCkkgd2lsbCBwdWJsaXNoIC0wMSBpbiB0 aGUgdXBjb21pbmcgd2Vla3MgYmVmb3JlIElFVEYgMTEzLg0KDQpCZXN0IHdpc2hlcw0KVGhvbWFz DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsaXUueWFvNzFAenRlLmNvbS5j biA8bGl1LnlhbzcxQHp0ZS5jb20uY24+IA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA3LCAyMDIy IDEwOjQyIEFNDQpUbzogR3JhZiBUaG9tYXMsIElOSS1ORVQtVENaLVpIMSA8VGhvbWFzLkdyYWZA c3dpc3Njb20uY29tPg0KQ2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6W3NwcmluZ10g TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2 Ni1zcmgtMDAudHh0DQoNCkhpIFRob21hcywNCg0KU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5LiBQ bGVhc2Ugc2VlIGlubGluZSBbWWFvMl0uDQo+IFtZYW9dIFNlZ21lbnRzIGxlZnQgaXMgb25lIG9m IHRoZSBlbGVtZW50cyB0byBpZGVudGlmeSBhbiBTUkguIEZvciBleGFtcGxlLCAoU0EsREE9U0lE QikgKFNJREIsU0lEQyxTSURCLFNJREE7IFNMPTIpIGFuZCAoU0EsREE9U0lEQikgKFNJREIsU0lE QyxTSURCLFNJREE7IFNMPTApIGFyZSBkaWZmZXJlbnQuIFNvIEkgdGhpbmsgc2VnbWVudHMgbGVm dCBpcyBhbHNvIHVzZWZ1bCB3aGVuIGV4cG9ydGluZyBTUnY2IGluZm9ybWF0aW9uLg0KV291bGQg eW91IGFncmVlIHRoYXQgaXB2NlNSSFNlZ21lbnRMaXN0IGF0IG5vZGUgZWdyZXNzIHdvdWxkIGJl IGVxdWFsIHRvIFNlZ21lbnRzIGxlZnQ/IE9yIGluIG90aGVyIHdvcmRzIHNlZ21lbnRzIGxlZnQg d291bGQgb25seSBkaWZmZXIgYXQgaW5ncmVzcyB0byBpcHY2U1JIU2VnbWVudExpc3QuIENvcnJl Y3Q/IElmIHllcywgdGhhbiBJIHRoaW5rIEkgZ290IHlvdXIgcG9pbnQuIFdvdWxkIHlvdSBwbGVh c2UgZGVzY3JpYmUgbWUgd2hhdCBraW5kIG9mIHVzZSBjYXNlIHlvdSBoYXZlIGluIG1pbmQuDQpb WWFvMl0gSSBtZWFuIHdpdGhvdXQgc2VnbWVudCBsZWZ0LCBpdCdzIGRpZmZpY3VsdCB0byBkaXN0 aW5ndWlzaCBiZXR3ZWVuIHBhY2tldHMgb2YgdGhlIHNhbWUgc2VnbWVudCBsaXN0IGluIHNvbWUg Y2FzZXMuDQpCZWxvdyBpcyBvbmUgc2NlbmFyaW8gSSBjYW4gdGhpbmsgb2YuIFRoZSBjb3JyZXNw b25kaW5nIHNlZ21lbnQgbGlzdCBvZiBwYXRoIDEtLUEtLTItLTMtLTEtLUEtLTQgaXMgPFNJRC0x LFNJRC1BLFNJRC0yLFNJRC0zLFNJRC0xLFNJRC1BLFNJRC00Pi4gDQogICAgMw0KICAvICAgXA0K IC8gICAgIFwNCjEgICAgICAgMg0KIFwgICAgIC8NCiAgXCAgIC8NCiAgICBBLS0tLS00DQpUaGUg ZmxvdyBwYXNzZXMgbm9kZSBBIHR3aWNlLg0KVGhlIGZpcnN0IHRpbWUsIHRoZSBwYWNrZXQgaXMg KFNBLERBPVNJRC1BKTxTSUQtMSxTSUQtQSxTSUQtMixTSUQtMyxTSUQtMSxTSUQtQSxTSUQtNDsg c2VnbWVudCBsZWZ0PTU+Lg0KVGhlIHNlY29uZCB0aW1lLCB0aGUgcGFja2V0IGlzIChTQSxEQT1T SUQtQSk8U0lELTEsU0lELUEsU0lELTIsU0lELTMsU0lELTEsU0lELUEsU0lELTQ7IHNlZ21lbnQg bGVmdD0xPi4NCklmIG9uZSB3YW50cyB0byBjb2xsZWN0IHRoZSBpbmZvIG9mIHRoZXNlIHR3byB0 cmFmZmljIHNlcGFyYXRlbHksIHRoZSBzZWdtZW50IGxlZnQgZWxlbWVudCBpcyBuZWVkZWQuDQpC dXQgdG8gYmUgaG9uZXN0LCBJJ20gbm90IHN1cmUgd2hldGhlciB0aGlzIHJlcXVpcmVtZW50IGlz IHN0cm9uZy4JDQoNCj4gW1lhb10gSSBtZWFuIHRoYXQgSVBGSVggSUUgZm9yIFNSSCBUTFYgaXMg bm90IGRlZmluZWQgaW4gdGhlIGRyYWZ0IHdoaWxlIG90aGVyIG1haW4gZWxlbWVudHMgb2YgU1JI KFNSSEZsYWdzLFNSSFRhZyxpcHY2U1JIU2VnbWVudExpc3QuLi4pIGFyZSBkZWZpbmVkLiBXaGF0 IGlmIHRoZSB1c2VyIHdhbnQgdG8gZXhwb3J0IHRoZSBTUkggVExWIGluZm8gb2YgdGhlIHBhY2tl dHM/DQpZb3UgbWVhbiB0aGUgZW50aXJlIFNSSCBoZWFkZXIgd2l0aG91dCBkaXNhc3NlbWJsZSB0 aGUgZGltZW5zaW9ucyBpbnRvIElQRklYIGVudGl0aWVzLiBMaWtlIElFIDMxNiBtcGxzTGFiZWxT dGFja1NlY3Rpb24uIENvcnJlY3Q/IEkgdGhpbmsgdGhpcyBtYWtlcyBhIGxvdCBvZiBzZW5zZSBh bmQgSSBjb25zaWRlciB0aGlzIHRvIHRoZSAtMDEgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuIA0K W1lhbzJdIFllcywgdGhhdCdzIHdoYXQgSSBtZWFuLg0KDQpCZXN0IFJlZ2FyZHMsDQpZYW8NCg0K DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS3ljp/lp4vpgq7ku7YtLS0tLS0tLS0tLS0tLS0tLS0N CuWPkeS7tuS6uu+8mlRob21hcy5HcmFmQHN3aXNzY29tLmNvbQ0K5pS25Lu25Lq677ya5YiY5bCn MDAxNjUyODY7DQrmioTpgIHkurrvvJpzcHJpbmdAaWV0Zi5vcmc7DQrml6Ug5pyfIO+8mjIwMjLl ubQwMeaciDMw5pelIDE0OjE3DQrkuLsg6aKYIO+8mlJlOiBbc3ByaW5nXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQN CkhpIFlhbw0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGlucHV0Lg0KPiBbWWFvXSBTZWdtZW50cyBs ZWZ0IGlzIG9uZSBvZiB0aGUgZWxlbWVudHMgdG8gaWRlbnRpZnkgYW4gU1JILiBGb3IgZXhhbXBs ZSwgKFNBLERBPVNJREIpIChTSURCLFNJREMsU0lEQixTSURBOyBTTD0yKSBhbmQgKFNBLERBPVNJ REIpIChTSURCLFNJREMsU0lEQixTSURBOyBTTD0wKSBhcmUgZGlmZmVyZW50LiBTbyBJIHRoaW5r IHNlZ21lbnRzIGxlZnQgaXMgYWxzbyB1c2VmdWwgd2hlbiBleHBvcnRpbmcgU1J2NiBpbmZvcm1h dGlvbi4NCldvdWxkIHlvdSBhZ3JlZSB0aGF0IGlwdjZTUkhTZWdtZW50TGlzdCBhdCBub2RlIGVn cmVzcyB3b3VsZCBiZSBlcXVhbCB0byBTZWdtZW50cyBsZWZ0PyBPciBpbiBvdGhlciB3b3JkcyBz ZWdtZW50cyBsZWZ0IHdvdWxkIG9ubHkgZGlmZmVyIGF0IGluZ3Jlc3MgdG8gaXB2NlNSSFNlZ21l bnRMaXN0LiBDb3JyZWN0PyBJZiB5ZXMsIHRoYW4gSSB0aGluayBJIGdvdCB5b3VyIHBvaW50LiBX b3VsZCB5b3UgcGxlYXNlIGRlc2NyaWJlIG1lIHdoYXQga2luZCBvZiB1c2UgY2FzZSB5b3UgaGF2 ZSBpbiBtaW5kLg0KPiBbWWFvXSBJIG1lYW4gdGhhdCBJUEZJWCBJRSBmb3IgU1JIIFRMViBpcyBu b3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQgd2hpbGUgb3RoZXIgbWFpbiBlbGVtZW50cyBvZiBTUkgo U1JIRmxhZ3MsU1JIVGFnLGlwdjZTUkhTZWdtZW50TGlzdC4uLikgYXJlIGRlZmluZWQuIFdoYXQg aWYgdGhlIHVzZXIgd2FudCB0byBleHBvcnQgdGhlIFNSSCBUTFYgaW5mbyBvZiB0aGUgcGFja2V0 cz8NCllvdSBtZWFuIHRoZSBlbnRpcmUgU1JIIGhlYWRlciB3aXRob3V0IGRpc2Fzc2VtYmxlIHRo ZSBkaW1lbnNpb25zIGludG8gSVBGSVggZW50aXRpZXMuIExpa2UgSUUgMzE2IG1wbHNMYWJlbFN0 YWNrU2VjdGlvbi4gQ29ycmVjdD8gSSB0aGluayB0aGlzIG1ha2VzIGEgbG90IG9mIHNlbnNlIGFu ZCBJIGNvbnNpZGVyIHRoaXMgdG8gdGhlIC0wMSB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCkxv b2tpbmcgZm9yd2FyZCB0byB5b3VyIGNsYXJpZmljYXRpb25zLg0KQmVzdCB3aXNoZXMNClRob21h cw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxpdS55YW83MUB6dGUuY29tLmNu IDxsaXUueWFvNzFAenRlLmNvbS5jbj4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMjIg MTA6MjcgQU0NClRvOiBHcmFmIFRob21hcywgSU5JLU5FVC1UQ1otWkgxIDxUaG9tYXMuR3JhZkBz d2lzc2NvbS5jb20+DQpDYzogc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTpbc3ByaW5nXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2 LXNyaC0wMC50eHQNCkhpIFRob21hcywNClBsZWFzZSBzZWUgaW5saW5lIFtZYW9dLg0KQmVzdCBS ZWdhcmRzLA0KWWFvDQotLS0tLS0tLS0tLS0tLS0tLS3ljp/lp4vpgq7ku7YtLS0tLS0tLS0tLS0t LS0tLS0NCuWPkeS7tuS6uu+8mlRob21hcy5HcmFmQHN3aXNzY29tLmNvbQ0K5pS25Lu25Lq677ya 5YiY5bCnMDAxNjUyODY7DQrmioTpgIHkurrvvJpzcHJpbmdAaWV0Zi5vcmc7DQrml6Ug5pyfIO+8 mjIwMjLlubQwMeaciDIz5pelIDAxOjE2DQrkuLsg6aKYIO+8mlJlOiBbc3ByaW5nXSBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0w MC50eHQNCkhpIFlhbywNCk1hbnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCBmZWVkYmFjay4N Cj4gMSkgQnV0IHRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSByb3V0aW5nIHByb3RvY29sIHdoZXJl IHRoZSBsYXN0IFNSdjYgc2VnbWVudCBoYXMgYmVlbiBsZWFybmVkIGZyb20sIGluc3RlYWQgb2Yg dGhlIFNSdjYgc2VnbWVudCB0byBiZSBwcm9jZXNzZWQgYnkgdGhlIGN1cnJlbnQgaG9wLg0KSSBh bSBnb2luZyB0byByZXBocmFzZSB0aGUgc2VudGVuY2VzIHRvIHJlZmVyIHRvIHRoZSBhY3RpdmUg c2VnbWVudC4gV2hpY2ggc2hvdWxkIG1ha2UgaXQgbGVzcyBhbWJpZ3VvdXMuDQo+IDIpIGJ1dCBp biBTUnY2LCBzZWdtZW50IGxpc3QgYW5kIHNlZ21lbnRzIGxlZnQoY3VycmVudGx5IG5vdCBkZWZp bmVkIGluIHRoZSBkcmFmdCkgYXJlIGJvdGggbmVlZGVkIHRvIHByb3ZpZGUgdGhlIHNpbWlsYXIg aW5mb3JtYXRpb24uDQpDb3VsZCB5b3UgZWxhYm9yYXRlIHRoZSB1c2UgY2FzZSBmb3Igc2VnbWVu dHMgbGVmdCBpbiB0aGlzIGNvbnRleHQuIFRoaXMgZG9jdW1lbnQgY292ZXJzIGFsbCBkaW1lbnNp b25zIGJlaW5nIHByZXNlbnQgaW4gdGhlIFNSdjYgc2VnbWVudCByb3V0aW5nIGhlYWRlciBkZXNj cmliZWQgaW4gc2VjdGlvbiBvZiBSRkM4NzU0IChodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9y ZyUyRmRvYyUyRmh0bWwlMkZyZmM4NzU0JTIzc2VjdGlvbi0yJmFtcDtkYXRhPTA0JTdDMDElN0NU aG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzAwOTM4OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUx ZTQzJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzc5ODIz NzMzOTUyMjA3NyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxD SlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtz ZGF0YT1uNlkweFgzRFQxQm11c09MYnVVWERaSGIyQ1ElMkJpSmxZJTJGU09QeEljVHI3YyUzRCZh bXA7cmVzZXJ2ZWQ9MCkgd2l0aCB0aGUgZXhjZXB0aW9uIG9mICJMYXN0IEVudHJ5Ii4NCltZYW9d IFNlZ21lbnRzIGxlZnQgaXMgb25lIG9mIHRoZSBlbGVtZW50cyB0byBpZGVudGlmeSBhbiBTUkgu IEZvciBleGFtcGxlLCAoU0EsREE9U0lEQikgKFNJREIsU0lEQyxTSURCLFNJREE7IFNMPTIpIGFu ZCAoU0EsREE9U0lEQikgKFNJREIsU0lEQyxTSURCLFNJREE7IFNMPTApIGFyZSBkaWZmZXJlbnQu IFNvIEkgdGhpbmsgc2VnbWVudHMgbGVmdCBpcyBhbHNvIHVzZWZ1bCB3aGVuIGV4cG9ydGluZyBT UnY2IGluZm9ybWF0aW9uLg0KPiAzKSBFbGVtZW50IGZvciBTUkggVExWIGlzIG5vdCBkZWZpbmVk IGluIHRoZSBkcmFmdCwgd2hhdCdzIHRoZSBjb25zaWRlcmF0aW9uIGFib3V0IHRoYXQ/DQpDb3Vs ZCB5b3UgZWxhYm9yYXRlIGZ1cnRoZXIgcGxlYXNlLiBUaGUgZG9jdW1lbnQgcmVmZXJzIHRvIFJG QyA4NzU0IHdoZXJlIHRoZSBTUkggVExWIGlzIGJlaW5nIGRlc2NyaWJlZC4NCltZYW9dIEkgbWVh biB0aGF0IElQRklYIElFIGZvciBTUkggVExWIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBkcmFmdCB3 aGlsZSBvdGhlciBtYWluIGVsZW1lbnRzIG9mIFNSSChTUkhGbGFncyxTUkhUYWcsaXB2NlNSSFNl Z21lbnRMaXN0Li4uKSBhcmUgZGVmaW5lZC4gV2hhdCBpZiB0aGUgdXNlciB3YW50IHRvIGV4cG9y dCB0aGUgU1JIIFRMViBpbmZvIG9mIHRoZSBwYWNrZXRzPw0KQmVzdCB3aXNoZXMNClRob21hcw0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxpdS55YW83MUB6dGUuY29tLmNuIDxs aXUueWFvNzFAenRlLmNvbS5jbj4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIwLCAyMDIyIDEw OjIzIEFNDQpUbzogR3JhZiBUaG9tYXMsIElOSS1ORVQtVENaLVpIMSA8VGhvbWFzLkdyYWZAc3dp c3Njb20uY29tPg0KQ2M6IHNwcmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6W3NwcmluZ10gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1z cmgtMDAudHh0DQpIaSBUaG9tYXMsDQpJJ3ZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBoYXZlIHNvbWUg cXVlc3Rpb25zLg0KMSkgUkZDIDkxNjAgaW50cm9kdWNlcyBuZXcgcHJvdG9jb2wgdHlwZXMgZm9y IFNSLU1QTFMgdG9wIGxhYmVsLiBDb25zaWRlcmluZyB0aGF0IHRoZSBNUExTIHRvcCBsYWJlbCBp cyBhbHdheXMgdGhlIGxhYmVsIHRvIGJlIHByb2Nlc3NlZCwgdGhlIHVzZXIgY2FuIGtub3cgd2hp Y2ggcHJvdG9jb2wgdGhlIFNSLU1QTFMgU0lEIHRvIGJlIHByb2Nlc3NlZCBpcyBsZWFybmVkIGZy b20uDQpCdXQgdGhpcyBkcmFmdCBkZXNjcmliZXMgdGhlIHJvdXRpbmcgcHJvdG9jb2wgd2hlcmUg dGhlIGxhc3QgU1J2NiBzZWdtZW50IGhhcyBiZWVuIGxlYXJuZWQgZnJvbSwgaW5zdGVhZCBvZiB0 aGUgU1J2NiBzZWdtZW50IHRvIGJlIHByb2Nlc3NlZCBieSB0aGUgY3VycmVudCBob3AuDQpBcyBm b3IgbXkgdW5kZXJzdGFuZGluZywgdGhlIGN1cnJlbnQgZHJhZnQgaXMgaW5jb25zaXN0ZW50IHdp dGggUkZDIDkxNjAgaW4gdGhpcyBhc3BlY3QuDQoyKSBSZWxhdGVkIHRvIHBvaW50IDHvvIxpbiBT Ui1NUExTLCBleHBvcnRpbmcgdGhlIHRvcCBsYWJlbCBjYW4gcHJvdmlkZSB0aGUgaW5mb3JtYXRp b24gb2YgdGhlIHNlZ21lbnQgdG8gYmUgcHJvY2Vzc2VkLCBidXQgaW4gU1J2Niwgc2VnbWVudCBs aXN0IGFuZCBzZWdtZW50cyBsZWZ0KGN1cnJlbnRseSBub3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQp IGFyZSBib3RoIG5lZWRlZCB0byBwcm92aWRlIHRoZSBzaW1pbGFyIGluZm9ybWF0aW9uLg0KMikg RWxlbWVudCBmb3IgU1JIIFRMViBpcyBub3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQsIHdoYXQncyB0 aGUgY29uc2lkZXJhdGlvbiBhYm91dCB0aGF0Pw0KQmVzdCBSZWdhcmRzLA0KWWFvDQotLS0tLS0t LS0tLS0tLS0tLS3ljp/lp4vpgq7ku7YtLS0tLS0tLS0tLS0tLS0tLS0NCuWPkeS7tuS6uu+8mlRo b21hcy5HcmFmQHN3aXNzY29tLmNvbQ0K5pS25Lu25Lq677yac3ByaW5nQGlldGYub3JnOw0K5pel IOacnyDvvJoyMDIy5bm0MDHmnIgxNeaXpSAxNzoyNw0K5Li7IOmimCDvvJpbc3ByaW5nXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNy aC0wMC50eHQNCkRlYXIgU1BSSU5HIHdvcmtpbmcgZ3JvdXAsDQpGb2xsb3dpbmcgdXAgb24ganVz dCByZWxlYXNlZCBSRkMgOTE2MCAoaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2Ml MkZodG1sJTJGcmZjOTE2MCZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2Nv bS5jb20lN0MwMDkzODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2NGU1Yjg3YzFjNzQy MGQ5YmVlYzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIwNzclN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRp STZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9WlJZelNrRlhDRFNTVVlw ckxYamdIQWRmUUhQTEZuVGw2c0E4eE1XMlVyNCUzRCZhbXA7cmVzZXJ2ZWQ9MCksIElQRklYIGNv ZGUgcG9pbnRzIGZvciBNUExTIFNlZ21lbnQgUm91dGluZywNCmh0dHBzOi8vZXVyMDMuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2Vy LmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNy aCZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20lN0MwMDkzODlh M2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1 N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIwNzclN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW Q0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9T1dnUUFBN2JDOThRS0NnbWRtempVSSUyQnNVUngw Y2xCdnU0R1ZiSHcwVHVFJTNEJmFtcDtyZXNlcnZlZD0wIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3Ig dGhlIFNSVjYgZGF0YS1wbGFuZS4NClRoZSBkb2N1bWVudCBhaW1zIHRvIGJlIG9uIHBhciB3aXRo IE1QTFMtU1IuIERlc2NyaWJlIHRoZSByb3V0aW5nIHByb3RvY29sIG9yIFBDRVAgZXh0ZW5zaW9u IHdoZXJlIHRoZSBsYXN0IFNSdjYgc2VnbWVudCBoYXMgYmVlbiBsZWFybmVkIGZyb20sIHRoZSBT UnY2IHNlZ21lbnQgbGlzdCBhbmQgYWxsIG90aGVyIHByb3BlcnRpZXMgZnJvbSB0aGUgU2VnbWVu dCBSb3V0aW5nIGhlYWRlci4NCkkgd291bGQgYXBwcmVjaWF0ZSB5b3VyIGRvY3VtZW50IHJldmll dyBhbmQgZmVlZGJhY2suDQpJIGFpbSB0byBwcmVzZW50IGF0IElFVEYgMTEzIGF0IE9QU0FXRyBh bmQgU1BSSU5HIGFuZCByZXF1ZXN0IGFkb3B0aW9uIGF0IE9QU0FXRy4NCkJlc3Qgd2lzaGVzDQpU aG9tYXMNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBKYW51 YXJ5IDE1LCAyMDIyIDEwOjEyIEFNDQpUbzogR3JhZiBUaG9tYXMsIElOSS1ORVQtVENaLVpIMSA8 VGhvbWFzLkdyYWZAc3dpc3Njb20uY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDAudHh0DQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAwLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaG9tYXMgR3JhZiBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQpOYW1lOiAgICAgICAgZHJhZnQtdGdyYWYtb3BzYXdn LWlwZml4LXNydjYtc3JoDQpSZXZpc2lvbjogICAgMDANClRpdGxlOiAgICAgICAgRXhwb3J0IG9m IFNlZ21lbnQgUm91dGluZyBJUHY2IEluZm9ybWF0aW9uIGluIElQIEZsb3cgSW5mb3JtYXRpb24g RXhwb3J0IChJUEZJWCkNCkRvY3VtZW50IGRhdGU6ICAgIDIwMjItMDEtMTUNCkdyb3VwOiAgICAg ICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgIDkNClVSTDogICAgICAgICAg ICBodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZhcmNoaXZlJTJGaWQlMkZkcmFmdC10Z3JhZi1vcHNh d2ctaXBmaXgtc3J2Ni1zcmgtMDAudHh0JmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0 MHN3aXNzY29tLmNvbSU3QzAwOTM4OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUxZTQzJTdDMzY0ZTVi ODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzc5ODIzNzMzOTUyMjA3NyU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1YU3A3em5W aklrUXFQWkxwQ1V4MDR0RDFlYUg5Um9PSFQ2eEpsWDFjTXEwJTNEJmFtcDtyZXNlcnZlZD0wDQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFm dC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmglMkYmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21h cy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMDA5Mzg5YTNjN2FmNGU1M2RhODIwOGQ5ZWExZTFlNDMl N0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3Nzk4MjM3MzM5 NTIyMDc3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRh PWU4MGtkN0tyazdWNHlpdzZqdGp5aDdPMTQ0SFB3d0FsSmtVTU5ZY096WGMlM0QmYW1wO3Jlc2Vy dmVkPTANCkh0bWxpemVkOiAgICAgICBodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgmYW1wO2RhdGE9MDQl N0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMDA5Mzg5YTNjN2FmNGU1M2RhODIw OGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdD NjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMw MDAmYW1wO3NkYXRhPU9XZ1FBQTdiQzk4UUtDZ21kbXpqVUklMkJzVVJ4MGNsQnZ1NEdWYkh3MFR1 RSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGludHJvZHVjZXMg bmV3IElQIEZsb3cgSW5mb3JtYXRpb24gRXhwb3J0IChJUEZJWCkgY29kZSBwb2ludHMgdG8gaWRl bnRpZnkgd2hpY2ggdHJhZmZpYyBpcyBiZWluZyBmb3J3YXJkZWQgd2l0aCB3aGljaCBTZWdlbW50 IFJvdXRpbmcgSGVhZGVyIGRpbWVuc2lvbnMgYmFzZWQgb24gd2hpY2ggU1J2NiBjb250cm9sIHBs YW5lIHByb3RvY29sLg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdA aWV0Zi5vcmcNCmh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZyZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20lN0MwMDkz ODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5 YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIwNzclN0NVbmtub3duJTdDVFdGcGJHWnNi M2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxD SlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9Mm1GU3VyeEVTaEdESkdJeHZxT2l3TzhwdnB2 RkU3YklvVzlNJTJCWTVsVGNnJTNEJmFtcDtyZXNlcnZlZD0wDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5n QGlldGYub3JnDQpodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz cHJpbmcmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMDA5 Mzg5YTNjN2FmNGU1M2RhODIwOGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQx OWI1NTdhMSU3QzAlN0MwJTdDNjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5rbm93biU3Q1RXRnBiR1pz YjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lM Q0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPTJtRlN1cnhFU2hHREpHSXh2cU9pd084cHZw dkZFN2JJb1c5TSUyQlk1bFRjZyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmlu Z0BpZXRmLm9yZw0KaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c3ByaW5nJmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzAw OTM4OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUxZTQzJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVk MTliNTU3YTElN0MwJTdDMCU3QzYzNzc5ODIzNzMzOTUyMjA3NyU3Q1Vua25vd24lN0NUV0ZwYkda c2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dp TENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT0ybUZTdXJ4RVNoR0RKR0l4dnFPaXdPOHB2 cHZGRTdiSW9XOU0lMkJZNWxUY2clM0QmYW1wO3Jlc2VydmVkPTANCg== ------=_Part_4586038_1076914602.1644653385974 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 HuzkCrsqTOsJYDnOymLYLm4AADGCA7swggO3AgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAh4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMjEyMDgwOTQ2WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCDgVGn/ NBI7lhveo8UDxsFKxLHjxqPZZCvs+Y4ZzlQC5jB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQAJH6ech3VO7tPrK6i4+gductqS 4SHFHf0Cssi7bMYrQJgIsUDp3mf8gLUqSCqcZn4uAAyUhvC0wHHcmct1AN+Jq/aiumSgZsh5Wj8h WzZuJRRaPzgqzwySni2BIwQ1RmixU+yzD+qalO//zM3UykI09NQDTwNNusHrvQKtfsnd/NungN5+ vZuDjHuGPvlPw9iwS76fvX7Tkkzcfdug+Fp9k85Eu13t/yDhgkqn9ZcZCIVlDeaS7byPBLwZyl3Q GbZtsXg/p/xhGOyoN1LisjgDoq1GyIfkJlFM8gLI4mXYNX+bhOXsvTpqWh2D/cFaucw3AYimv7mN 6tGsQlbjTnr2AAAAAAAA ------=_Part_4586038_1076914602.1644653385974-- From nobody Sun Feb 13 13:04:29 2022 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 ED1E33A0AA3; Sun, 13 Feb 2022 13:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 trvoTmiSbMWO; Sun, 13 Feb 2022 13:04:08 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 0447E3A0A9B; Sun, 13 Feb 2022 13:04:07 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id p14so9383758ejf.11; Sun, 13 Feb 2022 13:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XXJjqqLg86gMMssbkoKogK1rI8U7XNJv0lQC3YCIXLY=; b=RAIcbDx86OuUG24zK1OqLMfG4dEE/0CClwlP7rONm5r6u6OmelT3ZfhdtHqFOxEu0G Uq9JavgmquXmv7O17m9quDX8y9JHWOi+trWxPE/DKBS573E4Uom9MF9OQSg19fiPWxl8 rmVVsfw8dwgXpFK1MLtRj2k6hKpY9DXInLYEEUNydlqv1OB9PevpXtpsj4uR1O2XFgAM IiFejKS4jQJAQB/y0W9LwZPKCmjRuc9Bl27qw/rn7pVfDdqGXwcOmbzScXtk/KUrIHvB SuLjuArBzDqEdaoylrzFN3UlS80HSjcmyMkekI/K0IxG6/0Tmv+7dsNEYLPHnsbBtKvW MpEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XXJjqqLg86gMMssbkoKogK1rI8U7XNJv0lQC3YCIXLY=; b=qOhi53iVTvq2rVwhRPgimUTFSETUA0nNV8GbIR3hRD/E/yGBFwCzZ3wZXFPaC8lJzv 6MJ3BTLsTKKr+Ks33bG7o/u36Xn1cENWfeqlmXHJXyjolOZhW30BlPulinbF2+4vzK8J +HJtiyNddJT5fxfi4vZohH7vVtnM5/z7NMM04CjeiYpBv3vxS1N6JzwoP92k7TYFlTsv Sg4S9IQr9hqhuPidCvu4B8KBhFolIOtJCQzgXAj2P/m6nuKhiN24Ov3dRE04s3lV1bHq ZTAf3kMk9nDnMae6WGfXt1FjTe9xxqpUhUa1MRSOTSluVGoPmP7EHUeIGTZ8TVaMwdhj gPAA== X-Gm-Message-State: AOAM5311wwkFrXOtqVUw9VH1EIMNLoEsvUvASzIHTr1tGDpRGe7td7aC OhHtqxaI6YSdwQEnkUq7hqgsEnPmX6aozEbiqxqATeGt X-Google-Smtp-Source: ABdhPJzNf0Le79LITuIgZFN4U+i54qUHUkIH9BWcayjE+7hGfG3hK1MF+lADZCM6ksr3EYxTmYMERDINWFEaW33+CQA= X-Received: by 2002:a17:907:7da4:: with SMTP id oz36mr3354673ejc.59.1644786244646; Sun, 13 Feb 2022 13:04:04 -0800 (PST) MIME-Version: 1.0 References: <202202071741403841025@zte.com.cn> In-Reply-To: From: Greg Mirsky Date: Sun, 13 Feb 2022 13:03:53 -0800 Message-ID: To: Thomas.Graf@swisscom.com Cc: liu.yao71@zte.com.cn, spring , opsawg Content-Type: multipart/alternative; boundary="000000000000d8197d05d7eca35e" Archived-At: Subject: Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.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: Sun, 13 Feb 2022 21:04:14 -0000 --000000000000d8197d05d7eca35e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, et al., what do you think of the new SPRING WG draft that introduces two methods of the compressed SRv6 SID list encoding in the SRH ? Regards, Greg On Sat, Feb 12, 2022 at 12:10 AM wrote: > Dear Yao, > > Thanks a lot for the detailed description. Both understood, acknowledged > and being merged to the -01 version. Feedback welcome. > > > https://www.ietf.org/rfcdiff?url1=3Dhttps://raw.githubusercontent.com/gra= f3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-= srh-00.txt&url2=3Dhttps://raw.githubusercontent.com/graf3net/draft-tgraf-op= sawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-01.txt > > I will publish -01 in the upcoming weeks before IETF 113. > > Best wishes > Thomas > > -----Original Message----- > From: liu.yao71@zte.com.cn > Sent: Monday, February 7, 2022 10:42 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 > Cc: spring@ietf.org > Subject: Re:[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > > Hi Thomas, > > Sorry for the late reply. Please see inline [Yao2]. > > [Yao] Segments left is one of the elements to identify an SRH. For > example, (SA,DA=3DSIDB) (SIDB,SIDC,SIDB,SIDA; SL=3D2) and (SA,DA=3DSIDB) > (SIDB,SIDC,SIDB,SIDA; SL=3D0) are different. So I think segments left is = also > useful when exporting SRv6 information. > Would you agree that ipv6SRHSegmentList at node egress would be equal to > Segments left? Or in other words segments left would only differ at ingre= ss > to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. > Would you please describe me what kind of use case you have in mind. > [Yao2] I mean without segment left, it's difficult to distinguish between > packets of the same segment list in some cases. > Below is one scenario I can think of. The corresponding segment list of > path 1--A--2--3--1--A--4 is . > 3 > / \ > / \ > 1 2 > \ / > \ / > A-----4 > The flow passes node A twice. > The first time, the packet is > (SA,DA=3DSID-A). > The second time, the packet is > (SA,DA=3DSID-A). > If one wants to collect the info of these two traffic separately, the > segment left element is needed. > But to be honest, I'm not sure whether this requirement is strong. > > > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft whil= e > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? > You mean the entire SRH header without disassemble the dimensions into > IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this > makes a lot of sense and I consider this to the -01 version of the > document. > [Yao2] Yes, that's what I mean. > > Best Regards, > Yao > > > > > > ------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6------------------ > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AThomas.Graf@swisscom.com > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A=E5=88=98=E5=B0=A700165286; > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Aspring@ietf.org; > =E6=97=A5 =E6=9C=9F =EF=BC=9A2022=E5=B9=B401=E6=9C=8830=E6=97=A5 14:17 > =E4=B8=BB =E9=A2=98 =EF=BC=9ARe: [spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Yao > Thanks a lot for your input. > > [Yao] Segments left is one of the elements to identify an SRH. For > example, (SA,DA=3DSIDB) (SIDB,SIDC,SIDB,SIDA; SL=3D2) and (SA,DA=3DSIDB) > (SIDB,SIDC,SIDB,SIDA; SL=3D0) are different. So I think segments left is = also > useful when exporting SRv6 information. > Would you agree that ipv6SRHSegmentList at node egress would be equal to > Segments left? Or in other words segments left would only differ at ingre= ss > to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. > Would you please describe me what kind of use case you have in mind. > > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft whil= e > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? > You mean the entire SRH header without disassemble the dimensions into > IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this > makes a lot of sense and I consider this to the -01 version of the docume= nt. > Looking forward to your clarifications. > Best wishes > Thomas > -----Original Message----- > From: liu.yao71@zte.com.cn > Sent: Tuesday, January 25, 2022 10:27 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 > Cc: spring@ietf.org > Subject: Re:[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Thomas, > Please see inline [Yao]. > Best Regards, > Yao > ------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6------------------ > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AThomas.Graf@swisscom.com > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A=E5=88=98=E5=B0=A700165286; > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Aspring@ietf.org; > =E6=97=A5 =E6=9C=9F =EF=BC=9A2022=E5=B9=B401=E6=9C=8823=E6=97=A5 01:16 > =E4=B8=BB =E9=A2=98 =EF=BC=9ARe: [spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Yao, > Many thanks for the review and feedback. > > 1) But this draft describes the routing protocol where the last SRv6 > segment has been learned from, instead of the SRv6 segment to be processe= d > by the current hop. > I am going to rephrase the sentences to refer to the active segment. Whic= h > should make it less ambiguous. > > 2) but in SRv6, segment list and segments left(currently not defined in > the draft) are both needed to provide the similar information. > Could you elaborate the use case for segments left in this context. This > document covers all dimensions being present in the SRv6 segment routing > header described in section of RFC8754 ( > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Frfc8754%23section-2&data=3D04%7C01%7CTho= mas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c742= 0d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&= sdata=3Dn6Y0xX3DT1BmusOLbuUXDZHb2CQ%2BiJlY%2FSOPxIcTr7c%3D&reserved=3D0= ) > with the exception of "Last Entry". > [Yao] Segments left is one of the elements to identify an SRH. For > example, (SA,DA=3DSIDB) (SIDB,SIDC,SIDB,SIDA; SL=3D2) and (SA,DA=3DSIDB) > (SIDB,SIDC,SIDB,SIDA; SL=3D0) are different. So I think segments left is = also > useful when exporting SRv6 information. > > 3) Element for SRH TLV is not defined in the draft, what's the > consideration about that? > Could you elaborate further please. The document refers to RFC 8754 where > the SRH TLV is being described. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while > other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are > defined. What if the user want to export the SRH TLV info of the packets? > Best wishes > Thomas > -----Original Message----- > From: liu.yao71@zte.com.cn > Sent: Thursday, January 20, 2022 10:23 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 > Cc: spring@ietf.org > Subject: Re:[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Hi Thomas, > I've read the draft and have some questions. > 1) RFC 9160 introduces new protocol types for SR-MPLS top label. > Considering that the MPLS top label is always the label to be processed, > the user can know which protocol the SR-MPLS SID to be processed is learn= ed > from. > But this draft describes the routing protocol where the last SRv6 segment > has been learned from, instead of the SRv6 segment to be processed by the > current hop. > As for my understanding, the current draft is inconsistent with RFC 9160 > in this aspect. > 2) Related to point 1=EF=BC=8Cin SR-MPLS, exporting the top label can pro= vide the > information of the segment to be processed, but in SRv6, segment list and > segments left(currently not defined in the draft) are both needed to > provide the similar information. > 2) Element for SRH TLV is not defined in the draft, what's the > consideration about that? > Best Regards, > Yao > ------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6------------------ > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AThomas.Graf@swisscom.com > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Aspring@ietf.org; > =E6=97=A5 =E6=9C=9F =EF=BC=9A2022=E5=B9=B401=E6=9C=8815=E6=97=A5 17:27 > =E4=B8=BB =E9=A2=98 =EF=BC=9A[spring] New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > Dear SPRING working group, > Following up on just released RFC 9160 ( > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Frfc9160&data=3D04%7C01%7CThomas.Graf%40s= wisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19= b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA= wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DZRYz= SkFXCDSSUYprLXjgHAdfQHPLFnTl6sA8xMW2Ur4%3D&reserved=3D0), > IPFIX code points for MPLS Segment Routing, > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data= =3D04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%= 7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C3000&sdata=3DOWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&am= p;reserved=3D0 > has been submitted for the SRV6 data-plane. > The document aims to be on par with MPLS-SR. Describe the routing protoco= l > or PCEP extension where the last SRv6 segment has been learned from, the > SRv6 segment list and all other properties from the Segment Routing heade= r. > I would appreciate your document review and feedback. > I aim to present at IETF 113 at OPSAWG and SPRING and request adoption at > OPSAWG. > Best wishes > Thomas > -----Original Message----- > From: internet-drafts@ietf.org > Sent: Saturday, January 15, 2022 10:12 AM > To: Graf Thomas, INI-NET-TCZ-ZH1 > Subject: New Version Notification for > draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-00.txt > has been successfully submitted by Thomas Graf and posted to the IETF > repository. > Name: draft-tgraf-opsawg-ipfix-srv6-srh > Revision: 00 > Title: Export of Segment Routing IPv6 Information in IP Flow > Information Export (IPFIX) > Document date: 2022-01-15 > Group: Individual Submission > Pages: 9 > URL: > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-00.txt&data= =3D04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%= 7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C3000&sdata=3DXSp7znVjIkQqPZLpCUx04tD1eaH9RoOHT6xJlX1cMq0%3D&= reserved=3D0 > Status: > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2F&data=3D04%= 7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e= 5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C3000&sdata=3De80kd7Krk7V4yiw6jtjyh7O144HPwwAlJkUMNYcOzXc%3D&reserv= ed=3D0 > Htmlized: > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data= =3D04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%= 7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C3000&sdata=3DOWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&am= p;reserved=3D0 > Abstract: > This document introduces new IP Flow Information Export (IPFIX) code > points to identify which traffic is being forwarded with which Segemnt > Routing Header dimensions based on which SRv6 control plane protocol. > The IETF Secretariat > _______________________________________________ > spring mailing list > spring@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fspring&data=3D04%7C01%7CThomas.Graf%40sw= isscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b= 557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D2mFSu= rxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=3D0 > _______________________________________________ > spring mailing list > spring@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fspring&data=3D04%7C01%7CThomas.Graf%40sw= isscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b= 557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D2mFSu= rxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=3D0 > _______________________________________________ > spring mailing list > spring@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fspring&data=3D04%7C01%7CThomas.Graf%40sw= isscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b= 557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D2mFSu= rxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=3D0 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000d8197d05d7eca35e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas, et al.,
what do you think of the new SPRING= WG draft that introduces two methods of the compressed SR= v6 SID list encoding in the SRH?

Regards,
Greg

On Sat, Feb 12, 2022 at 12:10 AM <Thomas.Graf@swisscom.com> wrote:
Dear Yao,

Thanks a lot for the detailed description. Both understood,=C2=A0 acknowled= ged and being merged to the -01 version. Feedback welcome.

https://www.ietf.org/rfcdiff?url1= =3Dhttps://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6= -srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-00.txt&url2=3Dhttps://raw.g= ithubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-= tgraf-opsawg-ipfix-srv6-srh-01.txt

I will publish -01 in the upcoming weeks before IETF 113.

Best wishes
Thomas

-----Original Message-----
From: liu.yao71@z= te.com.cn <liu.yao71@zte.com.cn>
Sent: Monday, February 7, 2022 10:42 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@swisscom.com>
Cc: spring@ietf.org
Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-= srv6-srh-00.txt

Hi Thomas,

Sorry for the late reply. Please see inline [Yao2].
> [Yao] Segments left is one of the elements to identify an SRH. For exa= mple, (SA,DA=3DSIDB) (SIDB,SIDC,SIDB,SIDA; SL=3D2) and (SA,DA=3DSIDB) (SIDB= ,SIDC,SIDB,SIDA; SL=3D0) are different. So I think segments left is also us= eful when exporting SRv6 information.
Would you agree that ipv6SRHSegmentList at node egress would be equal to Se= gments left? Or in other words segments left would only differ at ingress t= o ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would= you please describe me what kind of use case you have in mind.
[Yao2] I mean without segment left, it's difficult to distinguish betwe= en packets of the same segment list in some cases.
Below is one scenario I can think of. The corresponding segment list of pat= h 1--A--2--3--1--A--4 is <SID-1,SID-A,SID-2,SID-3,SID-1,SID-A,SID-4>.=
=C2=A0 =C2=A0 3
=C2=A0 /=C2=A0 =C2=A0\
=C2=A0/=C2=A0 =C2=A0 =C2=A0\
1=C2=A0 =C2=A0 =C2=A0 =C2=A02
=C2=A0\=C2=A0 =C2=A0 =C2=A0/
=C2=A0 \=C2=A0 =C2=A0/
=C2=A0 =C2=A0 A-----4
The flow passes node A twice.
The first time, the packet is (SA,DA=3DSID-A)<SID-1,SID-A,SID-2,SID-3,SI= D-1,SID-A,SID-4; segment left=3D5>.
The second time, the packet is (SA,DA=3DSID-A)<SID-1,SID-A,SID-2,SID-3,S= ID-1,SID-A,SID-4; segment left=3D1>.
If one wants to collect the info of these two traffic separately, the segme= nt left element is needed.
But to be honest, I'm not sure whether this requirement is strong.=C2= =A0 =C2=A0 =C2=A0

> [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft whi= le other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are de= fined. What if the user want to export the SRH TLV info of the packets?
You mean the entire SRH header without disassemble the dimensions into IPFI= X entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes = a lot of sense and I consider this to the -01 version of the document.
[Yao2] Yes, that's what I mean.

Best Regards,
Yao





------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6------------------ =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AThomas.Graf@swisscom.com
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A=E5=88=98=E5=B0=A700165286;
=E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Aspring@ietf.org;
=E6=97=A5 =E6=9C=9F =EF=BC=9A2022=E5=B9=B401=E6=9C=8830=E6=97=A5 14:17
=E4=B8=BB =E9=A2=98 =EF=BC=9ARe: [spring] New Version Notification for draf= t-tgraf-opsawg-ipfix-srv6-srh-00.txt
Hi Yao
Thanks a lot for your input.
> [Yao] Segments left is one of the elements to identify an SRH. For exa= mple, (SA,DA=3DSIDB) (SIDB,SIDC,SIDB,SIDA; SL=3D2) and (SA,DA=3DSIDB) (SIDB= ,SIDC,SIDB,SIDA; SL=3D0) are different. So I think segments left is also us= eful when exporting SRv6 information.
Would you agree that ipv6SRHSegmentList at node egress would be equal to Se= gments left? Or in other words segments left would only differ at ingress t= o ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would= you please describe me what kind of use case you have in mind.
> [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft whi= le other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are de= fined. What if the user want to export the SRH TLV info of the packets?
You mean the entire SRH header without disassemble the dimensions into IPFI= X entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes = a lot of sense and I consider this to the -01 version of the document.
Looking forward to your clarifications.
Best wishes
Thomas
-----Original Message-----
From: liu.yao71@z= te.com.cn <liu.yao71@zte.com.cn>
Sent: Tuesday, January 25, 2022 10:27 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@swisscom.com>
Cc: spring@ietf.org
Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-= srv6-srh-00.txt
Hi Thomas,
Please see inline [Yao].
Best Regards,
Yao
------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6------------------ =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AThomas.Graf@swisscom.com
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A=E5=88=98=E5=B0=A700165286;
=E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Aspring@ietf.org;
=E6=97=A5 =E6=9C=9F =EF=BC=9A2022=E5=B9=B401=E6=9C=8823=E6=97=A5 01:16
=E4=B8=BB =E9=A2=98 =EF=BC=9ARe: [spring] New Version Notification for draf= t-tgraf-opsawg-ipfix-srv6-srh-00.txt
Hi Yao,
Many thanks for the review and feedback.
> 1) But this draft describes the routing protocol where the last SRv6 s= egment has been learned from, instead of the SRv6 segment to be processed b= y the current hop.
I am going to rephrase the sentences to refer to the active segment. Which = should make it less ambiguous.
> 2) but in SRv6, segment list and segments left(currently not defined i= n the draft) are both needed to provide the similar information.
Could you elaborate the use case for segments left in this context. This do= cument covers all dimensions being present in the SRv6 segment routing head= er described in section of RFC8754 (https://eur03.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8754%23section-2&a= mp;data=3D04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea= 1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ= XVCI6Mn0%3D%7C3000&amp;sdata=3Dn6Y0xX3DT1BmusOLbuUXDZHb2CQ%2BiJlY%2FSOP= xIcTr7c%3D&amp;reserved=3D0) with the exception of "Last Entry= ".
[Yao] Segments left is one of the elements to identify an SRH. For example,= (SA,DA=3DSIDB) (SIDB,SIDC,SIDB,SIDA; SL=3D2) and (SA,DA=3DSIDB) (SIDB,SIDC= ,SIDB,SIDA; SL=3D0) are different. So I think segments left is also useful = when exporting SRv6 information.
> 3) Element for SRH TLV is not defined in the draft, what's the con= sideration about that?
Could you elaborate further please. The document refers to RFC 8754 where t= he SRH TLV is being described.
[Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while ot= her main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined= . What if the user want to export the SRH TLV info of the packets?
Best wishes
Thomas
-----Original Message-----
From: liu.yao71@z= te.com.cn <liu.yao71@zte.com.cn>
Sent: Thursday, January 20, 2022 10:23 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@swisscom.com>
Cc: spring@ietf.org
Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-= srv6-srh-00.txt
Hi Thomas,
I've read the draft and have some questions.
1) RFC 9160 introduces new protocol types for SR-MPLS top label. Considerin= g that the MPLS top label is always the label to be processed, the user can= know which protocol the SR-MPLS SID to be processed is learned from.
But this draft describes the routing protocol where the last SRv6 segment h= as been learned from, instead of the SRv6 segment to be processed by the cu= rrent hop.
As for my understanding, the current draft is inconsistent with RFC 9160 in= this aspect.
2) Related to point 1=EF=BC=8Cin SR-MPLS, exporting the top label can provi= de the information of the segment to be processed, but in SRv6, segment lis= t and segments left(currently not defined in the draft) are both needed to = provide the similar information.
2) Element for SRH TLV is not defined in the draft, what's the consider= ation about that?
Best Regards,
Yao
------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6------------------ =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AThomas.Graf@swisscom.com
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Aspring@ietf.org;
=E6=97=A5 =E6=9C=9F =EF=BC=9A2022=E5=B9=B401=E6=9C=8815=E6=97=A5 17:27
=E4=B8=BB =E9=A2=98 =EF=BC=9A[spring] New Version Notification for draft-tg= raf-opsawg-ipfix-srv6-srh-00.txt
Dear SPRING working group,
Following up on just released RFC 9160 (https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9160&amp;data=3D04%7C01%7CThom= as.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420= d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJW= IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a= mp;sdata=3DZRYzSkFXCDSSUYprLXjgHAdfQHPLFnTl6sA8xMW2Ur4%3D&amp;reserved= =3D0), IPFIX code points for MPLS Segment Routing,
htt= ps://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracke= r.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&amp;data=3D= 04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C3= 64e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTW= FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C3000&amp;sdata=3DOWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&a= mp;amp;reserved=3D0 has been submitted for the SRV6 data-plane.
The document aims to be on par with MPLS-SR. Describe the routing protocol = or PCEP extension where the last SRv6 segment has been learned from, the SR= v6 segment list and all other properties from the Segment Routing header. I would appreciate your document review and feedback.
I aim to present at IETF 113 at OPSAWG and SPRING and request adoption at O= PSAWG.
Best wishes
Thomas
-----Original Message-----
From: interne= t-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Saturday, January 15, 2022 10:12 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@swisscom.com>
Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.= txt
A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-00.txt
has been successfully submitted by Thomas Graf and posted to the IETF repos= itory.
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-tgraf-opsawg-ipfix-srv6-srh
Revision:=C2=A0 =C2=A0 00
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Export of Segment Routing IPv6 Informatio= n in IP Flow Information Export (IPFIX)
Document date:=C2=A0 =C2=A0 2022-01-15
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://eur03.safelinks.protecti= on.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgr= af-opsawg-ipfix-srv6-srh-00.txt&amp;data=3D04%7C01%7CThomas.Graf%40swis= scom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b55= 7a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DXSp= 7znVjIkQqPZLpCUx04tD1eaH9RoOHT6xJlX1cMq0%3D&amp;reserved=3D0
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://eur03.safelinks.protection.outloo= k.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-= ipfix-srv6-srh%2F&amp;data=3D04%7C01%7CThomas.Graf%40swisscom.com%7C009= 389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C= 637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu= MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3De80kd7Krk7V4yiw6j= tjyh7O144HPwwAlJkUMNYcOzXc%3D&amp;reserved=3D0
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://eur03.safelinks.protection.outloo= k.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-= opsawg-ipfix-srv6-srh&amp;data=3D04%7C01%7CThomas.Graf%40swisscom.com%7= C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C= 0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi= V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DOWgQAA7bC98QK= CgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&amp;reserved=3D0
Abstract:
This document introduces new IP Flow Information Export (IPFIX) code points= to identify which traffic is being forwarded with which Segemnt Routing He= ader dimensions based on which SRv6 control plane protocol.
The IETF Secretariat
_______________________________________________
spring mailing list
spring@ietf.org https://eur03.safelinks.protec= tion.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring&amp;data=3D04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e5= 3da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339= 522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6= Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3D2mFSurxEShGDJGIxvqOiwO8pvpvFE= 7bIoW9M%2BY5lTcg%3D&amp;reserved=3D0
_______________________________________________
spring mailing list
spring@ietf.org https://eur03.safelinks.protec= tion.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring&amp;data=3D04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e5= 3da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339= 522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6= Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3D2mFSurxEShGDJGIxvqOiwO8pvpvFE= 7bIoW9M%2BY5lTcg%3D&amp;reserved=3D0
_______________________________________________
spring mailing list
spring@ietf.org https://eur03.safelinks.protec= tion.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fs= pring&amp;data=3D04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e5= 3da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339= 522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6= Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3D2mFSurxEShGDJGIxvqOiwO8pvpvFE= 7bIoW9M%2BY5lTcg%3D&amp;reserved=3D0
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000d8197d05d7eca35e-- From nobody Sun Feb 13 13:24:21 2022 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 772BF3A0B5E; Sun, 13 Feb 2022 13:23:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Carlos Bernardos via Datatracker To: Cc: draft-ietf-spring-segment-routing-policy.all@ietf.org, last-call@ietf.org, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164478742540.12952.13879543917832873504@ietfa.amsl.com> Reply-To: Carlos Bernardos Date: Sun, 13 Feb 2022 13:23:45 -0800 Archived-At: Subject: [spring] Intdir telechat review of draft-ietf-spring-segment-routing-policy-16 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: Sun, 13 Feb 2022 21:23:46 -0000 Reviewer: Carlos Bernardos Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-spring-segment-routing-policy. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . The document is very well written and I just have a couple of small comments. Based on my review, if I was on the IESG I would ballot this document as NO OBJECTION. The following are other issues I found with this document that SHOULD be corrected before publication: Section 3 makes use of a lot of potentially normative “may†which is not clear if they are meant to be normative or not. The following are minor issues (typos, misspelling, minor text improvements) with the document: In section 3, when describing the SR-DB, two IGP protocols are mentioned (ISIS and OSPF). Are those the only ones meant to be supported? “with the End behavior (as defined in [RFC8986]), of the node†—> I think the “,†should be removed From nobody Sun Feb 13 22:04:56 2022 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 665153A0848; Sun, 13 Feb 2022 22:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQiee-J1KoJJ; Sun, 13 Feb 2022 22:04:51 -0800 (PST) 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 2ACD53A0847; Sun, 13 Feb 2022 22:04:51 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id v6so17501364vsp.11; Sun, 13 Feb 2022 22:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+Kr3Ks2wIIhh8b+uAGlw4Abe24S8dCSg+/7AZlS6tL8=; b=lUImjxQDuFF9oGw/DTMPBpqUmQpzKDcmRkrwWTPFBb5JcUanv9bbB7MDwy6gyjUjvX u66esMKqe/6l2qHzZ4oGOMznZ0DeZjNcanS+RXreg1p8ZJl9F4CC1hXx9BQEjiwo7w4e optjNZLTooh/1G8a+nafX5FATTD7Mckml+NNEJT+456VYtK8DLNGMU0R+R+6JTj4dZ7E eTcidPS9LJ6HIVw4SeZ5xC/bozxtb1yZvbtRvhiMRD1QGYnef/pu6Nv8vRTGCPoxFb8t 5GRTMoxpul3HP7jSh9qHyyMVC8z+bCVgeJ2+NZWQDy9pZFOg75Fnue0O22dTWoLRDqD3 KYug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+Kr3Ks2wIIhh8b+uAGlw4Abe24S8dCSg+/7AZlS6tL8=; b=ioJCu34TqohQCeoEDkQUqozPuyIXZg1V5n7U3q4WtjUh2xZDtIsw4ftQh2t17rJfW0 woZM6203L+SXWG8bB/Ayya96w6Q/mSXciTxfUo3GUJXhiwzXsbC/f7g1j/m5RBGAMWHJ /vWxZcVaLEkXbMB3l5XQtdsiVQSepi6J5XgFWRLNCGiJrGnmL/4ypu8OQSX5KbIn7FAt FaHcKdjS+szIltcdIr9etsrnvoSsSaNE2zFgksE+voJh13T0LgVzZGJZquKbGHEBl3tQ Q70rnuAnQ2cymsCOvQiKf5WmHp6rmXwrlBhm4x0X4Dk6fGokhwe9hJG04rVUyjpZJK44 tN1g== X-Gm-Message-State: AOAM532dPepMk3arIQBrTr3kHcxF9mFJaAWx4Q/PCzFKO+9nGl0NXEsw s3aX3kZqWmbPORZr8jq+lkf5PA+hTj4v/DvhjylxFyOU X-Google-Smtp-Source: ABdhPJyGQeSnwqU9lMXaLAiWVQPd2xgjisp2NE/er4m93oSglpR2TQHVlg7rCG6mCzfUvPyI4OTH9pTscVsGdrI3E9g= X-Received: by 2002:a05:6102:3a7a:: with SMTP id bf26mr3131415vsb.27.1644818687599; Sun, 13 Feb 2022 22:04:47 -0800 (PST) MIME-Version: 1.0 References: <164478742540.12952.13879543917832873504@ietfa.amsl.com> In-Reply-To: <164478742540.12952.13879543917832873504@ietfa.amsl.com> From: Ketan Talaulikar Date: Mon, 14 Feb 2022 11:34:35 +0530 Message-ID: To: Carlos Bernardos Cc: int-dir@ietf.org, draft-ietf-spring-segment-routing-policy.all@ietf.org, last-call@ietf.org, SPRING WG Content-Type: multipart/alternative; boundary="00000000000098291305d7f43162" Archived-At: Subject: Re: [spring] Intdir telechat review of draft-ietf-spring-segment-routing-policy-16 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, 14 Feb 2022 06:04:54 -0000 --00000000000098291305d7f43162 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, Thanks for your review and please check inline below for responses. We will include these changes as part of the next update. On Mon, Feb 14, 2022 at 2:53 AM Carlos Bernardos via Datatracker < noreply@ietf.org> wrote: > Reviewer: Carlos Bernardos > Review result: Ready with Nits > > I am an assigned INT directorate reviewer for > draft-ietf-spring-segment-routing-policy. These comments were written > primarily > for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat commen= ts > from any other IETF contributors and resolve them along with any other La= st > Call comments that have been received. For more details on the INT > Directorate, > see https://datatracker.ietf.org/group/intdir/about/ > . > > The document is very well written and I just have a couple of small > comments. > > Based on my review, if I was on the IESG I would ballot this document as = NO > OBJECTION. > > The following are other issues I found with this document that SHOULD be > corrected before publication: > > Section 3 makes use of a lot of potentially normative =E2=80=9Cmay=E2=80= =9D which is not > clear > if they are meant to be normative or not. > KT> The section 3 covers something that is implementation specific and hence not normative. Previous versions of the document did carry the normative MAYs which was later changed to "may" based on the WG inputs. > > The following are minor issues (typos, misspelling, minor text > improvements) > with the document: > > In section 3, when describing the SR-DB, two IGP protocols are mentioned > (ISIS > and OSPF). Are those the only ones meant to be supported? > KT> Those are the "popular" IGPs and others are not precluded. That said, I am not aware of the required SR extensions being available in others so as to include/reference them here. > > =E2=80=9Cwith the End behavior (as defined in [RFC8986]), of the node=E2= =80=9D =E2=80=94> I think > the > =E2=80=9C,=E2=80=9D should be removed > KT> Ack Thanks, Ketan --00000000000098291305d7f43162 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thanks for = your review and please check inline below for responses. We will include th= ese changes as part of the next update.


On Mon, Feb 14,= 2022 at 2:53 AM Carlos Bernardos via Datatracker <noreply@ietf.org> wrote:
Reviewer: Carlos Bernardos
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-spring-segment-routing-policy. These comments were written prima= rily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments=
from any other IETF contributors and resolve them along with any other Last=
Call comments that have been received. For more details on the INT Director= ate,
see https://datatracker.ietf.org/group/intdir/about/=
<https://datatracker.ietf.org/group/intdir/about/= >.

The document is very well written and I just have a couple of small comment= s.

Based on my review, if I was on the IESG I would ballot this document as NO=
OBJECTION.

The following are other issues I found with this document that SHOULD be corrected before publication:

Section 3 makes use of a lot of potentially normative =E2=80=9Cmay=E2=80=9D= which is not clear
if they are meant to be normative or not.

KT> The section 3 covers something that is implementation specific an= d hence not normative. Previous versions of the document did carry the norm= ative MAYs which was later changed to "may" based on the WG input= s.
=C2=A0

The following are minor issues (typos, misspelling, minor text improvements= )
with the document:

In section 3, when describing the SR-DB, two IGP protocols are mentioned (I= SIS
and OSPF). Are those the only ones meant to be supported?
<= div>
KT> Those are the "popular" IGPs and others= are not precluded. That said, I am not aware of the required SR extensions= being available in others so as to include/reference them here.
= =C2=A0

=E2=80=9Cwith the End behavior (as defined in [RFC8986]), of the node=E2=80= =9D =E2=80=94> I think the
=E2=80=9C,=E2=80=9D should be removed

K= T> Ack

Thanks,
Ketan

=C2=A0
--00000000000098291305d7f43162-- From nobody Mon Feb 14 04:14:43 2022 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 A16013A0A7E for ; Mon, 14 Feb 2022 04:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8ka2P7x1Tkq for ; Mon, 14 Feb 2022 04:14:28 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450: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 C15AB3A0A65 for ; Mon, 14 Feb 2022 04:14:25 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id z22so1272901edd.1 for ; Mon, 14 Feb 2022 04:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7OttMdkFYC3LQAYjqX8OU3ufaPwJyuaX5SbHiXkSajo=; b=GRxzxlOojOzs+ny1M61s0K1d+XVAS9d/Q4J2TatYN25Vg+Qimt/oS7U4O1o0bkDT9A rlyz3vh9MceVEqr/tK1VEIojSr3BReJMx847WdjuQw+rksXRqii4l6C81Ael/ZJgGyrg UAF5+Ig7fsep6cA5VC8b2Kas+cbB7QUtncfQyulvD2Ntb/PaS+YjurbAINWWtRkWybh4 vLPbnZD9AcHxoLDiZAQnHzFtNsTsIzSF6ud/G21Fux+Wcjsbv3M8mteSyEWZrztK+yOW E+KuF5lhi5UqXaurOzyhblNICEoDhZ65WltxqwkASVgyVWs1pOqeX4OUgYmYagGJ8dJO /cHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7OttMdkFYC3LQAYjqX8OU3ufaPwJyuaX5SbHiXkSajo=; b=UBLZBmnbrOjDcx0/A2shPdGi9b1JuwvgdZR+kTzW7jKSiZ+Rcwq/jf1cF9R0IhXTFK K3KIu3RJ32mngJh7M3utNEqB+Gi9yhl/yFjCaDYiD6V6z2ye6xxHeerdflRZeeYJEUYk UaiR8MT7iXUzs+T3Jrfj3Lta2RsEyXU5opxC8MEW8twF1SoPaIhCyz/SgszNcZW8xc0J C7UVhXGbakPpM7HIoALfyiCdvdwS/RpBaJkQ4BLlaXTlOUh/shjfoYmlIBoiOImJ80tm IHbMNNt6ygIdLZssaQoYuenwbGXop8vktEFzfqE9WBj32xXiITWkoNePQSWZ/KRmkkmU rmbg== X-Gm-Message-State: AOAM532qJB2LLbYrwS13r1i05TePm4fAKOhf7yUEl4tDz3B22zFE0gTB ERlwl8M06R5LC6z6YCjlaagDj1RoA+XdnFqkUDXKrg== X-Google-Smtp-Source: ABdhPJy1Zl6BgiGnsiTNV+ZlSrzpyPjdRziu03VvN0kLIALDx58Ooxs7gTh/S20KuMVbxllTf0T0nU716qQcXvG/f8U= X-Received: by 2002:a05:6402:42cd:: with SMTP id i13mr15123220edc.121.1644840859659; Mon, 14 Feb 2022 04:14:19 -0800 (PST) MIME-Version: 1.0 References: <164478742540.12952.13879543917832873504@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Mon, 14 Feb 2022 13:14:03 +0100 Message-ID: To: Ketan Talaulikar Cc: "" , draft-ietf-spring-segment-routing-policy.all@ietf.org, Last Call , SPRING WG Content-Type: multipart/alternative; boundary="000000000000270ae805d7f95b6e" Archived-At: Subject: Re: [spring] Intdir telechat review of draft-ietf-spring-segment-routing-policy-16 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, 14 Feb 2022 12:14:31 -0000 --000000000000270ae805d7f95b6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ketan. This is OK. Maybe an explicit note on Section 3 that it is not normative might be good. But this is just a suggestion. Feel free to ignore it. Thanks, Carlos On Mon, Feb 14, 2022 at 7:04 AM Ketan Talaulikar wrote: > Hi Carlos, > > Thanks for your review and please check inline below for responses. We > will include these changes as part of the next update. > > > On Mon, Feb 14, 2022 at 2:53 AM Carlos Bernardos via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Carlos Bernardos >> Review result: Ready with Nits >> >> I am an assigned INT directorate reviewer for >> draft-ietf-spring-segment-routing-policy. These comments were written >> primarily >> for the benefit of the Internet Area Directors. Document editors and >> shepherd(s) should treat these comments just like they would treat >> comments >> from any other IETF contributors and resolve them along with any other >> Last >> Call comments that have been received. For more details on the INT >> Directorate, >> see https://datatracker.ietf.org/group/intdir/about/ >> . >> >> The document is very well written and I just have a couple of small >> comments. >> >> Based on my review, if I was on the IESG I would ballot this document as >> NO >> OBJECTION. >> >> The following are other issues I found with this document that SHOULD be >> corrected before publication: >> >> Section 3 makes use of a lot of potentially normative =E2=80=9Cmay=E2=80= =9D which is not >> clear >> if they are meant to be normative or not. >> > > KT> The section 3 covers something that is implementation specific and > hence not normative. Previous versions of the document did carry the > normative MAYs which was later changed to "may" based on the WG inputs. > > >> >> The following are minor issues (typos, misspelling, minor text >> improvements) >> with the document: >> >> In section 3, when describing the SR-DB, two IGP protocols are mentioned >> (ISIS >> and OSPF). Are those the only ones meant to be supported? >> > > KT> Those are the "popular" IGPs and others are not precluded. That said, > I am not aware of the required SR extensions being available in others so > as to include/reference them here. > > >> >> =E2=80=9Cwith the End behavior (as defined in [RFC8986]), of the node=E2= =80=9D =E2=80=94> I think >> the >> =E2=80=9C,=E2=80=9D should be removed >> > > KT> Ack > > Thanks, > Ketan > > > --000000000000270ae805d7f95b6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ketan.

This is OK. Maybe an expl= icit note on Section 3 that it is not normative might be good. But this is = just a suggestion. Feel free to ignore it.

Thanks,=

Carlos

=
On Mon, Feb 14, 2022 at 7:04 AM Ketan= Talaulikar <ketant.ietf@gmail.= com> wrote:
Hi Carlos,

Thanks for your review and please check i= nline below for responses. We will include these changes as part of the nex= t update.


On Mon, Feb 14, 2022 at 2:53 AM Carlos Bernar= dos via Datatracker <noreply@ietf.org> wrote:
Reviewer: Carl= os Bernardos
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-spring-segment-routing-policy. These comments were written prima= rily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments=
from any other IETF contributors and resolve them along with any other Last=
Call comments that have been received. For more details on the INT Director= ate,
see https://datatracker.ietf.org/group/intdir/about/=
<https://datatracker.ietf.org/group/intdir/about/= >.

The document is very well written and I just have a couple of small comment= s.

Based on my review, if I was on the IESG I would ballot this document as NO=
OBJECTION.

The following are other issues I found with this document that SHOULD be corrected before publication:

Section 3 makes use of a lot of potentially normative =E2=80=9Cmay=E2=80=9D= which is not clear
if they are meant to be normative or not.

KT> The section 3 covers something that is implementation specific an= d hence not normative. Previous versions of the document did carry the norm= ative MAYs which was later changed to "may" based on the WG input= s.
=C2=A0

The following are minor issues (typos, misspelling, minor text improvements= )
with the document:

In section 3, when describing the SR-DB, two IGP protocols are mentioned (I= SIS
and OSPF). Are those the only ones meant to be supported?
<= div>
KT> Those are the "popular" IGPs and others= are not precluded. That said, I am not aware of the required SR extensions= being available in others so as to include/reference them here.
= =C2=A0

=E2=80=9Cwith the End behavior (as defined in [RFC8986]), of the node=E2=80= =9D =E2=80=94> I think the
=E2=80=9C,=E2=80=9D should be removed

K= T> Ack

Thanks,
Ketan

=C2=A0
Hi=C2=A0Huaimo,
thank you for respond= ing to my notes and questions. I wanted to highlight one issue (top-posting= ):
For the mechanism in draft-ietf-spring-segment-protection= -sr-te-paths,
if a node X on the shortest path= from a upstream node to N does not
support the mech= anism, node X drops the traffic transported by the path.
=
For the solution in our draft, proxy capable nodes off node X on the s= hortest
path to a neighbor of N are used.
From reading your response, it seems that you compare how dif= ferent solutions=C2=A0behave not in identical environments. I don't see= that as a fair comparison.

Regards,
Greg

On Wed, Feb 9, 2022 at 7:41 PM Huaimo Chen <huaimo.chen@futurewei.com> wrote:
Hi Greg,

=C2=A0 =C2=A0 Thank you very much for your notes.

=C2=A0 =C2=A0 My responses/explanations are inline below with [HC2].

Best Regards,
Huaimo

Fro= m: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, February 8, 2022 11:25 PM
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>; SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
=C2=A0
Hi=C2=A0Huaimo,
thank you for the expedient response. Please find my follow-up notes i= n-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Feb 8, 2022 at 6:35 PM Huaimo Chen <huaimo.chen@futurewei.c= om> wrote:
Hi Greg,

=C2=A0 =C2=A0 Thank you very much for your comments.

=C2=A0 =C2=A0 My responses/explanations are inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors

From: spring <spring-bounces@ietf.org> on behalf = of Greg Mirsky <greg= imirsky@gmail.com>
Sent: Tuesday, February 8, 2022 4:38 PM
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
=C2=A0
Dear Authors, et al.,
I've read the draft and would appreciate it if the authors can cla= rify one question:
  • What do you consider as the significant advantage of the mechanism defi= ned=C2=A0in your draft compared with the mechanism defined=C2=A0in draft-ie= tf-spring-segment-protection-sr-te-paths?
As I've compared the two solutions, I couldn't find any significant= advantage of the proxy forwarding to have two standardized mechanisms for = SR path e2e protection. It might be reasonable to have one standard while o= ther proposals get experimental=C2=A0status?
[HC]: It provides more protection coverage in some cases as compared t= o
the mechanism defined in draft-ietf-spring-segment-protection-sr-te-pa= ths.
GIM>> I find it hard to quantify your characterization. I imagin= e that if an operator uses the protection mechanism defined in draft-ietf-s= pring-segment-protection-sr-te-paths it designs the network with that in mi= nd and thus minimizes if not completely avoids any possible limitation the protection mechanism may have. Perhaps = you can help with some more specific scenarios.=C2=A0
[HC2]: Assume that a SR path has the SID of a node N and node N failed= .
For the mechanism in draft-ietf-spring-segment-protection-sr-te-paths,=
if a node X on the shortest path from a upstream node to N does not
support the mechanism, node X drops the traffic transported by the pat= h.
For the solution in our draft, proxy capable nodes off node X on the s= hortest
path to a neighbor of N are used. The neighbor re-routes the traffic a= round
failed node N towards the destination. The traffic is protected.
This improves the reliability of networks, and QoE. This should be a <= /div>
significant advantage. There is no solution for BSID protection in the=
other existing draft.
GIM>> Though BSID may be used inside the network, I find such us= e case questionable making no significant impact on the usefulness of the p= rotection mechanism.=C2=A0
[HC2]: Considering two drafts A and B. Draft A supports protection
of a SR path, which contains two types of components, say C1 and C2. <= /div>
If the path contains a third type of components, say, C3, then =C2=A0<= /div>
protection of the path for C3 is not supported.
Draft B supports protection of a SR path, containing C1, C2 and C3. In this case, draft B seems having a significant advantage over draft= A.
The solution for BSID protection in our draft has
been there for a few years. In addition, after a node failed, in
our solution, the nodes of the entire network converge to the latest <= /div>
state consistently in time. After a node failed, the mechanism defined=
in the other existing draft holds off the FIB during the HoldTimer
period configured, when the network changes again,
GIM>> I consider that property of the protection defined in draf= t-ietf-spring-segment-protection-sr-te-paths as a benefit that allows bette= r control for the proper coordination between protection mechanisms that op= erate on different network layers.=C2=A0
our solution continues
to converge at any time.
The mechanisms in two drafts are different. It seems ok and reasonable=
to have the two drafts to be adopted in the WG.
GIM>> I agree with you, drafts are fundamentally different and, = in my opinion, merging them would not change the situation. But I don't= see that as the justification for producing two standards. It seems to me,= releasing two standard-based=C2=A0specifications might be detrimental and I propose the authors consider taking this draft = onto the experimental track. I'd support the adoption of it as the expe= rimental=C2=A0track document.


Regards,
Greg

On Thu, Jan 13, 2022 at 2:19 AM <bruno.decraene@orange.com> = wrote:

Dear WG,

=C2=A0

This message starts a 2 week WG adoption call, ending 27/01/2022, for dr= aft-hu-spring-segment-routing-proxy-forwarding

https://datatracker= .ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<= u>

=C2=A0

After review of the document please indicate support (or not) for WG ado= ption of the document to the mailing list.

=C2=A0

Please also provide comments/reasons for your support (or lack thereof) = as this is a stronger way to indicate your (non) support as this is not a v= ote.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

If you are willing to work on or review the document, please state this = explicitly. This gives the chairs an indication of the energy level of peop= le in the working group willing to work on the document.

=C2= =A0

Thanks= !=

Bruno, Jim, = Joel

______________________________________________________________________=
___________________________________________________

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/s= pring
--000000000000270ae805d7f95b6e-- From nobody Mon Feb 14 06:31:18 2022 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 7F4A63A0EE0 for ; Mon, 14 Feb 2022 06:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 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, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 u3g6EkvADfgl for ; Mon, 14 Feb 2022 06:31:09 -0800 (PST) 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 EBD543A0FD1 for ; Mon, 14 Feb 2022 06:31:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Jy68q4V7tz6G9CP for ; Mon, 14 Feb 2022 06:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1644849067; bh=QbTinXFzkGHVTjEeyTNP0naayreDcyHksywK8ctV/HQ=; h=Date:Subject:From:To:References:In-Reply-To:From; b=G2terFrBzyDtOQqOH2qM58wBZIPSpuGbXqAc3yNiGqhpEU9Z3FcWfVFNwnvhsnZlP rMV/hjPImxNKGUhozCeEEvDavT7+6HVrXblmqxtgQM79lbOFUxT5mpaGVk4h7QvSun 7/Pr8fVGmQkIh8EH1a7pT2U11lgtORVObPMzS4Pw= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4Jy68q1NXwz6G7vG for ; Mon, 14 Feb 2022 06:31:07 -0800 (PST) Message-ID: <88007069-524e-534a-79be-070f8f1cda37@joelhalpern.com> Date: Mon, 14 Feb 2022 09:31:06 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US From: "Joel M. Halpern" To: "spring@ietf.org" References: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> <3b13f790-d9a7-6da3-8b40-0641eab0e2a3@joelhalpern.com> In-Reply-To: <3b13f790-d9a7-6da3-8b40-0641eab0e2a3@joelhalpern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Moving forward with draft-filsfilscheng-spring-srv6-srh-compression 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, 14 Feb 2022 14:31:14 -0000 With thanks to the secretariat for fixing a permissions problem, and Dhruv for telling me how to move the repository, the issue tracker is now properly in the wg repository: https://github.com/ietf-wg-spring/draft-ietf-spring-srv6-srh-compression Thank you, Joel On 2/11/2022 1:19 PM, Joel M. Halpern wrote: > The authors have submitted the draft, and I have approved it to become a > working group draft: > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-00 > > > The issue tracker is also up, and has the two issues copied from the > email.  I did add a reference to Suresh's draft in the second issue. > > https://github.com/JoelHalpern/draft-ietf-spring-srv6-srh-compression/issues > > > Yours, > Joel > > PS: Looking at this, it seems to have put the repository in the wrong > place.   If someone can help me fix that, or tell me what I did wrong so > that I recreate it in the spring tree, I would be grateful.  It is not > supposed to be in my personal github space. > > On 2/11/2022 10:44 AM, Joel M. Halpern wrote: >> As you can see, Suresh has published an Internet Draft about SRv6 SIDs. >> >> As described in >> https://mailarchive.ietf.org/arch/msg/spring/VjVIxo7fZFhsIHJ5wFQXIBvvtNM/ >> which concluded the adoption call on >> draft-filsfilscheng-spring-srv6-srh-compression, we can now move on to >> the next steps. >> >> Authors, please submit draft-ietf-spring-srv6-srh-compression with the >> content being what was presented to the WG, with the changes called >> for in the conclusion message above. >> >> I will be creating the issue tracker, and seeding it with the two >> issues called out for identification in the draft. >> >> I look forward to working group discussion of the draft.  I will do my >> best to identify and record specific issues.  Participants are welcome >> to create issues directly in the issue tracker.  When you do so, >> please also send the issue to the list as a basis for on list >> discussion. Similarly, if you choose to put a comment in the issue >> tracker, please also make sure your comment goes to the list. >> >> Note that changing the status of issues is a chair responsibility.  I >> will do my best to do so promptly. >> >> Yours, >> Joel >> >> -------- Forwarded Message -------- >> Subject:     [spring] Requesting comments on >> draft-krishnan-6man-sids-00.txt >> Date:     Thu, 10 Feb 2022 23:35:43 -0500 >> From:     Suresh Krishnan >> To:     IPv6 List >> CC:     spring@ietf.org >> >> >> >> Hi all, >>     As discussed during the IETF112 6man working group meeting I have >> written a short draft that describes the characteristics of SRv6 SIDs >> and attempts to clarify the relationship of SRv6 SIDs to the IPv6 >> Addressing Architecture [RFC4291]. Comments are welcome and greatly >> appreciated. >> >> Text: https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt >> >> Html: https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids >> >> >> Thanks >> Suresh >> >> _______________________________________________ >> 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 Tue Feb 15 01:35:24 2022 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 E26E03A09B9; Tue, 15 Feb 2022 01:34:50 -0800 (PST) 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.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164491769075.2297.8645152633755260563@ietfa.amsl.com> Date: Tue, 15 Feb 2022 01:34:50 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-redundancy-protection-01.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, 15 Feb 2022 09:34:52 -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 for Redundancy Protection Authors : Xuesong Geng Mach(Guoyi) Chen Fan Yang Pablo Camarillo Garvia Gyan Mishra Filename : draft-ietf-spring-sr-redundancy-protection-01.txt Pages : 10 Date : 2022-02-15 Abstract: Redundancy Protection is a generalized protection mechanism to achieve the high reliability of service transmission in Segment Routing network. The mechanism inherits the "Live-Live" methodology, targeting to enhance the functionalities of Segment Routing over IPv6. Inspired by DetNet Packet Replication and Packet Elimination functions, two new Segments are introduced to provide replication and elimination functions on specific network nodes by leveraging SRv6 Segment programming capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-redundancy-protection/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-redundancy-protection-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-redundancy-protection-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Feb 15 01:46:46 2022 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 231433A0A97 for ; Tue, 15 Feb 2022 01:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFCYrZpnQuuG for ; Tue, 15 Feb 2022 01:46:39 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AD53A0A8E for ; Tue, 15 Feb 2022 01:46:39 -0800 (PST) Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jybng2WCnz6F97k for ; Tue, 15 Feb 2022 17:46:15 +0800 (CST) Received: from kwepeml500003.china.huawei.com (7.221.188.182) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 15 Feb 2022 10:46:36 +0100 Received: from kwepeml500003.china.huawei.com (7.221.188.182) by kwepeml500003.china.huawei.com (7.221.188.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 15 Feb 2022 17:46:34 +0800 Received: from kwepeml500003.china.huawei.com ([7.221.188.182]) by kwepeml500003.china.huawei.com ([7.221.188.182]) with mapi id 15.01.2308.021; Tue, 15 Feb 2022 17:46:34 +0800 From: "Yangfan(Fan,IP Standards)" To: "spring@ietf.org" Thread-Topic: I-D Action: draft-ietf-spring-sr-redundancy-protection-01.txt Thread-Index: AdgiT/u/Auea0RTJ8E6ig7Hkuho5fQ== Date: Tue, 15 Feb 2022 09:46:34 +0000 Message-ID: <6f5c1a73e3214e318534af0db8127286@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.41.70] Content-Type: multipart/alternative; boundary="_000_6f5c1a73e3214e318534af0db8127286huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] FW: I-D Action: draft-ietf-spring-sr-redundancy-protection-01.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: Tue, 15 Feb 2022 09:46:44 -0000 --_000_6f5c1a73e3214e318534af0db8127286huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Spring, The new version proposes the encapsulation of meta data (flow id= entification and sequence number) in section 5, which is proposed to be in = SRH based on its SRv6 nature. Any comments and suggestions are greatly welcome. Best regards, Fan -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, February 15, 2022 5:35 PM To: i-d-announce@ietf.org Cc: spring@ietf.org Subject: I-D Action: draft-ietf-spring-sr-redundancy-protection-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking WG of = the IETF. Title : SRv6 for Redundancy Protection Authors : Xuesong Geng Mach(Guoyi) Chen Fan Yang Pablo Camarillo Garvia Gyan Mishra Filename : draft-ietf-spring-sr-redundancy-protection-01.txt Pages : 10 Date : 2022-02-15 Abstract: Redundancy Protection is a generalized protection mechanism to achieve the high reliability of service transmission in Segment Routing network. The mechanism inherits the "Live-Live" methodology, targeting to enhance the functionalities of Segment Routing over IPv6. Inspired by DetNet Packet Replication and Packet Elimination functions, two new Segments are introduced to provide replication and elimination functions on specific network nodes by leveraging SRv6 Segment programming capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-redundancy-protection= / There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-redundancy-prote= ction-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-sr-redundancy-protect= ion-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt --_000_6f5c1a73e3214e318534af0db8127286huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Spring,
 
The new version proposes the encapsulation of meta data (flow identification and s= equence number) in section 5, which is proposed to be in SRH based on its SRv6 nature.
Any comments and suggestions are greatly welcome.
 
Best regards,
Fan
 
 
 
 
 
-----Original Message-----
From: I-D-Announce [mailto= :i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, February 15, 2022 5:35 PM
To: i-d-announce@ietf.org
Cc: spring@ietf.org
Subject: I-D Action: draft-ietf-spring-sr-redundancy-protection-01.txt
 
 
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Source Packet Routing in Networking W= G of the IETF.
 
        Title   &nbs= p;       : SRv6 for Redundancy Protection
        Authors   &n= bsp;     : Xuesong Geng
           &nbs= p;            &= nbsp; Mach(Guoyi) Chen
           &nbs= p;            &= nbsp; Fan Yang
           &nbs= p;            &= nbsp; Pablo Camarillo Garvia
           &nbs= p;            &= nbsp; Gyan Mishra
        Filename   &= nbsp;    : draft-ietf-spring-sr-redundancy-protection-01.txt=
        Pages   &nbs= p;       : 10
        Date    = ;        : 2022-02-15
 
Abstract:
   Redundancy Protection is a generalized protection mechani= sm to
   achieve the high reliability of service transmission in S= egment
   Routing network.  The mechanism inherits the "L= ive-Live" methodology,
   targeting to enhance the functionalities of Segment Routi= ng over
   IPv6.  Inspired by DetNet Packet Replication and Pac= ket Elimination
   functions, two new Segments are introduced to provide rep= lication and
   elimination functions on specific network nodes by levera= ging SRv6
   Segment programming capabilities.
 
 
 
The IETF datatracker status page for this draft is:
 
There is also an htmlized version available at:
 
A diff from the previous version is available at:
 
 
Internet-Drafts are also available by rsync at rsync.ietf.org::interne= t-drafts
 
 
_______________________________________________
I-D-Announce mailing list
 
 --_000_6f5c1a73e3214e318534af0db8127286huaweicom_-- From nobody Tue Feb 15 04:23:02 2022 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 7CA8B3A07AE; Tue, 15 Feb 2022 04:22:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <164492775749.13041.11325015268231469212@ietfa.amsl.com> Date: Tue, 15 Feb 2022 04:22:37 -0800 Archived-At: Subject: [spring] Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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, 15 Feb 2022 12:22:38 -0000 Robert Wilton has entered the following ballot position for draft-ietf-spring-segment-routing-policy-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document, I have a few minor suggestions that may improve the readability of this document. Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. Possibly the abstract would be more readable if it gave a brief description of what an SR Policy is. Segment Routing (SR) [RFC8402] allows a headend node to steer a packet flow along any path. The headend is a node where the instructions for source routing (i.e. segments) are instantiated into the packet and hence becomes the starting node for a specific segment routing path. Intermediate per-path states are eliminated thanks to source routing. Would "written" be better than "instantiated"? The headend node is said to steer a flow into a Segment Routing Policy (SR Policy). [RFC8402] introduces the SR Policy construct and provides an overview of how it is leveraged for Segment Routing use- cases. I was slightly confuses as where SR policy is actually defined. My interpretation is that the base definition is in RFC8402, but that definition is being explained in more detail in this document. Is that correct? If so, possibly adding a sentence here to make that clear may be helpful. 2.9. Active Candidate Path I found the description of the path selection to be somewhat confusing. I would suggest this might be clearer if it just gave the full list of path selection, rather than treating the preference as a special case and listing the rest of tie-breakers. E.g., 1. Higher value of preference is selected. 2. Higher value of Protocol-Origin is selected. 3. If specified by configuration, prefer the existing installed path. 4. Lower value of originator is selected. 5. Finally, the higher value of discriminator is selected. The paragraphs above this list would need to be changed slightly, but the paragraphs below would then be easier to read/understand (at least to me). 4. Segment Types Based on the desired dataplane, either the MPLS label stack or the SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. A couple of the types, i.e., the IPv4 related E and F, don't obviously appear to be either MPLS or SRv6. Hence does the first sentence need to be expanded to cover these types? Regards, Rob From nobody Tue Feb 15 06:17:36 2022 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 54D6A3A0C32; Tue, 15 Feb 2022 06:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 BcaIdHMCpJoR; Tue, 15 Feb 2022 06:17:05 -0800 (PST) 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 6EC2A3A0C27; Tue, 15 Feb 2022 06:17:05 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id e26so6463867vso.3; Tue, 15 Feb 2022 06:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WetH15YCTSB4cOmD+Io46FTzsOICOIFL7rkG4255nOE=; b=bT6lZbj2tcn5+vg+3Tc/9Yaf+7tlK8744OADrWSmYgbeq1Nz4LKv44hUwDWQ2X+tmq 3MT1BkmRzn1gQB8FY++vSo6Wi55Jj62hZOqK1eygWIvmDIciyxT/l1A8nCLuJVUR+VkQ QbOEjkdEfXErMOQAEf6ClBzR/4gTcBzwRT1mxRtByn7aKiC7O5bS9ZafHsY9jOuAnONr ZE49rTN3W8fULx7ed9iRugps1DJUxWTQzFilr92m+Lqr9WiEAHgzH7M/CHDwNyQx4Hpg IHZRklBqyMTu5ZDvaa+Phq7X9YwLUYgb1X4OnqXSMAriE8SpKsert/hWR//OtSDMiCXG /RQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WetH15YCTSB4cOmD+Io46FTzsOICOIFL7rkG4255nOE=; b=kXqtm2RWgrJT685zTgifb376oCPAnsmRa2kIQ6qXoWAtxAz8WZSZX42dQlsSl5ekld lw1s7+EBgu02fvBiMeMOTYbqdx06rZgEQNqmQdF9QWtuo4pBd98xokNu7Co2zAVrtxr8 TKRhDBEpfikOmqCr6YVRgTdGa5W2hNAlKZIRSH2nWab3MQsm0N/1eNSdYH5gYDHXz66e d+I5/wQOysEl9JLt0wUzhIH4BQRvKXVF+ZZQeOpnYAotsJCFM6gVHY7hfOd7wR40ztT5 EEIbm1BlTgyFwJt0gM5QAD8sRSYLxrYBRsV97oyKmd+piQz16mRmFP/CMGCH74E36Trl AwCw== X-Gm-Message-State: AOAM530GOTvjvtt/G6iFe9YQqITyEEJ2xtP+Che7P43CyyYXufiCtsaK DYpgycU1zBKQk+jge7V7FUsZ9U9vWojHUEjUY9Y= X-Google-Smtp-Source: ABdhPJydG5qDJ2Nsp183KBNokaFy31MRTcBcozrkrrLchXoxIG9HmwwLtefX613so0e3MVURb8l1Lfy7hJ9ZqCz1pkQ= X-Received: by 2002:a05:6102:3e8f:: with SMTP id m15mr1305330vsv.15.1644934623705; Tue, 15 Feb 2022 06:17:03 -0800 (PST) MIME-Version: 1.0 References: <164492775749.13041.11325015268231469212@ietfa.amsl.com> In-Reply-To: <164492775749.13041.11325015268231469212@ietfa.amsl.com> From: Ketan Talaulikar Date: Tue, 15 Feb 2022 19:46:50 +0530 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000ecc6d905d80f2f5e" Archived-At: Subject: Re: [spring] Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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, 15 Feb 2022 14:17:11 -0000 --000000000000ecc6d905d80f2f5e Content-Type: text/plain; charset="UTF-8" Hi Rob, Thanks for your review and your comments. Please check inline below for responses. We will include these changes in the next update of the document. On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document, I have a few minor suggestions that may improve > the > readability of this document. > > Segment Routing (SR) allows a headend node to steer a packet flow > along any path. Intermediate per-path states are eliminated thanks > to source routing. The headend node steers a flow into an SR Policy. > The packets steered into an SR Policy carry an ordered list of > segments associated with that SR Policy. This document details the > concepts of SR Policy and steering into an SR Policy. > > Possibly the abstract would be more readable if it gave a brief > description of > what an SR Policy is. > KT> How about if we added the following sentence in the abstract and the introduction? Note that this document doesn't define SR Policy - that comes from RFC8402. SR Policy is an ordered list of segments (i.e. instructions) that represent a source-routed policy. > > Segment Routing (SR) [RFC8402] allows a headend node to steer a > packet flow along any path. The headend is a node where the > instructions for source routing (i.e. segments) are instantiated into > the packet and hence becomes the starting node for a specific segment > routing path. Intermediate per-path states are eliminated thanks to > source routing. > > Would "written" be better than "instantiated"? > KT> Ack. > > The headend node is said to steer a flow into a Segment Routing > Policy (SR Policy). [RFC8402] introduces the SR Policy construct and > provides an overview of how it is leveraged for Segment Routing use- > cases. > > I was slightly confuses as where SR policy is actually defined. My > interpretation is that the base definition is in RFC8402, but that > definition > is being explained in more detail in this document. Is that correct? If > so, > possibly adding a sentence here to make that clear may be helpful. > KT> Yes, that is correct. The introduction does say that RFC8402 introduces the SR Policy construct (para 2) and that this document details it (para 4). > > 2.9. Active Candidate Path > > I found the description of the path selection to be somewhat confusing. I > would suggest this might be clearer if it just gave the full list of path > selection, rather than treating the preference as a special case and > listing > the rest of tie-breakers. > > E.g., > > 1. Higher value of preference is selected. > > 2. Higher value of Protocol-Origin is selected. > > 3. If specified by configuration, prefer the existing installed > path. > > 4. Lower value of originator is selected. > > 5. Finally, the higher value of discriminator is selected. > > The paragraphs above this list would need to be changed slightly, but the > paragraphs below would then be easier to read/understand (at least to me). > KT> The motivation for the current text is that preference is the primary parameter (we can clarify this in the text) in determining the order of selection of active candidate path. The other parameters are coming from the identifiers of the candidate path and are hence called tie-breakers in the event of having the same preference (for any reason whatsoever). > > 4. Segment Types > > Based on the desired dataplane, either the MPLS label stack or the > SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. > > A couple of the types, i.e., the IPv4 related E and F, don't obviously > appear > to be either MPLS or SRv6. Hence does the first sentence need to be > expanded > to cover these types? > KT> These are only relevant/applicable for SR-MPLS. We can do - s/label/SR-MPLS label - to make this more explicit. Thanks, Ketan > > Regards, > Rob > > > > --000000000000ecc6d905d80f2f5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rob,

Thanks for you= r review and your comments. Please check inline below for responses.
<= div>
We will include these changes in the next update of the = document.


On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton= via Datatracker <noreply@ietf.org> wrote:
Ro= bert Wilton has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document, I have a few minor suggestions that may improve t= he
readability of this document.

=C2=A0 =C2=A0Segment Routing (SR) allows a headend node to steer a packet f= low
=C2=A0 =C2=A0along any path.=C2=A0 Intermediate per-path states are elimina= ted thanks
=C2=A0 =C2=A0to source routing.=C2=A0 The headend node steers a flow into a= n SR Policy.
=C2=A0 =C2=A0The packets steered into an SR Policy carry an ordered list of=
=C2=A0 =C2=A0segments associated with that SR Policy.=C2=A0 This document d= etails the
=C2=A0 =C2=A0concepts of SR Policy and steering into an SR Policy.

Possibly the abstract would be more readable if it gave a brief description= of
what an SR Policy is.

KT> How about = if we added the following sentence in the abstract and the introduction? No= te that this document doesn't define SR Policy - that comes from RFC840= 2.

SR Policy is an ordered list of segments (i.e. = instructions) that represent a source-routed policy.
=C2=A0

=C2=A0 =C2=A0Segment Routing (SR) [RFC8402] allows a headend node to steer = a
=C2=A0 =C2=A0packet flow along any path.=C2=A0 The headend is a node where = the
=C2=A0 =C2=A0instructions for source routing (i.e. segments) are instantiat= ed into
=C2=A0 =C2=A0the packet and hence becomes the starting node for a specific = segment
=C2=A0 =C2=A0routing path.=C2=A0 Intermediate per-path states are eliminate= d thanks to
=C2=A0 =C2=A0source routing.

Would "written" be better than "instantiated"?

KT> Ack.
=C2=A0

=C2=A0 =C2=A0The headend node is said to steer a flow into a Segment Routin= g
=C2=A0 =C2=A0Policy (SR Policy).=C2=A0 [RFC8402] introduces the SR Policy c= onstruct and
=C2=A0 =C2=A0provides an overview of how it is leveraged for Segment Routin= g use-
=C2=A0 =C2=A0cases.

I was slightly confuses as where SR policy is actually defined.=C2=A0 My interpretation is that the base definition is in RFC8402, but that definiti= on
is being explained in more detail in this document.=C2=A0 Is that correct?= =C2=A0 If so,
possibly adding a sentence here to make that clear may be helpful.

KT> Yes, that is correct. The introduction d= oes say that RFC8402 introduces the SR Policy construct (para 2) and that t= his document details it (para 4).
=C2=A0

2.9.=C2=A0 Active Candidate Path

I found the description of the path selection to be somewhat confusing.=C2= =A0 I
would suggest this might be clearer if it just gave the full list of path selection, rather than treating the preference as a special case and listin= g
the rest of tie-breakers.

E.g.,

=C2=A0 =C2=A01.=C2=A0 Higher value of preference is selected.

=C2=A0 =C2=A02.=C2=A0 Higher value of Protocol-Origin is selected.

=C2=A0 =C2=A03.=C2=A0 If specified by configuration, prefer the existing in= stalled
=C2=A0 =C2=A0 =C2=A0 =C2=A0path.

=C2=A0 =C2=A04.=C2=A0 Lower value of originator is selected.

=C2=A0 =C2=A05.=C2=A0 Finally, the higher value of discriminator is selecte= d.

The paragraphs above this list would need to be changed slightly, but the paragraphs below would then be easier to read/understand (at least to me).<= br>

KT> The motivation for the current t= ext is that preference is the primary parameter (we can clarify this in the= text) in determining the order of selection of active candidate path. The = other parameters are coming from the identifiers of the candidate path and = are hence called tie-breakers in the event of having the same preference (f= or any reason whatsoever).
=C2=A0

4.=C2=A0 Segment Types

=C2=A0 =C2=A0Based on the desired dataplane, either the MPLS label stack or= the
=C2=A0 =C2=A0SRv6 Segment Routing Header [RFC8754] is built from the Segmen= t-List.

A couple of the types, i.e., the IPv4 related E and F, don't obviously = appear
to be either MPLS or SRv6.=C2=A0 Hence does the first sentence need to be e= xpanded
to cover these types?

KT> These are = only relevant/applicable for SR-MPLS. We can do - s/label/SR-MPLS label - t= o make this more explicit.=C2=A0

Thanks,
Ketan
=C2=A0

Regards,
Rob



--000000000000ecc6d905d80f2f5e-- From nobody Tue Feb 15 07:35:38 2022 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 374DF3A0D66; Tue, 15 Feb 2022 07:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.895 X-Spam-Level: X-Spam-Status: No, score=-11.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=bi4xUmKb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GgEqOXTz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sky8hFIrFjvm; Tue, 15 Feb 2022 07:35:24 -0800 (PST) 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 E3EC93A0A9A; Tue, 15 Feb 2022 07:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31192; q=dns/txt; s=iport; t=1644939324; x=1646148924; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HHVGKzw0Odt3eb8mo0J92oev5m1aO4x6uG+AR5EJRgk=; b=bi4xUmKbqlCapTdDni1KIi6HiQcgg+iG0hlQA1V9BkffpYRHRDgiW2BL VYZhTbtIUWY9dDNoipKaSUjQjGP/eDMxbSOy4OQ50ulstX71g1JPzy2JL BJZjRAQV4npNADUlx4lFAbwzIzsaIAxhxYjoiqc4DdTbYHkAUPLIEX/Kp Q=; IronPort-PHdr: =?us-ascii?q?A9a23=3AdBCitR1j2Mhnd5/vsmDPr1BlVkEcU/3cMg0U7?= =?us-ascii?q?88hjLRDOuSm8o/5NUPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AU?= =?us-ascii?q?hYfgpAQmAotSMeOFUz8KqvsaCo3VMRPXVNo5Te1K09QTc3/fFbV5Ha16G16J?= =?us-ascii?q?w=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A/BiAFKlO25BJzf5iwtVEEN7o5gwsJERdPkR7X?= =?us-ascii?q?Q2eYbSJt1+Wr1GztxIfCDiGMvmJN2D0LoxzaIzj9kgHup7SyNZiSAo+rCEwE?= =?us-ascii?q?1tH+JHPbTi7wugcHM8zwvUuxyuL1u1GAjX7BJ1yHi+0SiuFaOC79yEmjfjQH?= =?us-ascii?q?9IQNcadUsxPbV48IMseoUoLd94R2uaEsPDha++/kYqaT/73YDdJ7wVJ3lc8s?= =?us-ascii?q?Mpvnv/AUMPa41v0tnRmDRxCUcS3e3M9VPrzLonpR5f0rxU9IwK0ewrD5OnRE?= =?us-ascii?q?mLx5RwhDJaulaz2NxdMSb/JNg/IgX1TM0SgqkEd/WppjeBqb7xFNBw/Zzahx?= =?us-ascii?q?7idzP1Xqp20VQAvFqbNg+8aFRJfFkmSOIUXqOeWfSDg4Jf7I0ruNiGEL+9VJ?= =?us-ascii?q?EM/OIADvOAxDnxP/vwRMjwlYA2fmvi737+6DOJrg6wLN9HxPYUQknBt0T+fC?= =?us-ascii?q?uwpKbjYW7/L49Ad1zc5h9pVNffTe8RfbiBgBDzMeRRBJhIWBY4w2fywnHj5f?= =?us-ascii?q?HhDpV2QqKwrpnLU0RBw1reoKN3Re9ebbcRYgkjeoXjJl0z4DwoVHN2S1TTD9?= =?us-ascii?q?Wij7sfMkD/yXp5UFbCk+NZlhVSSwioYDxh+aLcRiZFVkWakUN5ZbkcT4Cdr9?= =?us-ascii?q?+459VegSZ/2WBjQnZJNhTZEM/I4LgHwwFvlJnLo3juk?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AAHqj66xYRmqfjnYiijL5KrPxgOskLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5XI3SEj?= =?us-ascii?q?UO3VHJEGgM1/qY/9SNIVyaygcZ79YdT0EcMqywMbEZt7eB3ODQKb9Jq7PrnN?= =?us-ascii?q?HK9IXjJjVWPHxXgspbnmFE43OgYzVLrX59dOME/fSnl656jgvlXU5SQtWwB3?= =?us-ascii?q?EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUySw71M7aXdi0L0i+W/Kn0jS/a?= =?us-ascii?q?O4qcy2zRfayiv684lWot380dFObfb8yfT9aw+cyDpAVr4RH4FqjwpF591HL2?= =?us-ascii?q?xa1uUkli1QevibLUmhJ11d7yGdgzUImwxemkMKgWXo8UcL5/aJHw7Tz6F69N?= =?us-ascii?q?9kmtyz0Tt7gDg06tM540uJ85VQFh/OhyL7+pzBUAxrjFO9pT44nfcUlGE3a/?= =?us-ascii?q?pSVFZ9l/1VwKpuKuZLIMs60vFRLMB+SMXHoPpGe1KTaH7U+mFp3dy3R3w2Wh?= =?us-ascii?q?OLWFILtMCZ2yVf2CkR9TpW+OUP2nMbsJ4tQZhN4OrJdqxuibFVV8cTKaZwHv?= =?us-ascii?q?0IT8e7AnHEBRjMLGWRK1L6E7xvAQOAl7fnpLEuoO26cp0By5U/3JzHTVNDrG?= =?us-ascii?q?Y3P1njDMWftac7uiwlgF/NFAgF5vsukqSRi4eMMoYDaxfzOmzGu/HQ18kiPg?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4BgDOHvlh/5ldJa1agmOBITEuKAd?= =?us-ascii?q?3WjcxhEmDRwOFOYUOgwIDixCQFIEuFIERA1QLAQEBDQEBNwoEAQGFBQIXg0g?= =?us-ascii?q?CJTQJDgECBAEBARIBAQUBAQECAQYEgQkThWgNhkIBAQEBAxIRChMBATcBDwI?= =?us-ascii?q?BCBEEAQEhBwMCAgIfERQJCAIEDgUIGoIEX4IOVwMuAQ6iLAGBOgKKH3qBMYE?= =?us-ascii?q?BgggBAQYEBIFKQYMCDQuCNwMGgTqDDoQcAQGHByccgUlEgRVDgWaBAT6CIUI?= =?us-ascii?q?CA4EoARIBIysJgmI3gi6SIQcBPCYEIhkIEBcvNQR5ChEekjMQBIMIRolOjXK?= =?us-ascii?q?RPDprCoNGiwGOYwSGExWDcowchlqOLYJylkqCR4pIg06QYYUEAgQCBAUCDgE?= =?us-ascii?q?BBoFhPCs+cHAVO4JpURkPjiwWFYM6hRSFSnQCNgIGAQoBAQMJjUwBAQ?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="980940793" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Feb 2022 15:35:22 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 21FFZMbt024385 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2022 15:35:22 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 15 Feb 2022 09:35:21 -0600 Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 15 Feb 2022 09:35:21 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 15 Feb 2022 10:35:20 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=azHoJSkyuA8REP+HNWP5vKkQgTtuakAlXZoUsOuiURUb2Dnij6wuVGLS6VIgMWFwDoAbMuBlxE05fH6jNYh1F8CrbmOpMwBbdOhZi1lVWupAMcg0hG470dfLX6JUWoM98cOtgJb5X/yXcDH9v455MIZ0HmKjR4Cq5x9ZCUtTjzj9ar3iJXj1JDXII6f4EcakHv33E4UwnsoRPviHe3EXVr5gdgVMb3Jqdg/k6Heba1ARlBVeB3z7Y41ZHo85NZ8nYCj7JgqZVjsXZENbZw+znk6lYUTAIsvwXlClWTOlfli+PZbG4o7Cc3cNoL2VoRDU0KOwTtJXTLzTPL6cGTQ+rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HHVGKzw0Odt3eb8mo0J92oev5m1aO4x6uG+AR5EJRgk=; b=aIDXvR2A7f8+uxPWsltWFhMemMZ1z85/vRww9e9MB/t1ATLmPOZ8iqQ+ABFC0rNJghnyZUB0JCUpFUGnD69zky5kZXjzV+r6LwqQg5k636ZsnAZpL07tJpQH7mpAbuINVLZmHqAjxtAAUiIgxtv/4zycLroUfOoz4BU8dFr77xsad99R1oajJ/3sJLexpBstycOltcmiJQdMbOudtkEnXkpODrvSFaD+XM2CNdejHZH+s2+jH0Xf+ev8PW4efMANNGnKIqVCgphSIsaafJ+GLAzkafKe2UiQolVqzOlAgfeU5Gqmex7vJXfMiaC6g0WSS6MlN1tNNfh8fqhjewtDKQ== 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=HHVGKzw0Odt3eb8mo0J92oev5m1aO4x6uG+AR5EJRgk=; b=GgEqOXTzVo83LCzSsZTo2oNrCaltpG9NRWHivtHyt7mtsBCloHjWqvlG+Ye1WbsQ4PAJZmWtxdWU9ey9A0G0K7zqkBp6u4/vQVknlWfGYxOgu6Sv9XBhSgf842g6pOmSzp2qjFiYTDLNNuhedaecRSQTAZoh5FqyV9sExv2aUGY= Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by BN6PR11MB1713.namprd11.prod.outlook.com (2603:10b6:404:3c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.15; Tue, 15 Feb 2022 15:35:16 +0000 Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::c13b:f3ae:bbbe:2af4]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::c13b:f3ae:bbbe:2af4%3]) with mapi id 15.20.4975.019; Tue, 15 Feb 2022 15:35:16 +0000 From: "Rob Wilton (rwilton)" To: Ketan Talaulikar CC: The IESG , "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , SPRING WG , "james.n.guichard@futurewei.com" Thread-Topic: Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) Thread-Index: AQHYIma/ovfIV077SUy5z/mnQjnPsayUqIsAgAATknA= Date: Tue, 15 Feb 2022 15:35:15 +0000 Message-ID: References: <164492775749.13041.11325015268231469212@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cef8de62-1551-4d6c-9d45-08d9f098c3c9 x-ms-traffictypediagnostic: BN6PR11MB1713:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dFMBM/26TpJGBlyFkqGDDr1DX1DbNH4V38B6Mc7gJknJEOVixxaBQse5RyBrM4k1lXH8ixdMOvDRShZXmXxTz9nM57HZN3lIufm4S5hV/DKonOuFAgIPfGEP4idub2EJOviW0tN9fbCzgT2hORPEpRemZcwcvMaDAupqR80kGpkFy6zuujkd52HS8o2vcJtU+pLRmIPrEyylEdt5L1wrvFXERjnUyMdOcoxyDm2PUVWNNDrC7+uL8a8bH0px7i7tW9TCfu4RxhClZDiuEJsO2WjeneVUZ1NYtKZRDdHGl/e/vxye3B9fur0lsJ+Go+v2kZypwamyw6WtMvLVysaVQqIcniL/OlObxxKiw4gLwNkFQgHNvkvFK7YyDB6Cd+pkOWi5YZD1pHENqCE2bYlJzkIWSquSa5IM/3yYV+sZF2VUfIw/VAAEaXPU+CDFBulmLqmV+nfM7ZxFyoEGn7sVRynBzwCGsyGe0UvVytwjoY5bIRxzhfKJnjIotTkoxI9X40cRWCfaPIS4GAIFM0tgGJxZVwfL0OBGg81OZqLFiS1YBT6FHcbd77Un+hfn/bD1oMu5tSIJ03kBl9PwYOlVi0X8HO1k8OArTiq6M1Q3684dpVC94NPs/ZzIvMovf9JIctigLBYJBQ7KEtIyNN1g9pyrZj+YUx3hPUs3WAEjYDaEucrdjx8isUc6E5X5ihVAh5APAaEHDxeFvlQb9LjfCIYbnBdrllS9XlVcgguCk1zGUBahhid6jHvnG0ehTIhtOJexyYtX1cxOuVJD1b0cc4U4TfKbfGxTE0BNEr7dyYk0lTmJlPgJ8vAxVzAtW0I4swXtIgCBkH5nSMpFpy0FOg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(2906002)(54906003)(6916009)(316002)(52536014)(122000001)(38070700005)(9326002)(166002)(8936002)(86362001)(4326008)(5660300002)(38100700002)(8676002)(76116006)(64756008)(66446008)(66476007)(66556008)(66946007)(55016003)(33656002)(53546011)(9686003)(71200400001)(6506007)(186003)(26005)(83380400001)(7696005)(508600001)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QWViNS9PMDdHdmlIRitra1o4aEFjSjdVT3ZGSmxoZnBrRy80K3p5ZGxTQi80?= =?utf-8?B?dkRndGxHQkJIRVJNNHh3YngwcUV5T3VhenU1UGJHdEN1MDFuRkkvbHc4K3BN?= =?utf-8?B?dzZsNTlIVmx3NTM5R3JRS0taZTQ4S3ZFalZjRUl6QW5EVUhCT1c5UGR5cUlx?= =?utf-8?B?WVdhMDJJdHZ4YnhsVUFRK1FEb3AxQ2lWWE1yQlNJQnBKK2FPcTlBSTZva2V5?= =?utf-8?B?anhTa25wb2N5ZkErTkJEamd6RGlvSHkrU2FUaFJRcnJkVWRYYWR3ZUIvZjRH?= =?utf-8?B?YnpwRzhVRjBlSThmY0N6OENQVmVxaURPTHA0cUxTL2t1UEJWdzg3MmxJWllq?= =?utf-8?B?eVIvRXl4Rm1weUtJV1lYUnF3Y3JCOTJYUlg3VWZEcUwzYWlJYUx5UVV2UWs5?= =?utf-8?B?SVpycGFIYXBUTkNPdGYvSlFQb0pkazkraWdOWGJqdzJCRnZQbFJNRDI3T0NL?= =?utf-8?B?RXQvRWlmTllxcVRmQ2F2T3Q5RmZTVDR5VWg4Y1pYZGtEcnAyZ1h0OFRDN1BR?= =?utf-8?B?TmRVdlpqN0hleHQ5SDBLUzA4WjlXZ2FWTmEwcWlvOWRXa0lTRFJvWjNmbmtL?= =?utf-8?B?ZFQ5VDY3UXVHTFN2Nm1oV1gvNE8vL2F4UUlnYkNTSzRFUkR2OGIreEk0dk9R?= =?utf-8?B?eFRHRENyZUVJQ1JaKzJoVS8xMm9Fa1JzMEtMbFoxODdLNzkzMDUwNFkyRnVs?= =?utf-8?B?OHQ5U29MeFNuV2diSWkrNktGaUdEeitSYUZsUXZmNDlqWFAzQ1QzL3MvYnJh?= =?utf-8?B?b2RZVXFBTFVmdTJlVldjZjlVUW5mWnJsUnI5cVZIWFhCdlBERW13QnQ5U3JC?= =?utf-8?B?eWRncTFJVE85dHpqNjdFeUdvSjFhd2pScTd4S2VSMjlOSHBIUDViWVNqVTgr?= =?utf-8?B?UXJiWWljNXNKb0haRUlpSFlmdit3Mjh4WFVrdzlnSjZ5RjR6OHU3YllBOWg0?= =?utf-8?B?KytteVBpV3owVGZMVDRyYTFsRUdoYzcwcXVHa2xIaEtNZFIzZVZONjNoU3pW?= =?utf-8?B?U01RYWlaanVlUFg2OHE2OExkejR2bHFEYkJBeldmSC9NY29uZ0ZaL3o1MExj?= =?utf-8?B?R1FveVpEL2NkYmpWSDFUMXlkYWE3RmZ2Wlk2eFI3bDVtOTVLQURYUzM5ZnJW?= =?utf-8?B?eXZidW1WTmw4b2p5N3JOSDEzbzZpNXNJR0xmYk04eEZXZGFndkJsbjRwV3FQ?= =?utf-8?B?azhuZlF1V05uNlljTldHSVd5bXcwMEk5eXQrRVBYdWZWS3M3V2xrZWF1OUdU?= =?utf-8?B?UzNGaGt5eXE4Ylg1NkZNSDRJcWsxa0Njek1kV2FtNnlPbkh4Rm5zTEJlUHFq?= =?utf-8?B?UWRMM1hQMkNnNm1EZUFsV3BwSjRva0FySDk5RjkrVXZwNGJlOFQ3T1hFd0Z0?= =?utf-8?B?UnhwckkwUXp5aDQrcFR1M2pMdGh3M1psRWE0d1pUYWVPcWJuZ010bFp6c01P?= =?utf-8?B?YVdEa1MxbGNjUE5yS0tMS1NiSW9wV0drSGVISDE0ZEIrOFJEdGdRa3NCZU45?= =?utf-8?B?S1V4WHFNVDN6cnBrK2xBOVo3NFNrTmxrRi9PZTl6WnoyckFWM1VqeUxpOVo5?= =?utf-8?B?MDJYcmMrQ1psZVVKaW1XZ2kzQ2xqckw3ZTAxYlZ4ajFaZFg2ejJlMWE0MlQ2?= =?utf-8?B?VHdkYlNGT1ZOWDNlZVcxYm4rejdnaGNkdUVqZU1DTDVKcDd2a1duelBzVXJi?= =?utf-8?B?N2tQWTc0T21VcDljTnJudTRBUkZOclFDYlNiS0xKMHBjM1pDRTRCNEo2QTlL?= =?utf-8?B?UFFwYnZXTHB4b3pJMDIvMVNNWEp3RkRHam9zNE12dllrZUxaei9nTDkyR1BE?= =?utf-8?B?Y2plVzloK3BWWVpPcmhiRXhUbDAxSDNRa3IzRjFsM0V2Z1NXZkFrbDdqcHFR?= =?utf-8?B?cFNFdGZqQllJL3plaTVCN055MnZ0NXVZaG4wVnRCSlIyTERSLzJjZXZXME1k?= =?utf-8?B?S3YvTXl0NWErOEVTRGE3UVAwUUp0d1pSMS9LSVFodzF2UGkrUENTSmFOakd1?= =?utf-8?B?TW1vNUhYT01uOElGOVAvMXpHVXVLbUkzUUtVbE5iUTR2bVBqQmNSRnhvMUVB?= =?utf-8?B?L21PaUdQdkw4Mnd6YVhDV2JVbnNKUFhOUUtuSWErMHAyUXpGNzdWOXhzSHRO?= =?utf-8?B?MDNhTFM3cFp6TWRVUmxCZVBKNWlncmsyZE90cHBjOUpVN2Z3dVBsOWlYNWNB?= =?utf-8?B?aWc9PQ==?= Content-Type: multipart/alternative; boundary="_000_BY5PR11MB419668ABBA7C2F6E34B7BBCBB5349BY5PR11MB4196namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cef8de62-1551-4d6c-9d45-08d9f098c3c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2022 15:35:15.9007 (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: 1oLj1Fe8khuh99BLMtb2hYLTVfqJuhSJu+My6r81wdR8f+8r5w8bNOoLcV8Xiuf/DGFRVt/ioL6WtfHgeD/i4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1713 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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, 15 Feb 2022 15:35:30 -0000 --_000_BY5PR11MB419668ABBA7C2F6E34B7BBCBB5349BY5PR11MB4196namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2V0YW4sDQoNClBsZWFzZSBzZWUgaW5saW5lIOKApg0KDQpGcm9tOiBLZXRhbiBUYWxhdWxp a2FyIDxrZXRhbnQuaWV0ZkBnbWFpbC5jb20+DQpTZW50OiAxNSBGZWJydWFyeSAyMDIyIDE0OjE3 DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KQ2M6IFRoZSBJ RVNHIDxpZXNnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBv bGljeUBpZXRmLm9yZzsgc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzsgU1BSSU5HIFdHIDxzcHJpbmdA aWV0Zi5vcmc+OyBqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20NClN1YmplY3Q6IFJlOiBS b2JlcnQgV2lsdG9uJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1wb2xpY3ktMTY6ICh3aXRoIENPTU1FTlQpDQoNCkhpIFJvYiwNCg0KVGhhbmtzIGZv ciB5b3VyIHJldmlldyBhbmQgeW91ciBjb21tZW50cy4gUGxlYXNlIGNoZWNrIGlubGluZSBiZWxv dyBmb3IgcmVzcG9uc2VzLg0KDQpXZSB3aWxsIGluY2x1ZGUgdGhlc2UgY2hhbmdlcyBpbiB0aGUg bmV4dCB1cGRhdGUgb2YgdGhlIGRvY3VtZW50Lg0KDQoNCk9uIFR1ZSwgRmViIDE1LCAyMDIyIGF0 IDU6NTIgUE0gUm9iZXJ0IFdpbHRvbiB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8 bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToNClJvYmVydCBXaWx0b24gaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcG9saWN5LTE2OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQpl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxl YXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvaGFuZGxpbmctaWVzZy1iYWxs b3QtcG9zaXRpb25zLw0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGhhbmRsZSBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdp dGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5Lw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K SGksDQoNClRoYW5rcyBmb3IgdGhpcyBkb2N1bWVudCwgSSBoYXZlIGEgZmV3IG1pbm9yIHN1Z2dl c3Rpb25zIHRoYXQgbWF5IGltcHJvdmUgdGhlDQpyZWFkYWJpbGl0eSBvZiB0aGlzIGRvY3VtZW50 Lg0KDQogICBTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8gc3Rl ZXIgYSBwYWNrZXQgZmxvdw0KICAgYWxvbmcgYW55IHBhdGguICBJbnRlcm1lZGlhdGUgcGVyLXBh dGggc3RhdGVzIGFyZSBlbGltaW5hdGVkIHRoYW5rcw0KICAgdG8gc291cmNlIHJvdXRpbmcuICBU aGUgaGVhZGVuZCBub2RlIHN0ZWVycyBhIGZsb3cgaW50byBhbiBTUiBQb2xpY3kuDQogICBUaGUg cGFja2V0cyBzdGVlcmVkIGludG8gYW4gU1IgUG9saWN5IGNhcnJ5IGFuIG9yZGVyZWQgbGlzdCBv Zg0KICAgc2VnbWVudHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiAgVGhpcyBkb2N1 bWVudCBkZXRhaWxzIHRoZQ0KICAgY29uY2VwdHMgb2YgU1IgUG9saWN5IGFuZCBzdGVlcmluZyBp bnRvIGFuIFNSIFBvbGljeS4NCg0KUG9zc2libHkgdGhlIGFic3RyYWN0IHdvdWxkIGJlIG1vcmUg cmVhZGFibGUgaWYgaXQgZ2F2ZSBhIGJyaWVmIGRlc2NyaXB0aW9uIG9mDQp3aGF0IGFuIFNSIFBv bGljeSBpcy4NCg0KS1Q+IEhvdyBhYm91dCBpZiB3ZSBhZGRlZCB0aGUgZm9sbG93aW5nIHNlbnRl bmNlIGluIHRoZSBhYnN0cmFjdCBhbmQgdGhlIGludHJvZHVjdGlvbj8gTm90ZSB0aGF0IHRoaXMg ZG9jdW1lbnQgZG9lc24ndCBkZWZpbmUgU1IgUG9saWN5IC0gdGhhdCBjb21lcyBmcm9tIFJGQzg0 MDIuDQoNClNSIFBvbGljeSBpcyBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgKGkuZS4gaW5z dHJ1Y3Rpb25zKSB0aGF0IHJlcHJlc2VudCBhIHNvdXJjZS1yb3V0ZWQgcG9saWN5Lg0KDQpMb29r cyBnb29kLg0KDQoNCg0KICAgU2VnbWVudCBSb3V0aW5nIChTUikgW1JGQzg0MDJdIGFsbG93cyBh IGhlYWRlbmQgbm9kZSB0byBzdGVlciBhDQogICBwYWNrZXQgZmxvdyBhbG9uZyBhbnkgcGF0aC4g IFRoZSBoZWFkZW5kIGlzIGEgbm9kZSB3aGVyZSB0aGUNCiAgIGluc3RydWN0aW9ucyBmb3Igc291 cmNlIHJvdXRpbmcgKGkuZS4gc2VnbWVudHMpIGFyZSBpbnN0YW50aWF0ZWQgaW50bw0KICAgdGhl IHBhY2tldCBhbmQgaGVuY2UgYmVjb21lcyB0aGUgc3RhcnRpbmcgbm9kZSBmb3IgYSBzcGVjaWZp YyBzZWdtZW50DQogICByb3V0aW5nIHBhdGguICBJbnRlcm1lZGlhdGUgcGVyLXBhdGggc3RhdGVz IGFyZSBlbGltaW5hdGVkIHRoYW5rcyB0bw0KICAgc291cmNlIHJvdXRpbmcuDQoNCldvdWxkICJ3 cml0dGVuIiBiZSBiZXR0ZXIgdGhhbiAiaW5zdGFudGlhdGVkIj8NCg0KS1Q+IEFjay4NCg0KDQog ICBUaGUgaGVhZGVuZCBub2RlIGlzIHNhaWQgdG8gc3RlZXIgYSBmbG93IGludG8gYSBTZWdtZW50 IFJvdXRpbmcNCiAgIFBvbGljeSAoU1IgUG9saWN5KS4gIFtSRkM4NDAyXSBpbnRyb2R1Y2VzIHRo ZSBTUiBQb2xpY3kgY29uc3RydWN0IGFuZA0KICAgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YgaG93 IGl0IGlzIGxldmVyYWdlZCBmb3IgU2VnbWVudCBSb3V0aW5nIHVzZS0NCiAgIGNhc2VzLg0KDQpJ IHdhcyBzbGlnaHRseSBjb25mdXNlcyBhcyB3aGVyZSBTUiBwb2xpY3kgaXMgYWN0dWFsbHkgZGVm aW5lZC4gIE15DQppbnRlcnByZXRhdGlvbiBpcyB0aGF0IHRoZSBiYXNlIGRlZmluaXRpb24gaXMg aW4gUkZDODQwMiwgYnV0IHRoYXQgZGVmaW5pdGlvbg0KaXMgYmVpbmcgZXhwbGFpbmVkIGluIG1v cmUgZGV0YWlsIGluIHRoaXMgZG9jdW1lbnQuICBJcyB0aGF0IGNvcnJlY3Q/ICBJZiBzbywNCnBv c3NpYmx5IGFkZGluZyBhIHNlbnRlbmNlIGhlcmUgdG8gbWFrZSB0aGF0IGNsZWFyIG1heSBiZSBo ZWxwZnVsLg0KDQpLVD4gWWVzLCB0aGF0IGlzIGNvcnJlY3QuIFRoZSBpbnRyb2R1Y3Rpb24gZG9l cyBzYXkgdGhhdCBSRkM4NDAyIGludHJvZHVjZXMgdGhlIFNSIFBvbGljeSBjb25zdHJ1Y3QgKHBh cmEgMikgYW5kIHRoYXQgdGhpcyBkb2N1bWVudCBkZXRhaWxzIGl0IChwYXJhIDQpLg0KDQpPa2F5 LiAgSXQgd291bGQgYmUgbmljZSBpZiB0aGUgdGV4dCBpbiBwYXJhZ3JhcGggMiBhbmQgNCBjb3Vs ZCBiZSBtb3JlIGNsb3NlbHkgYWxpZ25lZCwgYnV0IEkgZG9u4oCZdCBhY3R1YWxseSBzZWUgYW4g ZWFzeS9jbGVhbiB3YXkgb2YgZG9pbmcgdGhpcy4NCg0KDQoNCjIuOS4gIEFjdGl2ZSBDYW5kaWRh dGUgUGF0aA0KDQpJIGZvdW5kIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgcGF0aCBzZWxlY3Rpb24g dG8gYmUgc29tZXdoYXQgY29uZnVzaW5nLiAgSQ0Kd291bGQgc3VnZ2VzdCB0aGlzIG1pZ2h0IGJl IGNsZWFyZXIgaWYgaXQganVzdCBnYXZlIHRoZSBmdWxsIGxpc3Qgb2YgcGF0aA0Kc2VsZWN0aW9u LCByYXRoZXIgdGhhbiB0cmVhdGluZyB0aGUgcHJlZmVyZW5jZSBhcyBhIHNwZWNpYWwgY2FzZSBh bmQgbGlzdGluZw0KdGhlIHJlc3Qgb2YgdGllLWJyZWFrZXJzLg0KDQpFLmcuLA0KDQogICAxLiAg SGlnaGVyIHZhbHVlIG9mIHByZWZlcmVuY2UgaXMgc2VsZWN0ZWQuDQoNCiAgIDIuICBIaWdoZXIg dmFsdWUgb2YgUHJvdG9jb2wtT3JpZ2luIGlzIHNlbGVjdGVkLg0KDQogICAzLiAgSWYgc3BlY2lm aWVkIGJ5IGNvbmZpZ3VyYXRpb24sIHByZWZlciB0aGUgZXhpc3RpbmcgaW5zdGFsbGVkDQogICAg ICAgcGF0aC4NCg0KICAgNC4gIExvd2VyIHZhbHVlIG9mIG9yaWdpbmF0b3IgaXMgc2VsZWN0ZWQu DQoNCiAgIDUuICBGaW5hbGx5LCB0aGUgaGlnaGVyIHZhbHVlIG9mIGRpc2NyaW1pbmF0b3IgaXMg c2VsZWN0ZWQuDQoNClRoZSBwYXJhZ3JhcGhzIGFib3ZlIHRoaXMgbGlzdCB3b3VsZCBuZWVkIHRv IGJlIGNoYW5nZWQgc2xpZ2h0bHksIGJ1dCB0aGUNCnBhcmFncmFwaHMgYmVsb3cgd291bGQgdGhl biBiZSBlYXNpZXIgdG8gcmVhZC91bmRlcnN0YW5kIChhdCBsZWFzdCB0byBtZSkuDQoNCktUPiBU aGUgbW90aXZhdGlvbiBmb3IgdGhlIGN1cnJlbnQgdGV4dCBpcyB0aGF0IHByZWZlcmVuY2UgaXMg dGhlIHByaW1hcnkgcGFyYW1ldGVyICh3ZSBjYW4gY2xhcmlmeSB0aGlzIGluIHRoZSB0ZXh0KSBp biBkZXRlcm1pbmluZyB0aGUgb3JkZXIgb2Ygc2VsZWN0aW9uIG9mIGFjdGl2ZSBjYW5kaWRhdGUg cGF0aC4gVGhlIG90aGVyIHBhcmFtZXRlcnMgYXJlIGNvbWluZyBmcm9tIHRoZSBpZGVudGlmaWVy cyBvZiB0aGUgY2FuZGlkYXRlIHBhdGggYW5kIGFyZSBoZW5jZSBjYWxsZWQgdGllLWJyZWFrZXJz IGluIHRoZSBldmVudCBvZiBoYXZpbmcgdGhlIHNhbWUgcHJlZmVyZW5jZSAoZm9yIGFueSByZWFz b24gd2hhdHNvZXZlcikuDQoNCk9rYXkuICBJdCB3YXMgdGhpcyBwYXJhZ3JhcGggdGhhdCBpbml0 aWFsbHkgdGhyZXcgbWUgKHJlbGF0aXZlIHRvIHRoZSBsaXN0KToNCg0KICAgbyAgVGhlIHByZWZl cmVuY2UsIGJlaW5nIHRoZSBmaXJzdCB0aWVicmVha2VyLCBhbGxvd3MgYW4gb3BlcmF0b3IgdG8N CiAgICAgIGluZmx1ZW5jZSBzZWxlY3Rpb24gYWNyb3NzIHBhdGhzIHRodXMgYWxsb3dpbmcgcHJv dmlzaW9uaW5nIG9mDQogICAgICBtdWx0aXBsZSBwYXRoIG9wdGlvbnMsIGUuZy4sIENQMSBpcyBw cmVmZXJyZWQgYW5kIGlmIGl0IGJlY29tZXMNCiAgICAgIGludmFsaWQgdGhlbiBmYWxsYmFjayB0 byBDUDIgYW5kIHNvIG9uLiAgU2luY2UgcHJlZmVyZW5jZSB3b3Jrcw0KICAgICAgYWNyb3NzIHBy b3RvY29sIHNvdXJjZXMsIGl0IGFsc28gZW5hYmxlcyAod2hlcmUgbmVjZXNzYXJ5KQ0KICAgICAg c2VsZWN0aXZlIG92ZXJyaWRlIG9mIHRoZSBkZWZhdWx0IFByb3RvY29sLU9yaWdpbiBwcmVmZXJl bmNlLA0KICAgICAgZS5nLiwgdG8gcHJlZmVyIGEgcGF0aCBzaWduYWxlZCB2aWEgQkdQIFNSIFBv bGljeSBvdmVyIHdoYXQgaXMNCiAgICAgIGNvbmZpZ3VyZWQuDQoNClBlcmhhcHMgdGhpcyB0ZXh0 IHNob3VsZG7igJl0IHJlZmVyIHRvIHByZWZlcmVuY2UgYmVpbmcgYSB0aWUtYnJlYWtlciwgYW5k IHBlcmhhcHMgaXQgd291bGQgYmUgYmV0dGVyIHRvIGxpc3QgaXQgYmVmb3JlIHRoZSBQcm90b2Nv bC1PcmlnaW4gcGFyYWdyYXBoPyAgSS5lLiwgSSBjb3VsZG7igJl0IGZpZ3VyZSBvdXQgd2h5IHNv bWV0aGluZyBsb3dlciBpbiB0aGUgbGlzdCB3b3VsZCBiZSBhYmxlIHRvIG92ZXJyaWRlIHRoZSBQ cm90b2NvbC1PcmlnaW4sIHRoYXQgaXMgaGlnaGVyIGluIHRoZSBsaXN0Lg0KDQoNCg0KNC4gIFNl Z21lbnQgVHlwZXMNCg0KICAgQmFzZWQgb24gdGhlIGRlc2lyZWQgZGF0YXBsYW5lLCBlaXRoZXIg dGhlIE1QTFMgbGFiZWwgc3RhY2sgb3IgdGhlDQogICBTUnY2IFNlZ21lbnQgUm91dGluZyBIZWFk ZXIgW1JGQzg3NTRdIGlzIGJ1aWx0IGZyb20gdGhlIFNlZ21lbnQtTGlzdC4NCg0KQSBjb3VwbGUg b2YgdGhlIHR5cGVzLCBpLmUuLCB0aGUgSVB2NCByZWxhdGVkIEUgYW5kIEYsIGRvbid0IG9idmlv dXNseSBhcHBlYXINCnRvIGJlIGVpdGhlciBNUExTIG9yIFNSdjYuICBIZW5jZSBkb2VzIHRoZSBm aXJzdCBzZW50ZW5jZSBuZWVkIHRvIGJlIGV4cGFuZGVkDQp0byBjb3ZlciB0aGVzZSB0eXBlcz8N Cg0KS1Q+IFRoZXNlIGFyZSBvbmx5IHJlbGV2YW50L2FwcGxpY2FibGUgZm9yIFNSLU1QTFMuIFdl IGNhbiBkbyAtIHMvbGFiZWwvU1ItTVBMUyBsYWJlbCAtIHRvIG1ha2UgdGhpcyBtb3JlIGV4cGxp Y2l0Lg0KDQpBaCwgb2theS4gIElmIHlvdSBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdCB0aGVuIGRv aW5nIGl0IGluIHRoZSBpbmRpdmlkdWFsIHR5cGVzIG1pZ2h0IGJlIHVzZWZ1bC4gIE9yIGV2ZW4g bW9yZSBleHBsaWNpdCB3b3VsZCBiZSB0byBsaXN0IHRoZSB0eXBlcyB0aGF0IGFyZSByZWxldmFu dCB0byBTUi1NUExTIGFuZCB0aG9zZSB3aGljaCBhcmUgcmVsZXZhbnQgdG8gU1J2Ni4gIEJ1dCBJ 4oCZbGwgbGVhdmUgdGhpcyB0byB5b3VyIGRpc2NyZXRpb24uDQoNClRoYW5rcywNClJvYg0KDQoN ClRoYW5rcywNCktldGFuDQoNCg0KUmVnYXJkcywNClJvYg0KDQoNCg== --_000_BY5PR11MB419668ABBA7C2F6E34B7BBCBB5349BY5PR11MB4196namp_ 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 OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBLZXRhbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UGxlYXNlIHNlZSBp bmxpbmUg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gS2V0YW4gVGFsYXVsaWthciAmbHQ7a2V0YW50 LmlldGZAZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE1IEZlYnJ1YXJ5IDIwMjIg MTQ6MTc8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNp c2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0 OzsgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeUBpZXRmLm9yZzsgc3By aW5nLWNoYWlyc0BpZXRmLm9yZzsgU1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7OyBq YW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJv YmVydCBXaWx0b24ncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLXBvbGljeS0xNjogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBSb2IsPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCB5b3VyIGNvbW1l bnRzLiBQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93IGZvciByZXNwb25zZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldlIHdpbGwgaW5jbHVkZSB0 aGVzZSBjaGFuZ2VzIGluIHRoZSBuZXh0IHVwZGF0ZSBvZiB0aGUgZG9jdW1lbnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBGZWIgMTUsIDIwMjIgYXQgNTo1MiBQTSBSb2JlcnQgV2ls dG9uIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmci Pm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPlJvYmVydCBXaWx0b24gaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yPGJyPg0KZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0xNjog Tm8gT2JqZWN0aW9uPGJyPg0KPGJyPg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8 YnI+DQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQo8YnI+DQo8YnI+DQpQ bGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYmxvZy9oYW5kbGlu Zy1pZXNnLWJhbGxvdC1wb3NpdGlvbnMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9ibG9nL2hhbmRsaW5nLWllc2ctYmFsbG90LXBvc2l0aW9ucy88L2E+PGJyPg0KZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgaG93IHRvIGhhbmRsZSBESVNDVVNTIGFuZCBDT01NRU5U IHBvc2l0aW9ucy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1y b3V0aW5nLXBvbGljeS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LzwvYT48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ09NTUVOVDo8YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KPGJyPg0KSGksPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGlzIGRvY3Vt ZW50LCBJIGhhdmUgYSBmZXcgbWlub3Igc3VnZ2VzdGlvbnMgdGhhdCBtYXkgaW1wcm92ZSB0aGU8 YnI+DQpyZWFkYWJpbGl0eSBvZiB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtTZWdtZW50IFJvdXRpbmcgKFNSKSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8gc3RlZXIgYSBw YWNrZXQgZmxvdzxicj4NCiZuYnNwOyAmbmJzcDthbG9uZyBhbnkgcGF0aC4mbmJzcDsgSW50ZXJt ZWRpYXRlIHBlci1wYXRoIHN0YXRlcyBhcmUgZWxpbWluYXRlZCB0aGFua3M8YnI+DQombmJzcDsg Jm5ic3A7dG8gc291cmNlIHJvdXRpbmcuJm5ic3A7IFRoZSBoZWFkZW5kIG5vZGUgc3RlZXJzIGEg ZmxvdyBpbnRvIGFuIFNSIFBvbGljeS48YnI+DQombmJzcDsgJm5ic3A7VGhlIHBhY2tldHMgc3Rl ZXJlZCBpbnRvIGFuIFNSIFBvbGljeSBjYXJyeSBhbiBvcmRlcmVkIGxpc3Qgb2Y8YnI+DQombmJz cDsgJm5ic3A7c2VnbWVudHMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1IgUG9saWN5LiZuYnNwOyBU aGlzIGRvY3VtZW50IGRldGFpbHMgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2NvbmNlcHRzIG9mIFNS IFBvbGljeSBhbmQgc3RlZXJpbmcgaW50byBhbiBTUiBQb2xpY3kuPGJyPg0KPGJyPg0KUG9zc2li bHkgdGhlIGFic3RyYWN0IHdvdWxkIGJlIG1vcmUgcmVhZGFibGUgaWYgaXQgZ2F2ZSBhIGJyaWVm IGRlc2NyaXB0aW9uIG9mPGJyPg0Kd2hhdCBhbiBTUiBQb2xpY3kgaXMuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LVCZndDsgSG93IGFi b3V0IGlmIHdlIGFkZGVkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgaW4gdGhlIGFic3RyYWN0IGFu ZCB0aGUgaW50cm9kdWN0aW9uPyBOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2Vzbid0IGRlZmlu ZSBTUiBQb2xpY3kgLSB0aGF0IGNvbWVzIGZyb20gUkZDODQwMi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U1IgUG9saWN5IGlzIGFuIG9yZGVyZWQg bGlzdCBvZiBzZWdtZW50cyAoaS5lLiBpbnN0cnVjdGlvbnMpIHRoYXQgcmVwcmVzZW50IGEgc291 cmNlLXJvdXRlZCBwb2xpY3kuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tzIGdvb2QuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KJm5ic3A7ICZu YnNwO1NlZ21lbnQgUm91dGluZyAoU1IpIFtSRkM4NDAyXSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUg dG8gc3RlZXIgYTxicj4NCiZuYnNwOyAmbmJzcDtwYWNrZXQgZmxvdyBhbG9uZyBhbnkgcGF0aC4m bmJzcDsgVGhlIGhlYWRlbmQgaXMgYSBub2RlIHdoZXJlIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtp bnN0cnVjdGlvbnMgZm9yIHNvdXJjZSByb3V0aW5nIChpLmUuIHNlZ21lbnRzKSBhcmUgaW5zdGFu dGlhdGVkIGludG88YnI+DQombmJzcDsgJm5ic3A7dGhlIHBhY2tldCBhbmQgaGVuY2UgYmVjb21l cyB0aGUgc3RhcnRpbmcgbm9kZSBmb3IgYSBzcGVjaWZpYyBzZWdtZW50PGJyPg0KJm5ic3A7ICZu YnNwO3JvdXRpbmcgcGF0aC4mbmJzcDsgSW50ZXJtZWRpYXRlIHBlci1wYXRoIHN0YXRlcyBhcmUg ZWxpbWluYXRlZCB0aGFua3MgdG88YnI+DQombmJzcDsgJm5ic3A7c291cmNlIHJvdXRpbmcuPGJy Pg0KPGJyPg0KV291bGQgJnF1b3Q7d3JpdHRlbiZxdW90OyBiZSBiZXR0ZXIgdGhhbiAmcXVvdDtp bnN0YW50aWF0ZWQmcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5LVCZndDsgQWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQombmJzcDsgJm5ic3A7VGhlIGhl YWRlbmQgbm9kZSBpcyBzYWlkIHRvIHN0ZWVyIGEgZmxvdyBpbnRvIGEgU2VnbWVudCBSb3V0aW5n PGJyPg0KJm5ic3A7ICZuYnNwO1BvbGljeSAoU1IgUG9saWN5KS4mbmJzcDsgW1JGQzg0MDJdIGlu dHJvZHVjZXMgdGhlIFNSIFBvbGljeSBjb25zdHJ1Y3QgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO3By b3ZpZGVzIGFuIG92ZXJ2aWV3IG9mIGhvdyBpdCBpcyBsZXZlcmFnZWQgZm9yIFNlZ21lbnQgUm91 dGluZyB1c2UtPGJyPg0KJm5ic3A7ICZuYnNwO2Nhc2VzLjxicj4NCjxicj4NCkkgd2FzIHNsaWdo dGx5IGNvbmZ1c2VzIGFzIHdoZXJlIFNSIHBvbGljeSBpcyBhY3R1YWxseSBkZWZpbmVkLiZuYnNw OyBNeTxicj4NCmludGVycHJldGF0aW9uIGlzIHRoYXQgdGhlIGJhc2UgZGVmaW5pdGlvbiBpcyBp biBSRkM4NDAyLCBidXQgdGhhdCBkZWZpbml0aW9uPGJyPg0KaXMgYmVpbmcgZXhwbGFpbmVkIGlu IG1vcmUgZGV0YWlsIGluIHRoaXMgZG9jdW1lbnQuJm5ic3A7IElzIHRoYXQgY29ycmVjdD8mbmJz cDsgSWYgc28sPGJyPg0KcG9zc2libHkgYWRkaW5nIGEgc2VudGVuY2UgaGVyZSB0byBtYWtlIHRo YXQgY2xlYXIgbWF5IGJlIGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LVCZndDsgWWVzLCB0aGF0IGlzIGNvcnJlY3QuIFRo ZSBpbnRyb2R1Y3Rpb24gZG9lcyBzYXkgdGhhdCBSRkM4NDAyIGludHJvZHVjZXMgdGhlIFNSIFBv bGljeSBjb25zdHJ1Y3QgKHBhcmEgMikgYW5kIHRoYXQgdGhpcyBkb2N1bWVudCBkZXRhaWxzIGl0 IChwYXJhIDQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Pa2F5LiZuYnNwOyBJdCB3b3VsZCBiZSBuaWNlIGlmIHRoZSB0 ZXh0IGluIHBhcmFncmFwaCAyIGFuZCA0IGNvdWxkIGJlIG1vcmUgY2xvc2VseSBhbGlnbmVkLCBi dXQgSSBkb27igJl0IGFjdHVhbGx5IHNlZSBhbiBlYXN5L2NsZWFuIHdheSBvZiBkb2luZyB0aGlz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxicj4NCjIuOS4mbmJzcDsgQWN0aXZlIENhbmRpZGF0ZSBQYXRoPGJyPg0KPGJyPg0KSSBm b3VuZCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHBhdGggc2VsZWN0aW9uIHRvIGJlIHNvbWV3aGF0 IGNvbmZ1c2luZy4mbmJzcDsgSTxicj4NCndvdWxkIHN1Z2dlc3QgdGhpcyBtaWdodCBiZSBjbGVh cmVyIGlmIGl0IGp1c3QgZ2F2ZSB0aGUgZnVsbCBsaXN0IG9mIHBhdGg8YnI+DQpzZWxlY3Rpb24s IHJhdGhlciB0aGFuIHRyZWF0aW5nIHRoZSBwcmVmZXJlbmNlIGFzIGEgc3BlY2lhbCBjYXNlIGFu ZCBsaXN0aW5nPGJyPg0KdGhlIHJlc3Qgb2YgdGllLWJyZWFrZXJzLjxicj4NCjxicj4NCkUuZy4s PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOzEuJm5ic3A7IEhpZ2hlciB2YWx1ZSBvZiBwcmVmZXJl bmNlIGlzIHNlbGVjdGVkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsyLiZuYnNwOyBIaWdoZXIg dmFsdWUgb2YgUHJvdG9jb2wtT3JpZ2luIGlzIHNlbGVjdGVkLjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDszLiZuYnNwOyBJZiBzcGVjaWZpZWQgYnkgY29uZmlndXJhdGlvbiwgcHJlZmVyIHRoZSBl eGlzdGluZyBpbnN0YWxsZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYXRoLjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDs0LiZuYnNwOyBMb3dlciB2YWx1ZSBvZiBvcmlnaW5hdG9y IGlzIHNlbGVjdGVkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDs1LiZuYnNwOyBGaW5hbGx5LCB0 aGUgaGlnaGVyIHZhbHVlIG9mIGRpc2NyaW1pbmF0b3IgaXMgc2VsZWN0ZWQuPGJyPg0KPGJyPg0K VGhlIHBhcmFncmFwaHMgYWJvdmUgdGhpcyBsaXN0IHdvdWxkIG5lZWQgdG8gYmUgY2hhbmdlZCBz bGlnaHRseSwgYnV0IHRoZTxicj4NCnBhcmFncmFwaHMgYmVsb3cgd291bGQgdGhlbiBiZSBlYXNp ZXIgdG8gcmVhZC91bmRlcnN0YW5kIChhdCBsZWFzdCB0byBtZSkuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LVCZndDsgVGhlIG1vdGl2 YXRpb24gZm9yIHRoZSBjdXJyZW50IHRleHQgaXMgdGhhdCBwcmVmZXJlbmNlIGlzIHRoZSBwcmlt YXJ5IHBhcmFtZXRlciAod2UgY2FuIGNsYXJpZnkgdGhpcyBpbiB0aGUgdGV4dCkgaW4gZGV0ZXJt aW5pbmcgdGhlIG9yZGVyIG9mIHNlbGVjdGlvbiBvZiBhY3RpdmUgY2FuZGlkYXRlIHBhdGguIFRo ZSBvdGhlciBwYXJhbWV0ZXJzIGFyZSBjb21pbmcNCiBmcm9tIHRoZSBpZGVudGlmaWVycyBvZiB0 aGUgY2FuZGlkYXRlIHBhdGggYW5kIGFyZSBoZW5jZSBjYWxsZWQgdGllLWJyZWFrZXJzIGluIHRo ZSBldmVudCBvZiBoYXZpbmcgdGhlIHNhbWUgcHJlZmVyZW5jZSAoZm9yIGFueSByZWFzb24gd2hh dHNvZXZlcikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rYXkuICZuYnNwO0l0IHdhcyB0aGlz IHBhcmFncmFwaCB0aGF0IGluaXRpYWxseSB0aHJldyBtZSAocmVsYXRpdmUgdG8gdGhlIGxpc3Qp OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5k OiNGRkZERjUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45 cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3Bh ZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBU aGUgcHJlZmVyZW5jZSwgYmVpbmcgdGhlIGZpcnN0IHRpZWJyZWFrZXIsIGFsbG93cyBhbiBvcGVy YXRvciB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZmx1ZW5jZSBzZWxlY3Rpb24gYWNyb3NzIHBh dGhzIHRodXMgYWxsb3dpbmcgcHJvdmlzaW9uaW5nIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3Vu ZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVs dGlwbGUgcGF0aCBvcHRpb25zLCBlLmcuLCBDUDEgaXMgcHJlZmVycmVkIGFuZCBpZiBpdCBiZWNv bWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW52YWxpZCB0aGVuIGZhbGxiYWNrIHRvIENQMiBhbmQg c28gb24uJm5ic3A7IFNpbmNlIHByZWZlcmVuY2Ugd29ya3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20i Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh Y3Jvc3MgcHJvdG9jb2wgc291cmNlcywgaXQgYWxzbyBlbmFibGVzICh3aGVyZSBuZWNlc3Nhcnkp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jv cmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VsZWN0aXZlIG92ZXJyaWRlIG9mIHRoZSBkZWZhdWx0IFBy b3RvY29sLU9yaWdpbiBwcmVmZXJlbmNlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG NTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGUuZy4sIHRvIHBy ZWZlciBhIHBhdGggc2lnbmFsZWQgdmlhIEJHUCBTUiBQb2xpY3kgb3ZlciB3aGF0IGlzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpu b25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY29uZmlndXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UGVyaGFwcyB0aGlzIHRleHQgc2hvdWxkbuKAmXQgcmVmZXIgdG8gcHJlZmVyZW5j ZSBiZWluZyBhIHRpZS1icmVha2VyLCBhbmQgcGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g bGlzdCBpdCBiZWZvcmUgdGhlIFByb3RvY29sLU9yaWdpbiBwYXJhZ3JhcGg/Jm5ic3A7IEkuZS4s IEkgY291bGRu4oCZdCBmaWd1cmUgb3V0IHdoeSBzb21ldGhpbmcgbG93ZXIgaW4gdGhlIGxpc3Qg d291bGQgYmUgYWJsZSB0byBvdmVycmlkZQ0KIHRoZSBQcm90b2NvbC1PcmlnaW4sIHRoYXQgaXMg aGlnaGVyIGluIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxicj4NCjQuJm5ic3A7IFNlZ21lbnQgVHlwZXM8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7QmFzZWQgb24gdGhlIGRlc2lyZWQgZGF0YXBsYW5lLCBlaXRoZXIgdGhlIE1QTFMgbGFiZWwg c3RhY2sgb3IgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO1NSdjYgU2VnbWVudCBSb3V0aW5nIEhlYWRl ciBbUkZDODc1NF0gaXMgYnVpbHQgZnJvbSB0aGUgU2VnbWVudC1MaXN0Ljxicj4NCjxicj4NCkEg Y291cGxlIG9mIHRoZSB0eXBlcywgaS5lLiwgdGhlIElQdjQgcmVsYXRlZCBFIGFuZCBGLCBkb24n dCBvYnZpb3VzbHkgYXBwZWFyPGJyPg0KdG8gYmUgZWl0aGVyIE1QTFMgb3IgU1J2Ni4mbmJzcDsg SGVuY2UgZG9lcyB0aGUgZmlyc3Qgc2VudGVuY2UgbmVlZCB0byBiZSBleHBhbmRlZDxicj4NCnRv IGNvdmVyIHRoZXNlIHR5cGVzPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+S1QmZ3Q7IFRoZXNlIGFyZSBvbmx5IHJlbGV2YW50L2FwcGxp Y2FibGUgZm9yIFNSLU1QTFMuIFdlIGNhbiBkbyAtIHMvbGFiZWwvU1ItTVBMUyBsYWJlbCAtIHRv IG1ha2UgdGhpcyBtb3JlIGV4cGxpY2l0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B aCwgb2theS4mbmJzcDsgSWYgeW91IG1ha2UgdGhpcyBtb3JlIGV4cGxpY2l0IHRoZW4gZG9pbmcg aXQgaW4gdGhlIGluZGl2aWR1YWwgdHlwZXMgbWlnaHQgYmUgdXNlZnVsLiZuYnNwOyBPciBldmVu IG1vcmUgZXhwbGljaXQgd291bGQgYmUgdG8gbGlzdCB0aGUgdHlwZXMgdGhhdCBhcmUgcmVsZXZh bnQgdG8gU1ItTVBMUyBhbmQgdGhvc2Ugd2hpY2ggYXJlIHJlbGV2YW50IHRvIFNSdjYuJm5ic3A7 IEJ1dCBJ4oCZbGwgbGVhdmUgdGhpcyB0bw0KIHlvdXIgZGlzY3JldGlvbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Um9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+S2V0YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpSb2I8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY5PR11MB419668ABBA7C2F6E34B7BBCBB5349BY5PR11MB4196namp_-- From nobody Tue Feb 15 07:56:32 2022 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 9EBCE3A0D9D; Tue, 15 Feb 2022 07:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpw_OpVHkJ7R; Tue, 15 Feb 2022 07:56:11 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 33E933A0D9B; Tue, 15 Feb 2022 07:56:11 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id m24so23142465vsp.7; Tue, 15 Feb 2022 07:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kdiOCgLk1HcE2koJgCuY5UgsjIga7weiFKbvy0rwpNg=; b=Rwcjos6DsGLFbQs7/6ib6cr9/OBgE0+omsaM3fr6OGp7a1/BtvhnJlmsdnDc8d/U4E 2TufSy2XqiBG/1sj1m6Hsl378qgP4f2srgCIF/3kpNqeiSUHXTNvw4wQqQjSDOh5rKa2 oCPMwvODgDdl4nEbMNf7T6TgNlMMe/IDAzRH2RXcH2uJ7tfVabf4raYTEYfl1aqsNIlP Yy50yr3JbBwmDZElsA9lkProCJl0lScfxxy9Ix8+KB/nFOn+4qI+llY5tArxthbGw0KQ Hi1lAcLNDd+qYky+Tz75i09y6/wyOHNv30oCcsL7npU+ee3m32fdk6YR6JbnOxsa9WAW 6qMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kdiOCgLk1HcE2koJgCuY5UgsjIga7weiFKbvy0rwpNg=; b=1nNgAj0c/iIBTfPY8+j+6BRBu8N7MF1botRKm8pqZ6I3sWy0hNpLD+EpuqSodnaqjK IFiW/NqY3oovGiZ7YKVj7psABmK/I8N6LqK1i0oLt3AuoxUqXpI6COm2vzmzii9wDOw9 Bf2udZcTB+todLVeO7BqH8HkS4R8rAU/2ZMkUSjTxROSSXHr8fHgA/6kAQjuJon60B5F di97OKXtNcRCxCud7yRFjYNrxTErAR5Il5P6VbMSQON7pm2Tq7bGMtU7S+vXJiFxFRaR lAOlWIQS1kw7NNSeaz8pfheZmpi+DDx+C/7sPRnutPAVqVkUFfmmccsQjU2RZ3PRvCq2 tMaw== X-Gm-Message-State: AOAM533yocPiwU/yrHfAPqBMs4YlR2OEUK4jvXShvYAOj4ph2NiayEP6 49kn0kI/EoabzQU7oGaMqcw38arqbwuZG/V35pE= X-Google-Smtp-Source: ABdhPJybdfUAGlTq9IGbRIJNKVu2GSBkUepfirxfGsV3lkMLNaHbBFcZ1KUw1T0P83+NyOXSJubr5ffPuG1Sh85TEoc= X-Received: by 2002:a05:6102:3e8f:: with SMTP id m15mr1487837vsv.15.1644940569324; Tue, 15 Feb 2022 07:56:09 -0800 (PST) MIME-Version: 1.0 References: <164492775749.13041.11325015268231469212@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Tue, 15 Feb 2022 21:25:58 +0530 Message-ID: To: "Rob Wilton (rwilton)" Cc: The IESG , "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , SPRING WG , "james.n.guichard@futurewei.com" Content-Type: multipart/alternative; boundary="0000000000004fb18105d8109249" Archived-At: Subject: Re: [spring] Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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, 15 Feb 2022 15:56:17 -0000 --0000000000004fb18105d8109249 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rob, Thanks for your quick response and please check further inline below with KT2. On Tue, Feb 15, 2022 at 9:05 PM Rob Wilton (rwilton) wrote: > Hi Ketan, > > > > Please see inline =E2=80=A6 > > > > *From:* Ketan Talaulikar > *Sent:* 15 February 2022 14:17 > *To:* Rob Wilton (rwilton) > *Cc:* The IESG ; > draft-ietf-spring-segment-routing-policy@ietf.org; spring-chairs@ietf.org= ; > SPRING WG ; james.n.guichard@futurewei.com > *Subject:* Re: Robert Wilton's No Objection on > draft-ietf-spring-segment-routing-policy-16: (with COMMENT) > > > > Hi Rob, > > > > Thanks for your review and your comments. Please check inline below for > responses. > > > > We will include these changes in the next update of the document. > > > > > > On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton via Datatracker < > noreply@ietf.org> wrote: > > Robert Wilton has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document, I have a few minor suggestions that may improve > the > readability of this document. > > Segment Routing (SR) allows a headend node to steer a packet flow > along any path. Intermediate per-path states are eliminated thanks > to source routing. The headend node steers a flow into an SR Policy. > The packets steered into an SR Policy carry an ordered list of > segments associated with that SR Policy. This document details the > concepts of SR Policy and steering into an SR Policy. > > Possibly the abstract would be more readable if it gave a brief > description of > what an SR Policy is. > > > > KT> How about if we added the following sentence in the abstract and the > introduction? Note that this document doesn't define SR Policy - that com= es > from RFC8402. > > > > SR Policy is an ordered list of segments (i.e. instructions) that > represent a source-routed policy. > > > > Looks good. > > > > > > > Segment Routing (SR) [RFC8402] allows a headend node to steer a > packet flow along any path. The headend is a node where the > instructions for source routing (i.e. segments) are instantiated into > the packet and hence becomes the starting node for a specific segment > routing path. Intermediate per-path states are eliminated thanks to > source routing. > > Would "written" be better than "instantiated"? > > > > KT> Ack. > > > > > The headend node is said to steer a flow into a Segment Routing > Policy (SR Policy). [RFC8402] introduces the SR Policy construct and > provides an overview of how it is leveraged for Segment Routing use- > cases. > > I was slightly confuses as where SR policy is actually defined. My > interpretation is that the base definition is in RFC8402, but that > definition > is being explained in more detail in this document. Is that correct? If > so, > possibly adding a sentence here to make that clear may be helpful. > > > > KT> Yes, that is correct. The introduction does say that RFC8402 > introduces the SR Policy construct (para 2) and that this document detail= s > it (para 4). > > > > Okay. It would be nice if the text in paragraph 2 and 4 could be more > closely aligned, but I don=E2=80=99t actually see an easy/clean way of do= ing this. > KT2> We'll work on this. > > > > > > 2.9. Active Candidate Path > > I found the description of the path selection to be somewhat confusing. = I > would suggest this might be clearer if it just gave the full list of path > selection, rather than treating the preference as a special case and > listing > the rest of tie-breakers. > > E.g., > > 1. Higher value of preference is selected. > > 2. Higher value of Protocol-Origin is selected. > > 3. If specified by configuration, prefer the existing installed > path. > > 4. Lower value of originator is selected. > > 5. Finally, the higher value of discriminator is selected. > > The paragraphs above this list would need to be changed slightly, but the > paragraphs below would then be easier to read/understand (at least to me)= . > > > > KT> The motivation for the current text is that preference is the primary > parameter (we can clarify this in the text) in determining the order of > selection of active candidate path. The other parameters are coming from > the identifiers of the candidate path and are hence called tie-breakers i= n > the event of having the same preference (for any reason whatsoever). > > > > Okay. It was this paragraph that initially threw me (relative to the > list): > > > > o The preference, being the first tiebreaker, allows an operator to > > influence selection across paths thus allowing provisioning of > > multiple path options, e.g., CP1 is preferred and if it becomes > > invalid then fallback to CP2 and so on. Since preference works > > across protocol sources, it also enables (where necessary) > > selective override of the default Protocol-Origin preference, > > e.g., to prefer a path signaled via BGP SR Policy over what is > > configured. > > > > Perhaps this text shouldn=E2=80=99t refer to preference being a tie-break= er, and > perhaps it would be better to list it before the Protocol-Origin > paragraph? I.e., I couldn=E2=80=99t figure out why something lower in th= e list > would be able to override the Protocol-Origin, that is higher in the list= . > KT2> Ack > > > > > > 4. Segment Types > > Based on the desired dataplane, either the MPLS label stack or the > SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. > > A couple of the types, i.e., the IPv4 related E and F, don't obviously > appear > to be either MPLS or SRv6. Hence does the first sentence need to be > expanded > to cover these types? > > > > KT> These are only relevant/applicable for SR-MPLS. We can do - > s/label/SR-MPLS label - to make this more explicit. > > > > Ah, okay. If you make this more explicit then doing it in the individual > types might be useful. Or even more explicit would be to list the types > that are relevant to SR-MPLS and those which are relevant to SRv6. But > I=E2=80=99ll leave this to your discretion. > KT2> We will go with the explicit text for type E & F to align with others. Thanks, Ketan > > > Thanks, > > Rob > > > > > > Thanks, > > Ketan > > > > > Regards, > Rob > > > --0000000000004fb18105d8109249 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rob,

Thanks for you= r quick response and please check further inline below with KT2.
=

On Tue, Feb 15, 2022 at 9:05 PM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Ketan,

=C2=A0

Please see inline =E2=80=A6

=C2=A0

F= rom: Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: 15 February 2022 14:17
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: The IESG <= iesg@ietf.org>; draft-ietf-spring-segment-routing-policy= @ietf.org; = spring-chairs@ietf.org; SPRING WG <spring@ietf.org>; james.n.guichard@futurewei.com Subject: Re: Robert Wilton's No Objection on draft-ietf-spring-s= egment-routing-policy-16: (with COMMENT)

=C2=A0

Hi Rob,

=C2=A0

Thanks for your review an= d your comments. Please check inline below for responses.

=C2=A0

We will include these cha= nges in the next update of the document.

=C2=A0

=C2=A0

On Tue, Feb 15, 2022 at 5= :52 PM Robert Wilton via Datatracker <noreply@ietf.org> wrote:

Robert Wilton has entered= the following ballot position for
draft-ietf-spring-segment-routing-policy-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-s= pring-segment-routing-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document, I have a few minor suggestions that may improve t= he
readability of this document.

=C2=A0 =C2=A0Segment Routing (SR) allows a headend node to steer a packet f= low
=C2=A0 =C2=A0along any path.=C2=A0 Intermediate per-path states are elimina= ted thanks
=C2=A0 =C2=A0to source routing.=C2=A0 The headend node steers a flow into a= n SR Policy.
=C2=A0 =C2=A0The packets steered into an SR Policy carry an ordered list of=
=C2=A0 =C2=A0segments associated with that SR Policy.=C2=A0 This document d= etails the
=C2=A0 =C2=A0concepts of SR Policy and steering into an SR Policy.

Possibly the abstract would be more readable if it gave a brief description= of
what an SR Policy is.

=C2=A0

KT> How about if we ad= ded the following sentence in the abstract and the introduction? Note that = this document doesn't define SR Policy - that comes from RFC8402.

=C2=A0

SR Policy is an ordered l= ist of segments (i.e. instructions) that represent a source-routed policy.<= u>

=C2=A0

Looks good.

=C2=A0

=C2=A0


=C2=A0 =C2=A0Segment Routing (SR) [RFC8402] allows a headend node to steer = a
=C2=A0 =C2=A0packet flow along any path.=C2=A0 The headend is a node where = the
=C2=A0 =C2=A0instructions for source routing (i.e. segments) are instantiat= ed into
=C2=A0 =C2=A0the packet and hence becomes the starting node for a specific = segment
=C2=A0 =C2=A0routing path.=C2=A0 Intermediate per-path states are eliminate= d thanks to
=C2=A0 =C2=A0source routing.

Would "written" be better than "instantiated"?

=C2=A0

KT> Ack.=

=C2=A0


=C2=A0 =C2=A0The headend node is said to steer a flow into a Segment Routin= g
=C2=A0 =C2=A0Policy (SR Policy).=C2=A0 [RFC8402] introduces the SR Policy c= onstruct and
=C2=A0 =C2=A0provides an overview of how it is leveraged for Segment Routin= g use-
=C2=A0 =C2=A0cases.

I was slightly confuses as where SR policy is actually defined.=C2=A0 My interpretation is that the base definition is in RFC8402, but that definiti= on
is being explained in more detail in this document.=C2=A0 Is that correct?= =C2=A0 If so,
possibly adding a sentence here to make that clear may be helpful.

=C2=A0

KT> Yes, that is corre= ct. The introduction does say that RFC8402 introduces the SR Policy constru= ct (para 2) and that this document details it (para 4).

=C2=A0

Okay.=C2=A0 It would be nice if the text in paragrap= h 2 and 4 could be more closely aligned, but I don=E2=80=99t actually see a= n easy/clean way of doing this.


KT2> We'll work on this.
=C2=A0

=C2=A0

=C2=A0


2.9.=C2=A0 Active Candidate Path

I found the description of the path selection to be somewhat confusing.=C2= =A0 I
would suggest this might be clearer if it just gave the full list of path selection, rather than treating the preference as a special case and listin= g
the rest of tie-breakers.

E.g.,

=C2=A0 =C2=A01.=C2=A0 Higher value of preference is selected.

=C2=A0 =C2=A02.=C2=A0 Higher value of Protocol-Origin is selected.

=C2=A0 =C2=A03.=C2=A0 If specified by configuration, prefer the existing in= stalled
=C2=A0 =C2=A0 =C2=A0 =C2=A0path.

=C2=A0 =C2=A04.=C2=A0 Lower value of originator is selected.

=C2=A0 =C2=A05.=C2=A0 Finally, the higher value of discriminator is selecte= d.

The paragraphs above this list would need to be changed slightly, but the paragraphs below would then be easier to read/understand (at least to me).<= u>

=C2=A0

KT> The motivation for= the current text is that preference is the primary parameter (we can clari= fy this in the text) in determining the order of selection of active candid= ate path. The other parameters are coming from the identifiers of the candidate path and are hence called tie-breake= rs in the event of having the same preference (for any reason whatsoever).<= u>

=C2=A0

Okay.=C2=A0 It was this paragraph that initially thr= ew me (relative to the list):

=C2=A0

=C2=A0=C2=A0 o=C2=A0 The preference, being the first tiebreaker, allo= ws an operator to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 influence selection across paths thus = allowing provisioning of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multiple path options, e.g., CP1 is pr= eferred and if it becomes

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 invalid then fallback to CP2 and so on= .=C2=A0 Since preference works

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 across protocol sources, it also enabl= es (where necessary)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 selective override of the default Prot= ocol-Origin preference,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 e.g., to prefer a path signaled via BG= P SR Policy over what is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configured.

=C2=A0

Perhaps this text shouldn=E2=80=99t refer to prefere= nce being a tie-breaker, and perhaps it would be better to list it before t= he Protocol-Origin paragraph?=C2=A0 I.e., I couldn=E2=80=99t figure out why= something lower in the list would be able to override the Protocol-Origin, that is higher in the list.


KT2> Ack=C2=A0
=C2=A0=

=C2=A0

=C2=A0


4.=C2=A0 Segment Types

=C2=A0 =C2=A0Based on the desired dataplane, either the MPLS label stack or= the
=C2=A0 =C2=A0SRv6 Segment Routing Header [RFC8754] is built from the Segmen= t-List.

A couple of the types, i.e., the IPv4 related E and F, don't obviously = appear
to be either MPLS or SRv6.=C2=A0 Hence does the first sentence need to be e= xpanded
to cover these types?

=C2=A0

KT> These are only rel= evant/applicable for SR-MPLS. We can do - s/label/SR-MPLS label - to make t= his more explicit.=C2=A0

=C2=A0

Ah, okay.=C2=A0 If you make this more explicit then = doing it in the individual types might be useful.=C2=A0 Or even more explic= it would be to list the types that are relevant to SR-MPLS and those which = are relevant to SRv6.=C2=A0 But I=E2=80=99ll leave this to your discretion.


KT2> We will go with the explicit text for type E & F to al= ign with others.

Thanks,
Ketan
=C2=A0

<= /u>

=C2=A0

Thanks,

Rob

=C2=A0

=C2=A0

Thanks,

Ketan

=C2=A0


Regards,
Rob


--0000000000004fb18105d8109249-- From nobody Tue Feb 15 08:11:40 2022 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 9805C3A0DD6; Tue, 15 Feb 2022 08:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.594 X-Spam-Level: X-Spam-Status: No, score=-9.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=K6I++P3A; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nDteAuHY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfTwQkrlRjIt; Tue, 15 Feb 2022 08:11:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CCD3A0DDF; Tue, 15 Feb 2022 08:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44034; q=dns/txt; s=iport; t=1644941486; x=1646151086; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H5C7AGghkrVgDS0zKEjSqUc3AKL3pERSzGUUSwYgSNE=; b=K6I++P3AbNafzTqXIff3HnClHunA2zk+dafoIA54XgvQvWxBB/wW8knm G/DVywhznYrsmREF2rc96S5mugHzfpgsCeWiSoaA7uuPvExx2U0wzTEFw TPieHDiIAU+PdehAD2Ivkb8Ol1HHDnhLec41dV8e/4bLq9VtzwvlL1VO/ 4=; IronPort-PHdr: =?us-ascii?q?A9a23=3AQ0QXYhPnd+hyMVk0m2wl6ncDWUAX0o4cdiYZ6?= =?us-ascii?q?Zsi3rRJdKnrv5HvJ1fW6vgliljVFZ7a5PRJh6uz0ejgVGUM7IzHvCUEd5pBB?= =?us-ascii?q?BMAgN8dygonBsPNAEbnLfnsOio9GskKVFJs83yhd0ZPH8OrbFzJqXr05jkXS?= =?us-ascii?q?X3C?= IronPort-Data: =?us-ascii?q?A9a23=3AqM2xl6so2rAdBw/wDHXfpTr6n+fnVPlcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKTqDPq2LYTejfo0lYdu39khQuZLdnN9gHQZppXw1F?= =?us-ascii?q?ytAgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmM9n9BDpC79SMmjfvQH?= =?us-ascii?q?+KlYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?= =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j83Ad+j1738aEBPG+aUNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO12vhc?= =?us-ascii?q?9NZkL2hsbSqVgYtIqrKsO8cSBJfVSp5OMWq/ZeWfiDh4ZPLlh2un3zEhq8G4?= =?us-ascii?q?FsNFY8R/+tsR2cI+uEZIzAEdByrif+q3ai2VeRtwM8kKaHDJ5sFu3dv5TDUE?= =?us-ascii?q?fhgRorMK43R/cVZ2jh1jcBHHOzFT8sUdTQpaw7PCzVDIF4ZFNc/kfumw2Lna?= =?us-ascii?q?TxepxeOqKUy7m7PiRZ2zaTsNtWQYtuORM5EtkeVumyA+H72ajkbOceQ4TuI7?= =?us-ascii?q?nzqgfXA9Qv4VZ4bEqH+9/N2jnWcw2USDFsdUl7TnBUToiZSQPpFIEASvyEpt?= =?us-ascii?q?6V3rRTtRdjmVBr+q3mB1iPwkuF4S4USgDxhAIKPi+pBOlU5cw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AN2luk6tjn2C044nAJS40vJqS7skC2oMji2?= =?us-ascii?q?hC6mlwRA09TyXGraGTdaUguyMc1gx/ZJh5o6H+BEGBKUmskqKdkrNhQ4tKPT?= =?us-ascii?q?OW9ldASbsD0WKM+UyaJ8STzJ856U4kSdkDNDSSNyk6sS+Z2njDLz9I+rDum8?= =?us-ascii?q?rE6Za8vhVQpENRGtxdBmxCe2Cm+zhNNXF77O0CZeOhD6R81l6dUEVSSv7+Km?= =?us-ascii?q?gOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonis2Yndq+/MP4GLFmwv26u?= =?us-ascii?q?GIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaQkEyzzYJriJaYfy+Azdk9vfr2?= =?us-ascii?q?rCV+O85SvICv4Drk85uFvF+CcFlTOQiArGoEWSuGNwyUGT0fARAghKUPaoQe?= =?us-ascii?q?liA0bkA41KhqAn7EsD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSp?= =?us-ascii?q?Z2Us4dkWUzxjIfLH47JlOx1GnnKpgYMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx?= =?us-ascii?q?+DBkwPoNac3TRalG1wixJw/r1Rol4QsJYmD5VU7eXNNapl0LlIU88NdKp4QO?= =?us-ascii?q?MMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+63JwloOWxPJAYxpo7n5rMFFteqG?= =?us-ascii?q?4pYkrrTdaD2ZVamyq9CFlVnQ6dg/22y6IJz4EUdYCbRxFrEmpe4fdIi89vdv?= =?us-ascii?q?HmZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5BgByHvlh/5JdJa1agmOBITEuKAd?= =?us-ascii?q?3WjcxhEmDRwOFOYUOgwIDixCQFIEuFIERA1QLAQEBDQEBNwoEAQGFBQIXg0g?= =?us-ascii?q?CJTQJDgECBAEBARIBAQUBAQECAQYEgQkThWgNhkIBAQEBAxIRChMBATcBDwI?= =?us-ascii?q?BCBEEAQEhAQYDAgICHxEUCQgCBA4FCBqCBF+CDlcDLgEOoisBgToCih96gTG?= =?us-ascii?q?BAYIIAQEGBASBSkGDAg0LgjcDBoE6gw6EHAEBgR6FaSccgUlEgRVDgWaBAT6?= =?us-ascii?q?CIUICA4EoARIBIysJgmI3gi6SIQcBPCYEIhkIEBcvNQR5ChEeRpFtEASDCEa?= =?us-ascii?q?JTo1ykTw6awqDRosBjmMEhhMVg3KMHIZaji2CcpZKgkeKSINOkGGFBAIEAgQ?= =?us-ascii?q?FAg4BAQaBYTwrPnBwFTuCaVEZD44sFhVuAQiCQ4UUhUp0AjYCBgEKAQEDCY1?= =?us-ascii?q?MAQE?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="970687018" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Feb 2022 16:11:23 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 21FGBNMQ011514 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2022 16:11:23 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 15 Feb 2022 10:11:23 -0600 Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 15 Feb 2022 11:11:22 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 15 Feb 2022 10:11:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MvJEgpT1rFXU9wxKDYpAn1OVnMDT80d3Lon+rx0cmtIat6aXyP+mCSK7TUTEbWHiMlWg6vmdgKvBX7h4JQX3rF7zTv2IK6Pe5Jt4sD6m0i9oYbLNyHTlO+RSb4Nj/Px1SdZgDU+rYA4XIJm+H5sa3hUOroIL3boRXF6qsHjJlJvUL/n6LFYh2uJOdTVpCHjzgtCO5M6IfnVmHi5LcxasyeYATzFGFMhOj4MWYSYq9XbX6yqa4nl7Frwtb4UAp7i3LYxCabNdDyJqx+VQk1t0zw3LwL9JzYqmwql5gfDcDtvUU+3e+/b1WKuEWs6KjnuDnOxZrI7tpUjpPxT/cD2b+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H5C7AGghkrVgDS0zKEjSqUc3AKL3pERSzGUUSwYgSNE=; b=me2PseKLVdS50vLsLXe7VN0l4/i0JcOu+Op77s5JbhrO/b6sItVVZwIXtAc9sEyuhs3MHInOEN8mmPdxZLd20NaQNrFU8LI1xaVeKm3Ul3Y5CfY+WQXpYHSKQXO98esvbwWUKBuqvc5p3Xco2tlznPRiDsNDspAXFHSjXkHzz39gvGhZOPcIdTZohq5s6H67YNEhu49AJZvROFOMYpryHz1jS8YFqBsss08t9wYjr2SxIYdfmYwQrl5WbjcXqUldKr2XxZPbm75QnaVkw9QN6Es/lFrxumunEe04TBBad4mNYrIAolzmovYLxAgtRw3hdTIbXjXCmadIq5vDwL9zFg== 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=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H5C7AGghkrVgDS0zKEjSqUc3AKL3pERSzGUUSwYgSNE=; b=nDteAuHYD74vVD9LETSc8D3jBh5sKyl05KIfa2f7hn+5IbkcxqNd6f6tp+jLG2M56JpF1CR8E5jclsJYeBVeqI183J3sDyDllTtjFKu4IQuz5sKqMzccqqP6Eto8Xw68P4vEkfDahrGFgOKWjHhA5sEkn/t3muHHOse3Xz3+Z2w= Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by SA1PR11MB5922.namprd11.prod.outlook.com (2603:10b6:806:239::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Tue, 15 Feb 2022 16:11:20 +0000 Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::c13b:f3ae:bbbe:2af4]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::c13b:f3ae:bbbe:2af4%3]) with mapi id 15.20.4975.019; Tue, 15 Feb 2022 16:11:19 +0000 From: "Rob Wilton (rwilton)" To: Ketan Talaulikar CC: The IESG , "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , SPRING WG , "james.n.guichard@futurewei.com" Thread-Topic: Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) Thread-Index: AQHYIma/ovfIV077SUy5z/mnQjnPsayUqIsAgAATknCAAAggAIAABDsQ Date: Tue, 15 Feb 2022 16:11:19 +0000 Message-ID: References: <164492775749.13041.11325015268231469212@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4bce22fe-24bd-47b0-351d-08d9f09dcd7a x-ms-traffictypediagnostic: SA1PR11MB5922:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8ox9SJ2W58sXadnccoA798RKUCrEEyLAR0FuX9lekNdAGmpvX0lARDtB4jMZpwMAG9IpreJ6vidMHRM46M7pdbZJWIWXjs8IbRpyoU332y3DJx9/Ah5tJ5qbEUwLCagKl+8T+LWUYNZ3dHTymP0awWHX3oqQoU6UDgYpFQ2dzz6AjyfSqHpY0U7J/qmbBBVIUW44TNwOPENDF/MXT821E07b6koRFZXAxCYTlJB+KD5A6NSbStfB04XG1D8IJVQRbAmtgJtI0AG3Ov2WL6LzloNZ/660WJi9nVP0g4JRniFg2KPsafECOM8y8i//9Dui+9NDXXBn4IL/YSxLbvfFnaY76Y1flAHj1gfyPzshqqXW0QCmhsdsUN49OOsLVJCZ2iqyhGlQK//yNNrcUPAvo4ISVcmO/C+nMEsTLj8ufC8htomJkmrQGr2nuxy8VTJEVz8WaGymcXXgSlJrYuuev5CdkQK2B1htKE8m3IPDYH3v1w5kdNgKr5JlzVIhMAT4gcqJMHyhfT9iPDnWX+oTgEiNF+ACdOYTsXlOVN54Qjwtm/KR+x3xO+4cceqNhoOSl/FJ1/ltcntsB01ljc1QCANFHekw+5reTxQXoyxqk1vEcfc38iyAj+YH9l62GpCJSTM2KBZBKhWbuENAZO1kpFK+2AkNGCfM3IKB/qZcKqour3Ssxy9CN2PPWnxhcyupZ1xmFI/8bWdktW4RjLx307WQpHAXKtIuKYDdW4bNRVGGzWJR9coQrpJoEQljLmlSDD9Oc/JtPPktU+vg1pECYEVr93aIWJeTxPrHjT3VIqccM0s5DrVaEmvR0wC/rYWbd6tNYQnZigAsfKuMHuUdHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(9326002)(966005)(38070700005)(8936002)(508600001)(66476007)(66556008)(4326008)(64756008)(66446008)(8676002)(52536014)(76116006)(9686003)(83380400001)(5660300002)(66946007)(122000001)(53546011)(2906002)(316002)(26005)(55016003)(7696005)(186003)(33656002)(6506007)(6916009)(86362001)(54906003)(38100700002)(71200400001)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?djRGKzRpOWZVdjdTdzhJazA0U2dzbloyaGZ3NEhQK1ZFNnNTUytqM0ZiVCtL?= =?utf-8?B?Y2RpNlpndHh1SWJsTllkS0VyNU55aThjQ2FkUUxjb0JOa0xpNjhZYVJoRGk2?= =?utf-8?B?Vk4zRUZjc3A3M0gvRVgrcTc0WkZLWE9EWUlvNFo1cGRaN3BHcWdTTWFSajZI?= =?utf-8?B?S3BjMmUwTWwzYnBZVTI0V3pjYXBzd3VuQVpsdzdnaGJOdlJMOGxSQTV5TjRQ?= =?utf-8?B?ZmdldW4yRFVMY2JCUzFTQm1IeWFLV1lQREhHdGpCb0gzYzF3MHdEdE56WFlJ?= =?utf-8?B?KzZrK25nSThoSDk2czFrNzdTVVYyQ2dQV0E1RVRuVWFKdU9BYzh5K3NOcFZx?= =?utf-8?B?aEVRYUJGQ1NkYUhZd3BrbHlHNVZVTnY5U0NBZDlSeVdqdkFYUGdXQzRUNGhn?= =?utf-8?B?Q2wvWW1zdDgxVGhYUkJDK2E4YWsrSElycFFjWDFycS9rOXdORU43UmZsZGdp?= =?utf-8?B?VmJ0RlgvbkYrbU9MSWdqL285N2kydjljOWdRbHlVc2VNVkJIeTNsKzZMOHJl?= =?utf-8?B?NkhUSHd4K2twcHZtWUE2aWVHRmExWXNsU3QySGlUMGVJdEVONm5KSTlQZURC?= =?utf-8?B?dzN5MUVYbUpoUSt1c1lvdFlzZDFEM29pTDZRYS91YW1DVk1QZmhPdFNDSVlU?= =?utf-8?B?azRwME9BYTQ1OHZiQllxNk5mRkd3OVVXVVNmT1IzWHBOQS9TRkNvOWdheVRE?= =?utf-8?B?NE5mMVZZUE16UVh3YlJ4NUU5YU9Ra01TTUhraUREOWp3RzlrZDVqUld6eFhD?= =?utf-8?B?dER0R29WblZHdFVKN2I3VHY0WVR5c0VWdlN6cFg3OElYNzk0LzlKSjJPV3pv?= =?utf-8?B?WDJSdzV4STRXZkJFSUxUWGdPa3d4QTZXN3ZLVXljVFBjd2E4c0sxRjF3TEVi?= =?utf-8?B?MGVrbityU05YMjJyajFpVWQ0M2hRZmhGbVBiUVRVdFY0eTlMRXV6TEhtb1lm?= =?utf-8?B?VTJqQ09kd2Rwb0FHNmsrYlMvQkZrUGt1OHFtYzZQcndJU0V5VzYrK29DcDJq?= =?utf-8?B?b1k1MzZuWjlQRE1wVGlCYjI4UGt5Z09VbkNZRkxaMkxyam1FcUUvOGZZbjNO?= =?utf-8?B?VkJHMy9LbFB0elRTNXA1dkNsNmduWUNyZDF4U2tPSTNYWFIwdTlFd0ljRnJM?= =?utf-8?B?Tjd4ejUvcm5IUUtweXVtYWRweWtSQi9YamtVQW1iMnp4R2tDd1llem1NT3dk?= =?utf-8?B?djB2RTczMVl2a3RnS2xDVnkzOGVTV1NOZittYnBIekxVL3IwMDdjbHdlTnMr?= =?utf-8?B?RXhieEJvWmhra2FFbEVGZGVhdkNPenlURDRJNjl6MGNzR3VTeVQrdEIxWUhx?= =?utf-8?B?em1yNytYc1ZSSlI1UHAzdnB0YjBJU012RXhxam92Y0VITk9rOWlnTDF2dCtz?= =?utf-8?B?SS95aWUvYjlsUlJCbEY4Wmh3NHNNM2ZWWk5ncko3M0hDa0hkVVlTTTFoclpy?= =?utf-8?B?MG5SNkVKdjZlb0kvMnNnMEVSOGNBeFBvQUJEMWxHZERZTWNMdjdQcDYyemFT?= =?utf-8?B?V0lIL1BYSVZDaHJMZWlZQXNidHd6aCtLNE9JbWFRcjNLUUNZbkN3K2FhREkz?= =?utf-8?B?bzkwZXVlMThxQUk3YThZeFNDd3VqU0hJNEhqdjM1WkFWemVkUzBmcjFNN0JV?= =?utf-8?B?L0M5M2dDZ1ltV210QTVXMzRiNjVyRlZ2eUpjc3RCaEhCanVYK0xLT29lTENL?= =?utf-8?B?Mlc4R3VGVDk3SVFIUjZidFZUbTN4cUNsMmlLcE8zdXdsVm5RNHpjZVA0YUhm?= =?utf-8?B?bGwwMGlzeWp2ZDlaNEczYVh3V0tKdXJyS1FZSTV4RmQwTVlFcjYxRExlTXZy?= =?utf-8?B?RWloblNoVEg1TUNSNnN5QUtCK3QyNXpQbUdySDdsbEczWkdXRk42UFlCUmk1?= =?utf-8?B?cDRCNjZDRTY1K09XSWtzMExrQThUY2w4REUzMEF0UlB2V3BNYjg4ZHlkbXZu?= =?utf-8?B?RktkOTdDWWVZY2hBUDEwb0txN3JoODBrRlVzUy9hZGJES0I3bWgzMnEvM2JY?= =?utf-8?B?VVlZb3JZVGtycXFTOGRYTlEvc1lYU00vMjRtY2w1UitPVTlodmJvSldwTFEz?= =?utf-8?B?cGFST1ErS3B0NnR4b1J5WGU1KzhRenZYbm9tbXM1SGlQbEhVMHkyK0dIQVIz?= =?utf-8?B?cDhaQlFUc0hjN1dUeE9WODV6bW1vMDJJR2ZYbklTUjlKTk45Z09kWWNJWnlW?= =?utf-8?B?M2c9PQ==?= Content-Type: multipart/alternative; boundary="_000_BY5PR11MB419671083B8D2E3F3E2BF8DBB5349BY5PR11MB4196namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4bce22fe-24bd-47b0-351d-08d9f09dcd7a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2022 16:11:19.6412 (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: 9KDOMl8K48qsF3lrV5wbC5hLztjH9CbbC528r+lfApqkMl1NHe9K9Wzhaf++HXGbo0WZNGEGZlvmZsFgLwMAvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB5922 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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, 15 Feb 2022 16:11:32 -0000 --_000_BY5PR11MB419671083B8D2E3F3E2BF8DBB5349BY5PR11MB4196namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2V0YW4sDQoNCkFsbCBzb3VuZHMgZ29vZC4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KRnJvbTog S2V0YW4gVGFsYXVsaWthciA8a2V0YW50LmlldGZAZ21haWwuY29tPg0KU2VudDogMTUgRmVicnVh cnkgMjAyMiAxNTo1Ng0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNv bT4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3lAaWV0Zi5vcmc7IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7IFNQUklO RyBXRyA8c3ByaW5nQGlldGYub3JnPjsgamFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tDQpT dWJqZWN0OiBSZTogUm9iZXJ0IFdpbHRvbidzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTE2OiAod2l0aCBDT01NRU5UKQ0KDQpIaSBSb2Is DQoNClRoYW5rcyBmb3IgeW91ciBxdWljayByZXNwb25zZSBhbmQgcGxlYXNlIGNoZWNrIGZ1cnRo ZXIgaW5saW5lIGJlbG93IHdpdGggS1QyLg0KDQoNCk9uIFR1ZSwgRmViIDE1LCAyMDIyIGF0IDk6 MDUgUE0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2ls dG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgS2V0YW4sDQoNClBsZWFzZSBzZWUgaW5saW5lIOKA pg0KDQpGcm9tOiBLZXRhbiBUYWxhdWxpa2FyIDxrZXRhbnQuaWV0ZkBnbWFpbC5jb208bWFpbHRv OmtldGFudC5pZXRmQGdtYWlsLmNvbT4+DQpTZW50OiAxNSBGZWJydWFyeSAyMDIyIDE0OjE3DQpU bzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9u QGNpc2NvLmNvbT4+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0 Zi5vcmc+PjsgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeUBpZXRmLm9y ZzxtYWlsdG86ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeUBpZXRmLm9y Zz47IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+ OyBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj47IGph bWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1 cmV3ZWkuY29tPg0KU3ViamVjdDogUmU6IFJvYmVydCBXaWx0b24ncyBObyBPYmplY3Rpb24gb24g ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0xNjogKHdpdGggQ09NTUVO VCkNCg0KSGkgUm9iLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCB5b3VyIGNvbW1lbnRz LiBQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93IGZvciByZXNwb25zZXMuDQoNCldlIHdpbGwgaW5j bHVkZSB0aGVzZSBjaGFuZ2VzIGluIHRoZSBuZXh0IHVwZGF0ZSBvZiB0aGUgZG9jdW1lbnQuDQoN Cg0KT24gVHVlLCBGZWIgMTUsIDIwMjIgYXQgNTo1MiBQTSBSb2JlcnQgV2lsdG9uIHZpYSBEYXRh dHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3Rl Og0KUm9iZXJ0IFdpbHRvbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCmRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMTY6IE5vIE9i amVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFy YWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvYmxvZy9oYW5kbGluZy1pZXNnLWJhbGxvdC1wb3NpdGlvbnMvDQpmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBob3cgdG8gaGFuZGxlIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K DQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpD T01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIaSwNCg0KVGhhbmtzIGZvciB0aGlzIGRvY3VtZW50 LCBJIGhhdmUgYSBmZXcgbWlub3Igc3VnZ2VzdGlvbnMgdGhhdCBtYXkgaW1wcm92ZSB0aGUNCnJl YWRhYmlsaXR5IG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFs bG93cyBhIGhlYWRlbmQgbm9kZSB0byBzdGVlciBhIHBhY2tldCBmbG93DQogICBhbG9uZyBhbnkg cGF0aC4gIEludGVybWVkaWF0ZSBwZXItcGF0aCBzdGF0ZXMgYXJlIGVsaW1pbmF0ZWQgdGhhbmtz DQogICB0byBzb3VyY2Ugcm91dGluZy4gIFRoZSBoZWFkZW5kIG5vZGUgc3RlZXJzIGEgZmxvdyBp bnRvIGFuIFNSIFBvbGljeS4NCiAgIFRoZSBwYWNrZXRzIHN0ZWVyZWQgaW50byBhbiBTUiBQb2xp Y3kgY2FycnkgYW4gb3JkZXJlZCBsaXN0IG9mDQogICBzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGgg dGhhdCBTUiBQb2xpY3kuICBUaGlzIGRvY3VtZW50IGRldGFpbHMgdGhlDQogICBjb25jZXB0cyBv ZiBTUiBQb2xpY3kgYW5kIHN0ZWVyaW5nIGludG8gYW4gU1IgUG9saWN5Lg0KDQpQb3NzaWJseSB0 aGUgYWJzdHJhY3Qgd291bGQgYmUgbW9yZSByZWFkYWJsZSBpZiBpdCBnYXZlIGEgYnJpZWYgZGVz Y3JpcHRpb24gb2YNCndoYXQgYW4gU1IgUG9saWN5IGlzLg0KDQpLVD4gSG93IGFib3V0IGlmIHdl IGFkZGVkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgaW4gdGhlIGFic3RyYWN0IGFuZCB0aGUgaW50 cm9kdWN0aW9uPyBOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2Vzbid0IGRlZmluZSBTUiBQb2xp Y3kgLSB0aGF0IGNvbWVzIGZyb20gUkZDODQwMi4NCg0KU1IgUG9saWN5IGlzIGFuIG9yZGVyZWQg bGlzdCBvZiBzZWdtZW50cyAoaS5lLiBpbnN0cnVjdGlvbnMpIHRoYXQgcmVwcmVzZW50IGEgc291 cmNlLXJvdXRlZCBwb2xpY3kuDQoNCkxvb2tzIGdvb2QuDQoNCg0KDQogICBTZWdtZW50IFJvdXRp bmcgKFNSKSBbUkZDODQwMl0gYWxsb3dzIGEgaGVhZGVuZCBub2RlIHRvIHN0ZWVyIGENCiAgIHBh Y2tldCBmbG93IGFsb25nIGFueSBwYXRoLiAgVGhlIGhlYWRlbmQgaXMgYSBub2RlIHdoZXJlIHRo ZQ0KICAgaW5zdHJ1Y3Rpb25zIGZvciBzb3VyY2Ugcm91dGluZyAoaS5lLiBzZWdtZW50cykgYXJl IGluc3RhbnRpYXRlZCBpbnRvDQogICB0aGUgcGFja2V0IGFuZCBoZW5jZSBiZWNvbWVzIHRoZSBz dGFydGluZyBub2RlIGZvciBhIHNwZWNpZmljIHNlZ21lbnQNCiAgIHJvdXRpbmcgcGF0aC4gIElu dGVybWVkaWF0ZSBwZXItcGF0aCBzdGF0ZXMgYXJlIGVsaW1pbmF0ZWQgdGhhbmtzIHRvDQogICBz b3VyY2Ugcm91dGluZy4NCg0KV291bGQgIndyaXR0ZW4iIGJlIGJldHRlciB0aGFuICJpbnN0YW50 aWF0ZWQiPw0KDQpLVD4gQWNrLg0KDQoNCiAgIFRoZSBoZWFkZW5kIG5vZGUgaXMgc2FpZCB0byBz dGVlciBhIGZsb3cgaW50byBhIFNlZ21lbnQgUm91dGluZw0KICAgUG9saWN5IChTUiBQb2xpY3kp LiAgW1JGQzg0MDJdIGludHJvZHVjZXMgdGhlIFNSIFBvbGljeSBjb25zdHJ1Y3QgYW5kDQogICBw cm92aWRlcyBhbiBvdmVydmlldyBvZiBob3cgaXQgaXMgbGV2ZXJhZ2VkIGZvciBTZWdtZW50IFJv dXRpbmcgdXNlLQ0KICAgY2FzZXMuDQoNCkkgd2FzIHNsaWdodGx5IGNvbmZ1c2VzIGFzIHdoZXJl IFNSIHBvbGljeSBpcyBhY3R1YWxseSBkZWZpbmVkLiAgTXkNCmludGVycHJldGF0aW9uIGlzIHRo YXQgdGhlIGJhc2UgZGVmaW5pdGlvbiBpcyBpbiBSRkM4NDAyLCBidXQgdGhhdCBkZWZpbml0aW9u DQppcyBiZWluZyBleHBsYWluZWQgaW4gbW9yZSBkZXRhaWwgaW4gdGhpcyBkb2N1bWVudC4gIElz IHRoYXQgY29ycmVjdD8gIElmIHNvLA0KcG9zc2libHkgYWRkaW5nIGEgc2VudGVuY2UgaGVyZSB0 byBtYWtlIHRoYXQgY2xlYXIgbWF5IGJlIGhlbHBmdWwuDQoNCktUPiBZZXMsIHRoYXQgaXMgY29y cmVjdC4gVGhlIGludHJvZHVjdGlvbiBkb2VzIHNheSB0aGF0IFJGQzg0MDIgaW50cm9kdWNlcyB0 aGUgU1IgUG9saWN5IGNvbnN0cnVjdCAocGFyYSAyKSBhbmQgdGhhdCB0aGlzIGRvY3VtZW50IGRl dGFpbHMgaXQgKHBhcmEgNCkuDQoNCk9rYXkuICBJdCB3b3VsZCBiZSBuaWNlIGlmIHRoZSB0ZXh0 IGluIHBhcmFncmFwaCAyIGFuZCA0IGNvdWxkIGJlIG1vcmUgY2xvc2VseSBhbGlnbmVkLCBidXQg SSBkb27igJl0IGFjdHVhbGx5IHNlZSBhbiBlYXN5L2NsZWFuIHdheSBvZiBkb2luZyB0aGlzLg0K DQpLVDI+IFdlJ2xsIHdvcmsgb24gdGhpcy4NCg0KDQoNCg0KMi45LiAgQWN0aXZlIENhbmRpZGF0 ZSBQYXRoDQoNCkkgZm91bmQgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBwYXRoIHNlbGVjdGlvbiB0 byBiZSBzb21ld2hhdCBjb25mdXNpbmcuICBJDQp3b3VsZCBzdWdnZXN0IHRoaXMgbWlnaHQgYmUg Y2xlYXJlciBpZiBpdCBqdXN0IGdhdmUgdGhlIGZ1bGwgbGlzdCBvZiBwYXRoDQpzZWxlY3Rpb24s IHJhdGhlciB0aGFuIHRyZWF0aW5nIHRoZSBwcmVmZXJlbmNlIGFzIGEgc3BlY2lhbCBjYXNlIGFu ZCBsaXN0aW5nDQp0aGUgcmVzdCBvZiB0aWUtYnJlYWtlcnMuDQoNCkUuZy4sDQoNCiAgIDEuICBI aWdoZXIgdmFsdWUgb2YgcHJlZmVyZW5jZSBpcyBzZWxlY3RlZC4NCg0KICAgMi4gIEhpZ2hlciB2 YWx1ZSBvZiBQcm90b2NvbC1PcmlnaW4gaXMgc2VsZWN0ZWQuDQoNCiAgIDMuICBJZiBzcGVjaWZp ZWQgYnkgY29uZmlndXJhdGlvbiwgcHJlZmVyIHRoZSBleGlzdGluZyBpbnN0YWxsZWQNCiAgICAg ICBwYXRoLg0KDQogICA0LiAgTG93ZXIgdmFsdWUgb2Ygb3JpZ2luYXRvciBpcyBzZWxlY3RlZC4N Cg0KICAgNS4gIEZpbmFsbHksIHRoZSBoaWdoZXIgdmFsdWUgb2YgZGlzY3JpbWluYXRvciBpcyBz ZWxlY3RlZC4NCg0KVGhlIHBhcmFncmFwaHMgYWJvdmUgdGhpcyBsaXN0IHdvdWxkIG5lZWQgdG8g YmUgY2hhbmdlZCBzbGlnaHRseSwgYnV0IHRoZQ0KcGFyYWdyYXBocyBiZWxvdyB3b3VsZCB0aGVu IGJlIGVhc2llciB0byByZWFkL3VuZGVyc3RhbmQgKGF0IGxlYXN0IHRvIG1lKS4NCg0KS1Q+IFRo ZSBtb3RpdmF0aW9uIGZvciB0aGUgY3VycmVudCB0ZXh0IGlzIHRoYXQgcHJlZmVyZW5jZSBpcyB0 aGUgcHJpbWFyeSBwYXJhbWV0ZXIgKHdlIGNhbiBjbGFyaWZ5IHRoaXMgaW4gdGhlIHRleHQpIGlu IGRldGVybWluaW5nIHRoZSBvcmRlciBvZiBzZWxlY3Rpb24gb2YgYWN0aXZlIGNhbmRpZGF0ZSBw YXRoLiBUaGUgb3RoZXIgcGFyYW1ldGVycyBhcmUgY29taW5nIGZyb20gdGhlIGlkZW50aWZpZXJz IG9mIHRoZSBjYW5kaWRhdGUgcGF0aCBhbmQgYXJlIGhlbmNlIGNhbGxlZCB0aWUtYnJlYWtlcnMg aW4gdGhlIGV2ZW50IG9mIGhhdmluZyB0aGUgc2FtZSBwcmVmZXJlbmNlIChmb3IgYW55IHJlYXNv biB3aGF0c29ldmVyKS4NCg0KT2theS4gIEl0IHdhcyB0aGlzIHBhcmFncmFwaCB0aGF0IGluaXRp YWxseSB0aHJldyBtZSAocmVsYXRpdmUgdG8gdGhlIGxpc3QpOg0KDQogICBvICBUaGUgcHJlZmVy ZW5jZSwgYmVpbmcgdGhlIGZpcnN0IHRpZWJyZWFrZXIsIGFsbG93cyBhbiBvcGVyYXRvciB0bw0K ICAgICAgaW5mbHVlbmNlIHNlbGVjdGlvbiBhY3Jvc3MgcGF0aHMgdGh1cyBhbGxvd2luZyBwcm92 aXNpb25pbmcgb2YNCiAgICAgIG11bHRpcGxlIHBhdGggb3B0aW9ucywgZS5nLiwgQ1AxIGlzIHBy ZWZlcnJlZCBhbmQgaWYgaXQgYmVjb21lcw0KICAgICAgaW52YWxpZCB0aGVuIGZhbGxiYWNrIHRv IENQMiBhbmQgc28gb24uICBTaW5jZSBwcmVmZXJlbmNlIHdvcmtzDQogICAgICBhY3Jvc3MgcHJv dG9jb2wgc291cmNlcywgaXQgYWxzbyBlbmFibGVzICh3aGVyZSBuZWNlc3NhcnkpDQogICAgICBz ZWxlY3RpdmUgb3ZlcnJpZGUgb2YgdGhlIGRlZmF1bHQgUHJvdG9jb2wtT3JpZ2luIHByZWZlcmVu Y2UsDQogICAgICBlLmcuLCB0byBwcmVmZXIgYSBwYXRoIHNpZ25hbGVkIHZpYSBCR1AgU1IgUG9s aWN5IG92ZXIgd2hhdCBpcw0KICAgICAgY29uZmlndXJlZC4NCg0KUGVyaGFwcyB0aGlzIHRleHQg c2hvdWxkbuKAmXQgcmVmZXIgdG8gcHJlZmVyZW5jZSBiZWluZyBhIHRpZS1icmVha2VyLCBhbmQg cGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gbGlzdCBpdCBiZWZvcmUgdGhlIFByb3RvY29s LU9yaWdpbiBwYXJhZ3JhcGg/ICBJLmUuLCBJIGNvdWxkbuKAmXQgZmlndXJlIG91dCB3aHkgc29t ZXRoaW5nIGxvd2VyIGluIHRoZSBsaXN0IHdvdWxkIGJlIGFibGUgdG8gb3ZlcnJpZGUgdGhlIFBy b3RvY29sLU9yaWdpbiwgdGhhdCBpcyBoaWdoZXIgaW4gdGhlIGxpc3QuDQoNCktUMj4gQWNrDQoN Cg0KDQoNCjQuICBTZWdtZW50IFR5cGVzDQoNCiAgIEJhc2VkIG9uIHRoZSBkZXNpcmVkIGRhdGFw bGFuZSwgZWl0aGVyIHRoZSBNUExTIGxhYmVsIHN0YWNrIG9yIHRoZQ0KICAgU1J2NiBTZWdtZW50 IFJvdXRpbmcgSGVhZGVyIFtSRkM4NzU0XSBpcyBidWlsdCBmcm9tIHRoZSBTZWdtZW50LUxpc3Qu DQoNCkEgY291cGxlIG9mIHRoZSB0eXBlcywgaS5lLiwgdGhlIElQdjQgcmVsYXRlZCBFIGFuZCBG LCBkb24ndCBvYnZpb3VzbHkgYXBwZWFyDQp0byBiZSBlaXRoZXIgTVBMUyBvciBTUnY2LiAgSGVu Y2UgZG9lcyB0aGUgZmlyc3Qgc2VudGVuY2UgbmVlZCB0byBiZSBleHBhbmRlZA0KdG8gY292ZXIg dGhlc2UgdHlwZXM/DQoNCktUPiBUaGVzZSBhcmUgb25seSByZWxldmFudC9hcHBsaWNhYmxlIGZv ciBTUi1NUExTLiBXZSBjYW4gZG8gLSBzL2xhYmVsL1NSLU1QTFMgbGFiZWwgLSB0byBtYWtlIHRo aXMgbW9yZSBleHBsaWNpdC4NCg0KQWgsIG9rYXkuICBJZiB5b3UgbWFrZSB0aGlzIG1vcmUgZXhw bGljaXQgdGhlbiBkb2luZyBpdCBpbiB0aGUgaW5kaXZpZHVhbCB0eXBlcyBtaWdodCBiZSB1c2Vm dWwuICBPciBldmVuIG1vcmUgZXhwbGljaXQgd291bGQgYmUgdG8gbGlzdCB0aGUgdHlwZXMgdGhh dCBhcmUgcmVsZXZhbnQgdG8gU1ItTVBMUyBhbmQgdGhvc2Ugd2hpY2ggYXJlIHJlbGV2YW50IHRv IFNSdjYuICBCdXQgSeKAmWxsIGxlYXZlIHRoaXMgdG8geW91ciBkaXNjcmV0aW9uLg0KDQpLVDI+ IFdlIHdpbGwgZ28gd2l0aCB0aGUgZXhwbGljaXQgdGV4dCBmb3IgdHlwZSBFICYgRiB0byBhbGln biB3aXRoIG90aGVycy4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KDQpUaGFua3MsDQpSb2INCg0KDQpU aGFua3MsDQpLZXRhbg0KDQoNClJlZ2FyZHMsDQpSb2INCg0K --_000_BY5PR11MB419671083B8D2E3F3E2BF8DBB5349BY5PR11MB4196namp_ 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 OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBLZXRhbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QWxsIHNvdW5kcyBn b29kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Sb2I8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEtldGFuIFRh bGF1bGlrYXIgJmx0O2tldGFudC5pZXRmQGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9i PiAxNSBGZWJydWFyeSAyMDIyIDE1OjU2PGJyPg0KPGI+VG86PC9iPiBSb2IgV2lsdG9uIChyd2ls dG9uKSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUaGUgSUVTRyAm bHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1w b2xpY3lAaWV0Zi5vcmc7IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7IFNQUklORyBXRyAmbHQ7c3By aW5nQGlldGYub3JnJmd0OzsgamFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBSb2JlcnQgV2lsdG9uJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMTY6ICh3aXRoIENPTU1FTlQpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgUm9iLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmtzIGZvciB5b3VyIHF1 aWNrIHJlc3BvbnNlIGFuZCBwbGVhc2UgY2hlY2sgZnVydGhlciBpbmxpbmUgYmVsb3cgd2l0aCBL VDIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBGZWIgMTUsIDIwMjIgYXQgOTowNSBQ TSBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28u Y29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCkhpIEtldGFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KUGxlYXNlIHNlZSBpbmxp bmUg4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8Yj48c3BhbiBs YW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gS2V0YW4gVGFs YXVsaWthciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldGFudC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmtldGFudC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50Ojwv Yj4gMTUgRmVicnVhcnkgMjAyMiAxNDoxNzxicj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndp bHRvbikgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFRoZSBJRVNHICZs dDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2dAaWV0 Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRv OnNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNwcmluZy1jaGFpcnNA aWV0Zi5vcmc8L2E+OyBTUFJJTkcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5qYW1l cy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBS b2JlcnQgV2lsdG9uJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1wb2xpY3ktMTY6ICh3aXRoIENPTU1FTlQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6NzIuMHB0Ij4NCkhpIFJvYiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBw dCI+DQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgY2hl Y2sgaW5saW5lIGJlbG93IGZvciByZXNwb25zZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjcyLjBwdCI+DQpXZSB3aWxsIGluY2x1ZGUgdGhlc2UgY2hhbmdlcyBpbiB0aGUgbmV4 dCB1cGRhdGUgb2YgdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCk9uIFR1ZSwgRmViIDE1LCAyMDIy IGF0IDU6NTIgUE0gUm9iZXJ0IFdpbHRvbiB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpub3JlcGx5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bm9yZXBseUBpZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo3Mi4wcHQiPg0KUm9iZXJ0IFdpbHRvbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctcG9saWN5LTE2OiBObyBPYmplY3Rpb248YnI+DQo8YnI+DQpXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQpl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpczxicj4NCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4N Cjxicj4NCjxicj4NClBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9ibG9nL2hhbmRsaW5nLWllc2ctYmFsbG90LXBvc2l0aW9ucy8iIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvaGFuZGxpbmctaWVzZy1iYWxsb3QtcG9zaXRpb25z LzwvYT48YnI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBob3cgdG8gaGFuZGxlIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxicj4NCjxicj4NCjxicj4NClRoZSBkb2N1bWVudCwg YWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+ DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1w b2xpY3kvPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDT01N RU5UOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpIaSw8YnI+DQo8YnI+DQpUaGFua3Mg Zm9yIHRoaXMgZG9jdW1lbnQsIEkgaGF2ZSBhIGZldyBtaW5vciBzdWdnZXN0aW9ucyB0aGF0IG1h eSBpbXByb3ZlIHRoZTxicj4NCnJlYWRhYmlsaXR5IG9mIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwO1NlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93cyBhIGhlYWRlbmQgbm9k ZSB0byBzdGVlciBhIHBhY2tldCBmbG93PGJyPg0KJm5ic3A7ICZuYnNwO2Fsb25nIGFueSBwYXRo LiZuYnNwOyBJbnRlcm1lZGlhdGUgcGVyLXBhdGggc3RhdGVzIGFyZSBlbGltaW5hdGVkIHRoYW5r czxicj4NCiZuYnNwOyAmbmJzcDt0byBzb3VyY2Ugcm91dGluZy4mbmJzcDsgVGhlIGhlYWRlbmQg bm9kZSBzdGVlcnMgYSBmbG93IGludG8gYW4gU1IgUG9saWN5Ljxicj4NCiZuYnNwOyAmbmJzcDtU aGUgcGFja2V0cyBzdGVlcmVkIGludG8gYW4gU1IgUG9saWN5IGNhcnJ5IGFuIG9yZGVyZWQgbGlz dCBvZjxicj4NCiZuYnNwOyAmbmJzcDtzZWdtZW50cyBhc3NvY2lhdGVkIHdpdGggdGhhdCBTUiBQ b2xpY3kuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGV0YWlscyB0aGU8YnI+DQombmJzcDsgJm5ic3A7 Y29uY2VwdHMgb2YgU1IgUG9saWN5IGFuZCBzdGVlcmluZyBpbnRvIGFuIFNSIFBvbGljeS48YnI+ DQo8YnI+DQpQb3NzaWJseSB0aGUgYWJzdHJhY3Qgd291bGQgYmUgbW9yZSByZWFkYWJsZSBpZiBp dCBnYXZlIGEgYnJpZWYgZGVzY3JpcHRpb24gb2Y8YnI+DQp3aGF0IGFuIFNSIFBvbGljeSBpcy48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpLVCZndDsg SG93IGFib3V0IGlmIHdlIGFkZGVkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgaW4gdGhlIGFic3Ry YWN0IGFuZCB0aGUgaW50cm9kdWN0aW9uPyBOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2Vzbid0 IGRlZmluZSBTUiBQb2xpY3kgLSB0aGF0IGNvbWVzIGZyb20gUkZDODQwMi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4w cHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NClNSIFBvbGljeSBpcyBhbiBvcmRlcmVkIGxp c3Qgb2Ygc2VnbWVudHMgKGkuZS4gaW5zdHJ1Y3Rpb25zKSB0aGF0IHJlcHJlc2VudCBhIHNvdXJj ZS1yb3V0ZWQgcG9saWN5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KTG9va3MgZ29vZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1NlZ21lbnQgUm91dGlu ZyAoU1IpIFtSRkM4NDAyXSBhbGxvd3MgYSBoZWFkZW5kIG5vZGUgdG8gc3RlZXIgYTxicj4NCiZu YnNwOyAmbmJzcDtwYWNrZXQgZmxvdyBhbG9uZyBhbnkgcGF0aC4mbmJzcDsgVGhlIGhlYWRlbmQg aXMgYSBub2RlIHdoZXJlIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtpbnN0cnVjdGlvbnMgZm9yIHNv dXJjZSByb3V0aW5nIChpLmUuIHNlZ21lbnRzKSBhcmUgaW5zdGFudGlhdGVkIGludG88YnI+DQom bmJzcDsgJm5ic3A7dGhlIHBhY2tldCBhbmQgaGVuY2UgYmVjb21lcyB0aGUgc3RhcnRpbmcgbm9k ZSBmb3IgYSBzcGVjaWZpYyBzZWdtZW50PGJyPg0KJm5ic3A7ICZuYnNwO3JvdXRpbmcgcGF0aC4m bmJzcDsgSW50ZXJtZWRpYXRlIHBlci1wYXRoIHN0YXRlcyBhcmUgZWxpbWluYXRlZCB0aGFua3Mg dG88YnI+DQombmJzcDsgJm5ic3A7c291cmNlIHJvdXRpbmcuPGJyPg0KPGJyPg0KV291bGQgJnF1 b3Q7d3JpdHRlbiZxdW90OyBiZSBiZXR0ZXIgdGhhbiAmcXVvdDtpbnN0YW50aWF0ZWQmcXVvdDs/ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KS1QmZ3Q7 IEFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhl IGhlYWRlbmQgbm9kZSBpcyBzYWlkIHRvIHN0ZWVyIGEgZmxvdyBpbnRvIGEgU2VnbWVudCBSb3V0 aW5nPGJyPg0KJm5ic3A7ICZuYnNwO1BvbGljeSAoU1IgUG9saWN5KS4mbmJzcDsgW1JGQzg0MDJd IGludHJvZHVjZXMgdGhlIFNSIFBvbGljeSBjb25zdHJ1Y3QgYW5kPGJyPg0KJm5ic3A7ICZuYnNw O3Byb3ZpZGVzIGFuIG92ZXJ2aWV3IG9mIGhvdyBpdCBpcyBsZXZlcmFnZWQgZm9yIFNlZ21lbnQg Um91dGluZyB1c2UtPGJyPg0KJm5ic3A7ICZuYnNwO2Nhc2VzLjxicj4NCjxicj4NCkkgd2FzIHNs aWdodGx5IGNvbmZ1c2VzIGFzIHdoZXJlIFNSIHBvbGljeSBpcyBhY3R1YWxseSBkZWZpbmVkLiZu YnNwOyBNeTxicj4NCmludGVycHJldGF0aW9uIGlzIHRoYXQgdGhlIGJhc2UgZGVmaW5pdGlvbiBp cyBpbiBSRkM4NDAyLCBidXQgdGhhdCBkZWZpbml0aW9uPGJyPg0KaXMgYmVpbmcgZXhwbGFpbmVk IGluIG1vcmUgZGV0YWlsIGluIHRoaXMgZG9jdW1lbnQuJm5ic3A7IElzIHRoYXQgY29ycmVjdD8m bmJzcDsgSWYgc28sPGJyPg0KcG9zc2libHkgYWRkaW5nIGEgc2VudGVuY2UgaGVyZSB0byBtYWtl IHRoYXQgY2xlYXIgbWF5IGJlIGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDo3Mi4wcHQiPg0KS1QmZ3Q7IFllcywgdGhhdCBpcyBjb3JyZWN0LiBUaGUgaW50 cm9kdWN0aW9uIGRvZXMgc2F5IHRoYXQgUkZDODQwMiBpbnRyb2R1Y2VzIHRoZSBTUiBQb2xpY3kg Y29uc3RydWN0IChwYXJhIDIpIGFuZCB0aGF0IHRoaXMgZG9jdW1lbnQgZGV0YWlscyBpdCAocGFy YSA0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCk9rYXkuJm5ic3A7IEl0IHdvdWxkIGJl IG5pY2UgaWYgdGhlIHRleHQgaW4gcGFyYWdyYXBoIDIgYW5kIDQgY291bGQgYmUgbW9yZSBjbG9z ZWx5IGFsaWduZWQsIGJ1dCBJIGRvbuKAmXQgYWN0dWFsbHkgc2VlIGFuIGVhc3kvY2xlYW4gd2F5 IG9mIGRvaW5nIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ S1QyJmd0OyBXZSdsbCB3b3JrIG9uIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8YnI+DQoyLjkuJm5ic3A7IEFjdGl2ZSBDYW5kaWRhdGUg UGF0aDxicj4NCjxicj4NCkkgZm91bmQgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBwYXRoIHNlbGVj dGlvbiB0byBiZSBzb21ld2hhdCBjb25mdXNpbmcuJm5ic3A7IEk8YnI+DQp3b3VsZCBzdWdnZXN0 IHRoaXMgbWlnaHQgYmUgY2xlYXJlciBpZiBpdCBqdXN0IGdhdmUgdGhlIGZ1bGwgbGlzdCBvZiBw YXRoPGJyPg0Kc2VsZWN0aW9uLCByYXRoZXIgdGhhbiB0cmVhdGluZyB0aGUgcHJlZmVyZW5jZSBh cyBhIHNwZWNpYWwgY2FzZSBhbmQgbGlzdGluZzxicj4NCnRoZSByZXN0IG9mIHRpZS1icmVha2Vy cy48YnI+DQo8YnI+DQpFLmcuLDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsxLiZuYnNwOyBIaWdo ZXIgdmFsdWUgb2YgcHJlZmVyZW5jZSBpcyBzZWxlY3RlZC48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7Mi4mbmJzcDsgSGlnaGVyIHZhbHVlIG9mIFByb3RvY29sLU9yaWdpbiBpcyBzZWxlY3RlZC48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7My4mbmJzcDsgSWYgc3BlY2lmaWVkIGJ5IGNvbmZpZ3Vy YXRpb24sIHByZWZlciB0aGUgZXhpc3RpbmcgaW5zdGFsbGVkPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cGF0aC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7NC4mbmJzcDsgTG93ZXIg dmFsdWUgb2Ygb3JpZ2luYXRvciBpcyBzZWxlY3RlZC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 NS4mbmJzcDsgRmluYWxseSwgdGhlIGhpZ2hlciB2YWx1ZSBvZiBkaXNjcmltaW5hdG9yIGlzIHNl bGVjdGVkLjxicj4NCjxicj4NClRoZSBwYXJhZ3JhcGhzIGFib3ZlIHRoaXMgbGlzdCB3b3VsZCBu ZWVkIHRvIGJlIGNoYW5nZWQgc2xpZ2h0bHksIGJ1dCB0aGU8YnI+DQpwYXJhZ3JhcGhzIGJlbG93 IHdvdWxkIHRoZW4gYmUgZWFzaWVyIHRvIHJlYWQvdW5kZXJzdGFuZCAoYXQgbGVhc3QgdG8gbWUp LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCktUJmd0 OyBUaGUgbW90aXZhdGlvbiBmb3IgdGhlIGN1cnJlbnQgdGV4dCBpcyB0aGF0IHByZWZlcmVuY2Ug aXMgdGhlIHByaW1hcnkgcGFyYW1ldGVyICh3ZSBjYW4gY2xhcmlmeSB0aGlzIGluIHRoZSB0ZXh0 KSBpbiBkZXRlcm1pbmluZyB0aGUgb3JkZXIgb2Ygc2VsZWN0aW9uIG9mIGFjdGl2ZSBjYW5kaWRh dGUgcGF0aC4gVGhlIG90aGVyIHBhcmFtZXRlcnMgYXJlIGNvbWluZyBmcm9tIHRoZSBpZGVudGlm aWVycyBvZiB0aGUgY2FuZGlkYXRlIHBhdGgNCiBhbmQgYXJlIGhlbmNlIGNhbGxlZCB0aWUtYnJl YWtlcnMgaW4gdGhlIGV2ZW50IG9mIGhhdmluZyB0aGUgc2FtZSBwcmVmZXJlbmNlIChmb3IgYW55 IHJlYXNvbiB3aGF0c29ldmVyKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCk9rYXkuJm5ic3A7IEl0IHdhcyB0aGlz IHBhcmFncmFwaCB0aGF0IGluaXRpYWxseSB0aHJldyBtZSAocmVsYXRpdmUgdG8gdGhlIGxpc3Qp OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw dCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45 cHQ7bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIHBy ZWZlcmVuY2UsIGJlaW5nIHRoZSBmaXJzdCB0aWVicmVha2VyLCBhbGxvd3MgYW4gb3BlcmF0b3Ig dG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDozNi4w cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5mbHVlbmNlIHNlbGVj dGlvbiBhY3Jvc3MgcGF0aHMgdGh1cyBhbGxvd2luZyBwcm92aXNpb25pbmcgb2Y8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3Vu ZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGlwbGUgcGF0aCBvcHRpb25zLCBlLmcu LCBDUDEgaXMgcHJlZmVycmVkIGFuZCBpZiBpdCBiZWNvbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludmFsaWQgdGhlbiBmYWxsYmFjayB0byBDUDIgYW5kIHNvIG9u LiZuYnNwOyBTaW5jZSBwcmVmZXJlbmNlIHdvcmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGFjcm9zcyBwcm90b2NvbCBzb3VyY2VzLCBpdCBhbHNvIGVuYWJsZXMgKHdo ZXJlIG5lY2Vzc2FyeSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJn aW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vs ZWN0aXZlIG92ZXJyaWRlIG9mIHRoZSBkZWZhdWx0IFByb3RvY29sLU9yaWdpbiBwcmVmZXJlbmNl LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0OjM2LjBw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlLmcuLCB0byBwcmVmZXIg YSBwYXRoIHNpZ25hbGVkIHZpYSBCR1AgU1IgUG9saWN5IG92ZXIgd2hhdCBpczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5k OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25maWd1cmVkLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KUGVyaGFwcyB0aGlzIHRleHQgc2hvdWxkbuKAmXQgcmVmZXIgdG8gcHJlZmVy ZW5jZSBiZWluZyBhIHRpZS1icmVha2VyLCBhbmQgcGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIg dG8gbGlzdCBpdCBiZWZvcmUgdGhlIFByb3RvY29sLU9yaWdpbiBwYXJhZ3JhcGg/Jm5ic3A7IEku ZS4sIEkgY291bGRu4oCZdCBmaWd1cmUgb3V0IHdoeSBzb21ldGhpbmcgbG93ZXIgaW4gdGhlIGxp c3Qgd291bGQgYmUgYWJsZSB0byBvdmVycmlkZSB0aGUgUHJvdG9jb2wtT3JpZ2luLA0KIHRoYXQg aXMgaGlnaGVyIGluIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPktUMiZndDsgQWNrJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8YnI+DQo0LiZuYnNwOyBTZWdtZW50 IFR5cGVzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0Jhc2VkIG9uIHRoZSBkZXNpcmVkIGRhdGFw bGFuZSwgZWl0aGVyIHRoZSBNUExTIGxhYmVsIHN0YWNrIG9yIHRoZTxicj4NCiZuYnNwOyAmbmJz cDtTUnY2IFNlZ21lbnQgUm91dGluZyBIZWFkZXIgW1JGQzg3NTRdIGlzIGJ1aWx0IGZyb20gdGhl IFNlZ21lbnQtTGlzdC48YnI+DQo8YnI+DQpBIGNvdXBsZSBvZiB0aGUgdHlwZXMsIGkuZS4sIHRo ZSBJUHY0IHJlbGF0ZWQgRSBhbmQgRiwgZG9uJ3Qgb2J2aW91c2x5IGFwcGVhcjxicj4NCnRvIGJl IGVpdGhlciBNUExTIG9yIFNSdjYuJm5ic3A7IEhlbmNlIGRvZXMgdGhlIGZpcnN0IHNlbnRlbmNl IG5lZWQgdG8gYmUgZXhwYW5kZWQ8YnI+DQp0byBjb3ZlciB0aGVzZSB0eXBlcz88bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpLVCZndDsgVGhlc2UgYXJl IG9ubHkgcmVsZXZhbnQvYXBwbGljYWJsZSBmb3IgU1ItTVBMUy4gV2UgY2FuIGRvIC0gcy9sYWJl bC9TUi1NUExTIGxhYmVsIC0gdG8gbWFrZSB0aGlzIG1vcmUgZXhwbGljaXQuJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQpBaCwgb2theS4mbmJzcDsgSWYgeW91IG1ha2UgdGhpcyBtb3JlIGV4cGxpY2l0IHRo ZW4gZG9pbmcgaXQgaW4gdGhlIGluZGl2aWR1YWwgdHlwZXMgbWlnaHQgYmUgdXNlZnVsLiZuYnNw OyBPciBldmVuIG1vcmUgZXhwbGljaXQgd291bGQgYmUgdG8gbGlzdCB0aGUgdHlwZXMgdGhhdCBh cmUgcmVsZXZhbnQgdG8gU1ItTVBMUyBhbmQgdGhvc2Ugd2hpY2ggYXJlIHJlbGV2YW50IHRvIFNS djYuJm5ic3A7IEJ1dCBJ4oCZbGwgbGVhdmUgdGhpcyB0byB5b3VyIGRpc2NyZXRpb24uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+S1QyJmd0OyBXZSB3aWxsIGdvIHdp dGggdGhlIGV4cGxpY2l0IHRleHQgZm9yIHR5cGUgRSAmYW1wOyBGIHRvIGFsaWduIHdpdGggb3Ro ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5U aGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LZXRhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NClRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KUm9iPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBw dCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpL ZXRhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQ7bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxicj4NClJlZ2FyZHMsPGJyPg0KUm9iPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_BY5PR11MB419671083B8D2E3F3E2BF8DBB5349BY5PR11MB4196namp_-- From nobody Tue Feb 15 12:18:48 2022 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 A9D043A0AE2; Tue, 15 Feb 2022 12:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.088 X-Spam-Level: X-Spam-Status: No, score=-7.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] 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 mKCNAcNQc_be; Tue, 15 Feb 2022 12:18:40 -0800 (PST) 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 371963A0ABC; Tue, 15 Feb 2022 12:18:37 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id qx21so6944801ejb.13; Tue, 15 Feb 2022 12:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=dau+J8l4Y7lbJRTGCFBPnzzftRnybckJX68G2vYazSA=; b=Oo3duFCI/j3BiJLlP3jHMY7rcWfkQOh4vNa1HbAT8rj7YEZtc7HKhiTsNrk7zDDXa6 kNkKJEI1uGlgHGzjVT9QXfjtE8DrolfPU/6M2bjbv0JiKvSW0RCeo3xUYmrOGAaw96qU n9WwdsyZuT5o7f++jTUoEy/DWrjcJvFgL7P6Q4tMqmm80VHNv/OeF8Dp9kXfWDe9TOt7 03HhuoAPnSlGnVlF4xWaejIXC/jmsuolbtiQcaTrPCj54jIdSP4TF1fTWDBf/eKiSif1 8btDo1uj7TsrGeQHu7S6mjPwYYkxmh6QGnIlJMPAQ+3ZXpeK7TXowwaLfo4cQ1O6OPoo KL1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=dau+J8l4Y7lbJRTGCFBPnzzftRnybckJX68G2vYazSA=; b=uWcG0PV8br8ey4zJZ6+SpN3Wh69dUJoIWFBOLfkbkqAyAxETKu9ScoXlJVVGGzr+f9 aL8ZyNqsH3LjLuKW/YjQlbWrtbHQw+Ht4W4/z/0B0kn35q3/Hm4XR9/0yA1O2D/BAzKZ PvflsjpReeck+ANhgp50Rk/yD6E99GHgN5CViXEcDfU61NnrK3zeS+HY40aCmc6XNjD1 u8AmyF4r3z0b7WhBy9MbG3kgdWzev+HATeTtnZglRUQHtaurooAGadeTxRLOH09lgdiO 3RAm1zvmmz3LpCuP1QROi3pxukm8DxCaFNtk48nVP5i0btfFq2oCl6ej+JYiKdcGPHJq zsWA== X-Gm-Message-State: AOAM531Cx293/26naxznYTKu2xeF1UeL7RagdIwhLj2x/zZJ5mcnHbC6 kLbLAVe544O7UNVZZs9ZPmC7U4wWnCfOtwRr+y8beOUk X-Google-Smtp-Source: ABdhPJwlnW/WkrDfitgu2D8OYidV0Iwyhdaa//rk2owiLIT8SsjxU5cDpmZ+6eHbF+GmDPPtKDw3ODHL97hvs9CqDvw= X-Received: by 2002:a17:907:1b0b:: with SMTP id mp11mr651912ejc.382.1644956313162; Tue, 15 Feb 2022 12:18:33 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Tue, 15 Feb 2022 12:18:22 -0800 Message-ID: To: draft-bocci-mpls-miad-adi-requirements@ietf.org Cc: mpls , spring , DetNet WG Content-Type: multipart/mixed; boundary="000000000000b7c18805d8143cdf" Archived-At: Subject: [spring] Comments on draft-bocci-mpls-miad-adi-requirements 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, 15 Feb 2022 20:18:44 -0000 --000000000000b7c18805d8143cdf Content-Type: multipart/alternative; boundary="000000000000b7c18405d8143cdd" --000000000000b7c18405d8143cdd Content-Type: text/plain; charset="UTF-8" Hi Stewart and Matthew, thank you for organizing this document in a very clear and concise manner. I enjoyed reading it. Attached, please find a copy of the draft with my notes, comments, and suggestions. The most important, in my view, the question I have Should we add the requirement to have a common format for ancillary data defined? Looking forward to your feedback. Regards, Greg --000000000000b7c18405d8143cdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stewart and Matthew,
thank you for organizing this = document in a very clear and=C2=A0concise manner. I enjoyed reading it.
Attached, please find a copy of the draft with my notes, comments, a= nd suggestions. The most important, in my view, the question I have Should = we add the requirement to have a common format for ancillary data defined?<= /div>

Looking forward to your feedback.

Regards,
Greg
--000000000000b7c18405d8143cdd-- --000000000000b7c18805d8143cdf Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-bocci-mpls-miad-adi-requirements-01+GregM.docx" Content-Disposition: attachment; filename="draft-bocci-mpls-miad-adi-requirements-01+GregM.docx" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzokhe8e0 UEsDBBQABgAIAAAAIQAzN19eowEAAFkIAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lk9P4zAQxe9IfIfIV9S47AGhVVMOC0h7ASS60l6NPWkt/E+eKdBvzyRpoxUqpLvdXCIlM/Pez0+x k9nVm3fFC2S0MVTivJyKAoKOxoZlJX4tbieXokBSwSgXA1RiAyiu5qcns8UmARY8HbASK6L0XUrU K/AKy5ggcKWO2Svi27yUSelntQT5bTq9kDoGgkATajTEfHYNtVo7Km7e+HFHksGhKH50jY1XJVRK zmpFXJcvwXxwmWwdSp5se3BlE55xg5B7HZrK5wbbuXuOJlsDxYPKdKc8d8nXmI00Ua89T5Zfy+zh jHVtNfTzjVrKUQMiZ+5d2Ve8smHHv49Dr5Gi/+2dtAT+IceE50fj9KKNHmSy0Gf4aRZIGwf4/5Po dIftgYgHxgDYKg8ivMLT42gUf4gPgujoG5ERKHbKByO0W82AGQ9l53Aw0k8zYjAs/nfZoH1yMHI6 rccgVs32CzUKTS89CJEgpjEIOt1Be+JPF3TX40/RVuYrS+5sD2x+I/I/rHn3rWumJ+mgk7p3ZOmj 1wfbnbfHW7Y/BvN3AAAA//8DAFBLAwQUAAYACAAAACEAHpEat+8AAABOAgAACwAIAl9yZWxzLy5y ZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAKySwWrDMAxA74P9g9G9UdrBGKNOL2PQ2xjZBwhbSUwT29hq1/79PNjYAl3pYUfL 0tOT0HpznEZ14JRd8BqWVQ2KvQnW+V7DW/u8eACVhbylMXjWcOIMm+b2Zv3KI0kpyoOLWRWKzxoG kfiImM3AE+UqRPblpwtpIinP1GMks6OecVXX95h+M6CZMdXWakhbeweqPUW+hh26zhl+CmY/sZcz LZCPwt6yXcRU6pO4Mo1qKfUsGmwwLyWckWKsChrwvNHqeqO/p8WJhSwJoQmJL/t8ZlwSWv7niuYZ PzbvIVm0X+FvG5xdQfMBAAD//wMAUEsDBBQABgAIAAAAIQBgrxfHji0AAMO3AgARAAAAd29yZC9k b2N1bWVudC54bWzsXWtTGz2W/r5V+x9UfNiBLWww18BO2HKAJExBwmLempp9Kx/kbtnW0pZ6pG4c 76/fcyR1u7u5BDIbpHdKpCr4KtT9nLvO5c//+X2ekXumNJfi/dqgv71GmEhkysX0/dpvtx9779aI LqhIaSYFe7+2ZHrtP0/+9V/+vDhOZVLOmSgILCH08SJP3q/NiiI/3trSyYzNqe7PeaKklpOin8j5 lpxMeMK2FlKlWzvbg23zKFcyYVrD3zul4p7qNbdc8v1lq6WKLuDLuODeVjKjqmDfV2sMXr3I/tbR 1ruHC+38xEJwhTuDh0vtvnqpgy3c1YOF9n5qIdjVg5X2f26lRy7u4OdW2nm40uHPrbT7cKV3P7fS A3KaPyRwmTMBb06kmtMCnqrp1pyquzLvwcI5LfiYZ7xYwprbB9UylIu7n9gRfKteYb6bvnqFw625 TFm2m1aryPdrpRLH7vu9+vu49WP7ffer+oZ6yfXbr5w54WCufEuxDO6FFHrG85rD5z+7Grw5qxa5 f+4i7udZ9blFPnghuzwlns7srVwt+JLtu/s/z+zOn19xsP0CRHCJ+hsv2UL7b1Y7mQMVrv7wT92a xs0dvFCAVAvsPFjgIGEvFPjVGu/cGlvJikNxHf5C1qjWsajgOnx1YwcvlGPdzTQW0GmRzl61yk51 X7fwu7SgM6prQscV2es2tV8vt5w37lE+/ccY4ZOSZb5ajf9jq12sxNoCDYxXrOUYqsnk+h/bzGhG c5B28+T4YiqkouMMdgTsQYDCiUEA/wdCwV/mIftuXkesCcqYtROwjMYyXeLvHN7bO86pohdAlLs7 2x/Pjo4Ga+ZV0CsFvnrofuDVY7DC0pv3a9vup37pWuGLHw8OgXPqF8/YhJZZge8cHQ7emXXNO9eN D5tdXCvza1QsM9j/8T3N3q9dZyAAbmEPa1v4prKfUR+lKDR8huqEA7CnslScKfKFLXD12VDoh68m uv0SLLjlVtxyfx1/uxvyz3uR8PTRa/mFf3pxXJxcXV+OyF+lugP6JYY3yat+rvrkg0wSjosWdukI 2K8E7EIUTAlW9ED/T4ofA/TIzxd5x2kE7A0BEylL0REuSn1MLoQ1sMCipdkPwRoBg6klFUUE7G0A Q2vgWOc0AeWdK6aZumdrJ+ffcw5PjslfymxJdt5tErC4dho4teAJaedtcvpNcBOvKZZETsioVIot yf6ni9NIXuGA9PKfv1BRUgUEuWcJMqLoG8Ub9vcSJAXGGzQBQU+MhXVJxywjo4ImdyD/U57QQipN qEjJUCQ8yxDEM3DaIoABsWGKJlZvLMG+7c3zDGMqNO3RlPdUA+Xe9iCi9kbG1HCsC0WTaAz5ZpMW ALCKnCMv3FAxZSDlVAErYyht290bH7RyO+ts0ssuuLZihOicJXzCmSZN4WFUBF9pBC5IMWNWaWSo NCKle6Z0bZR2IYku81wCZb+Q9Af+SP/xa6G1oYHRYSAzWhD2nWv44y+8pJ3QLgn4Qy6e2/05GFiP 7x13frA3ODq1Qddq5y26P3UrsQlTTCTMLdG6utsZMPL7tTkXUn3GC6uv8OE7rUuqtlkt3tynV4mF 8seIHkv6L7q7XTkf6t01+3z+Urp8G+qlmH16JZR+1E2eddPtDMyLhVR3BH4j3+ZKpmVSYGwHn16c 3360tsTXnAlyxjSfCnLL6Dxi5xu7VqCAKkZSpvg9S8lEyTmhRJTzMawISAq2QGBzqWmmO+I4oEtC S5amKTepGpG8PJMXGKxtR2JlyNIMrSaAa0EVpuoRAE7ChxVSmTvLjvh5xi8FbxHTKjUiNmZkTlO2 SRg3OI2XICAKReHvFYhewRRYD7RAMC9HN5tkTDVLI4aeMZSC0DzP0LcHJBtu15wuEVNw9gE868Qg s45lUYDsd8o7uv/BuP/RWnorn2JkDsmRBYxte8XmMt77ELyMTt4JvKLL8ZwXBVisIMcmZZaRRNrU BuOkgqZCMRbR84we2HT3zpIArvpwek0O3xE8eDQPj6Jo8w1Qm7OsL4g+PRpzVZWMwc549O7D5FxM uWBMRVs9AAFJ9R35KBWIvXUMuWz0McmuYNbYs67VFHMrtbH8wIuXJOW6UHxcFlFC+oavy2wtQPzs 9QTEQFfn6j6qYvALgHJQHCSYvCWK1aciIXkmJCfAwTYCtsdKAn28tYVeH+Ys3DHV56yYVJU98Mkt B+FWVMIhKmF7br9SwXCXeGrDnCDHv/N5aXx1zb+TOex0FoOevlFEs9bFVsocGI+lm0SxPINPwiMM c461zBj6LOOlU8wrfGkIkv+Ja6NiGanLM3UVfM5AB18Y75cLmuOhjOIUDT1JSr2yzmspgsk+7tg2 wucZvjkABWhlJmAuScKNgc7mTg6ArS4QsDV7nirQcZ7C93V/LUIXYARqwbOMMFOWgYH2Vl1GtKfe yk85lflS8emsQIeXRynnnVVWgKwnG7ZIyWSB3KoS3EY0kEyeCFMaI4Ltuk1PNJSC9YWZsSmK3xgy 9k9DdW8eWhYzqTDwMARha8gKLRrzyTQK2SDUYg2WPZL5H5YUaN40Av11JpiRAX/S5JJNaTxZ9o3e 9epg5sZ0uBFTBM4gVbWsiSEF3yitV3G8ApmHsVUMLwNzR2jW42IiN9BhYJMJMp+0JRwYfiByEgH0 DGBejusMHHOIFoTNs5LboFyvM0Y1A8V6z5nJBIIndVgqEpBnAkqoYpjesNx09umSpEwnio8ZWcJy lV2Eqha+VyiemBRYmwIBr+QsFiy+GWOZbjTk3+g8/w/XOKOq5sUf18bhyS4O9uf3azplZPAtgvYm oI3xbxbLHBkPbnz1Zrzlv+6WZ1QXN9iWRrEUif2DYvTOXO1zHYauLoZnZHh20a5daP78pd3AwJMM cD0xtmM/DO/K05QhNLzUPkaoUgb/zXMpDP3AncGS/qrypfVxMgejO4LoGUQukqwE0EZ8nmc2Uvdh dEYurQNECrgtaBpVVpFJCB0xYwWRvX70gkLgQ/BIbQjYBH+awQe0WzHdwSSKYqMytFtlWZAFVQrs pyVgG/HzjF+LtxDMNi8GoHWf2LoTEv1IQW9k/Nxi31mMdJxK7DwYAwjeeXeASSOisKXZqBNJ/5X/ CImWrG8UEUdE8tbUWspMTpcRxT8kijsAxQea3GFKPtg+r0ZxN6LoGUVEsAWCn/2dtOIgl1RMSwwc vpyS9iIleaakXYDB9Ehot+EkdZPOTqwrohimVN81uvkTE0yBd/sjzB5DcT+i6BnFPbSTh1+G6LnA ngBJe472AK0ARP8TF/E0eb2L5OWZvPYBhhFL4HvF8ockFlEMFMUDgGGY3Am5yFg6fY2IjyiGg+Jh HxugucqYV+IXUQzH7Drst3uf+9ngSR/r7c1MlXv2arqKlBQGJaFTX8/GeTWOEUX/KA5tucCfyDBN sXLu9ZKdkKOI4hsJze6xRLzxntnndgbyzpRx8KngE55g8iJv4+KJVgqGma149pyye5bJ3BQrVP1F TWPDPKMCC6EjGXkmI2qFr4GnNWpCTl7a6H/X3TcfpCbYotk1s9vw+PGm7d0N43YHR7tH5+3ttojE R9N2s0+vnNw3ckazp+9x5Nm359limQMWWbasONZwr8m7wyQtZN3O+I7moJgcuwsV/YiidwWOqauI jmtCA5wvMaPOtW12mDXbcTf7/0b8POPXUTVe5PMjPaBdD+ImfdlxD2JFWGCgJSzHJGoqYuNv34Tk +ui7plNazplrMtNoul81eDdY0jsAcwzSX5aAZNTHgQBYeTlOwdr+i11FrNHith3FrNI2XYMihJ4h NHMQXPsDAQr5jmnTowsk65wlMyq4nmuCWdToHoUg+l1bOiqsPJ+zFHuLRUIKyyp4ymfe8+gzS/XM JldecneLuMEQvWSzT5+s+AQtMCPZUbJ0bjfHam+z9X1c3LbNeb/2SbGpBD1xxZW+W+I72BTi/RpW Jva2d3qDvdvBwfHeu+Pt7f+2V/QDZH4B6TxQVHAtgd1200X7hVx44I8LH989bDTPcOrrizi0u/1Q OdTs06uyrOZL2AgIzjsiVCUzXrCkKBVaadEN8m5FSyxA4iauxQtT6cuEKTrcdDWlaGCvj8uCCFmQ jM852kCF3CC/33w83d3eHXzbjCh6RtFBsfNt0zw8ODza/taPqPwxrNJDj1apDVf9/PDzziV6uYY4 gc07pT8YwG4bZL36jLDLCqHaVmafXok+Sve3utMPSkrjnfcsbSTplIId24Iw1WjR2Tl4tQ5qNXci Dl71DyKeqEtCbT9OROv5Ycf2tA0wtHhGlyMA/NzJJrX4XZ7fIHCXo5vWMWg1R3eet800P5dzwhNe kHXej91OQqCgBP4aXH3P+R7Jxmadj4HBo0eSMda56NlHSF0bUQ4EgCIV6RZO3JoUDGe0PDoku4Iv l7poAhjZ8G0AfK6b5P9fP9ad2I/1beCM/VhD4qDHheMTTVoDsIKeFOYv6R4bO7cGA5fE6qDeyGhT 6wcPhUt5aphPVay2VsKrc52Y0RqEAWUyCh1E1TSYlQ3lLCd8sSM7njpReOfuYzCXaS/tmd2vQsDd vePOQwwBm336FOKr4/VRb8xjB+YA+FizIjo0IWjFa/QyH9WLY7aUTsJejs6NmuyIpYCuxTL3B14g ZW2ScRm5PAAuH7OJdNVfE650QWRSsKKKdpTwWZLTZSZpWgdCq1b5qWQx6zwACDGVCV+zE4IWM2ZP G9qxKfxEwlKmMaw9kVkmF9iJPZ7/hWAxV8dDhUwk+jWqtDmFukxmOOiAmtiygvcWUqWIINVaJpit H8/+AgAQqzsE+AQzRlP48vrw9HM0nTwD07r9YZHMgyN/sur+uj48u9gAE6+z/VXC/xH+3dcl/O/v P57wf7S7t7+3/YtvwonoMkJ4Cf91SmA3IzBm44UgXl1CHiZMdGoh2XeuC5fHCaapTacAQ/WiIFfD vxGa6dgeJgAAHX9ZN6M6HsceFKY6El9s4xp15xuBdtIdThBvvGduua20T6u4CHt0uYx2M5DpdyyR 6JgIXugHK2YIRvndMC/wVSIJeSahutrclDs0MhGtesROHsDrU/AsiWAFeJR39QQ2WywBn40gegaR CizMp9lSc9NIDZWky/518bg/6Rq+jC5hded9jmNMxzd4zXYKREgUi+uX5tRwBJwGch2Y8cZ2XiE9 TDLVG6CFP2InWhz7HfHzjp+ZoY7NcjDjV4oM/kuS0qQHixD0rmN81/vFnqdbCsMm9a6tD+lFSvJM SZfnNxsYkndHLE6CYwsfjU1XTfEx6OGGkkYNDPfNHM4nGY2NfbxjuP7x/DSGc73DYLyiEnt861qJ YhuGFOQzsJDNyslLPbOvNNgNWQw+z+5jfphvENlkwhOOp8cNkWeyxBTFtwgTUy4YQx8Ezd6JPafE 064Q1K45cXuYZxEp6e0pCfkbBDPYzX+dcbgnUnGgHNP6o0ShgL7vxXVFV5tWfMyoJmPW6b4W0fMg B7AzC1ZGNcrscwl+U6+QPfNgc/V8DjeZm2coKiJ2vuNLNRwdcGwYYsfIc/t4l+DXeMJ0H888ibzH p2wRMfSMoYsoueEKJp0LXjIyEs/RbDAXQ80RKa9ItW5/WDT0+0XvrD82FXa9eZ7pHhBTL1d8zlRs 1+SdwYdElPMxfAc7+Tc614AJdM8IA5CmaMnOeDJzUX/MIb7RqJCxd20E0DOAP+ggUXXz1isfuBG1 tOI9YugZw8fOZ7od2leZD7yaRWewjAAGAGAjJ5cGEYC4w5YSNNdlZiIRKWM5q7PW6vQnsLQZVeAJ s+8U+41HOgrB3AbDekE1mZqZ8ZWYphiTmK1OeM3RbnWUC7rYdXhCdRBR9IyigWZMMxTZqJbBmSXn fy9pRk6lLsiV8YRpMSPr56dX1xumgRAXd2Q4nSo2NZBHDD1j+EnJMifrl8NPG6CevxdkJnMMTpjS Jt6wpqjAsHM5zx/AFtQVmazYaCqEZuvVhgOQ1MV1351eofhvRj7pveS2fFOwWMnjHUI8Mqh8YDCr 0Bq3alvmlcbmk64WQEwRPZylgrIjoujb1qqMYWtKYTAaPOMCLCo7jgeTeR7rJLIJb8c2ImFgeI7V jvnSpTRttZ+Hq4xXZVy/V43rXYiNYhK3gM/Fik3/1LXq8QmK+auNwjRDpKt8rVYip1ENmA8YlXUA IIKOdgFPI+JdaBT8aZf0Y034y9G16xDFyNfh1aZjx4TaCW0RRc8oGo3cGpBnat6R92yCNBlmIDSd IkCpaiaDoGsd9bR/+D61IfCzuxPBFE/IsG6JQE5dPb6lmvVPw0s74Gd//93BNys56oJEU1QaCelN oHqbvq27sW/r28AZ+7YGxUFPtGglsRPqH0yrNqerO2tWz2SZpXgaBIZuCDrXjhsnmUww5Rb8qBGL 5phvwnkuJctEN1NWUJ4hbhxbvU1ch6mG89uPIHoG8dZEH0yaFqaqY5V2nckl2AIFQC41zew0u5lc kAcD4iOGnjFMqFKuVYNt5iBSgxQOJTUfxOo+PHB0fog5DTIxqRHOnYn4ecavGrx9frNpuMzk0YSg dgGfC9HTvCgxnGXoamQz7MnHUtjkP/B+uYg9HPxT0fro4ykW9g9Bzc7nKJ9tmo82VpwT4iAFsLkj 3KaYbx+6DbUJDFfXsCCYGL5MKNakxqqJsFBcdbgHzWr83xqrb32HspZiajE2SRmYTt2zmXcxguQb QCsxObJWCHrXJmzbJE2udQnbMhMLTANCzBrQMivt6SHm9aQp2g+RiDwTkdW1AmR163x3Xcgq9G/S e1YdzRVdaJdAEsHzDF5rcLvJ4lnxHfYqYyKVymTs0FVPyYoNyUTJeYQwBFvqGS27cRwh8h9tAhG5 0l6KYa8rQRgPQe2a3BzUueOSZ0WPC5Oz3auyayP1eKaeB42zXeGKTc8gd0IuMtOQzJlOtsDNSHPN /xdfjhD6t5Ea5UY0MVlUFiscErLqG2o7M9sOtdjTMMaZg7GRTPh4zAgdZ8bfzanSNoFRgO1b1Z3a 1Dewd0uhGMUTIN6uaYwI+pCgIA0xRdFauvTBYEEfuz1JWZ7JpfGJmLjnSgp83I/U4plahiTnLAFK ATqpXR05KfCYEIvVmBXdK65HdsdXsOohoucZPbhsRStgjEcLfxkzKBol/40WoRP+HYuKliS1tzyy n28ALwwufJ5LrTnqWkyp4NhfDm5os5WZbYqVNTkRD3sjgJ4BlKJmsLQ0phKyXCLFJISqohOeYCrA quwYzw5F1cShaiIQici3yYYq1dUQfRpebn3qDU8/N6YurDQxfIhbxxc+F/0l/9DZ3Jti01aBUoLh Y7g1FkGnmN1wzKhtfYP1pXtug9FAO6626liGrAXWERe86qdSx5jxIC5CGEBw6eE0I9sf1BZeh6B2 cbpcXeLv5DZWCLreO5GKPFMRTZS0QUnN2hIBfCapXOhyDlJgzuETHK0lE0yJHXcCQC+RiMd3XuBA I1OoO8fjd1PkYLhuzDN4syMI4FsI4Q0VUzYqKPhUdvzpYNvdQx+Com0TtDd5Dtf2xBYNkR0c7O/u tzbYIpFTt1SVtuSWaF3E7QzI+v0aELpUn3H/9YU8fKe182qfdU5Uc6ORM3412eCIxVbl1SUQTEmn McfEt2zCs6w7tjRj1TVZu/ptdLu2aX+TL1/N45vz//rt4ub8DB+PPg8vL+sH9hMRQ88YAhhff7t0 +HQEtBd2x92sqOf069XV+ZczS0DwKum8dDX82xrmFUcz0zshfb2+vfj6ZXi5Vg+UrjMDsX+PPWM1 dgt8z0bqwPvUieJjW+vz4fQ6ougZxcGeafWwMxgcfTOP3g0O97ANExOGzWzoxz4Fj2KJDgWjJoGF ZjGjyLu3QHNe0ExvInPpmVwIglGffgTmjbTXbt81qxzWVaVnWFVa9TYLQcOqljkdScO7Fd1UldWg cswlbfg81XiZukeerV+uqSyi6BlFw+XrWCq1YfQkxm47MoAXmmUTlwPYzs9XJrkzgugZRJMrzWb0 nuPQENdUvupF3OiyVrfMS0vljiojdr5NHyl0wYuysOnuZvTLOJPJHQjPMgS1WyBFuSzSthRvd6CI lOSZklAaG2pSJWaU9E3mUiqB0YWsFLRtglw3hGmMForCIAAIsc/suFayJg0QJxKsDr+sdDfFFK3u L/aDsY/IG6L4Jm0NA1AATxDrXqyWfxsAYr/FoFg79lv8J9G1HdH6ZOrBwN0cD3s/uTy/eWabjeSD 7iYN/YSYfGA26lOdnTwWyHhw8pNKYzRX5zzg/0Tr2DvHTlyvMwxkdPK9yLzURVWI4RDOS5VL22k+ ZtAHAF/NXJhKLwlP4XHlkRZSZnfc1oh3GrN7EhM48MO03bRRNDPly+b2R0ryTUmVf2wYneMkri5S JpcH5HY92A+JrG7bhEcSEUTv4apVcng/ovFGYm23P+jjBA+cRpvFA9WQGAKBsaelYDyPuWBubKTm Nld6k0wwo9o+MZqSYREqB/N6iQFAM8guougZRfODvV0V6KI8o8IE5Qu4GxWsLYg8iYHUNjLEWjhT ZWqCyGa3kYBCIKBVXSm258HSRNfiwY6bxcIXemcO3xdUmTPDlCXcVMBFAEMAkI6xW2E1l66PJd3L VfMOY57O4R5hB2hX4oTNoZkqMIUmNsgKA0RUxv0IhWcosJCmxT4mfGCZphXFqwo44FVdKJ7EEenB cFILBT8bPJlapweN5yotsVWg/LudMzn4trkaORm53zf5YGbyI8oTPmKmwNpUNy4S03jHBOhGmOkC zu21jf9GBEMQAGYop80YRchW9i2wIh63IqDYQ8nloLqODxjVj/gF4ZBUdfbGDWmNphpdX7r2CYgu OitmuFEUnb6B2wtB66L4HtWGWxWXr3qWJtIE5V00Ani/tuHkGAQ+K6L4DoL9W0cnjZTyyOS+4dm3 9pFJPHqQk71ipzFm/Wb8HlOaTEzJdnOOJ5oBMRlmnCQ0N7IRdGsjOZvbnAaDVZyeEARY/15zXYPH EhwYFILWLWRuBr0W2OUKLbMGu1clAZGOQqAj+Ckx0xSgqsrvgKbs5Bt4WpohcygZ6jbvTOFABRIL bkLBL+U6l9o1I6w6ymHSiRHbZ413uUiyMgX2G8tiFvELBL+GojV8NxVSwZN+BCgQRdvRqE+mau+4 mxTMNfx1xmzqWdX4EtUxDg2VeY52uBn6HYK9UNsw1h2vvYjIAqHoGPTm6gbUbhLPA4/BmgZ2Ol5D K0UUA0GxaR08Zxp0VFLELxD8HjcN2hqpUZXT1Ud4IcPh4enRXutC/FflmI1G8vJFXgcYw3upkbPr z8g5OcUTniqGX9A7Vg+wcYF8Q1SgiTphyCjDfBNZh7qCk671AQMoxKJnDWVDOk+dNTwpdLv8gdd3 eLaz82EYmNA1G4384IvqDl8jdPc8Ct2rRgMnhTnALLVnOCkrGFr7Lq5Ls8w4Bu4wHj8Xp2EEYjs6 e96oyo5uxJkTilEb+607v4D3VlAUFlxEDMPA0KSa2TFixg1HHgN2e6Fa6koQo5YOdvYOt1sX5V8t mY1GUvNFau9QLZm4YUdOYNgQPtihNi8ayRRxW7vf5IM0opub8VwqDGm1yrAEwqnGGZi6e9vEj5k5 pOZ7wPxtIRZB+1WgvUnTMLIfe3O9DZyxN1dQHBR7c/2TaLCjlREUgr3zqCGGRhCYPa4yN9pB4VGR +Yl20B8LtMF2HzMr21nMw7+ZogGtZcKxtsTWC1RdFqSytdRMYMQkIhgC23GBmQj2rBt7hRegkSc8 IQlVsF7V2fhydG3G82zBJ3jhcI4ABgBgAGr3if11pQBq3xLerEnMzauIZORbkmNDoyfmCSlN1sEc 1xvEzvGz7UxK262xOguMCIYgyY1lu+oP1JiZDfBedGavr2zhOBIiFAAtbHh0WJ0uuRl4zeIwLnB0 hMngcNWYFZIRRN8ghquLSbuNY2yhEaYixg462BEZA2Ap03zqmmi4fsmEibRXyB78IuvnO+cbzfTT 2IsqDCnePg2MTOWdqbAxzXNMNZN5b7zswS+y/vnD58hUkakiKD9iqj1gqo9SEWCYDjibQdRJNfJR u/FkJkwZDka1OlM7IiV5Ym8uNHbUBIGLsYZ2yiS3YzJRei+AzNAHcgLaRicvRzc/0Rbj/wAAAP// 7F3vc+I2E/5XNHzo284QAuQHSfomUxLIJb3kjkKunbub+yBsAZrYkivLcPSvf3clm2CSu9LpW6zr KB8SsImR/Ozus7tardV5rdm8Pu40W+0aWZyplIfDHpvQLNJ45rTTOjltFWcGax+++O/iLBko82ek lxGDz8xpdF4bRJSLB/ZZ1/bxpLKfUddS6BQ+Q9OA8/PalcwUZ4q8YQu8+qwr0udHg7R8CC64n19x f/Xtqhj2QG0M7x/66sWZJp/j6CxNaMDOa4liKVNzVrsg+Q+NpJgSPWMkoXrWwH/U9t/tuM09K0aN Y7Y/q/tfmogH5W+D0jpqEFJCAS4l45gJPaRiykaaKg2X5+F5rXWU36EKJnBxLRW5ubwhVAQ8iqha kpBqWieUxCyYUcHTmPCUDPu/vLsd9ntES8IEHQPMVJC7/tBLmgvqzwUc0BxMQLd3myJIIdNMxVzA TZoxsAtqUxorkba70TDdsFUkoMILkQtClFCVMoNLRMcsIqmmwePXjFhfhOQLJgyn1DlqXR+elKZU uuNX+aXYhCkmApZfojTthxmLYbAgyFLd4IxXU39+pjTXYpzFxUsDrVIHXsaAwq1MlAxYmhoEQI23 po/jCumDajPckCWgyVzgG6/MLijzugoDAyhGuEYit0zBwu3UelO0cHLdztHhVcsxtTYDrZTaGl7u q/a5j8Hnvp2QsQRbZH3akPTbfVL2bUEFQh5QLRW4IqAX5hpCe/hcMFtaTo23Wrf+oWIBC42eb0uG nerI8OWZxVmqt3SiNseOI+91O63LK8esrRlopdZ2zEiasIBPOAtBoTfur0Nybb2jlE+FJ4jKCaID BNHdMrHxPKb2+LnAEE+JDT4x2jWhao+BEUXMAsCOBgFEI4b8i4iKQmwbPDLP8U4gGMD3wT1AzaJk yudMoIZ581i5eTxB84i2bnTz9t1djyDJZkkiMV4kE6msZz1oD4xyDdr3A5PBS+tknKHCLT2EFUNY AsA53c89tsBkt2K6JFJEy+dSJsG2wx+07RJjAW8ZKrcMp2AZehg7JxEFdFYeVGoAMzbj/t3oAbGE 6JolwMcQNxBpGNrD5wrrKhnlCOplwsj3d71BnQxHv8Lvy1fwK9VU86BObvEN08EPXvWqxq7d3IhZ Cj0L2QScYGsxS9hijpdkKcDrABtcsMbUC5ETBuBPlb28bIz0S8c84hp4euIhdCL2lQuRasVoTHAl fR9CXrPYb0Pe/adw10dV7hjw1tZJp9GwrIJ8gocBRQ+iC9oHwOVrRciwL+aUqhm2X3vc0Z2OaKqH GNsoFg7olF2CKX40s9UXlzIIOPmOxsmP5FKVUyEViQUFSV376X9OOMgv+TmDqLt9Ugffst1e/4D5 +YgTI8efvEjtBKUxfidGY2Bx4MYXJ/0tr0aLbwWQr2B6r6fopKQ997fdnklcDdnvGegRLoymJc35 mYoMiwxQrbz2VO12tf9CAfZJfocqmMDFw2qB2KbLwMt48hXXE/HBDM5SzLMbTxE+h46jFzQXXEP0 4ycTHnAQLyDXrSppK5E2XLgxGaQ3bx8IDUMSS+VlyAkZMqJiwnkUHCsyoPDCanoqo0wzkC3BMMYH nml8xbqtFRVt2jaDz0mneVWebfVFRWagXgarksH2QbH6i0UUxcpcUS5MgHgw22SXeu+77/Fknm/K z46GqTckLhgStPGIla2GtWXfyjqtIZoXiyn6EejOokdBtKIwCl8f4wR+SoKlx2VwhOhuNDC1sGJr Z/a0QmeWAj0tHPBzvnCD172xYh0tydLZttshNm+ts1xqBlolAD4lWT2hH24fAbebFRqNW70W5yYy TTkuiBiiCqIsNCUlxYYNXO0ub+fwcuYCZyEuMdxAnuBaVpJECBiXwhQjmHiGxrjf94UVk5dt7TOJ xIm2r1sHbcd2lNqBukd29a11v1Wh7mM0wWgwM64ohBVem13QZhP95UWZphxzTaO3095NmXJWe81A q9Re7ylV7yn9hWYt7Xa1ntIqbCn5SSagF2zxrFikooFaRw0HVPIFNqyHl/WK7DsVhEEUPI44xr6Y Y7BLS1iTP6NzRthnnj5tfcurXsqG6oumf1NBcM79k2azd1Cac/Wm3wzUS2JlVhe36+Pqp1naAPtg bRuNIvmSHQMjVwB3gN9KMz2TMI1Xik0lxIL3XKWPSzwDUSFDv7zd3mu291qHD63Ts+bhWbP5wU71 TwTzHzCHewFVagn6tGn+YFKO4YLJYyHF3lcBOPQA/GMA2BjZrAMG0thhT5uO0OYqjwGEWSZDD0kF /IG7+Z/zRxG22v4hZoESHRk5IRTOjVNWbEszvo1H0Y18w6qc2utV5XqF28C/rFcpumemceOGdhVZ eQ+gCyqFSyNelyrXJdw4/WVdmlDw7rwueV3yUPw5FAdmJ/RTOnHVTiJPLlrNMseWRW+g9aXiEoDV zO3CL1e7odGCsdCE2KUqxnyp+skqS4WCxLUpiVz/qEfRBRSL0oLCI/U22glYvu+HDSKkZmdbL6pV +QQEdM+eVB7zn08hjt2JLSM5XZrFEbQbvhOgI3IGBlmxAKifm618dYPdAuzBTGZRSBKmZjTBdupc PBpbAWCmvpeFI+ilSxHMlBRlZXJppFlqJIquRgoHJEhV7m9+xbatrYa+9GCEk06rc+BYT1870CpB uPjBK2bVIRb2KrkV4PeCRUX3GM7Osd9FJlbbzkgKzrBp3pmn0W3etg4+st9J6IZpXY9uNH1kovCU I5mHzjl0mw99mkjlEXQBQfaZxlhJzddL4w16uNkuJUEkcYOx3Sq6vquF+hUtJwAsyvMccG58gWn1 vIrNKLobiwA2nzSH4MXsypwzhYlLY5Yz3PCneeB777mj0RsPkXnKGgJ25rF2H4fXVwdHR+1PXt8q 1zfcy455nfXGKrbgg5iQrozlqiEG+wx22zuxTuhbIMWEYxdpTiPwX8E1ja3vinp2fNo5+PSkcYUn hHrota9a+Eq33y3BOsAdsV2xfCJiU/W+MeIvJqkrfM7iyzOKZYgPQNo2FfXSw/ycTEVV/zC/nC2K 4Au5gU4mLNCkf3U/8BbGBYIYsxmdc+kfD7Ezrdhocfo32ot2fHvR3YDm24vu/Jb79qL/IpOHHuNt 902XXOXrzBCDlG5+ReOC0XgZqNgLecBeraEMMtRVEtNHID8hCbZaY7hra2Ikx7snVeP0RmqzVjK8 viL9kGupzmyf3RQceowCsbLHFJPEcs5C3I2SZONVmSnFnJEHsWIQATyvSbtiF+yHMWIBnNfLdebz rOMC65Sev7dq7DnGtaN1QuL4TLAwC5jpw5HmcHr8KsavKFjMq8iAl+4HdyNTd1PCpiLVD/mchxmN nnKkG9ssYsawM4iXo4rlSM/gTaH+Nlq0/TPCUJmHgGGeu7DhZaHzRLorbcIWJ93gUchFxMKphcnf fAcY1DYvSckUVIJNsihaEvqEk1lMNA/V5GNjBFMyUTIm78Hw/TFjZUPtIdw9hL9kdXJD5TIjIymm dfJAFXskI0rDOrmTlHQx/ZamUthNAZcqg8C850Q1VqAoE8ybYJesAI1S+TVTwEWSmYQOvolZPAbh 8oVZTvhAxnsmbxMmQL9Nsc8Do7FXr12ZM2zCs1rA977N7m47btV4Y4ui5sxD4I5R+ji8vmq3Wqef CPgdNBRM1cmoUSe112xJFlKFtjlqliKvYF7TJAFubY97X3xYNXxrP2tLseSOzVmU1p51Va9E+y+v BqR1WDcrGihqdS817khN7+0taTUbrc7hSWc/twV1ck9VMCOt09OOB8shsL6L9I8zrZP0bH9/sVg0 1CTYY2aNsCHVdB/rjvfhGGL43VT/2PDYOcCuJ6BbwK53jI9pnVwit3bjMZ9mdr8MeZckTAUUCHae kju5yN9YtvUIuqN9qFYE3aLf0C0Ccl0nNkS5vmFNXSBfK3/eijskR/cUy+Janfq29hwR9PZ8twEr 7oG8Lfbx+JDVJVX6eLvXa4xNRfdenETpXsjme4niMVO+UNshO2eL7vN0QpcMDEJYr4aJ0B5GqDIx 0So4QZgXBUYNsdB4z4PoDogv69les0W+X0jlxmPiwVVOlJxiIcEP4IOxwKx5eClyyHVutlvee3GC OFMpplad4S4wuLoUezNGQ0+eTmmMrRS4Aeq843XyAf5+mMmsTh7g1Vq9wF3D1gx8aMB5Cv/iMXQH w5pZ7e0XakZujJqt3JyXNNHD5w581iruNY9zV2flZpRAqmb8F8bVWd9k5+l1N7f+axsm/39bjk88 Ge8GTr/l2CkN8luO/y2xBnY7ah60PhEylCkDV7UPruqvPF1QQTW4quDG5r7rsEGu8DmacKh2D7eb A8tqGcjIg+iEM+SAu/OVEd6ZfqKjBdfBzDwDWMFfzQKdKVaza3Mohz4wcsiz3iw6MQCt2e+mh8sl uLZcpkQU/TKlQ+TbLpPvA00S5N0evL5mIYS0clEnr+DdkD3ONFZ+vm94xXNI8a6p4oJCTGlBw0wg 5v+ceDgYOG7dBm63x1bsNtOVUzG29vZS5I4U9UUgQ3CNnryh9malkjUXnoL/BRTc9hTsDAWbbr/A rmkgVUSRhYnZ4NkgryV8EAi39irjIYu4YHafxW+KY78CX/rplvrhLcDKFWwz4wL5vtDqJq9H7bRz Kw+y5y24yzEvApSvBTSbBx6rb5BtAULPtq6w7dHRyTHuYpQmXrqHOKkfmpTzFK7Hss9rx5CER41V gSIe8xC6o342mnzFBFM8IN00lQE3z5K6mrlAvlQIFuXBFAqdlx2HadYABDQrGNKs33v6DdIsQuhp 1hWaPe6cNoFmX8s4YREGta+BUHuKPjJQMyxOjIFTma36vzGr/Dx4BPL9zfKux9Ad/btrkPemzLSG 7YXepQx3YvSxEWeytMncFIveDBtfS7VwgnyVTWV6OXJHjtARQrPwPKtsj76Rc7MjA3c9+qTEN8jA CKNnYGcY2DxOjlxJfLy7LaN6SIOZnDDB8z0D3bEsmg0MmGbK7BX42Ue5LunevVSKp9ZpuqHCLNNj hiIviRvFXM+AmgeKz2ngO2E7hFw58W7WbYq6VTLIaxcxH294EZTVq53DCQIDUJGHb3msvkX3BCD0 7skuo7CubUX7H9K1/dt9V4zK1eaeaj1jC7v+4dGoGI038pGXy/Q8CrtHoR9THp2R2KpGY4yq8ZNA aBqBjD08FcMzKiFQzeAuNFvgU7PtWrAXiYpF4p3gcwajsa0RR5lSbEmOXt36ajhHbGk6/im1KjM2 GuMN6c6w2c3O89Mtdp6X8fn24SwmiY/YHKyQ3XKmI/inzSlNR3/A2cV5rdVuHxq5n8HroxN4beaT TO8pfo+WCRw/tB9RfDrT+LGmufZYai3jp9MRm9izZji2OcV5rdM2JydS6rW300ybt/nXYT4KjuZq jZ8xh0MZvFI8xGtzwQa4g/K8dnBszu4Xd8O8HMtwaV4Uz+u7+B8AAAD//wMAUEsDBBQABgAIAAAA IQByK7k3awEAAEgGAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKxU0U7CMBR9N/Eflr67bqgIhsGLmvCqmPha2rvRuLZL e1H4ewsIbBk0Iezxnq7nnHtud0eTlSqjH7BOGp2RNE5IBJobIXWRkc/Z292ARA6ZFqw0GjKyBkcm 49ub0TuUDP0lt5CVizyLdhlZIFbPlDq+AMVcbCrQ/iQ3VjH0pS1oxfg3K4D2kqRPbZ2DjBuc0VRk xE6F15+tK2hxK8mtcSbHmBtFTZ5LvmFNBzQZNImp/0CBRve6QtBOzkvwnMwWgBlpn8XeMaGnzdyf MXOi0Z2jF8OXG/4T/VIHiD5mdzSzR0IWni7Mo0+T4Zk8pqKmXQND8r1OE8B1CfX+t3VIPu1Sni8d GvXl1Q4O4viIUomg0pCb/oWzSEMPU4A48yz9STCTTkNBf7f2f2zLHRiM4rHTwfx3384jmENy5Tgq MFV9N+zqkORDl13/wvyjtRJqYMjIsEsjudE4Y401eYD2Jmhj/4//AAAA//8DAFBLAwQUAAYACAAA ACEANZE9jKMMAAD+NwAAEQAAAHdvcmQvY29tbWVudHMueG1s3FnbbuO6FX0v0H8g/HQOMInuN2Pi ga9zAsxBg8kUA/SNlhhbiCSqJG3Hb/MbBdqfmy/p3pR8dwzJeeikCODIkri4ude+LNIfP73kGVky IVNe3HWsW7NDWBHzJC1md52/f5vchB0iFS0SmvGC3XXWTHY+9f76l4+rbszznBVKEoAoZHdVxned uVJl1zBkPGc5lbd5Ggsu+ZO6hZcN/vSUxsxYcZEYtmmZ+qoUPGZSwnxDWiyp7NRw8UsztETQFQxG QNeI51Qo9rLDsFqDeEZkhKdA9hVAsELbOoVyWkP5Blp1AuReBQRWnSB51yGdWZx/HZJ9ihRch+Sc IoXXIZ2EU34a4LxkBTx84iKnCr6KmZFT8bwobwC4pCqdplmq1oBp+hsYmhbPV1gEo7YIuZO0RgiM nCcsc5INCr/rLETRrcffbMej6d1qfP1vM0I0WX81ZMTjBVYHvXJDsAx8wQs5T8tthufXosHD+QZk eWkRyzzbvLcqrYbp8lp5GlWu3AE2Mb/2f55Vll9GtMwGjCDEdkQTEw7n3FiSQxTuJr7KNXvOtRoW kA2AfQLgx6xhwd9ghDWGEe8yFHHShqmxwalYQZx051irYR07NmYPQCYqmbdCsTd+NXAsVXRO5TbQ EZG1M8rbwq3zPR+Vs7clwmfBF+UOLX0b2v2urK1QYLTAqhNqP8nl24x5nNMSql0ed+9nBRd0moFF kB4EIpxoBvATAgX/6Uv2ou8j1wRrTKe3U0Zk1cVgtDtwQRdqzqF+fhZsxsWa/JkK+bzGJ0A0TALs 2zemfWO53yy/60Rd0/wHPk2LVKU0g3V9/lNjlzCf2y2poPeA7UWB44R+0NF3oVcpvOsPfCfwByEC gLJLvt51wFmuFQ3d7a0Re6KLTO090egPQv97VOsM1tpd0uyuM6yW8w3QO0bvo7F9rfqor88N+cqe mAA9yepx9bu0KLjSDQFeqJ9s8VTv549/T1nGVz9//IfkdE2mjKSFYqIUTLGEwGPJc7aaAzRJ+Kog Ci/h7VtyD9fQKOGTKrxNSi7VDQjY+JlgRpGYAoepRJAUTExS8H62Jk88gwkhAvSgAX8kGQUbEBOt Uxsbce36s6b4lG3zCrb9hmzb9iS0g3B0yLbte2N34DnvlO3HOV9kifZ7Urd5Ai7gRLKKQsH+uUgF q/Ya0Nn0zc0mhfAn/Z0WcZplFHyNNH9qSZp1BWlhQ9J8azQKzeFxilqBOzKj95qi/QN3V3zFtMBU LTMaQ5amBSyBaW50KuEuMn5um006qNsR43pNa6dnDkcjF/29R4w3sZ2+FUQHxFiRE411HT8mpn7y qxCDjbArS2DgrgPlUjKxZJ3eAxPQ2CShkEs1KFFcc3PAB3xslvggjlaneqBlQYpKSpObvMxQnsLV QjIsqfIYpxrSNg917LekO2hId+BO/Mgf9w/pNp0wNMejyfuku/dd105oZrRIDC6wY0IK5hw6I9Af p5K1pcC/goKmasXy+hMbStlRxnmO65pjPfE7pEAa4MAyS1l9sTZeyyltveuEk6jOqLbcYA9pyY1n NtUW7nDimebwKD367qAfRXj3PXLTl5AGHDSgbki64PWnUgkaqw+gFSWrGtSUFewpVaglaKJVxWXN AclGoPCR3+4fR2Qpb8nD4+j380qkbcPTgqAlxU7T9HMGfmhbR+nnhubAmriD/6eGdyRP6k1ELe2P dgnS0Pqk+ny1H+LSI8f1XLPK3fPzVhuNY4wLA1imY8w4P6YXczyaJ1Ou5nrnItuGk9V6OxJ0bbtp R436dugOjuIpcCPLtb1d8KDrTN/3HO9cPNVPfpmSAb30g05wmJCBhq0OcKGxtvV86z0FeL6pljGd ft8ZhkeetwPfCs3oMJPfj+fvZfHzx78U+TL+CgSQL4/wr9oBsmTGdHHGuw+HXfMoR/2JHXjhpRwl GzUsjXoWKO8wZ/3NaL13bH2+E3QdqynRdjiKzOBoj+Jak8icjLUc2K683w+G0dnNY/3k1yFaN17o t5RM4TNJnzSKusTrgW7K1i1KLJT7qjFfPjKoj4Bwk3TJDnBkP7BqOzAQeNHCFiIWGfYhiOsVIwmI joJ9QGMKsGZNCq53zNiUFmXJxUWPHFhyfv/1ihH90T1Z6Y0DNEU848TNYJJK1ElVmh04BijCBgqU NjXnlXkXRQLdDH9MPmtt77C5HeE7AxP+LuL/Dc8BV7Dn+QBiL67UG83w7FDwZBFjPOLyCrYial0y eWatWfqMx4G4h6IqnoNsXKVqfsku0wnM4fiiXfSN65qJ6miyWORTJtDqmJa0akwgWEEiKFh0pVVr lRtzXHSGhzEFe6v50AwBD2Qz+hDlLykpCJJ6qjlTTPAZSGi+kJBky1TwQtfHKYMEATeDlFYQaCSe 0yxjxYzdHqZYgxrb+hwo6LpNa2zg+kNvcnyGbg+iIAx8rZ+23gpGtj3AE4STGls/0ej/2xq7b284 tkbupkZ8x8JCRaWD2QuFvWqVA9X3VGpycwY0FanM5Sfy+aY//ANPy9lLyWI8e4dCcXpsvj0z//I4 xmi5FG+26YXepLYIhJaEQghdf4nVEOIoh4KYfLgEsL+kVwI21r7BJF7UGz+IpmlaaG/phMYN22G1 aRCDrQ+nIAabHhLboNxGk8n4MAbNEPq/PdqpNx1pvu0Gu7Dcj8HqyS8WgweM35OEVyoPWl9yWhkv 0bq3J7/YogPb9R3nUoSA4BNYmwAqqYKiaciex9O/RLVYym8Fh3aKP9GnSzweL2YLOmO/g1JRKI1y 2dieHjasNk4EkZti4uveqJeeSrmAivwIpZr88V23elmCY6pTxHgdY5UQjMbzzc9jIp3NlU726UKh PFhBC8VXEvwiOS+wSwlYGGR06zTT0d4uzbxGR/7/BQAA///Ul81u4zYQgF+F8HkTi5QUWcbaC1k/ bYBNGyQuivZGS+OYiCypIhXHPeUdem2vfbA8SYeUktip0Vp7cgBDljlDmpyP85dNBk7suk4chwOy oc5YwaO6zCaDi8APE8ZiHB3XUmQ3k4FleS5NnNHrUARL3uRqRzL9vBlX17X5ulXbHFD1geeTQViu 11CoOa4+GE4/D1/V2kf3fmjKDSyhhiKFbl6ny4uiVFyJskCFTvK6nppeErUSxT0+udKvkuBHrYDI ZiEVL5R4AFLxWpFy2cpr+K0RNei/JM9Pf7Qzv97eSMLzsrgzkyuuVoTXQFJe8QVuFSfjIlJ0clw5 7f5TFGneZCBJEF3Kc7099bJJfXjzTNsT6h13r3h2gcanF9rGvFGrsp4Mvqvhrqy35ErU8n6rJRlX MBkwi7Ezi51RZ069seuMLetXLRWFUILnEmdetUQMWdwo12SZH7iJe6Ex7vC2mEVtOw72eAee64T0 EO9OcjK85x1iXpCyUmItfje6n4hYV7mBan4Pv//5bI8FPg5c8HbNDCooMpzal573DfS8I+lZI8/1 o9k7b8VdJ6PQe0OlDxMFHjWK/6LXSU6GnhyuG6mGVz/dzodf+lrbxKM+1h6NKT3S2o7jUxYwf9/a TmB7EY3dPWv7I88K2SFrd5KTsfY11CteSSKrXHTBcTf4iYKoTdkbg7ZRXwzsSAxu4IU0uIj2MbhR FDAavN3wj4Xh+enPr3wBeZs1np/+IlySjcAMI5Qks/KWlLUeQr02r2CyyfUEibp98TCrPx7XPxIP 9UM7mFm6VtjBw2J7Ngu9t3JBQ2AJtdnBCqKTnAye+eq/EkVs0TixzW7VFNN9DTyTJBf38H6WUSGP 63wsK56ikasaJNQPMJgSvut4nwjuBwdacJnZ2XlfzCYD9MGsGR8bDGdxZIWuvkm7wdC3EjSGqVg+ IOZbEwRFoUqkIUGfVcFePGxdMCh0JUeugl/w19/f4oEmKPVEc2yAdDw/tm3rXVXg0pj5bpLsoYlH mP/tQ2g6yamgOewzl7qMf5ex+KJs8Jllug7X9baOnIi0LrMm1WMFbMw4loPncP6J4AmgkGIhkP32 C+lL0iT+niRHx8bSiFE2st5V58wf2Wzm7Ke6kUc9+2B910lOxsleoKGTyebuDqQuOzBqclLVZQrS NFC67tA9VF5u2kZrzbeIWeKZtAwRn5XLs7LOoCYZ5NjAodVNA5beA2bMl/l8DWSpFxHL9jLwCn0c Mn0joE5XvLgDbN62vR24d1Pmj+mxsZWNmBVFifbL3bI+tBObhiZ3f0DsL4Umhk9sw0oJpnIhlwVZ b8mDgI1pz0pDn3fxFVsA8sOPc8KXS0gVicOra7KAFX8Q6NNNkeNlMYqv/TU8It3UxHCp6ibVu8Fr kyONTF84vcL/pdG3dzn9BwAA//8DAFBLAwQUAAYACAAAACEAtvRnmNIGAADJIAAAFQAAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbOxZS4sbRxC+B/IfhrnLes3oYaw10kjya9c23rWDj71Sa6atnmnR3dq1 MIZgn3IJBJyQQwy55RBCDDHE5JIfY7BJnB+R6h5JMy31xI9dgwm7glU/vqr+uqq6ujRz4eL9mDpH mAvCko5bPVdxHZyM2JgkYce9fTAstVxHSJSMEWUJ7rgLLNyLO59/dgGdlxGOsQPyiTiPOm4k5ex8 uSxGMIzEOTbDCcxNGI+RhC4Py2OOjkFvTMu1SqVRjhFJXCdBMai9MZmQEXYOlEp3Z6V8QOFfIoUa GFG+r1RjQ0Jjx9Oq+hILEVDuHCHacWGdMTs+wPel61AkJEx03Ir+c8s7F8prISoLZHNyQ/23lFsK jKc1LcfDw7Wg5/leo7vWrwFUbuMGzUFj0Fjr0wA0GsFOUy6mzmYt8JbYHChtWnT3m/161cDn9Ne3 8F1ffQy8BqVNbws/HAaZDXOgtOlv4f1eu9c39WtQ2mxs4ZuVbt9rGngNiihJplvoit+oB6vdriET Ri9b4W3fGzZrS3iGKueiK5VPZFGsxege40MAaOciSRJHLmZ4gkaACxAlh5w4uySMIPBmKGEChiu1 yrBSh//q4+mW9ig6j1FOOh0aia0hxccRI05msuNeBa1uDvLqxYuXj56/fPT7y8ePXz76dbn2ttxl lIR5uTc/ffPP0y+dv3/78c2Tb+14kce//uWr13/8+V/qpUHru2evnz979f3Xf/38xALvcnSYhx+Q GAvnOj52brEYNmhZAB/y95M4iBDJS3STUKAEKRkLeiAjA319gSiy4HrYtOMdDunCBrw0v2cQ3o/4 XBIL8FoUG8A9xmiPceuerqm18laYJ6F9cT7P424hdGRbO9jw8mA+g7gnNpVBhA2aNym4HIU4wdJR c2yKsUXsLiGGXffIiDPBJtK5S5weIlaTHJBDI5oyocskBr8sbATB34Zt9u44PUZt6vv4yETC2UDU phJTw4yX0Fyi2MoYxTSP3EUyspHcX/CRYXAhwdMhpswZjLEQNpkbfGHQvQZpxu72PbqITSSXZGpD 7iLG8sg+mwYRimdWziSJ8tgrYgohipybTFpJMPOEqD74ASWF7r5DsOHut5/t25CG7AGiZubcdiQw M8/jgk4Qtinv8thIsV1OrNHRm4dGaO9iTNExGmPs3L5iw7OZYfOM9NUIssplbLPNVWTGquonWECt pIobi2OJMEJ2H4esgM/eYiPxLFASI16k+frUDJkBXHWxNV7paGqkUsLVobWTuCFiY3+FWm9GyAgr 1Rf2eF1ww3/vcsZA5t4HyOD3loHE/s62OUDUWCALmAMEVYYt3YKI4f5MRB0nLTa3yk3MQ5u5obxR 9MQkeWsFtFH7+B+v9oEK49UPTy3Y06l37MCTVDpFyWSzvinCbVY1AeNj8ukXNX00T25iuEcs0LOa 5qym+d/XNEXn+aySOatkzioZu8hHqGSy4kU/Alo96NFa4sKnPhNC6b5cULwrdNkj4OyPhzCoO1po /ZBpFkFzuZyBCznSbYcz+QWR0X6EZrBMVa8QiqXqUDgzJqBw0sNW3WqCzuM9Nk5Hq9XVc00QQDIb h8JrNQ5lmkxHG83sAd5ave6F+kHrioCSfR8SucVMEnULieZq8C0k9M5OhUXbwqKl1Bey0F9Lr8Dl 5CD1SNz3UkYQbhDSY+WnVH7l3VP3dJExzW3XLNtrK66n42mDRC7cTBK5MIzg8tgcPmVftzOXGvSU KbZpNFsfw9cqiWzkBpqYPecYzlzdBzUjNOu4E/jJBM14BvqEylSIhknHHcmloT8ks8y4kH0kohSm p9L9x0Ri7lASQ6zn3UCTjFu11lR7/ETJtSufnuX0V97JeDLBI1kwknVhLlVinT0hWHXYHEjvR+Nj 55DO+S0EhvKbVWXAMRFybc0x4bngzqy4ka6WR9F435IdUURnEVreKPlknsJ1e00ntw/NdHNXZn+5 mcNQOenEt+7bhdRELmkWXCDq1rTnj493yedYZXnfYJWm7s1c117luqJb4uQXQo5atphBTTG2UMtG TWqnWBDklluHZtEdcdq3wWbUqgtiVVfq3taLbXZ4DyK/D9XqnEqhqcKvFo6C1SvJNBPo0VV2uS+d OScd90HF73pBzQ9KlZY/KHl1r1Jq+d16qev79erAr1b6vdpDMIqM4qqfrj2EH/t0sXxvr8e33t3H q1L73IjFZabr4LIW1u/uq7Xid/cOAcs8aNSG7Xq71yi1691hyev3WqV20OiV+o2g2R/2A7/VHj50 nSMN9rr1wGsMWqVGNQhKXqOi6LfapaZXq3W9Zrc18LoPl7aGna++V+bVvHb+BQAA//8DAFBLAwQU AAYACAAAACEAtP6yBrMEAAA6DgAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFdtb9s2EP4+YP/B0Oc5 lqhXC3UKv2lNEa9DnGKfaYm2iYiiQFJ23GL/fUdKspxEK5IWgQGbuueeu+PxdDx/+PjI8sGBCEl5 MbGcK9sakCLlGS12E+vrfTKMrIFUuMhwzgsysU5EWh+vf//twzGWRClQkwMwUciYpRNrr1QZj0Yy 3ROG5RUvSQHglguGFTyK3Yhh8VCVw5SzEiu6oTlVpxGy7cBqzPCJVYkibkwMGU0Fl3yrNCXm2y1N SfPTMsRr/NaUBU8rRgplPI4EySEGXsg9LWVrjf2sNQD3rZHDjzZxYHmrd3TsV2z3yEV2ZrwmPE0o BU+JlHBALG8DpEXn2Hth6Oz7Cnw3WzSmgO7YZnUZuf82A+iFgSAlj2+zETU2RsC8tEOzt9kJznZo l1gn+LlgLgzITGX7N1lBbV5HmosV3mN5riJtkbwtKP9s7sS6HMn8NVVTQ7d0I7Co38mmZFga3+wK LvAmh3CgdAZw+gMTnf6GJOofsySPRq7zYF1Dj/jGORsc45KIFF4UaDC2bY00oAROH+7IgerGI40o I1tc5eoeb9aKl8A6YIg7RA0j3WPgKCLWJU6hrOe8UILnrV7G/+JqDm1FQNU3DNNkutW6bljAKDCD nTxpQiueQUc5xpWgr0+5Jhjvjn/p8rkjDg1W0Izc6wyu1SknCQS/pt/ItMg+V1JRsGha0S9E8KMA SKE9f4Ezvz+VJCFYVZCmd3JmTiLJabmiQnBxU2Rw9O/mjG63RIADihVZQflQwY8mz58IzuBeeye/ lST/gDK8cu69LuUZV4qzT6dyD7n+tZM09T66LF+4nTPZLu44V2dV209chJI6Uo12iO2G9nzZi3ho nIS9SBD4blPKTxHHc6Nk3IuM3fES9SHI9iO/NzaUOC6K+hB3ZsOnD/n/nQaeM557vUiCQr/XT4i8 wHV7Ed9JvH5OgLyw6UbPkAVCs2kfEoVO6M57kaWz8Joae4qMXc/3ev2MQyca93MiOO3eU5iGvjfv 5Uyn4XzcmzcQT8NezgLks979LG1nmfRmdBkBrxdJghAmg6bemypnsZ6k/hbtSrfKAasZc8w2guLB Ss9aI62xEQ8zWrT4hsCFRi6RdbVpweGwBiTDeZ7AS9sCJtUszqgsF2Rr1vkKi11nt9EQvVK4tz6f belrjog/Ba/KGj0KXNYtsFVxvPpwWUwLdUtZK5fVZt2yCriCL6CqyL4chMlTlx64RKGlmKvkFpvW ZHRJMfy6rpOd5mKt2w5Z4bKsu9dm50ysnO72ytENR8FTBiO5edjsUIMhg6EaMw841TsD7WbRyVAr u9BzW5nbybxW5nUyv5X5nSxoZYGW7eG+EjktHqCRtkst3/I850eSferwF6I6CXKPS7KoZwsoL14L mmFDDg4xeYTBhGRUwT+dkmYMP+o5BQWa3mjn+MQr9URXY1q5fGpBz3DN1TF6QjYl/iwWPfOkFMpx fWKbbpS5qgPPqYRrp4SpR3HRYn8YzPHijKc3eu7ymlp0nAg5jgkapjMzLSlzM8G535HtDEuSNVhL 9Wvqd9+eJYsoQsNZEgZDz53Oh7MwioY2Wi7Dpe8E85nzb/OStn/6rv8DAAD//wMAUEsDBBQABgAI AAAAIQDH+MoAtwAAACEBAAATACgAY3VzdG9tWG1sL2l0ZW0xLnhtbCCiJAAooCAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskEEOgjAQRa9CegCKLlgQwJDoVk2auHJTygBN2hnSjgZv b9XoCVxO5v2X+VPvVu+yO4RoCRuxyQuRRdY4aEcIjUASu7buK0W3YCBmicZY9Y2YmZdKymhm8Drm tACm3UjBa05jmCSNozWwJ3PzgCy3RVHK3vbO0hT0Mj/ER/YflQIHhmFQ/HDp7Gt37pRdeT4MllOz 01twQmcR8jW6FHiBR+0TnFiRXb4vKEVby1/h9gkAAP//AwBQSwMEFAAGAAgAAAAhADsQN6/hAAAA VQEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAnJDBasMwDIbvg71D0N110q5uKHFKGxPodWywq+s4iSG2gu2MjbF3n8NO 3XEn8UlI34+q04edsnftg0HHodjkkGmnsDNu4PD60pISshCl6+SETnNwCKf68aHqwrGTUYaIXl+j tllqmFSvgsNXw9hW5M2FFKUoydNOMHI+XFqyZ4eiFfuStbvmG7KkdulM4DDGOB8pDWrUVoYNztql YY/eypjQDxT73igtUC1Wu0i3ec6oWpLevtkJ6jXP7/az7sM9rtEWb/5ruZnbZHDwch4/gdYV/aNa +e4V9Q8AAAD//wMAUEsDBBQABgAIAAAAIQCIO7rusQwAABd8AAAPAAAAd29yZC9zdHlsZXMueG1s zJ1Nc9s4EobvWzX/gaXT7CGR5Q85SY0z5Tjx2rVx4omczRkiIQtrktCSVGzvr18AJCVQTVBssOPa S2JR6gdAd79NgJ9//PmUxMFPnuVCpmejyeuDUcDTUEYivT8bfb+7fPVmFOQFSyMWy5SfjZ55Pvrz /W9/++PxXV48xzwPFCDN3yXh2WhZFKt343EeLnnC8tdyxVP15UJmCSvUx+x+nLDsYb16FcpkxQox F7EonseHBwfTUYXJ+lDkYiFC/lGG64SnhbEfZzxWRJnmS7HKa9pjH9qjzKJVJkOe52rQSVzyEibS DWZyDECJCDOZy0XxWg2m6pFBKfPJgfkribeAExzgEACmIX/CMd5UjLGytDkiwnGmG46ILI5fZyxA HhXREkU5rP061rasYEuWL20ix3XqZIN7TrSPkvDd9X0qMzaPFUlFPVCBCwxY/6vGr/8zf/Ins10P YfReaSGS4Ue+YOu4yPXH7DarPlafzH+XMi3y4PEdy0Mh7lQHVSuJUA1enae5GKlvOMuL81yw1i+X +o/Wb8K8sDZ/EJEYjXWL+X/Vlz9ZfDY6PKy3XOgeNLbFLL2vt/H01feZ3RNr01xxz0YsezU714bj amDl/9ZwV7ufTMMrFgrTDlsUXMl8Mj3Q0FjoqnJ48rb+8G2tnc/WhawaMYDy/w12DDyu1K9qwaws SepbvvgswwcezQr1xdnItKU2fr++zYTMVNk5G701baqNM56IKxFFPLV+mC5FxH8sefo959F2+1+X pnRUG0K5TtXfR6dTkwVxHn16CvlKFyL1bcp0TL5og1j/ei22jRvz/9SwSRWJNvslZ7oaB5NdhOk+ CnGoLXJrtO3M9c7Yza9QDR29VEPHL9XQyUs1NH2phk5fqqE3L9WQwfzKhkQaqcJvfg+bAdR9HIca 0RyH2NAch5bQHIdU0ByHEtAcR6KjOY48RnMcaYrgFDJ0ZaGV7EeObO/m7t9H+HH37xL8uPv3AH7c /QXfj7u/vvtx95dzP+7+6u3H3V+s8dxyqhVcK5mlxWCVLaQsUlnwoOBPw2ksVSyzRKXh6Z0ez0gG SYApK1u1Ix5MC5n5vD9DjEj99+eFXukFchEsxP064/ngjvP0J4/ligcsihSPEJjxYp05POKT0xlf 8IynIadMbDqoXgkG6TqZE+Tmit2TsXgaEbuvJpIUhU1Cq/XzUotEECR1wsJMDu+aZGT14bPIh/tK Q4IP6zjmRKwvNClmWMPXBgYzfGlgMMNXBgYzfGFgxYzKRRWNyFMVjchhFY3Ib2V+UvmtohH5raIR +a2iDffbnShiU+LtWcek/7G7i1jqkwqD+zET9ylTE4Dhu5vqmGlwyzJ2n7HVMtBHpdux9pix7XyQ 0XNwR7FP25Co5vUmRS7UqEW6Hu7QBo1KXBsekbw2PCKBbXjDJXajpsl6gnZFs56ZredFq2gNqZdo ZyxelxPa4WpjxfAM2wrgUmQ5mQzasQQZ/EVPZ3U4KSrftpfDO7ZlDZfVblUi7V6FJOhlLMMHmjJ8 9bzimVqWPQwmXco4lo88oiPOikyWuWZL/tCEpJfkPyWrJcuFWSs1EP139fXlCMENWw0e0G3MREoT t0+vEibigG4GcXV38zm4kyu9zNSOoQF+kEUhEzJmdSTw9x98/neaDp6rRXD6TDTac6LDQwZ2IQh2 MiVJRkQkNc0UqSDZhxreP/nzXLIsoqHdZry8AqjgRMQZS1blpINAW6ouPqr6QzAbMrx/sUzo40JU orojgVmHDfP1/N88HF7qvsiA5MjQ13Vhjj+aqa6xpsMNnyY0cMOnCCaaaveg85dgsA3c8ME2cFSD vYhZngvnKVRvHtVwax71eIcv/iqejGW2WMd0DqyBZB6sgWQulPE6SXPKERse4YANj3q8hCljeASH 5AzvH5mIyIJhYFSRMDCqMBgYVQwMjDQAw6/QsWDDL9OxYMOv1SlhRFMAC0aVZ6S7f6KzPBaMKs8M jCrPDIwqzwyMKs+OPgZ8sVCTYLpdjIWkyjkLSbejSQuerGTGsmci5KeY3zOCA6Ql7TaTC31riEzL i7gJkPoYdUw42S5xVEH+wedkXdMsyn4RHBFlcSwl0bG17Q7HWDavXdtnZu7kGNyF25iFfCnjiGeO Mblt1Xp5Vt6Wsdt9041ehz0/i/tlEcyWm6P9NmZ6sNeyXrA3zPY32ObzaX0/S5vZDY/EOqk7Cm+m mB71NzYZ3TA+3m+8nUk0LE96WsI2p/stt7PkhuVpT0vY5puelkanDcsuPXxk2UNrIpx25c9mjedI vtOuLNoYtzbblUgby7YUPO3KooZUgvMw1GcLYHT6acZt3088bnuMitwUjJzclN66ciO6BPaN/xR6 z44pmqa9zdUToO6bSXSvyvnXWpbH7RsnnPrf1HWtJk5pzoNWzlH/E1eNKuP2Y+9y40b0rjtuRO8C 5Eb0qkROc1RJclN61yY3oneRciPQ1QruEXDVCtrjqhW096lWkOJTrQbMAtyI3tMBNwItVIhAC3XA TMGNQAkVmHsJFVLQQoUItFAhAi1UOAHDCRXa44QK7X2ECik+QoUUtFAhAi1UiEALFSLQQoUItFA9 5/ZOcy+hQgpaqBCBFipEoIVq5osDhArtcUKF9j5ChRQfoUIKWqgQgRYqRKCFChFooUIEWqgQgRIq MPcSKqSghQoRaKFCBFqo5a2G/kKF9jihQnsfoUKKj1AhBS1UiEALFSLQQoUItFAhAi1UiEAJFZh7 CRVS0EKFCLRQIQItVHOycIBQoT1OqNDeR6iQ4iNUSEELFSLQQoUItFAhAi1UiEALFSJQQgXmXkKF FLRQIQItVIjoys/qFKXrMvsJ/qin84r9/qeuqk59s2/ltlFH/VF1r9ys/vcifJDyIWi98fDIrDf6 QcQ8FtIconacVre55pII1InPrxfdd/jY9IEPXaruhTDnTAH8uK8lOKZy3JXytiVY5B13ZbptCWad x13V17YEu8HjrqJrdFlflKJ2R8C4q8xYxhOHeVe1tsyhi7tqtGUIPdxVmS1D6OCuemwZngS6OO9a n/T003RzfSkgdKWjRTh1E7rSEsaqLsdQGH2D5ib0jZ6b0DeMbgIqnk4MPrBuFDrCbpRfqKHMsKH2 F6qbgA01JHiFGmD8Qw1R3qGGKL9Qw8KIDTUkYEPtX5zdBK9QA4x/qCHKO9QQ5RdquCvDhhoSsKGG BGyoB+6QnRj/UEOUd6ghyi/UcHKHDTUkYEMNCdhQQ4JXqAHGP9QQ5R1qiPILNVglo0MNCdhQQwI2 1JDgFWqA8Q81RHmHGqK6Qm2OojRCjYqwZY6bhFmGuB2yZYgrzpahx2rJsvZcLVkEz9USjFUdc9xq yQ6am9A3em5C3zC6Cah4OjH4wLpR6Ai7UX6hxq2W2kLtL1Q3ARtq3GrJGWrcaqkz1LjVUmeocasl d6hxq6W2UONWS22h9i/OboJXqHGrpc5Q41ZLnaHGrZbcocatltpCjVsttYUat1pqC/XAHbIT4x9q 3GqpM9S41ZI71LjVUluocaultlDjVkttocatlpyhxq2WOkONWy11hhq3WnKHGrdaags1brXUFmrc aqkt1LjVkjPUuNVSZ6hxq6XOUONWSzfKRBA8AmqWsKwI6J4Xd8XyZcGGP5zwe5rxXMY/eRTQDvUz apTjx8brrzTbvJtP/b5QPtNPQLduV4rKJ8BWQPPD62jzmiptrHsSVC8EqzabDlena8sWjSFsKlyq tsLq2VWOpqpn0G5uojJPoN1t2PGgWtORbQLWv65cuvVX+buGtzr7XeiE7+izEUSnj0rNuDr4tioC +3qo+jOPy1emqT+u00gBHqvXhZU9jZ5YiVLfX/A4vmHlr+XK/dOYL4ry28mBeWTBzvfz8ul7TvvM lGknYNzsTPmxem2bw9/l8/ir6wecKalrUYu7zcUsQz3t7ltDLpvemPPz5hbr3Q5ZT2ssvclUC1+1 poGEdPlqmGmrC6WZfaNpSZQsFzo7zM8ODi6npweTqhi73rlnv3HvePOh/Y17jtcW6suBUlXzmLny xryS0NpUOn771sFalvZbB+uSVb88sE8hCde5yk9T3naTpOlFd2iCrZd34tNajtzR2hcpd1j+jxy6 cd+FTPRTS7cXLu16sPX1Hjg3DqmGTW9OjydvL6qLaCpvbp0zqWaLtnPKbfud0y75yjmtot99nw9G +Ra3j/aHeAmUAqz8reSrJqCN5DPb6NS865ldr1ffkyjaji4uAoikHOK0zqScVQ/N7MjL+rmabS4C g0+1R11ftritav9X52/l0Hk5hov8V2SbPRRXwlW/cedcq6bdfqPOONtBvvlX/5W//x8AAAD//wMA UEsDBBQABgAIAAAAIQDvCilOTgEAAH4DAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyc019rwjAQ APD3wb5DybumyhQpVmEMx17GYNsHiOnVhiW5kour7tPv2qlz+GL3kv/34y4h8+XO2eQTAhn0uRgN U5GA11gYv8nF+9tqMBMJReULZdFDLvZAYrm4vZk3WQPrV4iRT1LCiqfM6VxUMdaZlKQrcIqGWIPn zRKDU5GnYSOdCh/beqDR1SqatbEm7uU4TafiwIRrFCxLo+EB9daBj128DGBZRE+VqemoNddoDYai DqiBiOtx9sdzyvgTM7q7gJzRAQnLOORiDhl1FIeP0m7k7C8w6QeML4Cphl0/Y3YwJEeeO6bo50xP jinOnP8lcwZQEYuqlzI+3qtsY1VUlaLqXIR+SU1O3N61d+R09rTxGNTassSvnvDDJR3ctlx/23VD 2HXrbQliwR8C62ic+YIVhvuADUGQ7bKyFpuX50eeyD+/ZvENAAD//wMAUEsDBBQABgAIAAAAIQCy 8vN+2QIAAP0NAAAZAAAAd29yZC9jb21tZW50c0V4dGVuZGVkLnhtbKSXW2+bMBTH3yftO0S8t76A wURNJ8Jl6vO2D+CCE1AxRja59NvPJCHJxlZh+hII5v87F59zZJ6+HUW92HOlK9msHPQInQVvcllU zXbl/PqZPVBnoTvWFKyWDV8571w7356/fnk6ILLMpRC86XR6XBhMo5eHNl85Zde1SwB0XnLB9KOo ciW13HSP5nUgN5sq5+AgVQEwRPB01yqZc62NzZg1e6adCy4/TqMVih2MuAd6IC+Z6vjxxkDWEAJC QMcgPANkIsRojHKtUT7ovRqBvFkg49WIROaR/hGcP4+Ex6RgHskdk+g80qicxLjAZcsbs7iRSrDO /FVbIJh627UPBtyyrnqt6qp7N0zoDxhWNW8zPDKqK0G4hTUhAEIWvHaLgSJXzk41y4v+4arvXV+e 9ZfLoFBT4j9LEpnv+vlwihwoXptcyEaXVXvtcDGXZhbLAbL/KIi9qIf3Di2a2C7/G0/JOZU34BT3 L/kX9dnzj4kITtiRHnFVTHHhT5uDJ8JU4c3wrNTcJRdNHCADAI8Afs4nDvyBQS8MkN86tOdUE1tj 4Jx3pedUt8SiiXPsb2fuALroitKKgoe8gl7LOlYyfS30nsjtnCJX3Lu4y1G7/VwjfFdy195o1edo L7exdugPGRasS0PdN7n+nDM/StaaaSfy5cu2kYq91sYj0x4LU+GL0w70v6ZQ+svplh9Pz/u9XvQz xnm+Px2l/SpZtkyxF1OWJAxcl/qBc3panA5V0AEfSTDOKA5oYiHxUZJQGNtYIQTGSeJ5FpLAy/zQ TyMLCSJRhn0P2YTvxRmBMLax4q59ipGNlSCMMPXWNhLoRpEbUysJpkkIA7sk+zHJ7ArGRzTJstRC 4qWEeGlqk2QcRiQjPrUJnwYkTNY2VjwvRDjCoU0lR0GMIt+mX1AYu9EaWmVsnSYwJtBGEoSp69pV coIRptAmyZhimCSZO5KAO435Znv+DQAA//8DAFBLAwQUAAYACAAAACEAXq942jgDAADoDwAAFAAA AHdvcmQvY29tbWVudHNJZHMueG1spJfbcpswEIbvO9N38HCfIAmd8MTpYA4dX7d9AAWwzcQgBvAh b1/JNrYTqlQmNwYD++nX/rtr/PTjUG4mu7xpC1nNHPgInElepTIrqtXM+fM7eeDOpO1ElYmNrPKZ 85a3zo/n79+e9pCmRTZNZVnmVdcusnaiUFU73dfpzFl3XT113TZd56VoH8sibWQrl92jet6Vy2WR 5u5eNpmLAATHs7qRad62at1QVDvROmdcerCjZY3Yq2ANxG66Fk2XH64MeDeEuL7LhyA0AqR2iOAQ 5d2Noq5WNQDhUSClakAi40j/2BwdR0JDEhtH8oYkPo40KKdyWOCyzit1cymbUnTqa7NyS9G8busH Ba5FV7wUm6J7U0xAe4woqtcRilTUhVB62d0E5pYyyzde1lPkzNk21fQc/3CJ19Knp/jzoY9obPZ/ ColkutUD4rhzt8k3KheyatdFfenwcixN3Vz3kN1nm9iVm/65fQ0t28U0nqJTKq9AG/nn/Jebk/LP iRBYOKIRlwgbCe/X7JWUqgqvC49KzU1yoeUA6QFoAKBpbjnwewY/M9z02qGnH6f7OCdXNKe4JhZa zrGPYm4AbdZl67soqM+rq2NFJ9aivRS6Jub3iSIX3Ft5k6N69bVG+NnIbX2lFV+jLa5jba9fNO5g nRvqtsnbr4n5tRa1mnZlOl2sKtmIl41SpNpjoip8cnRAf6pC0YfjaX44XtdeT/SMcZ4/vCEtjs/q C7VoxEIVJ/GZ53HKnP5Gtj2upO8hMicAo7nj/p+DUMIR45GR4wVWHAqjiIPQrMdLPBsOISCMIoyN HDKPbTgMJ9SncWDkUMRsOJAECaIYmjkBsMozDhMCQGjmRNxKjzenHEGzHsaoVX78AHE8N3NiYuW7 qo/AC7mZkzAr3wHikQ+Y0XcIKLbznYYkMfcFRJEVB1HIoySJjRzMrDg4JgTHsdF3SGFopccPSEIo N3LI3M4vzogfzT/Rw6z0YOxDFCDfyPHt9JCAhTCgxvkDA2DXp36oJhUw+oUIspobeB5HICTAzKFW /Y6ZH3ueud+RpV8wQhBxYPQdMbs5hjgCUaRmsJETIs1x34P0X/PnvwAAAP//AwBQSwMEFAAGAAgA AAAhAE4ulF3yAgAA2REAABsAAAB3b3JkL2NvbW1lbnRzRXh0ZW5zaWJsZS54bWyk2M1TozAUAPD7 zuz/0OFe8wGBylgda3XH8+plbxHSwkgIQ6it//0mbaFVdg08L/2Q5sfj5b0H49XNThaTN1HrXJVz j1xgbyLKRKV5uZ57z08P05k30Q0vU16oUsy9d6G9m+ufP662JEzELk6UlKJs9P2uEaXOXwoxMWKp 422VzL2saaoYIZ1kQnJ9IfOkVlqtmguzDKnVKk8E2qo6RRQTvP9U1SoRWpvT3/HyjWvvyCW7YVpa 861ZbMEAJRmvG7E7GWQ0wtAlmvUhCoDMFVLSp/zRVIhsVD0oAEEmqp7EYNI/Li6ESbQvRTDJ70sz mNQrJ9kvcFWJ0hxcqVryxnyt10jy+nVTTQ1c8SZ/yYu8eTcmDluG5+UrICKzqhOkn44WIiRVKgo/ bRU19zZ1GR/XT7v1NvT4sP741q6oh1z/YclSJRs7J/ZXjmpRmFyoUmd51XW4hGrmYNYib19dxJss 2t9tKzKwXf43npaHVJ7AIeEf8y+LQ+RfiwQP2BFLdCuGhPDxnG0k0lTh6cSg1JwllwwcIC1Ae4C9 t4wzZkcDJacOtU4+sDVa57Ar1slPiSUD59jnYM4AnTZpNkqhbV6RXcsbnnHdFboVxbigWMe9y7Mc VevvNcKvWm2qk5Z/T3s8jbWtfd4YYR0b6rzJ9feC+Z3xykw7mcSP61LV3DzdzD3THhNT4ZP9DthX Uyj2bf9R7PZ/t3s9sTPGu/70oHT2nHQ8kG728KOpU8oWDAd04XXHeCOeG3OfMdVAp5hOCXvCOPYv Y4z/eGg87t+68RCMP/hOfAbF2eLehQcMioc0cuIRGL/FThy8oeFy5sIZhuJRFDpxH4rfM0cpkphS KP4QOUrR4NANJTgMXLhPoDhdOvEAjAeRG4d2KAnJnQtn0A4lbOGsFhaAI4/ckYOr5dIVOY0JeENv sWNwGRzaRJRRx8ilMYMOLspCx1S0gwWMu3JucHBaItfNwuDQJqLRHXXhpEsL+qif/RPm+i8AAAD/ /wMAUEsDBBQABgAIAAAAIQD/CXwnNwIAAI8IAAASAAAAd29yZC9mb250VGFibGUueG1s3JRRb9ow EIDfJ+0/RH4vcUKggBoqlRVp0rSHqf0BxnGItdiOfIbAv985CSkSoDWV1ofxEJw7+4vvy8UPjwdV BnthQRqdkmhESSA0N5nU25S8vqzvZiQAx3TGSqNFSo4CyOPy65eHepEb7SDA9RoWiqekcK5ahCHw QigGI1MJjcncWMUc3tptqJj9vavuuFEVc3IjS+mOYUzplHQY+x6KyXPJxTfDd0po16wPrSiRaDQU soITrX4PrTY2q6zhAgBrVmXLU0zqHhMlFyAluTVgcjfCYrodNShcHtFmpMo3wGQYIL4ATLk4DGPM OkaIK885MhvGmfYcmZ1xPraZMwBkLisGUeKT19CvZY4VDIpzohi2qUmPOyrvSPHF9602lm1KJOFb D/DFBQ3YX7F+/9cMxaGJ+xLIsvsUgnqhmcKVK1bKjZVNomLagIgwt2dlSrCGNZ1QX0tMEzr2VxL6 ibxgFoSHtBNpG86ZkuXxFIVaArSJSjpenOJ7ZqXfdZsCucXEDjY0Jc8JpfHzek3aSIS7oxhJ7p+6 SOyf1fzmXWTcR6iP8IbT3EYthzecfg4+M2wNXJh4kUpA8FPUwS+jmL5hJKZTNDFBH97MeJAR23AH GfH1Xxi5n00+xcgKjyhTMrih4glVzD/YHMpkwl5zkcuDyK6LoNNzET6wXvWRNxHR30XMB4vYWSms b44bLu7RQOvCt0Xyz11ca4pk/ClN0R4YwQ+5LdzNY8P3w396bHQDWP4BAAD//wMAUEsDBBQABgAI AAAAIQC+hexweQIAAA4KAAAPAAAAd29yZC9wZW9wbGUueG1spJbbjpswEIbvK/UdEPfEQAJJUJJt 1airXPRq2wfwGhOs4INs5/T2tTmmpV0BuQFsPJ//Gc+MvHm50cK5YKkIZ1s3mPmugxniKWHHrfvr 53dv5TpKQ5bCgjO8de9YuS+7z5821yBKBOaiwI5BMJVcBdq6udYiAUChHFOoZpQgyRXP9AxxCniW EYTBlcsUhH7gl19CcoSVMvt9g+wClVvj0G0YLZXwaowtcAFQDqXGt44RjIZEYA1WfVA4AWQ8DIM+ aj4aFQOrqgdaTAIZVT1SNI30D+fiaaSwT1pOI837pNU0Ui+daD/BucDM/My4pFCboTwCCuXpLDwD FlCTd1IQfTdMP24wkLDTBEXGqiXQeTqasASUp7iYpw2Fb92zZElt77X2VnpS2devxkIO8b8y2XN0 ppjp0nMgcWFiwZnKiWgrnE6lmZ95A7l85MSFFs26qwgGlsv/2tO+CmUHHCK/jj8tKuUfEwN/wIlY RGsxRMKfezZKqMnCbuNJoXkIbjCwgTSAsAeIER7Y8BvGqmYA1FWo5ZCBpdFwqlOxHNIFNhjYx/4W 8wBQqU7zUZSwiSuwtlDDHKo20S0RjxMVtbg7fYiROD5XCK+Sn0VHI8/RDl1bu9oLxghWXVCPRa6e E/OWQ2G6HUXJ4ci4hO+FUWTKwzEZ7pQnYJ8mUeyr/MS3ct6etWN7jLurb0ZScWbNEnjWOTed81Xi I5d35weR6nRv1kmszH0LH1jGy9VGy4WkWB5MFn/du+XcWVXjtyQ5VhDjlYV8wZIgZTayviUJClYQ rRH0YIRjb4GzzFvHMPMQWqV+uoziMIxcsNuATmE7sBe53W8AAAD//wMAUEsDBBQABgAIAAAAIQAO qoRbdQEAAPQCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACMklFPwjAQgN9N/A9L30e7IYYsYyRq8EUSEzEa32p7QGVrm7Yw9u/tNjZc4MG3 u953327XpvNjkQcHMFYoOUPRiKAAJFNcyM0Mva8W4RQF1lHJaa4kzFAFFs2z25uU6YQpA69GaTBO gA28SdqE6RnaOqcTjC3bQkHtyBPSF9fKFNT51GywpmxHN4BjQu5xAY5y6iiuhaHujeik5KxX6r3J GwFnGHIoQDqLo1GEz6wDU9irDU3lD1kIV2m4inbFnj5a0YNlWY7KcYP6+SP8uXx5a341FLLeFQOU pZwlTrgcshSfQx/Z/fcPMNce94mPmQHqlMmeDWyUqYKlMHZXNVhXqpe+g6pUhlsvGGQe42CZEdr5 q2z1gwNP59S6pb/btQD+UF186ZKomwwcRP06sviuQfo8Pe26HQ944HeUtBvtKh/jx6fVAmUxieOQ xGE0WRGSjCcJIV/1hIP+s7A4TfA/Y0wSMh0aO0G7pOE7zX4BAAD//wMAUEsDBBQABgAIAAAAIQC8 jysr4gEAAOMDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAJxTwW7bMAy9D9g/GLo3shMjDQJFxZBi6GFbA8Rtz5pMJ8JkSZDUoNnXj7IbT9l2 mk+Pj9TTE0mzu7deFyfwQVmzIdWsJAUYaVtlDhvy1Hy+WZEiRGFaoa2BDTlDIHf84we289aBjwpC gRImbMgxRremNMgj9CLMMG0w01nfi4ihP1DbdUrCvZWvPZhI52W5pPAWwbTQ3rhJkIyK61P8X9HW yuQvPDdnh3qcNdA7LSLwb+mkZnQiWGOj0I3qgVfV7QIzU8x24gCBVytGR8RerG8DX5Q1UiNm26Pw QkbsIMfjt0tGM4Z9ck4rKSJ2l39V0ttgu1g8DpaLpMBoXsLwGXuQr17FMy8ZzUP2RZnkpq4ZHSH6 8+LghTsGXpfJ5BSyvRQattgD3gkdgNHfBHsAkea7EypZPMX1CWS0vgjqJ054TorvIkDq3IachFfC RDKWjcGAtQvR80ZFjdpTPMC8LMeq5tVQgOC6cAgGD4iv3Q03hMcO3xb/YbbKzQ4eRquZndzZ5Y4/ VLe2d8Jgi+mEsMM/wpNr7H1akvceXpPZ6F9UPO6dkDiUeblY1fkSZDm2RxZanOo0lYlgD/gGr9MN eNYcoL3U/J1Ia/U8/rO8Ws5K/IY9unC4CtPPxH8BAAD//wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAA ACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjM+xisMwDAbg/eDewWhvnNxQyhGnSyl0O0oOuhpHSUxjy1hqad++ 5qYrdOgoif/7Ubu9hUVdMbOnaKCpalAYHQ0+TgZ++/1qA4rFxsEuFNHAHRm23edHe8TFSgnx7BOr okQ2MIukb63ZzRgsV5QwlstIOVgpY550su5sJ9Rfdb3W+b8B3ZOpDoOBfBgaUP094Ts2jaN3uCN3 CRjlRYV2FxYKp7D8ZCqNqrd5QjHgBcPfqqmKCbpr9dN/3QMAAP//AwBQSwECLQAUAAYACAAAACEA MzdfXqMBAABZCAAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQAekRq37wAAAE4CAAALAAAAAAAAAAAAAAAAANwDAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQBgrxfHji0AAMO3AgARAAAAAAAAAAAAAAAAAPwGAAB3b3JkL2RvY3VtZW50LnhtbFBL AQItABQABgAIAAAAIQByK7k3awEAAEgGAAAcAAAAAAAAAAAAAAAAALk0AAB3b3JkL19yZWxzL2Rv Y3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADWRPYyjDAAA/jcAABEAAAAAAAAAAAAAAAAA ZjcAAHdvcmQvY29tbWVudHMueG1sUEsBAi0AFAAGAAgAAAAhALb0Z5jSBgAAySAAABUAAAAAAAAA AAAAAAAAOEQAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQC0/rIGswQAADoO AAARAAAAAAAAAAAAAAAAAD1LAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQDH+MoA twAAACEBAAATAAAAAAAAAAAAAAAAAB9QAABjdXN0b21YbWwvaXRlbTEueG1sUEsBAi0AFAAGAAgA AAAhADsQN6/hAAAAVQEAABgAAAAAAAAAAAAAAAAAL1EAAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnht bFBLAQItABQABgAIAAAAIQCIO7rusQwAABd8AAAPAAAAAAAAAAAAAAAAAG5SAAB3b3JkL3N0eWxl cy54bWxQSwECLQAUAAYACAAAACEA7wopTk4BAAB+AwAAFAAAAAAAAAAAAAAAAABMXwAAd29yZC93 ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAsvLzftkCAAD9DQAAGQAAAAAAAAAAAAAAAADM YAAAd29yZC9jb21tZW50c0V4dGVuZGVkLnhtbFBLAQItABQABgAIAAAAIQBer3jaOAMAAOgPAAAU AAAAAAAAAAAAAAAAANxjAAB3b3JkL2NvbW1lbnRzSWRzLnhtbFBLAQItABQABgAIAAAAIQBOLpRd 8gIAANkRAAAbAAAAAAAAAAAAAAAAAEZnAAB3b3JkL2NvbW1lbnRzRXh0ZW5zaWJsZS54bWxQSwEC LQAUAAYACAAAACEA/wl8JzcCAACPCAAAEgAAAAAAAAAAAAAAAABxagAAd29yZC9mb250VGFibGUu eG1sUEsBAi0AFAAGAAgAAAAhAL6F7HB5AgAADgoAAA8AAAAAAAAAAAAAAAAA2GwAAHdvcmQvcGVv cGxlLnhtbFBLAQItABQABgAIAAAAIQAOqoRbdQEAAPQCAAARAAAAAAAAAAAAAAAAAH5vAABkb2NQ cm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQC8jysr4gEAAOMDAAAQAAAAAAAAAAAAAAAAACpy AABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4AAAAAAAAAAAAA AAAAQnUAAGN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVsc1BLBQYAAAAAEwATAOIEAABIdwAA AAA= --000000000000b7c18805d8143cdf-- From nobody Tue Feb 15 15:44:03 2022 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 766473A0E5A; Tue, 15 Feb 2022 15:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.676 X-Spam-Level: X-Spam-Status: No, score=-7.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 XTxE2z1vcEJp; Tue, 15 Feb 2022 15:43:54 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::619]) (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 A8FC53A0E57; Tue, 15 Feb 2022 15:43:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R9kjndkeN/QtRkxDvzUopRt7/X6d0hv/lTGevywySNrj7sWvkGmcv9MWyl6+/88+5k8doY7hZfQ363cFVPVtoc99lZRf/7RpjIrjZQSlqkmbtYgTRTgB7L2z7dGBGXo3iOVi2FUth+uh/A2y0bFGMPPYcUcDooyOWgZcmMIHCz0/yUahclDIMlQ3zC/VMewVNkfdtZ/5bk0FvAXxhkzS6EXV02AVuz6WTPp4+GMqswS5pzIoGOx5sY0kUFQyKeYOdVeXLKTwI+4pPeqQZs9GISdNsB2+b21vAQLvLN+Qqngosm0WpCXLBQfqwm6wfc98BMzJnVhd3RmKUCjsFKuGsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=a0Pk3GrZxu63TWh+7ZwsFnQlxtgrkAHu50riEF5f0T8=; b=Wg/5TPHnwpHfQTobuNK9iPSG71SBqDt0jS8T9H96uHnN48ZljuMp1PEmTYhK0RnkDuDD1v6LMV8RDV0cBbDPN2xeVBhZlFYVGY1rSmfsWCsVEf490HYx5FvHn4H3V5UQ++1HqWkI8hmbmmeimOzpAQD3rby9+sEEXYOCN8+MBW1Pz3oO8sBSNUlmjH1wT/g2dIY8Qzj6uQpkyi7n3m+/lI9Vs4N+yhrdldtSzY9uLbEVRE065VE3VQzn3sQsPgdCIymvD/RGJ54g+Z60eZ8vWRWqmjDwgJqxjlQThOieZzAi0dJ+3o/4MdTYg8FSBQk+hd8a7xJaPljzYdDiFBlSsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a0Pk3GrZxu63TWh+7ZwsFnQlxtgrkAHu50riEF5f0T8=; b=koFLxPxd+f+Jy2RDj1uk7EenCFW989yT9+pvEmcgI7SEr/Ia+pZF7Ovi9kbSgl6zRzZAOcF+/+OBw2j3s3i5pngN6VZMVut2eKpvDtuDpCDqonM2vegFtMGoKFFespTiRWDFBa55WY1vymBZ8sXQU2bFfT9ikYytvnh2p4be/zs= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by VI1PR07MB4142.eurprd07.prod.outlook.com (2603:10a6:803:35::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.8; Tue, 15 Feb 2022 23:43:46 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::b1e2:6c17:3ba8:9fdc]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::b1e2:6c17:3ba8:9fdc%5]) with mapi id 15.20.4995.016; Tue, 15 Feb 2022 23:43:45 +0000 From: Francesca Palombini To: Ketan Talaulikar , Cullen Jennings CC: "draft-ietf-spring-segment-routing-policy.all@ietf.org" , "art@ietf.org" , SPRING WG Thread-Topic: [art] Artart last call review of draft-ietf-spring-segment-routing-policy-16 Thread-Index: AQHYHw8cMyg48T982kaAP3q75jS4zayVTSl3 Date: Tue, 15 Feb 2022 23:43:45 +0000 Message-ID: References: <164418360967.24977.17268842252865901665@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ccaa921c-1317-4f7e-5113-08d9f0dd01d4 x-ms-traffictypediagnostic: VI1PR07MB4142:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EXkZ8rMOayQJ3okZMiL/j1I+JZ95Mzlix76plV4dsSNTIx9wgmpHfGyZm6RpzRX6odY8WJWDZ0+thLu1eTNe25fkU5YQnhLeVXZgXVz1u0ElnUtucJnSNc5TyYmus5QGqQqgfwGP64LApNhKv/ZXZ8IIIyw/7fNIqg5CF/+sYb1payUcQFKbn5PovwfmgEt5vOLpV6McBUuZKnlwPFq9MRjZAKZ+COVf07U+R2ijltZX7H0tX48798m2Zl/yWIyFb5JqXvygYPXRBokvEYQjJb3KpMAjcu4GVkpM92jOKHOSTO2wN5xMmaXdGnEUa2uyu9tPU7RYmLyI0D8c8PbuMCTw8PEsJEkdWgdGNfKX0o50OSF6En74Ab0YlthHiGJO0/w01EYJI4XslpQlDLTIf/uTG7o4MTmT8R8Yqa/V64SRXiRo3hzGyi+DzIm3xCV8VMSob/+87ALekvykK3iOvtaX1moEiXJ5j9YUzacN39ZtV3KaojYIfOq++fpwd0pMpABnrDu+7kVazxCQHX7mnvYsKLmKurfwFrtl7v4Cxc1c5MVJ3OOTL2Q7V6yLshVrce4Q0RzwXJAYfVxY3KrszpB/GPtxp0t+Ol1r+NRuonUKXweWVOBmQLyF/cInjYHlZkdKn9YBKhcK/3auAkIsbTScVU/RT3sd/BUUTa7f0ZB7DlWbwgLfG5O8OfEMBhB7xWBvRPFqp0kUi0anRm7bdw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(9686003)(33656002)(7696005)(38100700002)(71200400001)(186003)(316002)(53546011)(55016003)(508600001)(54906003)(6506007)(38070700005)(82960400001)(110136005)(5660300002)(66446008)(64756008)(66476007)(91956017)(66556008)(66946007)(76116006)(2906002)(122000001)(52536014)(8936002)(44832011)(86362001)(8676002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?5Is9EXUSNP99oZTpSaTwfpDbYLn/9q4awKl/sb6kViaD7RRm0lGbi6j6?= =?Windows-1252?Q?8VUD10U6jawBezCMdMbB2pukMue/bXrOBhuucQNYw4rPTmRdRKpetKY1?= =?Windows-1252?Q?AEd4ZN2MiGkmb/y0yTYgSDKDJrejezY7Yq0o6b/5SsTIq1G3eiiRselX?= =?Windows-1252?Q?DWTXO7ssZ99fTjlQ+ZgUZ3+UwYZVrVz+/fBNlAd7OQZSr3qYtvfCmXQw?= =?Windows-1252?Q?0s6WntDdKDnjZR3txxyoBTOEnAam5aI934f+LzRu2g1EyaHhUAcu63TY?= =?Windows-1252?Q?E1DhIjnFXpjFRuUtXhuEbiuK9dLfymWQUGz2NrgZ2CU8BjjI41hT2gmD?= =?Windows-1252?Q?JT9Eig1gW1sJwZPd4cwpsiKp1g+eR5PEHrqpTM3QDWeNQfAsaiUv9ypx?= =?Windows-1252?Q?XIFbsnCZrIf+/JKE6k8h1dKiPvylZYOYxflQJ2Q0f75q4qzu80XzRKdo?= =?Windows-1252?Q?QCcdvZgSQ7udfISRC4MHqfsxKGVJKUr5krHi1RubSWoxcK/93FdV6tAj?= =?Windows-1252?Q?Z4QMbDELZpMdQDoqNaC3aUk9gmUowN2ZNL7SqWsAMBEfgn/HOrS5NJZj?= =?Windows-1252?Q?kRB7d0HV/PXyXo0IRqz6L69Pk7OZNhjwtXGwm8KgWhmQHmfzAI4z0xr9?= =?Windows-1252?Q?Sf1vFHtjvPC6cc7SflONg/E7f3psIwDuksx8VB5r5l98EuaNFFszoP5u?= =?Windows-1252?Q?S6AVhc92o28u9uKB6tnyUxvbbqtAw8iCk5ggourWF8O6s/0Xy4iUfHj6?= =?Windows-1252?Q?coye5Cd0jIBavLSXFW+RMebXej8o3REg8lZLxRqjllWYrifuSkXOxLmL?= =?Windows-1252?Q?V7iuw+TL67J3FpeHWNlSlIG99GeRfqLUOR58qZ+fBkulQoRo3YPunj0d?= =?Windows-1252?Q?M3AmwkFrdCk2LcAPrTu2DB7matvFHN65yg34es5v/+j3ux3ob2nIU93N?= =?Windows-1252?Q?x12KfkFkD9AGL+g/LmabYswQ88O3FJXkKxoP4/8OBWDjFdv/1OR62fn8?= =?Windows-1252?Q?UgfPomAicgxCbpqKo4MBvhKu4eNBo/tfd8YZsHMetFIM3aNZ7GBoAlGH?= =?Windows-1252?Q?P8AWKbXWMxAAvXXNcR9UcV7yewJqi4yWWsKEVGR7gKF33itMIze2upXq?= =?Windows-1252?Q?HydU6U7Kn4fgsgADUm40Knz6uNElpQM7nXdA4WBhzx4kuUnICf4gPrsr?= =?Windows-1252?Q?T4ggB6PF14dtOCqLnGrOr63tCR6UETo53Ovo1u/n/SPny8qnWBhMBSgX?= =?Windows-1252?Q?qNCm2bq5032nB12m90uhPQ2UmWRNSRJnp9zSb7v2L/y5sUj8cvoljLC8?= =?Windows-1252?Q?ewXYLHSdwRg5HHseFkm9cjsBEEaPM4mB5eQgW7kh78hRDTnMlIjZOQjO?= =?Windows-1252?Q?aSNA75gVXai/XnZuRJ7QdJSBjQTyvyoy0wE1TG7w1VYuPDvHuxRL96xb?= =?Windows-1252?Q?rdP0gnmvOaLuzaKQvxmkq+pceNZqNxmgBEcMB6VOlAoQSDtcpINw/2aM?= =?Windows-1252?Q?E11LyHaXma9C6NynDjVbp85hEFGvMMOxXbIvnfEZwbRPbR6PJzDmjvEW?= =?Windows-1252?Q?xv6xs7RjFjiao+Pyx5lNk5cg8WVakqRyLlmE7gW80QcxfsPCD6wLNai9?= =?Windows-1252?Q?aloYOA5yajCkcoxOxm+IPPWpwQwMbmfGYPi5fEWUpN1lOKgBItTYqp78?= =?Windows-1252?Q?abcuENPMUAHxntx5IF+7LlKLrC0L4QSO6+MGY0QM8/poAXNXqCZk5WuA?= =?Windows-1252?Q?+9Bbg4HXn5G1JZn48K77+yfp8g4KelgFNUheGAen8mu3JRLMa9pypjP1?= =?Windows-1252?Q?xCZ30dZMOqcLzaWjkC7jAp+0ZhsxxT3ywHRWSXofSOtOILoy83NmdC3v?= =?Windows-1252?Q?d+aoWHAZqWXcEcU3BNCj4GH+KuwVNGLmHnYRDQ/t2Xs3X1Rax4tw1Yna?= =?Windows-1252?Q?BGsifHxL?= x-ms-exchange-antispam-messagedata-1: 6QlkbaNbpLYmdno6UIpKug8ffR7q2Qi1pOg= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB42173C64ECD8E7B471E5E5FA98349HE1PR07MB4217eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ccaa921c-1317-4f7e-5113-08d9f0dd01d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2022 23:43:45.7672 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: l99WcHMUx9sa+ZhvzFYpzQwtzZQr1nGvRmh0lhbH9SMaoCkjPphHzKbfRy7wArysCP2Oh6FI7XV9g6NYh8HtXxlzSiQSGjWZHNhjKmMQ8qudwDi0Plf/P+hVdBopIvTD X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4142 Archived-At: Subject: Re: [spring] [art] Artart last call review of draft-ietf-spring-segment-routing-policy-16 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, 15 Feb 2022 23:44:00 -0000 --_000_HE1PR07MB42173C64ECD8E7B471E5E5FA98349HE1PR07MB4217eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Cullen: thank you for this review =96 I agree with you and have balloted No= Objection. Authors: thank you for addressing Cullen=92s comment in the nex= t revision of the draft. Francesca From: art on behalf of Ketan Talaulikar Date: Friday, 11 February 2022 at 07:17 To: Cullen Jennings Cc: draft-ietf-spring-segment-routing-policy.all@ietf.org , art@ietf.org , SPRING= WG , last-call@ietf.org Subject: Re: [art] Artart last call review of draft-ietf-spring-segment-rou= ting-policy-16 Hi Cullen, Thanks for your review. We will include the range 0x20-0x7E in the spec and this was also what Benj= amin Kaduk had suggested. We will incorporate this in the next version of t= he document. Thanks, Ketan On Mon, Feb 7, 2022 at 3:10 AM Cullen Jennings via Datatracker > wrote: Reviewer: Cullen Jennings Review result: Ready This draft does not raise any issues specific to the ART area. The use of non UTF symbolic names is appropriate for this use case so I do = not see any issues with strings. I view printable ascii as fairly well defined = but if you want to be clearer, you could say 0x20 to 0x7E. As an outside reader not involved with the spring WG, this draft was relati= vely easy to understand. I do not see any problems with publication. --_000_HE1PR07MB42173C64ECD8E7B471E5E5FA98349HE1PR07MB4217eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Cullen: t= hank you for this review =96 I agree with you and have balloted No Objectio= n. Authors: thank you for addressing Cullen=92s comment in the next revisio= n of the draft.

&nbs= p;

Francesca=

&nbs= p;

From: art <art-bounces@ietf.org> on beha= lf of Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Friday, 11 February 2022 at 07:17
To: Cullen Jennings <fluffy@iii.ca>
Cc: draft-ietf-spring-segment-routing-policy.all@ietf.org <draft-= ietf-spring-segment-routing-policy.all@ietf.org>, art@ietf.org <art@i= etf.org>, SPRING WG <spring@ietf.org>, last-call@ietf.org <last= -call@ietf.org>
Subject: Re: [art] Artart last call review of draft-ietf-spring-segm= ent-routing-policy-16

Hi Cullen,

 

Thanks for your review.=  

 

We will include the ran= ge 0x20-0x7E in the spec and this was also what Benjamin Kaduk had sug= gested. We will incorporate this in the next version of the document.<= /o:p>

 

Thanks,

Ketan

 

 

On Mon, Feb 7, 2022 at = 3:10 AM Cullen Jennings via Datatracker <noreply@ietf.org> wrote:

Reviewer: Cullen Jennings
Review result: Ready

This draft does not raise any issues specific to the ART area.

The use of non UTF symbolic names is appropriate for this use case so I do = not
see any issues with strings. I view printable ascii as fairly well defined = but
if you want to be clearer, you could say  0x20 to 0x7E.

As an outside reader not involved with the spring WG, this draft was relati= vely
easy to understand. I do not see any problems with publication.


--_000_HE1PR07MB42173C64ECD8E7B471E5E5FA98349HE1PR07MB4217eurp_-- From nobody Wed Feb 16 03:23:40 2022 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 DDE1B3A1091; Wed, 16 Feb 2022 03:23:18 -0800 (PST) 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.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164501059883.29081.8434175399536223802@ietfa.amsl.com> Date: Wed, 16 Feb 2022 03:23:18 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-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, 16 Feb 2022 11:23:19 -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 : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-17.txt Pages : 39 Date : 2022-02-16 Abstract: Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e. instructions) that represent a source-routed policy. The headend node steers a flow into an SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-17 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Feb 16 03:26:00 2022 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 6D96E3A10BB; Wed, 16 Feb 2022 03:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8xQdS3XscsS; Wed, 16 Feb 2022 03:25:54 -0800 (PST) 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 B350E3A0CCB; Wed, 16 Feb 2022 03:25:53 -0800 (PST) Received: by mail-vk1-xa32.google.com with SMTP id n142so1074532vkf.5; Wed, 16 Feb 2022 03:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=drSyJQTWKItyPXY/S9u9Prgr4+WlXaCpsRIa9bb5PVk=; b=j+kBfxpRy8ipXlMcQXeo0ZKpf6vCiZ9RrOcA6+igbOitg5foXgBOu2nraHdSxv9GVa 55ti6NQ9EKOWG1E9Pr6P3sCDpE1AiUld6ybgOqjoVAA4Y0y1HtThOwjbBAJHJ9iPkrcD OTBzWJr3q/LVe7k79Kphel9LuQb2F76+QMfhscLYAuVdP+v6gFODgGoOb6XE2dA5i+kq bXVr1XB9XcRgf84Bb4jJL8dLInR5IjW78c1DtVj3e5DrmePAfhqM8vgnYo8FtYOzwS6r hReyJrEsrL1yySXMJVaS+chusVILrECJqIAY+DxU82YA0kj1Zo5c2lGffzSl2S37etM7 MEEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=drSyJQTWKItyPXY/S9u9Prgr4+WlXaCpsRIa9bb5PVk=; b=tFTgFwwkZacyzE/cZeKrk1Jvcx6nrHcpAiAkhgq3qMB2OWITnqTqgylzaPza4j/2lt Rdi6dEl36Sjb99FStBAhbOe5xJTi8Sjx6zH79wx7ba4qEKc33eTi36ZcWV51GdxcKU9f 2L+6V/GaMwnvRYJQXspfsvrOM+VjvrWpytnGEFO61DVDKA7oZ+7yNm9hiDYfFqCOohUP lgmlgGuFPPzN1krMkoYNrr0fTRCUU3MITanM3fuODQ5Obe4JTYwtFOMRuIJvJm9fVBWh gzMv+G+jBFEcMg3rzyyrNgIXVTgPES+ROriz3UiOQai/lEOlmpGPajnrQtcpBK4WTnCY 77ww== X-Gm-Message-State: AOAM531a4q0zd0x13wjbsungD4BRRywdWenDn9/cb25DGjVcskRBUzsD d8yzQXJE9NwMuRqdJlI2mjY8ndghi4kF9iaGf7I= X-Google-Smtp-Source: ABdhPJyDVd1Fkd6clwVYqYLJpawFKuS717JEz5ughCRvYD1Y+kQlBU7gPq2EY6/xAng22s9nrGdSixlEFGLJw4UA2BE= X-Received: by 2002:a1f:2355:0:b0:32a:e5bb:29a1 with SMTP id j82-20020a1f2355000000b0032ae5bb29a1mr757687vkj.2.1645010751062; Wed, 16 Feb 2022 03:25:51 -0800 (PST) MIME-Version: 1.0 References: <164418360967.24977.17268842252865901665@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Wed, 16 Feb 2022 16:55:39 +0530 Message-ID: To: Francesca Palombini Cc: Cullen Jennings , "draft-ietf-spring-segment-routing-policy.all@ietf.org" , "art@ietf.org" , SPRING WG Content-Type: multipart/alternative; boundary="00000000000078064c05d820e92a" Archived-At: Subject: Re: [spring] [art] Artart last call review of draft-ietf-spring-segment-routing-policy-16 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, 16 Feb 2022 11:25:59 -0000 --00000000000078064c05d820e92a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Francesca. We have just posted the updated version of the document : https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-17 On Wed, Feb 16, 2022 at 5:13 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Cullen: thank you for this review =E2=80=93 I agree with you and have bal= loted No > Objection. Authors: thank you for addressing Cullen=E2=80=99s comment in = the next > revision of the draft. > > > > Francesca > > > > *From: *art on behalf of Ketan Talaulikar < > ketant.ietf@gmail.com> > *Date: *Friday, 11 February 2022 at 07:17 > *To: *Cullen Jennings > *Cc: *draft-ietf-spring-segment-routing-policy.all@ietf.org < > draft-ietf-spring-segment-routing-policy.all@ietf.org>, art@ietf.org < > art@ietf.org>, SPRING WG , last-call@ietf.org < > last-call@ietf.org> > *Subject: *Re: [art] Artart last call review of > draft-ietf-spring-segment-routing-policy-16 > > Hi Cullen, > > > > Thanks for your review. > > > > We will include the range 0x20-0x7E in the spec and this was also what > Benjamin Kaduk had suggested. We will incorporate this in the next versio= n > of the document. > > > > Thanks, > > Ketan > > > > > > On Mon, Feb 7, 2022 at 3:10 AM Cullen Jennings via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Cullen Jennings > Review result: Ready > > This draft does not raise any issues specific to the ART area. > > The use of non UTF symbolic names is appropriate for this use case so I d= o > not > see any issues with strings. I view printable ascii as fairly well define= d > but > if you want to be clearer, you could say 0x20 to 0x7E. > > As an outside reader not involved with the spring WG, this draft was > relatively > easy to understand. I do not see any problems with publication. > > > --00000000000078064c05d820e92a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Francesca. We have just posted the updated version = of the document :=C2=A0 https://datatracker= .ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-17

=

On Wed, Feb 16, 2022 at 5:13 AM Francesca Palombini <francesca.palombini@ericsson.com= > wrote:

Cullen: thank you for this review =E2=80=93 I = agree with you and have balloted No Objection. Authors: thank you for addre= ssing Cullen=E2=80=99s comment in the next revision of the draft.=

=C2=A0

Francesca

=C2=A0

From: art <art-bounces@ietf.org> on behalf of Ketan Tala= ulikar <ketan= t.ietf@gmail.com>
Date: Friday, 11 February 2022 at 07:17
To: Cullen Jennings <fluffy@iii.ca>
Cc: draft-ietf-spring-segment-routing-policy.all@iet= f.org <draft-ietf-spring-segment-routing-policy.all@= ietf.org>, art@iet= f.org <art@ietf.or= g>, SPRING WG <spring@ietf.org>, last-call@ietf.org <last-call@ietf.org>
Subject: Re: [art] Artart last call review of draft-ietf-spring-segm= ent-routing-policy-16

Hi Cullen,<= /p>

=C2=A0

Thanks for your review.= =C2=A0

=C2=A0

We will include the range= 0x20-0x7E in the spec and this was also what Benjamin Kaduk had=C2=A0sugge= sted. We will incorporate this in the next version of the document.<= u>

=C2=A0

Thanks,

Ketan

=C2=A0

=C2=A0

On Mon, Feb 7, 2022 at 3:= 10 AM Cullen Jennings via Datatracker <noreply@ietf.org> wrote:

Reviewer: Cullen Jennings
Review result: Ready

This draft does not raise any issues specific to the ART area.

The use of non UTF symbolic names is appropriate for this use case so I do = not
see any issues with strings. I view printable ascii as fairly well defined = but
if you want to be clearer, you could say=C2=A0 0x20 to 0x7E.

As an outside reader not involved with the spring WG, this draft was relati= vely
easy to understand. I do not see any problems with publication.


--00000000000078064c05d820e92a-- From nobody Wed Feb 16 03:26:46 2022 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 EE0843A121B; Wed, 16 Feb 2022 03:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jqZaYCfKuFA; Wed, 16 Feb 2022 03:26:29 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 488AE3A1105; Wed, 16 Feb 2022 03:26:29 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id e26so2079060vso.3; Wed, 16 Feb 2022 03:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VCIeFGC9Ec5IVjAKeYOwq8oRiujgHBvRiyJxV2XXeKA=; b=pPC0bfjEYKSHIBPSFeIBDIU4hQrcL3G6KvqTAtZTpDP2Yyu4fs++63bg2ZPAyqAve4 gQvUn3Z85j4wU012elM1U1D6ySo0gJdPVyEJ8AO7H8AQk3Se4LZ/O+iOh4ll1vzlWcOu DOUi+Grloojz4rsTYN2XXDlduLxO1Oa1wgWHjredlz6RjhRZ/nveVcOyLdJxS7cF2wiY aOWAt9iOY7ash+Mm7x6VOgOy10ChdPO6hOsVcFG3J8OXPsK/aj7AIsM7sn5PvcPu9yAD Mhj5vR35cVmUjmpiTcFAWVSjJJg5LlDd+acTLGjNkz5xdROA5Wz5Vu6Y1Lchehsnk9Oz nRDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VCIeFGC9Ec5IVjAKeYOwq8oRiujgHBvRiyJxV2XXeKA=; b=b8OQO6BJb4OSZm6xh2tE+hM3AWHatltaJOUXe3TKAGMEeMnc3M8WGlGZ1kMkpMVh13 ZE7SCCCFxKLyVw2EHnKV6deIRn+VP2OpsDyGp/ZUlXP5QxNo6H6xbHtwlYB2EPiinZNl tQTATcSMvyGmL/eDcJUBMAi6OcGp/mKyfbJbwSTf1NJmV110nncTok58SN6aC9+5l1fF /RBZc5U7AUZ4cT5QNSxD1WkkKYO7/3l0tTxnfQbKt1zQaRQlZj/T3ZSJYOulWMkGTQbS 03PfOnheqsM1fKSHLKRFGSy/R+ueyGZbl7yPkWcpnOrZssIAGQWAPNaIQHukPkdjompQ 1dbw== X-Gm-Message-State: AOAM531Rcc/AxYXFwrfHQT1V69ZMn95eUlih7QOABvV2Lc2Rg4qcybw0 YutFj7b4lFycizbtyR/rTyPhgCRoVPGBaTJYYf2CN3xoL3A= X-Google-Smtp-Source: ABdhPJzkwLUES3WrcY+8/s8Luhj8vMqJmtR3wLYrslBEtMrLI7kf3JPAU16AmrEHI6hOskEoFSX896ESJ9XmB2KdgIU= X-Received: by 2002:a05:6102:3591:b0:310:ef5d:d2be with SMTP id h17-20020a056102359100b00310ef5dd2bemr850565vsu.34.1645010787277; Wed, 16 Feb 2022 03:26:27 -0800 (PST) MIME-Version: 1.0 References: <164492775749.13041.11325015268231469212@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Wed, 16 Feb 2022 16:56:16 +0530 Message-ID: To: "Rob Wilton (rwilton)" Cc: The IESG , "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , SPRING WG , "james.n.guichard@futurewei.com" Content-Type: multipart/alternative; boundary="000000000000a0a20805d820eb0c" Archived-At: Subject: Re: [spring] Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT) 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, 16 Feb 2022 11:26:44 -0000 --000000000000a0a20805d820eb0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Rob and we have just posted an updated version of the document : https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-17 On Tue, Feb 15, 2022 at 9:41 PM Rob Wilton (rwilton) wrote: > Hi Ketan, > > > > All sounds good. > > > > Thanks, > > Rob > > > > > > *From:* Ketan Talaulikar > *Sent:* 15 February 2022 15:56 > *To:* Rob Wilton (rwilton) > *Cc:* The IESG ; > draft-ietf-spring-segment-routing-policy@ietf.org; spring-chairs@ietf.org= ; > SPRING WG ; james.n.guichard@futurewei.com > *Subject:* Re: Robert Wilton's No Objection on > draft-ietf-spring-segment-routing-policy-16: (with COMMENT) > > > > Hi Rob, > > > > Thanks for your quick response and please check further inline below with > KT2. > > > > > > On Tue, Feb 15, 2022 at 9:05 PM Rob Wilton (rwilton) > wrote: > > Hi Ketan, > > > > Please see inline =E2=80=A6 > > > > *From:* Ketan Talaulikar > *Sent:* 15 February 2022 14:17 > *To:* Rob Wilton (rwilton) > *Cc:* The IESG ; > draft-ietf-spring-segment-routing-policy@ietf.org; spring-chairs@ietf.org= ; > SPRING WG ; james.n.guichard@futurewei.com > *Subject:* Re: Robert Wilton's No Objection on > draft-ietf-spring-segment-routing-policy-16: (with COMMENT) > > > > Hi Rob, > > > > Thanks for your review and your comments. Please check inline below for > responses. > > > > We will include these changes in the next update of the document. > > > > > > On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton via Datatracker < > noreply@ietf.org> wrote: > > Robert Wilton has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document, I have a few minor suggestions that may improve > the > readability of this document. > > Segment Routing (SR) allows a headend node to steer a packet flow > along any path. Intermediate per-path states are eliminated thanks > to source routing. The headend node steers a flow into an SR Policy. > The packets steered into an SR Policy carry an ordered list of > segments associated with that SR Policy. This document details the > concepts of SR Policy and steering into an SR Policy. > > Possibly the abstract would be more readable if it gave a brief > description of > what an SR Policy is. > > > > KT> How about if we added the following sentence in the abstract and the > introduction? Note that this document doesn't define SR Policy - that com= es > from RFC8402. > > > > SR Policy is an ordered list of segments (i.e. instructions) that > represent a source-routed policy. > > > > Looks good. > > > > > > > Segment Routing (SR) [RFC8402] allows a headend node to steer a > packet flow along any path. The headend is a node where the > instructions for source routing (i.e. segments) are instantiated into > the packet and hence becomes the starting node for a specific segment > routing path. Intermediate per-path states are eliminated thanks to > source routing. > > Would "written" be better than "instantiated"? > > > > KT> Ack. > > > > > The headend node is said to steer a flow into a Segment Routing > Policy (SR Policy). [RFC8402] introduces the SR Policy construct and > provides an overview of how it is leveraged for Segment Routing use- > cases. > > I was slightly confuses as where SR policy is actually defined. My > interpretation is that the base definition is in RFC8402, but that > definition > is being explained in more detail in this document. Is that correct? If > so, > possibly adding a sentence here to make that clear may be helpful. > > > > KT> Yes, that is correct. The introduction does say that RFC8402 > introduces the SR Policy construct (para 2) and that this document detail= s > it (para 4). > > > > Okay. It would be nice if the text in paragraph 2 and 4 could be more > closely aligned, but I don=E2=80=99t actually see an easy/clean way of do= ing this. > > > > KT2> We'll work on this. > > > > > > > > > 2.9. Active Candidate Path > > I found the description of the path selection to be somewhat confusing. = I > would suggest this might be clearer if it just gave the full list of path > selection, rather than treating the preference as a special case and > listing > the rest of tie-breakers. > > E.g., > > 1. Higher value of preference is selected. > > 2. Higher value of Protocol-Origin is selected. > > 3. If specified by configuration, prefer the existing installed > path. > > 4. Lower value of originator is selected. > > 5. Finally, the higher value of discriminator is selected. > > The paragraphs above this list would need to be changed slightly, but the > paragraphs below would then be easier to read/understand (at least to me)= . > > > > KT> The motivation for the current text is that preference is the primary > parameter (we can clarify this in the text) in determining the order of > selection of active candidate path. The other parameters are coming from > the identifiers of the candidate path and are hence called tie-breakers i= n > the event of having the same preference (for any reason whatsoever). > > > > Okay. It was this paragraph that initially threw me (relative to the > list): > > > > o The preference, being the first tiebreaker, allows an operator to > > influence selection across paths thus allowing provisioning of > > multiple path options, e.g., CP1 is preferred and if it becomes > > invalid then fallback to CP2 and so on. Since preference works > > across protocol sources, it also enables (where necessary) > > selective override of the default Protocol-Origin preference, > > e.g., to prefer a path signaled via BGP SR Policy over what is > > configured. > > > > Perhaps this text shouldn=E2=80=99t refer to preference being a tie-break= er, and > perhaps it would be better to list it before the Protocol-Origin > paragraph? I.e., I couldn=E2=80=99t figure out why something lower in th= e list > would be able to override the Protocol-Origin, that is higher in the list= . > > > > KT2> Ack > > > > > > > > > 4. Segment Types > > Based on the desired dataplane, either the MPLS label stack or the > SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. > > A couple of the types, i.e., the IPv4 related E and F, don't obviously > appear > to be either MPLS or SRv6. Hence does the first sentence need to be > expanded > to cover these types? > > > > KT> These are only relevant/applicable for SR-MPLS. We can do - > s/label/SR-MPLS label - to make this more explicit. > > > > Ah, okay. If you make this more explicit then doing it in the individual > types might be useful. Or even more explicit would be to list the types > that are relevant to SR-MPLS and those which are relevant to SRv6. But > I=E2=80=99ll leave this to your discretion. > > > > KT2> We will go with the explicit text for type E & F to align with other= s. > > > > Thanks, > > Ketan > > > > > > Thanks, > > Rob > > > > > > Thanks, > > Ketan > > > > > Regards, > Rob > > --000000000000a0a20805d820eb0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rob and we have just posted an updated version of t= he document :=C2=A0 https://datatracker= .ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-17

=


On Tue, Feb 15, 2022 at 9:41 PM Rob Wilton (rwilton) &= lt;rwilton@cisco.com> wrote:

Hi Ketan,

=C2=A0

All sounds good.

=C2=A0

Thanks,

Rob

=C2=A0

=C2=A0

F= rom: Ketan Talaulikar <ketant.ietf@gmail.com>
Sent: 15 February 2022 15:56
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: The IESG <= iesg@ietf.org>; draft-ietf-spring-segment-routing-policy= @ietf.org; = spring-chairs@ietf.org; SPRING WG <spring@ietf.org>; james.n.guichard@futurewei.com Subject: Re: Robert Wilton's No Objection on draft-ietf-spring-s= egment-routing-policy-16: (with COMMENT)

=C2=A0

Hi Rob,

=C2=A0

Thanks for your quick res= ponse and please check further inline below with KT2.

=C2=A0

=C2=A0

On Tue, Feb 15, 2022 at 9= :05 PM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Ketan,

=C2=A0

Please see inline =E2=80=A6

=C2=A0

From: Ketan Talauli= kar <ketant.i= etf@gmail.com>
Sent: 15 February 2022 14:17
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: The IESG <= iesg@ietf.org>; draft-ietf-spring-segment-routing-policy@ietf.org; spring-chairs@ietf.org; SPRING WG <spring@ietf.org>; james.n= .guichard@futurewei.com
Subject: Re: Robert Wilton's No Objection on draft-ietf-spring-s= egment-routing-policy-16: (with COMMENT)

=C2=A0

Hi Rob,

=C2=A0

Thanks for your review and your comments. Please check inline below for res= ponses.

=C2=A0

We will include these changes in the next update of the document.=

=C2=A0

=C2=A0

On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton via Datatracker <noreply@ietf.org> wro= te:

Robert Wilton has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-s= pring-segment-routing-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document, I have a few minor suggestions that may improve t= he
readability of this document.

=C2=A0 =C2=A0Segment Routing (SR) allows a headend node to steer a packet f= low
=C2=A0 =C2=A0along any path.=C2=A0 Intermediate per-path states are elimina= ted thanks
=C2=A0 =C2=A0to source routing.=C2=A0 The headend node steers a flow into a= n SR Policy.
=C2=A0 =C2=A0The packets steered into an SR Policy carry an ordered list of=
=C2=A0 =C2=A0segments associated with that SR Policy.=C2=A0 This document d= etails the
=C2=A0 =C2=A0concepts of SR Policy and steering into an SR Policy.

Possibly the abstract would be more readable if it gave a brief description= of
what an SR Policy is.

=C2=A0

KT> How about if we added the following sentence in the abstract and the= introduction? Note that this document doesn't define SR Policy - that = comes from RFC8402.

=C2=A0

SR Policy is an ordered list of segments (i.e. instructions) that represent= a source-routed policy.

=C2=A0

Looks good.

=C2=A0

=C2=A0


=C2=A0 =C2=A0Segment Routing (SR) [RFC8402] allows a headend node to steer = a
=C2=A0 =C2=A0packet flow along any path.=C2=A0 The headend is a node where = the
=C2=A0 =C2=A0instructions for source routing (i.e. segments) are instantiat= ed into
=C2=A0 =C2=A0the packet and hence becomes the starting node for a specific = segment
=C2=A0 =C2=A0routing path.=C2=A0 Intermediate per-path states are eliminate= d thanks to
=C2=A0 =C2=A0source routing.

Would "written" be better than "instantiated"?

=C2=A0

KT> Ack.

=C2=A0


=C2=A0 =C2=A0The headend node is said to steer a flow into a Segment Routin= g
=C2=A0 =C2=A0Policy (SR Policy).=C2=A0 [RFC8402] introduces the SR Policy c= onstruct and
=C2=A0 =C2=A0provides an overview of how it is leveraged for Segment Routin= g use-
=C2=A0 =C2=A0cases.

I was slightly confuses as where SR policy is actually defined.=C2=A0 My interpretation is that the base definition is in RFC8402, but that definiti= on
is being explained in more detail in this document.=C2=A0 Is that correct?= =C2=A0 If so,
possibly adding a sentence here to make that clear may be helpful.

=C2=A0

KT> Yes, that is correct. The introduction does say that RFC8402 introdu= ces the SR Policy construct (para 2) and that this document details it (par= a 4).

=C2=A0

Okay.=C2=A0 It would be nice if the text in paragraph 2 and 4 could be more= closely aligned, but I don=E2=80=99t actually see an easy/clean way of doi= ng this.

=C2=A0

KT2> We'll work on= this.

=C2=A0

=C2=A0

=C2=A0


2.9.=C2=A0 Active Candidate Path

I found the description of the path selection to be somewhat confusing.=C2= =A0 I
would suggest this might be clearer if it just gave the full list of path selection, rather than treating the preference as a special case and listin= g
the rest of tie-breakers.

E.g.,

=C2=A0 =C2=A01.=C2=A0 Higher value of preference is selected.

=C2=A0 =C2=A02.=C2=A0 Higher value of Protocol-Origin is selected.

=C2=A0 =C2=A03.=C2=A0 If specified by configuration, prefer the existing in= stalled
=C2=A0 =C2=A0 =C2=A0 =C2=A0path.

=C2=A0 =C2=A04.=C2=A0 Lower value of originator is selected.

=C2=A0 =C2=A05.=C2=A0 Finally, the higher value of discriminator is selecte= d.

The paragraphs above this list would need to be changed slightly, but the paragraphs below would then be easier to read/understand (at least to me).<= u>

=C2=A0

KT> The motivation for the current text is that preference is the primar= y parameter (we can clarify this in the text) in determining the order of s= election of active candidate path. The other parameters are coming from the= identifiers of the candidate path and are hence called tie-breakers in the event of having the same preferen= ce (for any reason whatsoever).

=C2=A0

Okay.=C2=A0 It was this paragraph that initially threw me (relative to the = list):

=C2=A0

=C2=A0=C2=A0 o=C2=A0 The preference, being the first tiebreaker, allo= ws an operator to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 influence selection across paths thus = allowing provisioning of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multiple path options, e.g., CP1 is pr= eferred and if it becomes

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 invalid then fallback to CP2 and so on= .=C2=A0 Since preference works

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 across protocol sources, it also enabl= es (where necessary)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 selective override of the default Prot= ocol-Origin preference,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 e.g., to prefer a path signaled via BG= P SR Policy over what is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configured.

=C2=A0

Perhaps this text shouldn=E2=80=99t refer to preference being a tie-breaker= , and perhaps it would be better to list it before the Protocol-Origin para= graph?=C2=A0 I.e., I couldn=E2=80=99t figure out why something lower in the= list would be able to override the Protocol-Origin, that is higher in the list.

=C2=A0

KT2> Ack=C2=A0<= u>

=C2=A0

=C2=A0

=C2=A0


4.=C2=A0 Segment Types

=C2=A0 =C2=A0Based on the desired dataplane, either the MPLS label stack or= the
=C2=A0 =C2=A0SRv6 Segment Routing Header [RFC8754] is built from the Segmen= t-List.

A couple of the types, i.e., the IPv4 related E and F, don't obviously = appear
to be either MPLS or SRv6.=C2=A0 Hence does the first sentence need to be e= xpanded
to cover these types?

=C2=A0

KT> These are only relevant/applicable for SR-MPLS. We can do - s/label/= SR-MPLS label - to make this more explicit.=C2=A0

=C2=A0

Ah, okay.=C2=A0 If you make this more explicit then doing it in the individ= ual types might be useful.=C2=A0 Or even more explicit would be to list the= types that are relevant to SR-MPLS and those which are relevant to SRv6.= =C2=A0 But I=E2=80=99ll leave this to your discretion.

=C2=A0

KT2> We will go with t= he explicit text for type E & F to align with others.

=C2=A0

Thanks,

Ketan

=C2=A0

=C2=A0

Thanks,

Rob

=C2=A0

=C2=A0

Thanks,

Ketan

=C2=A0


Regards,
Rob

--000000000000a0a20805d820eb0c-- From nobody Wed Feb 16 09:00:01 2022 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 181613A13C5; Wed, 16 Feb 2022 08:59:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <164503079307.9996.17286143339105134181@ietfa.amsl.com> Date: Wed, 16 Feb 2022 08:59:53 -0800 Archived-At: Subject: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 16 Feb 2022 16:59:53 -0000 John Scudder has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message. 1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.†I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right? If that's so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.) Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature? 2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits†discussed in Section 8.8. - I would be more comfortable if the work were all done in one place, to the extent possible. - Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don't see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive. I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/ Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture†document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration. 3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published. 4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have. 1. I see that Cullen Jennings referred to this in his ART review, but I’d like to talk about it a little more: why have you chosen to restrict symbolic names to ASCII? UTF-8 is the more usual choice in this context; indeed implementations may have to go to extra effort to scrub their input to insure that only ASCII is present. BCP 18 doesn’t require you to internationalize your strings, of course, it gives you two options, of which you have (sort of, you don't have the "US-") followed the latter: This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII. But in 2022 the choice to restrict symbolic names to ASCII seems unusual enough to invite the question. If you do stick with ASCII as currently written, might you add text mandating that implementations scrub their input to prevent non-ASCII characters from being accepted? From nobody Wed Feb 16 09:04:48 2022 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 EBE403A13B9; Wed, 16 Feb 2022 09:04:39 -0800 (PST) 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, T_SPF_PERMERROR=0.01] 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 nLfxBOcZjvol; Wed, 16 Feb 2022 09:04:30 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2072d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e89::72d]) (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 0BDA93A13E1; Wed, 16 Feb 2022 09:04:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CV/um4IwPpJc5Wtcb8+gCEC3MOkRQcjYUXnn1+s91OxMKxIGoLXP2P3klTAA0vAu6J/DPGCbN8HW2Lb/bLbepsqmKtDrFZ9q3BD+1yENHCH9bpaGhTCbQQYJYVyG1ykp58PBD8SlM/TwwOoo/yNxZZlNsz/PxoKf/+nkbefPwHsFG9/hth+c73q778UGg86mCpFVQIZTIAllmJq+ZEikRXAYA2HfNpBoPFt2AA67a/7ORGPR0TNj2HXEFjCX3kwiYuYrtNS9E10dgOwnvdR7IlyymDbD1GA0IldkZdYmMIiIW0hJVtXjI+kk6qLYK+hvK+glr/nSm/cYyzko5J81Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nIfg1fAm94B49blHfcitdrY14JjNc3MAvg9NMwCzHTY=; b=fJtRQMWG3cQL2jiqUg6dhzHfyUhhZS1W9gw2tZxEnk8HV4wh1G5VrR5HptYav5lBIcCQZ6t4lXWBToLy6kDZok/jaxUKKMfrHh8plzOxtJdydcoTWCCws2PR1EeE1jt50BhOJ7WCUeeMLml5b2nnhFkGSMiv0E5OHtCiT00Rg0UK32dohWfxnNJ3pUUTgXvZhXI/wqd/xyuIiOmQbhI2qZH86iS9URPWj3JO1R6MKSx3GQ2v9yyrR/KVclUpZRqk3GyTDXP8+KCkLQGs5YzvXcY5eUqUTgBx9//xe+cbyU1vBTu0mkdRPbFZQ/uTxF3IShY/zqhbi5WIAh0HSUxMag== 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=nIfg1fAm94B49blHfcitdrY14JjNc3MAvg9NMwCzHTY=; b=SXaaz/wKpmQZESIrxhwkNcE2O/Ft+NTnculMalYdQgEvZlLU0nc8kEdD0BWaqhGD2QWRi3k3qEOoKave6bykxkeVwiUMbEQEMct3RnVyiXY6t3G136geI7nMyhkPSoIUyUhAu1mZVj0PZW6pTbjNQyI00O3d/VVMHFdsGtCK6WU= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by MN2PR13MB3181.namprd13.prod.outlook.com (2603:10b6:208:136::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.7; Wed, 16 Feb 2022 17:04:22 +0000 Received: from MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::ac50:7bb3:e622:80b3]) by MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::ac50:7bb3:e622:80b3%4]) with mapi id 15.20.4995.014; Wed, 16 Feb 2022 17:04:22 +0000 From: James Guichard To: John Scudder , The IESG CC: "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) Thread-Index: AQHYI1afCx33Teo8/kyYyHZ7pxyyCqyWZPwA Date: Wed, 16 Feb 2022 17:04:21 +0000 Message-ID: References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: <164503079307.9996.17286143339105134181@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c99814e7-9d73-4fdf-efd8-08d9f16e60d1 x-ms-traffictypediagnostic: MN2PR13MB3181:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FEpmibT9yJyh9w8PpN+sFho3jIBlS0w/iTrEo7EVphTNf8ZL+q3qVue0/1XnNovs1E4TF5JzDKREt5uITCsvwpdeqLjhnF96r0t53FBXAzHPHO6IFFpp8E0m4Ch3pH7Y5w4AWDv2La3rGPG410PRSDPVfWrogmrfXpW4tteSfFBkmputOaBwk5ZfS5SKVmjNxiBKdWlVbd6KRVtwrcT159XtJ51820Nad/SlWTGocO/95oWD55kAbEwaSGnZPpUqijcWVEzTg1OS0D3xAoWhSneCYvydCGEP89lQUiihB3b3vMYpoECXenuzyH547RoJDzTMuYkgFEYHnW62Y5JtaY8FRbaGMt6RKUb0nUI0HgLfjU8jnwKYZyl2bBkB2MW8dU7Fxm2boqfLIiCVg65JgyUPbVjuNPvbxFt2DdbafCiJVUhJ/8Bao5Ofhy+bIcbqx8TaZ7wGM3kyn6H3v22zvTidXwR4o2SH/9afILTPnsYOz08V4JfeXzcAX/AaeeMloVLwXiR6m6/l1TZJ8s/BZwZKVUoyUBFIa/r1O0AfgQYZGz2GJZRGrGVBDeqH+DqKzWP8KJaM+ZjaUT6Kj+Xz3UZrO6AMji3CWNToHVpJqKgfxXnpNvJMe7kSUzuXlUDGQk8HOyW4YfZwsGkiRbd89BGw/+ggvDbgHQuFT2B6HbbRmxz3+NZL43ouiGGG+xbYWUHF64OvWEFBlEJe4OUzPtNq/RkHog/RUEZpaHma4cTWuFCn2eVsf08P0L67nDxCDlmsRuva5C86ZuresylHPpttNcDXCnxoW57LHk8RbXgksGzWhb2KqzjkqX5NovYEsa3JG1XdMjQqkxHHN2WLVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB4206.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(33656002)(83380400001)(86362001)(122000001)(38100700002)(76116006)(66946007)(4326008)(8676002)(66476007)(66446008)(64756008)(66556008)(110136005)(316002)(55016003)(54906003)(2906002)(52536014)(5660300002)(8936002)(45080400002)(966005)(186003)(7696005)(9686003)(53546011)(6506007)(71200400001)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?V1gzTHpXZTJaa2h0MUtKY1FDUDFlUzJOM3Ztb3BlR2tQdkkyWWJ5dHVOSmtM?= =?utf-8?B?OXF5RlljbkE0SVlOTlpKM203Zng1N2Z1NkxnNkVXellaU0ZZbU9rMGpwc1RH?= =?utf-8?B?eDA5eUdxaHpRZ0JSTlRncW55VlUrWklwc29SVExNZVBiU0xZWVgyU3hJL2ht?= =?utf-8?B?ZitMOWJUNm0rYkpvUHJ2WkhaNmUrM2xsYlIzSUdyV3NsbStTb3RHK1crbmJP?= =?utf-8?B?VkNHV2pSSm9IOUR2NEkwbDFpczR1TmlWV2k4MEZPSlVKZkxCdW4zbmZNcGtH?= =?utf-8?B?SGpELzNMTGxwVFd5Zkp1ZGVtVGQra2dweldxNmcwRDIvWFVFLzdUd3czUmR0?= =?utf-8?B?eExPdXdhNCtiQ3VFQXNuWjlXYTRTUEVrdjdPVFk0RitDVVRrQVNKcHY5VUVv?= =?utf-8?B?c2JjekxwY0xuZUJHY1I0L1N4ZXVxWlBDUnNiOGh1QSt4ZXIrbXA2eFl6d21O?= =?utf-8?B?dzJjYlZPaDhuVWpSRDBMZkhHSWxDMVF2NEdsQ3RUQkU0cS9HL2FEUGVWTWo1?= =?utf-8?B?ZjdvRWZObGZkcmo2ZmgyWGJQcmV1MmYyM1Rla21GT3M0YkxHUVZldFBuekd0?= =?utf-8?B?eHFlUCtrWjdLeU5GQWlRWXdmeVljekhiL0hTMnpQNlQ4Qno2a3o2N2VuMTU2?= =?utf-8?B?WEFMeldEWkJVdDJmRytiRHErSEZzdEVITTNsRkVOSGdrT0cxVTVobk5sQ1NC?= =?utf-8?B?Q2dkUndhYld3MmZtbm94azVoTTZmNzJpK2ZERmU0UFYwMHhtc3A3S2dSdTEz?= =?utf-8?B?blZ0RHhUcHpCR3lMc0p5VjBRbXJTa2dDbFgyTXkyQkt3OTNHNDBKSFhEZDY2?= =?utf-8?B?RVBMeUQvWUlWQkFmL2lxYUJqY1hUNmlpQVdKdlZ6My80ajlobFdyS0Zvd1JL?= =?utf-8?B?bGJQaU9VcG52S2JnV01zby9XK1FSaXhURHl0bGNuOUxmYkFWdzFOWlA4aFl5?= =?utf-8?B?V0ZrUExRNUROYnJMUjJ3MUZ4VmV0RmxXMXNGcEl0Q216Y2ZiNHU5c3Byc2Nz?= =?utf-8?B?dWZVQUhMR1BlWEVqVUJiNWNZZFpUYjZ5Q1ZDRVpZRzRaWW82M3Yzc3N6bFRS?= =?utf-8?B?THVwcGxFMDlzeE9kRmY2R3RUQktheW9ua05lL3VaKzltZ2pJNkFqS3VFNllO?= =?utf-8?B?b2NsaFNMSUJjSCtFQU1tcnJjdFBSYnkvYXVkTGZpY1lsWlhWcTQ2UUc0ZFVG?= =?utf-8?B?VnZRbWd1TWVHQWhqN3dFSFhCdWtGVVhsdy9DbUthQTF4UENYSlVYTWVibVpH?= =?utf-8?B?czVaSVIzN0FiU1lFRlIxWkp5QmNoeVh2eGZGd09Fa1IxVG93SVNXKzRtSlhN?= =?utf-8?B?ei9admVqeEs0UHVHajJVVmQySUR5VitPa21PaCt1eHJWNzBlVENyb2JOaUgx?= =?utf-8?B?OWpZcmZoV3VaM3BjMk5IMUtabTkvNklMblZNZ1N0eEd2MlNFVGRINnFlZVpp?= =?utf-8?B?OGYyY1lkN01QN1hMdGtIQXcrOGtZaVl5SDhUbmhrekRlNU5mbW00U1ZHWDVM?= =?utf-8?B?MHpzVEJhaWEvRVJrUVlLUnEzbnlEZENzVFQ5M1hlSWNUbGF4enA2dU1ETzZU?= =?utf-8?B?QVJLVUhxM2VGc0NidWJDVXlqMWhoV3Ivb3kxRXhDWG03Q3dNZjhtLzJ5Y2xU?= =?utf-8?B?TFNQVUdmR0VrRWZ0NFB5clJnRmhqSWRxMVdEOUFnekJ6cHZjT1M5cTdkdk1u?= =?utf-8?B?enlYZWRvZWF1OUQ1bm0vQkdJbnY2Q3F2RngvMXdmNkhaUjh5RnBsTCswMk5l?= =?utf-8?B?RWdNMVlnNGFQeVV2OCtNTXJZOGNPenJpVTJIODJ2OFJJeVMvOGhOOTRac0Jn?= =?utf-8?B?WUFCS3JqcU55em0zc085amFCMFRrWlBOcERpTTlicUQ5My9zVXQ5RkgvdW4y?= =?utf-8?B?VzB2Ykw3MENFRGE1SXRhRGZtSTdBZnIvR2FCTHIySDQ1cTBXUzZYZUpjYUsz?= =?utf-8?B?Smk4T2hoWDlOK3M3ZTU2QldoR1l0am1mSE1jSmxTdSsrazhqdTB3QjhIQUVM?= =?utf-8?B?TUNKSXE0cmtkcDhXdm0xOWNLRWlOd0Y3TGROZ25uTFNVQ1pKZkt2cEdBR3Bx?= =?utf-8?B?TExiMGFiNS94QmtPb1l1VWc2RXVkSjlYNG1SVXlRYUwrWXRKK205Rnd6ZHR5?= =?utf-8?B?c3VMTkU3cHNPWDdvUWtwbk9NbFhiZWlUaUJXL0JVVWgzcWRCYndCWUIxaCtY?= =?utf-8?B?MG1Rck45Sm95Y0RJVUtLUkwyQzF6Yi96bmpEWnpHbVF2bGdTVUxOM0FXdi9Z?= =?utf-8?Q?n53YfzAFhqDFRSWYaPzLaqjGw/FdsLU79DbhGe6c9s=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB4206.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c99814e7-9d73-4fdf-efd8-08d9f16e60d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 17:04:21.7703 (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: UNNzBoyfmV+v4yEFvEko7QfyZABCpY+vwTL8UUAICDTI/nAj+Pk+1W6wcvD+WUp2CyT1ucY2+N3sbTc93i4y1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3181 Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 16 Feb 2022 17:04:40 -0000 SGkgSm9obiwNCg0KVGhpcyBpcyB0aW1lbHkgYXMgSSBhY3R1YWxseSBtYWRlIHNvbWUgY2hhbmdl cyB0byB0aGUgc2hlcGhlcmQgd3JpdGV1cCB0aGlzIG1vcm5pbmcgdG8gbWFrZSBpdCBjbGVhcmVy IChJIGhvcGUpLiBJIGNoYW5nZWQgdGhlIHRleHQgeW91IGFyZSByZWZlcnJpbmcgdG8gYXMgZm9s bG93czoNCg0KU3RhbmRhcmQgVHJhY2sgaXMgcmVxdWVzdGVkIGFuZCBpbmRpY2F0ZWQgaW4gdGhl IHRpdGxlIHBhZ2UgaGVhZGVyLiBUaGlzIGlzIGFwcHJvcHJpYXRlIGZvciBhIHNwZWNpZmljYXRp b24gb2YgcGFja2V0IHN0ZWVyaW5nIGludG8gYW4gU1IgcG9saWN5IG5lZWRpbmcgaW50ZXJvcGVy YWJpbGl0eSBiZXR3ZWVuIHRoZSBwb2xpY3kgc291cmNlIC8gY29udHJvbGxlciBvZiB0aGUgcG9s aWN5IGluc3RhbnRpYXRpb24gYW5kIHRoZSB0cmFmZmljIGhlYWQgZW5kIGFzIHRoZSBkZXN0aW5h dGlvbiBvZiB0aGUgcG9saWN5IHRlcm1pbmF0aW9uLg0KDQpKaW0NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEpvaG4gU2N1ZGRlciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlA aWV0Zi5vcmc+IA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNiwgMjAyMiAxMjowMCBQTQ0K VG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1wb2xpY3lAaWV0Zi5vcmc7IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7IHNwcmlu Z0BpZXRmLm9yZzsgSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNv bT47IEphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQpTdWJq ZWN0OiBKb2huIFNjdWRkZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1wb2xpY3ktMTc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkpvaG4gU2N1 ZGRlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMTc6IERpc2N1c3MNCg0KV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K DQoNClBsZWFzZSByZWZlciB0byBodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZibG9nJTJGaGFuZGxp bmctaWVzZy1iYWxsb3QtcG9zaXRpb25zJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1 aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzEzMTRlOTgzODUwODRlYzIyOWQ2MDhkOWYxNmRjMTMw JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNjI3NTk2 MjU3Njg2MCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0 YT1IRnFsUW1aZWtyTW1UTDIxNmxnTmx6cmpQdTRRY1E5bzBodEFsJTJCelRQcjAlM0QmYW1wO3Jl c2VydmVkPTANCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGhvdyB0byBoYW5kbGUgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90 aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9uYW0xMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct cG9saWN5JTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2Vp LmNvbSU3QzEzMTRlOTgzODUwODRlYzIyOWQ2MDhkOWYxNmRjMTMwJTdDMGZlZThmZjJhM2IyNDAx ODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNjI3NTk2MjU3Njg2MCU3Q1Vua25vd24l N0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJ NklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1YVUMlMkZOQVo2M0FEbFc0 U2hUMWZzckZyUURiMWwzazIlMkJpSmlzRktTQm9pWSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSeKAmXZlIGRvbmUgYW4g aW5pdGlhbCByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCBhbmQgaGF2ZSBzZXZlcmFsIGNvbmNlcm5z IEnigJlkIGxpa2UgdG8gZGlzY3Vzcy4gSSBhcG9sb2dpemUgZm9yIG5vdCBhbHNvIHByb3ZpZGlu ZyBhIGZ1bGwgcmV2aWV3IGFzIGNvbW1lbnRzIGluIHRoaXMgYmFsbG90LCBJIGp1ZGdlZCBpdCBt b3JlIGltcG9ydGFudCB0byBiZWdpbiB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0aGVzZSBwb2ludHMg dGltZWx5LCB0aGFuIHRvIHByb3ZpZGUgYWxsIGNvbW1lbnRzIGluIGEgc2luZ2xlIG1lc3NhZ2Uu DQoNCjEuIFRoZSBzaGVwaGVyZCB3cml0ZXVwIGluZGljYXRlcyB0aGF0IOKAnFN0YW5kYXJkIFRy YWNrIGlzIHJlcXVlc3RlZCBhbmQgaW5kaWNhdGVkIGluIHRoZSB0aXRsZSBwYWdlIGhlYWRlci4g VGhpcyBpcyBhcHByb3ByaWF0ZSBmb3IgYSBzcGVjaWZpY2F0aW9uIG9mIHBhY2tldCBzdGVlcmlu ZyBpbnRvIGFuIFNSIHBvbGljeSBuZWVkaW5nIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGUg aW5ncmVzcy9zb3VyY2Ugb2YgdGhlIHBvbGljeSBpbnN0YW50aWF0aW9uIGFuZCB0aGUgZWdyZXNz L2Rlc3RpbmF0aW9uIG9mIHRoZSBwb2xpY3kgdGVybWluYXRpb24u4oCdDQoNCkkgcmVhbGl6ZSBp dOKAmXMgdW51c3VhbCB0byBhc2sgdG8gZGlzY3VzcyBhIHNoZXBoZXJkIHdyaXRldXAgcmF0aGVy IHRoYW4gdGhlIHNwZWMgaXRzZWxmLCBidXQgSSB0aGluayB0aGlzIG9uZSByaXNlcyB0byB0aGUg bGV2ZWwuIE15IGNvbmNlcm4gaXMgdGhhdCB0aGlzIGRlc2NyaXB0aW9uIChuZWVkaW5nIGludGVy b3BlcmFiaWxpdHkgYmV0d2VlbiB0aGUgaW5ncmVzcyBhbmQgdGhlIGVncmVzcykgZG9lc27igJl0 IGNvbXBvcnQgd2l0aCBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBTZWdtZW50IFJvdXRpbmcgYXJj aGl0ZWN0dXJlLg0KU3VyZWx5LCBvbmUgb2YgdGhlIGtleSB2YWx1ZSBwcm9wb3NpdGlvbnMgb2Yg U1IgaXMgdGhhdCBpdOKAmXMgc3RhdGVsZXNzIGV2ZXJ5d2hlcmUgb3RoZXIgdGhhbiB0aGUgaGVh ZGVuZD8gSW5kZWVkLCB0aGF04oCZcyBzdGF0ZWQgaW4gdGhlIGFic3RyYWN0LiBTUiBkb2VzbuKA mXQgcmVxdWlyZSB0aGUgZWdyZXNzIHRvIGV2ZW4gdW5kZXJzdGFuZCB0aGF0IGl0IElTIGFuIGVn cmVzcyBvZiBhIFNSIFBvbGljeSwgaXQganVzdCBkb2VzIHdoYXQgdGhlIGhlYWRlcnMgdGVsbCBp dCB0bywgcmlnaHQ/DQoNCklmIHRoYXQncyBzbywgdGhlbiB0aGUgcmF0aW9uYWxlIGdpdmVuIGZv ciB0aGUgcmVxdWVzdGVkIHRyYWNrIG11c3QgYmUgd3JvbmcuDQo6LSggQW5kIHRoYXQgaW4gdHVy biBsZWFkcyBtZSB0byBhc2ssIHdoZXRoZXIgdGhlIHRyYWNrIHJlYWxseSBpcyByaWdodC4gSXQg c2VlbXMgdG8gbWUgdGhhdCBpbiBtb3N0IHJlc3BlY3RzIHRoaXMgaXMgbW9yZSBhbiBJbmZvcm1h dGlvbmFsIGRvY3VtZW50IHRoYW4gYSBzdGFuZGFyZHMgdHJhY2sgb25lLiBUaGF04oCZcyBub3Qg YSB2YWx1ZSBqdWRnZW1lbnQgaW4gYW55IHJlc3BlY3QsIGp1c3QgYSBzdGF0ZW1lbnQgb2YgZmFj dCDigJQgZm9yIHRoZSBtb3N0IHBhcnQsIGl0IGRvZXNu4oCZdCBzZWVtIGFzIHRob3VnaCB0aGUg aW5mb3JtYXRpb24gZm91bmQgaW4gdGhpcyBkb2N1bWVudCBpcyBuZWVkZWQgaW4gb3JkZXIgdG8g aW50ZXJvcGVyYXRlIHdpdGggYW5vdGhlciBzeXN0ZW0uIChTZWN0aW9uIDguOCBpcyBhbiBleGNl cHRpb24sIEkgZGlzY3VzcyB0aGF0IHNlcGFyYXRlbHkuKQ0KDQpBbnl3YXksIG5vdCB0byBnZXQg dG9vIGZhciBhaGVhZCBvZiBteXNlbGYsIGxldOKAmXMgc3RhcnQgYnkgd29ya2luZyBvbiB0aGlz DQpxdWVzdGlvbjogaXMgdGhlIHNoZXBoZXJkIHdyaXRldXAgY29ycmVjdCBpbiBzYXlpbmcgdGhh dCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gaGVhZGVuZCBhbmQgdGFpbGVuZCBpcyByZXF1aXJl ZD8gSWYgc28sIGNhbiBzb21lb25lIHBsZWFzZSBjaGFyYWN0ZXJpemUgdGhlIG5hdHVyZSBvZiB0 aGF0IGludGVyb3BlcmFiaWxpdHksIGFuZCBwdXQgaXQgaW4gdGhlIGNvbnRleHQgb2YgU1LigJlz IHN0YXRlbGVzcyBuYXR1cmU/DQoNCjIuIEl0IHNlZW1zIHRvIG1lIGFuIHVudXN1YWwgcHJhY3Rp Y2UgZm9yIHRoaXMgZG9jdW1lbnQgdG8gYmUgZGVmaW5pbmcgc2VtYW50aWNzIGFuZCBldmVuIHJl c2VydmluZyB2YWx1ZXMgaW4gYSBmaWVsZCBhbGxvY2F0ZWQgYnkgYSBkaWZmZXJlbnQgZG9jdW1l bnQsIGJ5IGEgZGlmZmVyZW50IFdHLiBJ4oCZbSByZWZlcnJpbmcgaGVyZSB0byB0aGUgc28tY2Fs bGVkIOKAnOKAmENvbG9yLU9ubHnigJkNCmJpdHPigJ0gZGlzY3Vzc2VkIGluIFNlY3Rpb24gOC44 Lg0KDQotIEkgd291bGQgYmUgbW9yZSBjb21mb3J0YWJsZSBpZiB0aGUgd29yayB3ZXJlIGFsbCBk b25lIGluIG9uZSBwbGFjZSwgdG8gdGhlIGV4dGVudCBwb3NzaWJsZS4NCg0KLSBHaXZlbiB0aGUg ZmFjdCB0aGlzIGRvY3VtZW50IGlzIHJlYWNoaW5nIGluIHRvIGEgcmVnaXN0cnkgbm9ybWFsbHkg bWFuYWdlZCBieSBJRFIsIHdhcyB0aGVyZSBhbnkgZGlzY3Vzc2lvbiB3aXRoIHRoZSBJRFIgZ3Jv dXA/IEkgZG9uJ3Qgc2VlIGFueSBldmlkZW5jZSBvZiBhIGNvdXJ0ZXN5IG5vdGlmaWNhdGlvbiBv ZiB0aGUgbGFzdCBjYWxsIHdoZW4gSSBsb29rIGF0IHRoZSBJRFIgbWFpbGluZyBsaXN0IGFyY2hp dmUuDQoNCknigJl2ZSBhbHNvIGVtYWlsZWQgdGhlIElEUiBsaXN0IGFib3V0IHRoaXMgaW4gY29u bmVjdGlvbiB3aXRoIGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3ksIHNl ZQ0KaHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZhcmNoJTJGbXNnJTJGaWRyJTJGeUNj WmRTdG1UUi1GTFVZR0hUc0xMQnY1YVdvJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1 aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzEzMTRlOTgzODUwODRlYzIyOWQ2MDhkOWYxNmRjMTMw JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzgwNjI3NTk2 MjU3Njg2MCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0 YT00TlFlYlIzRml5YzZxdDFJWUFaVTRJYW1OYW5kJTJGaDg0eVRxeU5IU0c0UU0lM0QmYW1wO3Jl c2VydmVkPTANCg0KUmVsYXRpbmcgdGhpcyBiYWNrIHRvIG15IHByZXZpb3VzIHF1ZXN0aW9uLCBp dOKAmXMgZXZpZGVudCB0aGF0IGlmIHRoaXMgZG9jdW1lbnQgaXMgZ29pbmcgdG8gZGVmaW5lIHNl bWFudGljcyBmb3IgdGhlIENvbG9yIEV4dGVuZGVkIENvbW11bml0eSBGbGFncywgdGhlbiB0aGF0 IG1ha2VzIGl0IFN0YW5kYXJkcyBUcmFjayBiZWNhdXNlIHRoZXJlIGlzIGFuIGludGVyb3BlcmFi aWxpdHkgZmFjdG9yIHRvIHRha2UgaW50byBhY2NvdW50ICh0aGF0J3MgYmVlbiBpbXBvcnRlZCBm cm9tIElEUikuIEEgbW9yZSBpZGVhbCBzb2x1dGlvbiB3b3VsZCBiZSB0byB0YWtlIGNhcmUgb2Yg dGhhdCBpbiB0aGUgSURSIGRvY3VtZW50IHJhdGhlciB0aGFuIHB1dHRpbmcgaXQgaW4gdGhpcyDi gJxhcmNoaXRlY3R1cmXigJ0gZG9jdW1lbnQsIHRob3VnaC4gU3VyZWx5LCB0aGlzIGtpbmQgb2Yg ZGV0YWlsIGlzIGltcGxlbWVudGF0aW9uLCBub3QgYXJjaGl0ZWN0dXJlPw0KIEluZGVlZCwgS2V0 YW4gc2FpZCBpbiBoaXMgcmVwbHkgdG8gTWF0dGhldyBCb2NjaSdzIFJURyByZXZpZXcsICJHaXZl biB0aGF0IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50LCBpdCBkZXNjcmliZXMgdGhl IGFyY2hpdGVjdHVyZSBhbmQgbm90IHJlYWxseSB0aGUgcHJvdG9jb2wgbWVjaGFuaXNtcyIuLi4g YnV0IHRoaXMgc2VjdGlvbiBzZWVtcyB0byBiZSBhbiBleGNlcHRpb24gdG8gdGhhdCBhc3BpcmF0 aW9uLg0KDQozLiBSZWxhdGVkIHRvIHRoZSBhYm92ZSwgYXQgbGVhc3Qgb25lIG9mIHRoZSByZWZl cmVuY2VzIGxpc3RlZCBhcyBpbmZvcm1hdGlvbmFsIGNsZWFybHkgaGFzIHRvIGJlIG5vcm1hdGl2 ZSB3aXRoIHRoZSBkb2N1bWVudCBhcyBpdCBzdGFuZHMuDQpkcmFmdC1pZXRmLWlkci1zZWdtZW50 LXJvdXRpbmctdGUtcG9saWN5IGlzIHRoZSBvbmUgSeKAmW0gdGhpbmtpbmcgb2YsIGZvciBleGFt cGxlIGl0cyB1c2UgaW4gwqcyLjQgc2VlbXMgbGlrZSBpdCBtYXkgcmlzZSB0byB0aGUgIm5vcm1h dGl2ZSIgbGV2ZWwsIMKnMi41IGFsbW9zdCBzdXJlbHkgZG9lcywgwqc0LjEgc3VyZWx5IGRvZXMs IGFuZCDCpzguOC4xIGlzIHRoZSBpY2luZyBvbiB0aGUgY2FrZSBiZWNhdXNlIHRoaXMgZG9jdW1l bnQgZGVmaW5lcyBzZW1hbnRpY3MgZm9yIGEgZmllbGQgdGhhdCBpc27igJl0IGV2ZW4gYWxsb2Nh dGVkIHVudGlsIGFuZCB1bmxlc3MgZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBv bGljeSBpcyBwdWJsaXNoZWQuDQoNCjQuIEluIMKnMi4xIHlvdSB0YWxrIGFib3V0IHRoZSBzaWdu YWxpbmcgb2Ygc3ltYm9saWMgbmFtZXMgZm9yIGNhbmRpZGF0ZSBwYXRocy4NCkFsdGhvdWdoIHlv dSBhcmUgY2FyZWZ1bCB0byBzYXkgdGhhdCBzdWNoIHN5bWJvbGljIG5hbWVzIGFyZSBvbmx5IHVz ZWQgZm9yIHByZXNlbnRhdGlvbiBwdXJwb3NlcywgaXQgc2VlbXMgdG8gbWUgdGhleSBzdGlsbCBj b3VsZCBiZSBjb25zaWRlcmVkIGEgbmV3IHBvdGVudGlhbCBzb3VyY2Ugb2YgdnVsbmVyYWJpbGl0 eSwgc2luY2UgYSBzdHJpbmcgdGhhdCBoYXMgbm8gc2FuaXR5LWNoZWNraW5nIHdoYXRzb2V2ZXIg YXBwbGllZCBieSB0aGUgcHJvdG9jb2wgY2FuIGRpc3BsYXkgbGl0ZXJhbGx5IGFueXRoaW5nIHRv IGFuIG9wZXJhdG9yIHZpZXdpbmcgaXQuIFNob3VsZG7igJl0IHRoaXMgYmUgYWRkcmVzc2VkIGlu IHlvdXIgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM/IChGb3IgYW4gZXhhbXBsZSBvZiBhIHJlbGF0 ZWQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMsIHNlZSBSRkMgOTAwMy4gSXTigJlzIHByb2JhYmx5 IG5vdCB0aGUgYmVzdCBleGFtcGxlLCBidXQgaXTigJlzIHRoZSBvbmUgSSBoYWQgYXQgbXkNCmZp bmdlcnRpcHPigKYpDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KQXMgbm90ZWQgaW4gbXkgRElTQ1VTUywgdGhlc2UgY29tbWVudHMgYXJlIHVuZmluaXNoZWQg YnV0IEkgdGhvdWdodCBJ4oCZZCBnaXZlIHlvdSB3aGF0IEkgaGF2ZS4NCg0KMS4gSSBzZWUgdGhh dCBDdWxsZW4gSmVubmluZ3MgcmVmZXJyZWQgdG8gdGhpcyBpbiBoaXMgQVJUIHJldmlldywgYnV0 IEnigJlkIGxpa2UgdG8gdGFsayBhYm91dCBpdCBhIGxpdHRsZSBtb3JlOiB3aHkgaGF2ZSB5b3Ug Y2hvc2VuIHRvIHJlc3RyaWN0IHN5bWJvbGljIG5hbWVzIHRvIEFTQ0lJPyBVVEYtOCBpcyB0aGUg bW9yZSB1c3VhbCBjaG9pY2UgaW4gdGhpcyBjb250ZXh0OyBpbmRlZWQgaW1wbGVtZW50YXRpb25z IG1heSBoYXZlIHRvIGdvIHRvIGV4dHJhIGVmZm9ydCB0byBzY3J1YiB0aGVpciBpbnB1dCB0byBp bnN1cmUgdGhhdCBvbmx5IEFTQ0lJIGlzIHByZXNlbnQuIEJDUCAxOCBkb2VzbuKAmXQgcmVxdWly ZSB5b3UgdG8gaW50ZXJuYXRpb25hbGl6ZSB5b3VyIHN0cmluZ3MsIG9mIGNvdXJzZSwgaXQgZ2l2 ZXMgeW91IHR3byBvcHRpb25zLCBvZiB3aGljaCB5b3UgaGF2ZSAoc29ydCBvZiwgeW91IGRvbid0 IGhhdmUgdGhlICJVUy0iKSBmb2xsb3dlZCB0aGUgbGF0dGVyOg0KDQogICBUaGlzIGRvY3VtZW50 IGRvZXMgbm90IG1hbmRhdGUgYSBwb2xpY3kgb24gbmFtZSBpbnRlcm5hdGlvbmFsaXphdGlvbiwN CiAgIGJ1dCByZXF1aXJlcyB0aGF0IGFsbCBwcm90b2NvbHMgZGVzY3JpYmUgd2hldGhlciBuYW1l cyBhcmUNCiAgIGludGVybmF0aW9uYWxpemVkIG9yIFVTLUFTQ0lJLg0KDQpCdXQgaW4gMjAyMiB0 aGUgY2hvaWNlIHRvIHJlc3RyaWN0IHN5bWJvbGljIG5hbWVzIHRvIEFTQ0lJIHNlZW1zIHVudXN1 YWwgZW5vdWdoIHRvIGludml0ZSB0aGUgcXVlc3Rpb24uDQoNCklmIHlvdSBkbyBzdGljayB3aXRo IEFTQ0lJIGFzIGN1cnJlbnRseSB3cml0dGVuLCBtaWdodCB5b3UgYWRkIHRleHQgbWFuZGF0aW5n IHRoYXQgaW1wbGVtZW50YXRpb25zIHNjcnViIHRoZWlyIGlucHV0IHRvIHByZXZlbnQgbm9uLUFT Q0lJIGNoYXJhY3RlcnMgZnJvbSBiZWluZyBhY2NlcHRlZD8NCg0KDQoNCg== From nobody Wed Feb 16 11:04:21 2022 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 19A2B3A1536; Wed, 16 Feb 2022 11:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 shLEnZ_UOyoK; Wed, 16 Feb 2022 11:03:57 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 169623A1531; Wed, 16 Feb 2022 11:03:57 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id j20so3582615vsg.5; Wed, 16 Feb 2022 11:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0PxjaH4Y/5g2IYphsYmJYFHqOKsZn78PWKkazzzzrxY=; b=HovftpCQZLXcbhnqaC7H+3H2MQbBRqL74B/3FZiBLCMH9Pe9TnI7aubArF0HJobAMf P0hludP34ojrxqMH3Bpz+7p0kmdTPtItp33E1Yr7d5dpb+/jmnRC9n/Hb29nLi/7+kby DBUW9owTdK85NmgtYfiRY5Aglvs8RHm8OICx2G1MpSj4CjnfDsvyRTidztbOPRB6LUFy 39ohNLkv42/+/oOzxZRFmN2VuNmGkbiHsAJHHVuJu/GqDX8zCbazKCj+ts4MX5oxpHWn XsRNLT2BPMUjhvcDZb5kRsed7uSplRI+sbtJvq+XILBlb7eFichTIbGMFTVfnKnal3Kv 5GdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0PxjaH4Y/5g2IYphsYmJYFHqOKsZn78PWKkazzzzrxY=; b=hRXMzYg8ZRlQNY4zuyPKTDV/MpwL8UI/qB7m0IT1F7sVm05PVYAYKJGSRBuv8iUsbr qL/HAmeEjAjwadwPC1BTf5NYQ3payUquARUOIC8tQKLQa8E8uH1Mnttc3NO784tlSKUS nH2JLb8Omjgklf96dewDMZskrzDZm2RhVqF+Yrigyj3DE7ewJYSHF8DwifsSAp9UpuMp 4vuKgtAZTnSoZpZ2CtkBTufDVW/hG1TpcqWTsYbHkPz9MIs3xy9ZVACNOc/AV9w5ZVKD xMbMu3B64J1MXnGKxu6fkYFM3PRK6gHLg3AwrprhYb1aCiGM24y4q4l/obpV0Qd0WYsO E6Fg== X-Gm-Message-State: AOAM533AdWsEuilf4bx3mptd9+fMsq74jPffSwGitpj5NK4+EhmIf7CF Pil/PfyGscgdv2yF3AKQKDB/9fmvKfJftLI7OvYoDcnZBMI= X-Google-Smtp-Source: ABdhPJwRNriuJ9oiixa1IqMzeb7K1NISA72vuwxWnqC95UX2CD98EqjCa2ase8mD3usbgKuA79s+fnMECRGck6FKJHU= X-Received: by 2002:a05:6102:3591:b0:310:ef5d:d2be with SMTP id h17-20020a056102359100b00310ef5dd2bemr29034vsu.34.1645038234974; Wed, 16 Feb 2022 11:03:54 -0800 (PST) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: <164503079307.9996.17286143339105134181@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 00:33:43 +0530 Message-ID: To: John Scudder Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000a34b7605d8274ffb" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 16 Feb 2022 19:04:00 -0000 --000000000000a34b7605d8274ffb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Thanks for your review and please check inline below for responses. On Wed, Feb 16, 2022 at 10:29 PM John Scudder via Datatracker < noreply@ietf.org> wrote: > John Scudder has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I=E2=80=99ve done an initial review of this document and have several con= cerns I=E2=80=99d > like > to discuss. I apologize for not also providing a full review as comments = in > this ballot, I judged it more important to begin the discussion about the= se > points timely, than to provide all comments in a single message. > > 1. The shepherd writeup indicates that =E2=80=9CStandard Track is request= ed and > indicated in the title page header. This is appropriate for a > specification of > packet steering into an SR policy needing interoperability between the > ingress/source of the policy instantiation and the egress/destination of > the > policy termination.=E2=80=9D > > I realize it=E2=80=99s unusual to ask to discuss a shepherd writeup rathe= r than the > spec itself, but I think this one rises to the level. My concern is that > this > description (needing interoperability between the ingress and the egress) > doesn=E2=80=99t comport with my understanding of the Segment Routing arch= itecture. > Surely, one of the key value propositions of SR is that it=E2=80=99s stat= eless > everywhere other than the headend? Indeed, that=E2=80=99s stated in the a= bstract. > SR > doesn=E2=80=99t require the egress to even understand that it IS an egres= s of a SR > Policy, it just does what the headers tell it to, right? > > If that's so, then the rationale given for the requested track must be > wrong. > :-( And that in turn leads me to ask, whether the track really is right. = It > seems to me that in most respects this is more an Informational document > than a > standards track one. That=E2=80=99s not a value judgement in any respect,= just a > statement of fact =E2=80=94 for the most part, it doesn=E2=80=99t seem as= though the > information found in this document is needed in order to interoperate wit= h > another system. (Section 8.8 is an exception, I discuss that separately.) > > Anyway, not to get too far ahead of myself, let=E2=80=99s start by workin= g on this > question: is the shepherd writeup correct in saying that interoperability > between headend and tailend is required? If so, can someone please > characterize > the nature of that interoperability, and put it in the context of SR=E2= =80=99s > stateless nature? > KT> I see that Jim (doc shepherd) has clarified. The document aims to standardize the SR Policy constructs and related behaviors. It provides the basis then for protocol extensions (e.g. PCEP and BGP) and the YANG model to follow by a normative reference to it. > > 2. It seems to me an unusual practice for this document to be defining > semantics and even reserving values in a field allocated by a different > document, by a different WG. I=E2=80=99m referring here to the so-called > =E2=80=9C=E2=80=98Color-Only=E2=80=99 > bits=E2=80=9D discussed in Section 8.8. > > - I would be more comfortable if the work were all done in one place, to > the > extent possible. > > - Given the fact this document is reaching in to a registry normally > managed by > IDR, was there any discussion with the IDR group? I don't see any evidenc= e > of a > courtesy notification of the last call when I look at the IDR mailing lis= t > archive. > > I=E2=80=99ve also emailed the IDR list about this in connection with > draft-ietf-idr-segment-routing-te-policy, see > https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/ KT> Thanks. I will work on addressing them as a co-author of that IDR document. > > > Relating this back to my previous question, it=E2=80=99s evident that if = this > document > is going to define semantics for the Color Extended Community Flags, then > that > makes it Standards Track because there is an interoperability factor to > take > into account (that's been imported from IDR). A more ideal solution would > be to > take care of that in the IDR document rather than putting it in this > =E2=80=9Carchitecture=E2=80=9D document, though. Surely, this kind of det= ail is > implementation, > not architecture? Indeed, Ketan said in his reply to Matthew Bocci's RTG > review, "Given that this is an architecture document, it describes the > architecture and not really the protocol mechanisms"... but this section > seems > to be an exception to that aspiration. > KT> The resolution of BGP service routes over the underlying forwarding constructs may be seen by some as more of a "system" or "forwarding" aspect than a BGP protocol aspect. This is in the architecture because operators who have deployed SR Policies expected the same consistent resolution behavior across headed routers from different vendors. > > 3. Related to the above, at least one of the references listed as > informational > clearly has to be normative with the document as it stands. > draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinking = of, for > example its use in =C2=A72.4 seems like it may rise to the "normative" le= vel, > =C2=A72.5 > almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icing o= n the cake > because this document defines semantics for a field that isn=E2=80=99t ev= en > allocated > until and unless draft-ietf-idr-segment-routing-te-policy is published. > KT> It is the other way round. The SPRING document specifies the information model and the constructs of the SR Policy. The IDR document is primarily about signaling of the SR Policy from a controller to the headend using the new SR Policy SAFI (73) - as such it does refer normatively to the SPRING SR Policy. > > 4. In =C2=A72.1 you talk about the signaling of symbolic names for candid= ate > paths. > Although you are careful to say that such symbolic names are only used fo= r > presentation purposes, it seems to me they still could be considered a ne= w > potential source of vulnerability, since a string that has no > sanity-checking > whatsoever applied by the protocol can display literally anything to an > operator viewing it. Shouldn=E2=80=99t this be addressed in your Security > Considerations? (For an example of a related Security Considerations, see > RFC > 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the on= e I had at my > fingertips=E2=80=A6) > KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As such, I am not aware of security issues around printable ASCII - please do point me to any references. Also note that this document does not specify protocol encodings where some extra verbiage is normally required (e.g. that it is signaled without NULL, handling truncation/overruns, etc.). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As noted in my DISCUSS, these comments are unfinished but I thought I=E2= =80=99d > give > you what I have. > > 1. I see that Cullen Jennings referred to this in his ART review, but I= =E2=80=99d > like > to talk about it a little more: why have you chosen to restrict symbolic > names > to ASCII? UTF-8 is the more usual choice in this context; indeed > implementations may have to go to extra effort to scrub their input to > insure > that only ASCII is present. BCP 18 doesn=E2=80=99t require you to interna= tionalize > your > strings, of course, it gives you two options, of which you have (sort of, > you > don't have the "US-") followed the latter: > > This document does not mandate a policy on name internationalization, > but requires that all protocols describe whether names are > internationalized or US-ASCII. > > But in 2022 the choice to restrict symbolic names to ASCII seems unusual > enough > to invite the question. > > If you do stick with ASCII as currently written, might you add text > mandating > that implementations scrub their input to prevent non-ASCII characters fr= om > being accepted? > KT> As discussed in the WG, we are sticking to printable ASCII. When the encoding is specified to be printable ASCII, it is expected that implementations valid that. Thanks, Ketan --000000000000a34b7605d8274ffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks for yo= ur review and please check inline below for responses.=C2=A0

=

On Wed, Feb 16, 2022 at 10:29 PM John Scudder via Datatracker <noreply@ietf.org> 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">John Scudder has entered t= he following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I=E2=80=99ve done an initial review of this document and have several conce= rns I=E2=80=99d like
to discuss. I apologize for not also providing a full review as comments in=
this ballot, I judged it more important to begin the discussion about these=
points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that =E2=80=9CStandard Track is requested= and
indicated in the title page header. This is appropriate for a specification= of
packet steering into an SR policy needing interoperability between the
ingress/source of the policy instantiation and the egress/destination of th= e
policy termination.=E2=80=9D

I realize it=E2=80=99s unusual to ask to discuss a shepherd writeup rather = than the
spec itself, but I think this one rises to the level. My concern is that th= is
description (needing interoperability between the ingress and the egress) doesn=E2=80=99t comport with my understanding of the Segment Routing archit= ecture.
Surely, one of the key value propositions of SR is that it=E2=80=99s statel= ess
everywhere other than the headend? Indeed, that=E2=80=99s stated in the abs= tract. SR
doesn=E2=80=99t require the egress to even understand that it IS an egress = of a SR
Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be = wrong.
:-( And that in turn leads me to ask, whether the track really is right. It=
seems to me that in most respects this is more an Informational document th= an a
standards track one. That=E2=80=99s not a value judgement in any respect, j= ust a
statement of fact =E2=80=94 for the most part, it doesn=E2=80=99t seem as t= hough the
information found in this document is needed in order to interoperate with<= br> another system. (Section 8.8 is an exception, I discuss that separately.)
Anyway, not to get too far ahead of myself, let=E2=80=99s start by working = on this
question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characte= rize
the nature of that interoperability, and put it in the context of SR=E2=80= =99s
stateless nature?

KT> I see that Jim= (doc shepherd) has clarified. The document aims to standardize the SR Poli= cy constructs and related behaviors. It provides the basis then for protoco= l extensions (e.g. PCEP and BGP) and the YANG model to follow by a normativ= e reference to it.
=C2=A0

2. It seems to me an unusual practice for this document to be defining
semantics and even reserving values in a field allocated by a different
document, by a different WG. I=E2=80=99m referring here to the so-called = =E2=80=9C=E2=80=98Color-Only=E2=80=99
bits=E2=80=9D discussed in Section 8.8.

- I would be more comfortable if the work were all done in one place, to th= e
extent possible.

- Given the fact this document is reaching in to a registry normally manage= d by
IDR, was there any discussion with the IDR group? I don't see any evide= nce of a
courtesy notification of the last call when I look at the IDR mailing list<= br> archive.

I=E2=80=99ve also emailed the IDR list about this in connection with
draft-ietf-idr-segment-routing-te-policy, see
https://mailarchive.ietf.org/a= rch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/

KT> Thanks. I will work on addressing them as a co-author=C2=A0of that= IDR document.=C2=A0
=C2=A0


Relating this back to my previous question, it=E2=80=99s evident that if th= is document
is going to define semantics for the Color Extended Community Flags, then t= hat
makes it Standards Track because there is an interoperability factor to tak= e
into account (that's been imported from IDR). A more ideal solution wou= ld be to
take care of that in the IDR document rather than putting it in this
=E2=80=9Carchitecture=E2=80=9D document, though. Surely, this kind of detai= l is implementation,
not architecture?=E2=80=A8 Indeed, Ketan said in his reply to Matthew Bocci= 's RTG
review, "Given that this is an architecture document, it describes the=
architecture and not really the protocol mechanisms"... but this secti= on seems
to be an exception to that aspiration.

= KT> The resolution of BGP service routes over the underlying forwarding = constructs may be seen by some as more of a "system" or "for= warding" aspect than a BGP protocol aspect. This is in the architectur= e because operators who have deployed SR Policies expected the same consist= ent resolution behavior across headed routers from different vendors.
=
=C2=A0

3. Related to the above, at least one of the references listed as informati= onal
clearly has to be normative with the document as it stands.
draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinking of= , for
example its use in =C2=A72.4 seems like it may rise to the "normative&= quot; level, =C2=A72.5
almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icing on = the cake
because this document defines semantics for a field that isn=E2=80=99t even= allocated
until and unless draft-ietf-idr-segment-routing-te-policy is published.
=

KT> It is the other way round. The SPRI= NG document specifies the=C2=A0information model and the constructs of the = SR Policy. The IDR document is primarily about signaling of the SR Policy f= rom a controller to the headend using the new SR Policy SAFI (73) - as such= it does refer normatively to the SPRING SR Policy.=C2=A0
=C2=A0<= /div>

4. In =C2=A72.1 you talk about the signaling of symbolic names for candidat= e paths.
Although you are careful to say that such symbolic names are only used for<= br> presentation purposes, it seems to me they still could be considered a new<= br> potential source of vulnerability, since a string that has no sanity-checki= ng
whatsoever applied by the protocol can display literally anything to an
operator viewing it. Shouldn=E2=80=99t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see R= FC
9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the one = I had at my
fingertips=E2=80=A6)

KT> RFC9003 use= s UTF-8 while this document uses printable ASCII. As such, I am not aware o= f security issues around printable ASCII - please do point me to any refere= nces. Also note that this document does not specify protocol encodings wher= e some extra verbiage is normally required (e.g. that it is signaled withou= t NULL, handling=C2=A0truncation/overruns, etc.).
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As noted in my DISCUSS, these comments are unfinished but I thought I=E2=80= =99d give
you what I have.

1. I see that Cullen Jennings referred to this in his ART review, but I=E2= =80=99d like
to talk about it a little more: why have you chosen to restrict symbolic na= mes
to ASCII? UTF-8 is the more usual choice in this context; indeed
implementations may have to go to extra effort to scrub their input to insu= re
that only ASCII is present. BCP 18 doesn=E2=80=99t require you to internati= onalize your
strings, of course, it gives you two options, of which you have (sort of, y= ou
don't have the "US-") followed the latter:

=C2=A0 =C2=A0This document does not mandate a policy on name internationali= zation,
=C2=A0 =C2=A0but requires that all protocols describe whether names are
=C2=A0 =C2=A0internationalized or US-ASCII.

But in 2022 the choice to restrict symbolic names to ASCII seems unusual en= ough
to invite the question.

If you do stick with ASCII as currently written, might you add text mandati= ng
that implementations scrub their input to prevent non-ASCII characters from=
being accepted?

KT> As discussed in = the WG, we are sticking to printable ASCII. When the encoding is specified = to be printable ASCII, it is expected that implementations valid that.

Thanks,
Ketan=C2=A0
=C2=A0=C2=A0
--000000000000a34b7605d8274ffb-- From nobody Wed Feb 16 11:26:57 2022 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 29A043A157E; Wed, 16 Feb 2022 11:26:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <164503960643.17290.6124629269242232565@ietfa.amsl.com> Date: Wed, 16 Feb 2022 11:26:47 -0800 Archived-At: Subject: [spring] Zaheduzzaman Sarker's No Objection on draft-ietf-spring-segment-routing-policy-17: (with COMMENT) 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, 16 Feb 2022 19:26:48 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the efforts on this specification. This might be due to my lack of expertise on SR policy but it is not clear to me how to resolve policy conflicts where preferences and priority are same for policies. It would be nice if you point me information I am missing as I could not resolve it by reading this specification. This might be that the scenario I am having in mind never occurs. From nobody Wed Feb 16 11:42:49 2022 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 D20443A15AD; Wed, 16 Feb 2022 11:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=juniper.net header.b=KAMzgwl3; dkim=pass (1024-bit key) header.d=juniper.net header.b=U1ZR+KcN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHEbDegZb50t; Wed, 16 Feb 2022 11:42:41 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF4A3A15A6; Wed, 16 Feb 2022 11:42:07 -0800 (PST) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21GF3QUm031655; Wed, 16 Feb 2022 11:42:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=jt4EHNKK3OH/Oe4PnBy1SpST+hXRGhJh9xSMm+dSyhA=; b=KAMzgwl3+4BjuNFl0YIwLx5MLruQLgElAy96Q6OJWfs2l9Ew0CEiHIEnI/r0u/fXiAnH cI1jzu4xtRu6TyVDVMZZXbFoXanyYR8c1k4Ogm/FEVugEScef21nechQB3IuEqnQE58d X1vABbCp2zNrH0pg6gJmJBz0EyK/pKPy0jg9PLh5lDHDj86f3ljrpc+uSNF6IETUa0VW 0zZRtvpJ8g0cUWWpvqLFtPtIfCnWROT4TZ/zN8/WQdybVP2RAEsc/XsYApJBy1sGSUtV G5wQK0Ys5SHdmogiW6ep1W0crZFBGrMMc4vvZpxENAlmF/brTE+KkV2oZuGPopd5VL9h Qw== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3e93jxgga8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Feb 2022 11:42:04 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SHZV7DsR/5QAoK0sX/Ss87yUV5ipY5c/YN2tPF1b6yCKmt1D+2e/oEPjXAz0uEO8WjxREfaiK02Uhf34FtxDFGzNitYFe/8F8RU+ja9L54nqWZP2/3WYVKz0HmozVHAnpdxJlReQFYAltnefcltrjUKXncRa41nsulon42upE7UpVyhWgTDl7r4NeKtJbl7cn0xZ0MTWHvahE0+5aMZAvtXkHIglap/SP8OPd3JNSW+2uuf8CtR7o2ei6U1WSemhtGyN3GM3/cvZGCPAYXyDhaCJSTOQ94RaluZnv5dms8MqrxUcYtZ1SOS3JSCUsnmPJc6yq6MrzNd5lPvfJQk3vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jt4EHNKK3OH/Oe4PnBy1SpST+hXRGhJh9xSMm+dSyhA=; b=Z/mWdv1UnQc7HKn/ohuHy1P2nxODOJiqSZ1baCLLW6+9AQvT6eheehlmqXGDFF2r3pW3vuDWkHBEzo/OpHFdYYBQhe2YZ+cpWneAr4GrXjs48i96Lmr3bo55LkEmHNKVOhzJLIceLyoiV/j3EzDA+9uAm7PbQzOPAB8GDnCuzy0SmISJtSG6arRlpHermx++9m/xI7tCz7Y9aGi2YaNCy8EbO5BsQC6RFRxDsVm2xwPwAsHti7A9vWGSR5N4L5NR/ztfBKBlv/sYYu0P9CupYizMBOArcTFBKllnuvJz2sfnZK3N7dWXi89wFisapaPVgELFnqc31GIxjM6eom3UPg== 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=jt4EHNKK3OH/Oe4PnBy1SpST+hXRGhJh9xSMm+dSyhA=; b=U1ZR+KcNRA/dmF1UwUycYWbXbzHEB4bYsI7p7E3CDloq8u0e+WxWu25UbtzigRbn06wiRYnechySHgr3mPT0JEwheamcuvKg4vTovbpprjcLXEUDUXJT4Q8wKf2WFivKQX09nBkzcrtMHbz6bxyj3PVHwr3zalfiEVT/IWa987o= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by SN6PR05MB3997.namprd05.prod.outlook.com (2603:10b6:805:17::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.7; Wed, 16 Feb 2022 19:42:00 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::1cf9:4765:c8df:81b7]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::1cf9:4765:c8df:81b7%5]) with mapi id 15.20.4995.015; Wed, 16 Feb 2022 19:42:00 +0000 From: John Scudder To: Ketan Talaulikar CC: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Thread-Topic: John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) Thread-Index: AQHYI1ajQRbh7M614068Bbz53eGtPayWiSeAgAAKsYA= Date: Wed, 16 Feb 2022 19:42:00 +0000 Message-ID: References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1aa89960-671a-4967-363e-08d9f1846669 x-ms-traffictypediagnostic: SN6PR05MB3997:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UrtnTPNCCryEOk0IMPmdlnApDj4xcpEQuruKAFFjIjpypcPv6/L5fc0MGbb22Fg6U5mCoxkmanOQQr8uzc6PYMBN1Z2FadBqvrcOBvYlL4yc8sYicakGkAlokXj9A8kLsQc5goS3HLc7QnW9Q1aILZ5vJ7Utz3iT9m0bkPqz1PtizxAYtvsLO4Wc2CiPlpur76qPJxtytrBhEz2KOMZFh1gUooH71u3sUyr7ZlfdYZhjAsJYEbCZLBJSKCtfdGTUM5CnqZSldOPyjxZ/aMaFor6MeELjM90FRTzEOhgG41VU36mmCPJCAGM/8g2o9H3a3R32l0pZGq2JbCtuw4+oLoYMQo2lpZDDkS0gSuiEZULvy0pVXU+FuaqwWrXbOVd2Nu5bTby1g3soGbSo4mRxtpx4lFJSnYleo2gPgZKLAPn9DZ/+wMZ11GzAmL3HRVs9g3z4YFhejsyx9ZjaUY9cpmkIidp6crQrbazlZwdsp28aBqZZn1L8/IPAmyfOOctHk0KI4AKVYv7LPv/afm1DL8ZHPia1//ZmuSj4JaFN60tl8x07mmZKKzrACkeLWbBNl7XdDfKOBHj93NIotfKTRNj7Oi+RjONFyH6119bvNlqQRkZJNVHyqMe77/PkC9vaxxFPCLk4coav/1zpVRBdgjEU57IB3BRAZS/36p6vTEZPv1QJyK2DFxxKV6g1IIHbGb5sUbb8Xw262CjTdUkDclkRGarb3q9/x7q7NvUpo2s2sXthMsma0iwSCvjCG0fuvBA1Ko9DUmZSmgEK5fWI7dQ/lp09v9J0sje4prmg+CM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(8936002)(33656002)(6512007)(6506007)(83380400001)(53546011)(508600001)(122000001)(5660300002)(38070700005)(54906003)(76116006)(91956017)(316002)(8676002)(66946007)(6916009)(64756008)(66556008)(66446008)(38100700002)(4326008)(66476007)(6486002)(71200400001)(36756003)(2906002)(2616005)(26005)(186003)(86362001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dVhLaWhyQ01yOFJObU5rUjNWcWFINS9hTEZQQ0NKR1JoSmlNeWx4elNlcVgx?= =?utf-8?B?akFmbWtycHgwcEVXZkhDNldpMmV3VXRtd0dEMVRORGY3TXAyc1B4T1JxQzgx?= =?utf-8?B?VU1BS1VOK2Jxak9qUU9qSlBGZFAwN3RENUIrTXZRWWRQbkFpMURMaXhYNXZN?= =?utf-8?B?N2lOYnRNbXBVRWNkM3UwNkx2clN1cUlKTGM4RTgxdVpCcXNMeGNUeU1KOTRx?= =?utf-8?B?WHkrZm9LWG1oWjAzSU5VckNmajh0Z3NRUFJFalF3ZGxjNW96enVQeHFudmNp?= =?utf-8?B?Vk10WWpnU25XSUMwVHRVRVRnMDF5MlMzUnRiYVNhZGhzOE9vSGZ1S0plSjBt?= =?utf-8?B?WW0zOVN2TDk3OWpyVXdBMG52UGJzODgzVnAyNnFQUmNDSjFqUzZ4OEl6VExM?= =?utf-8?B?aHROcTZGZ1I4bVdMTTRxVXpUblRUWTdqWWw5QUduRjBOMFd1SS9lSllEOFNs?= =?utf-8?B?UHFuLzFsVUJvMU5aZVFvZWMrOVhWWGxwdDQrNlhaa1ZmaTIzb2YrS3cvZTc5?= =?utf-8?B?QmtNdmZYVW5jM3BLaFhwdHRUWEwxd0dYQXpmYzV2Q05uYXVJRUhGNDNNclRB?= =?utf-8?B?UEpCTmRxZEY3SkJ6MXp1Y2FpekJLbUZqd0NvcEpOU0FDeVBwdnVtZVdDdVZu?= =?utf-8?B?S1FHSkNSYlNBRFdUZE5JY1RpVHN4UFZSa2krN0VwT3hQVnRkTE5WSnVyVnlJ?= =?utf-8?B?akVEOEsrT3lVQTZveHJCWmp4aTNwbHlTSXIyb3lqeEZSMW52aWljTDM2MENT?= =?utf-8?B?bGo4OXRZRjlFcDVrS1d3Q1hGaUlKNVp4TERTR09nM1czN2hVVGJsalJQQzk2?= =?utf-8?B?Y1hmNEx0SkVUNFY1RDNXZ1h5aDdLbnBxSWZOdUVjenI0SGxJWkN4TzM0dTJ0?= =?utf-8?B?OGVZczQ1ZmtwSkNnK0QzeUNtQnJtUmxVK1N0Mjd6UXpwZE1nSksyZ01PdUNC?= =?utf-8?B?WFZlcElMWnJmOUxPUk4xUXFKTlBIOGJYUFZjRWVWYmlGbUJhZEdwS3NJVDhq?= =?utf-8?B?ZmNwbEhKRks0N2ZqM0l1UHd5WjAzcXBkSittK0pnc29kNzdqWlJpR3JQbGlq?= =?utf-8?B?Sk1hdkEzWEdPRGVsbTl2WmZWMmp3OFJkRnFPTDhhQ3pMQzJXd2RZUVF4ZGZ6?= =?utf-8?B?eTdsY3pPb1JOUGtmbFdhemN0aWtzYkMyYnR3WUVCN3lGNXlDMU0ySC9BZ0V2?= =?utf-8?B?TXhaTStUeXRoYUVtMEJSa3pCRk95Rm1PTVZVQTE2MkdUZjA1ODh5M1ljYlRJ?= =?utf-8?B?WitCVmpmMGZmdnNwOUR1S3RNQnpFbHdpS056OTNjSzUwYXlFa29xN1p6TGJS?= =?utf-8?B?R3Nic0lUc0tSSU5jNW9RQWJ3TDA0eGZSZ2s0VjB1bUd4ZTVUaHJzamJoWUF5?= =?utf-8?B?ZEd1eVMvVEp1bkduRzFTSUwvNys0d2R3UEJNeEdzSjBtdEtUSXJRUUZXSWRO?= =?utf-8?B?a1Z0b0d3QlZrQk9QNkx3Z2F5RldyTVhQSC9hYjdGQUQ4ZnBrV1JIdE5sY0hS?= =?utf-8?B?dktUV2xmVmJyVzlHRnJKVitPZUp1NTZOWm4xU2Rtb3lHTjREUmc2UXo5RWQw?= =?utf-8?B?STJkMElVZitmZ3d5L1FCNVpKcVk2WlFYRHNtQ2krd1Rya2V5d2xlQjVTZjhI?= =?utf-8?B?U09WT2RLT2dPNll4SE9sdXlrVnhLbmk5MnVsaDJUWXFhaWovL1AwWlNxMFZ4?= =?utf-8?B?dHRkMDBSNmlGK0VWdlgyRlU5SU40T2dBMFRWcHZSMWIxK3o3OXYxYi9ISytO?= =?utf-8?B?TWdpYWdNZDIwRWlxWXhXdjN3OWF1dDVPOTl2MUt5cVBXVXB0V1VKd0pYZDlB?= =?utf-8?B?eUFGSVBrOHNBVmV5eVVUdUdrWmwxK2xZOEFGTWJTUlFyZTJaVk5TME5uUTI4?= =?utf-8?B?VTlZMmlabjd5N3IzWGpyZXFtWm1qN1dOTW1nY0RsU2NnMXMvT0VNMWFWaDM0?= =?utf-8?B?QUNMWEJiQ3dGQlRPd2x3S3luUitOdExNNllyRGJwQkFESXZVN2drMTNEcTgz?= =?utf-8?B?Z3NEc2hDMTM3UmxvcGYzQk5aN3lRcEdQK3VJME1PZnp1Zndpa2UxbHFhM2Vn?= =?utf-8?B?QmdBaEdQUU1scThKSmQ4akRhTDF2RENxKzlpQWhSOTFreHdzQ1hrRE5aejJi?= =?utf-8?Q?z8kWn0Bkng05A4OWiARjq7kR9?= Content-Type: text/plain; charset="utf-8" Content-ID: <33C77165C83A2A4DBD89B3AB3E01A43D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1aa89960-671a-4967-363e-08d9f1846669 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 19:42:00.4377 (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: W8oYSmHzXfopyHGRc+37J3PpBv+6HtRRyqfDht3wm1fkl00SvovhQdrX9aJb2Sza X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB3997 X-Proofpoint-ORIG-GUID: US5lBxgUBLhL78k2A667xKASrM6XfDio X-Proofpoint-GUID: US5lBxgUBLhL78k2A667xKASrM6XfDio X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-16_09,2022-02-16_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 spamscore=0 clxscore=1011 phishscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202160110 Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 16 Feb 2022 19:42:46 -0000 SGkgS2V0YW4sDQoNCj4gT24gRmViIDE2LCAyMDIyLCBhdCAyOjAzIFBNLCBLZXRhbiBUYWxhdWxp a2FyIDxrZXRhbnQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgSm9obiwNCj4gDQo+ IFRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIHBsZWFzZSBjaGVjayBpbmxpbmUgYmVsb3cgZm9y IHJlc3BvbnNlcy4gDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4gRm9yIHRoaXMgcmVzcG9uc2Ug SeKAmW0gY29uZmluaW5nIG15c2VsZiB0byBwb2ludHMgMyBhbmQgNC4NCg0KW3NuaXBdDQoNCj4g My4gUmVsYXRlZCB0byB0aGUgYWJvdmUsIGF0IGxlYXN0IG9uZSBvZiB0aGUgcmVmZXJlbmNlcyBs aXN0ZWQgYXMgaW5mb3JtYXRpb25hbA0KPiBjbGVhcmx5IGhhcyB0byBiZSBub3JtYXRpdmUgd2l0 aCB0aGUgZG9jdW1lbnQgYXMgaXQgc3RhbmRzLg0KPiBkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJv dXRpbmctdGUtcG9saWN5IGlzIHRoZSBvbmUgSeKAmW0gdGhpbmtpbmcgb2YsIGZvcg0KPiBleGFt cGxlIGl0cyB1c2UgaW4gwqcyLjQgc2VlbXMgbGlrZSBpdCBtYXkgcmlzZSB0byB0aGUgIm5vcm1h dGl2ZSIgbGV2ZWwsIMKnMi41DQo+IGFsbW9zdCBzdXJlbHkgZG9lcywgwqc0LjEgc3VyZWx5IGRv ZXMsIGFuZCDCpzguOC4xIGlzIHRoZSBpY2luZyBvbiB0aGUgY2FrZQ0KPiBiZWNhdXNlIHRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBzZW1hbnRpY3MgZm9yIGEgZmllbGQgdGhhdCBpc27igJl0IGV2ZW4g YWxsb2NhdGVkDQo+IHVudGlsIGFuZCB1bmxlc3MgZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0 aW5nLXRlLXBvbGljeSBpcyBwdWJsaXNoZWQuDQo+IA0KPiBLVD4gSXQgaXMgdGhlIG90aGVyIHdh eSByb3VuZC4gVGhlIFNQUklORyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGluZm9ybWF0aW9uIG1v ZGVsIGFuZCB0aGUgY29uc3RydWN0cyBvZiB0aGUgU1IgUG9saWN5LiBUaGUgSURSIGRvY3VtZW50 IGlzIHByaW1hcmlseSBhYm91dCBzaWduYWxpbmcgb2YgdGhlIFNSIFBvbGljeSBmcm9tIGEgY29u dHJvbGxlciB0byB0aGUgaGVhZGVuZCB1c2luZyB0aGUgbmV3IFNSIFBvbGljeSBTQUZJICg3Mykg LSBhcyBzdWNoIGl0IGRvZXMgcmVmZXIgbm9ybWF0aXZlbHkgdG8gdGhlIFNQUklORyBTUiBQb2xp Y3kuIA0KDQpXaXRob3V0IGdldHRpbmcgdG9vIGZhciBpbnRvIHRoZSBkZXRhaWxzIG9uIHRoaXMg b25lLCB5b3UganVzdCBjYW7igJl0IHdyaXRlIGEgc3BlYyBhYm91dCBhIGZpZWxkIChvciBzZXQg b2YgZmxhZ3MpIHRoYXQgZG9lc27igJl0IChkb27igJl0KSBleGlzdC4gVGhlIHdheSB5b3XigJl2 ZSBzdHJ1Y3R1cmVkIHRoZXNlIHR3byBkb2N1bWVudHMsIHRoYXQgZmllbGQgKEkgd2lsbCBjYWxs IGl0IGEgZmllbGQpIGRvZXNu4oCZdCBmb3JtYWxseSBleGlzdCB1bnRpbCBhbmQgdW5sZXNzIGRy YWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1wb2xpY3kgaXMgcHVibGlzaGVkLiBUaGVy ZWZvcmUsIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kgaGFzIGEgaGFy ZCBkZXBlbmRlbmN5IG9uIGl0LCBhbmQgdGhpcyBpcyBvbmUgdGhpbmcgdGhhdCBtYWtlcyBhIHJl ZmVyZW5jZSDigJxub3JtYXRpdmXigJ0uIFRoZXNlIHdvdWxkIGhhcmRseSBiZSB0aGUgZmlyc3Qg dHdvIGRvY3VtZW50cyB0byBub3JtYXRpdmVseSByZWZlcmVuY2Ugb25lIGFub3RoZXIsIGl04oCZ cyB3aGF0IHRoZSBSRkMgRWRpdG9yIHVzZXMgY2x1c3RlcnMgZm9yIChhbW9uZ3N0IG90aGVyIHRo aW5ncykuDQoNCllvdSBjb3VsZCBhbHNvIHJlc29sdmUgdGhpcyBwYXJ0aWN1bGFyIGlzc3VlIGJ5 IHJlc3RydWN0dXJpbmcgdGhlIGRvY3VtZW50cyB0byBtYWtlIHRoZW0gbW9yZSBzZWxmLWNvbnRh aW5lZC4gSWYgeW91IGRvLCB0aGVuIHBlcmhhcHMgd2Ugd291bGQgbmVlZCB0byByZXZpc2l0IHRo ZSBvdGhlciByZWZlcmVuY2VzIHRvIGRyYWZ0LWlldGYtaWRyLXNlZ21lbnQtcm91dGluZy10ZS1w b2xpY3kgaW4gbW9yZSBkZXRhaWwg4oCUIGJ1dCB1bnRpbCB0aGVuIGl0IHdvdWxkbuKAmXQgYmUg dGltZSB3ZWxsIHNwZW50LCBhcyB0aGUgwqc4LjguMSByZWZlcmVuY2UgaXMgc3VmZmljaWVudCB0 byBjZW1lbnQgdGhlIHJlcXVpcmVtZW50Lg0KDQo+IDQuIEluIMKnMi4xIHlvdSB0YWxrIGFib3V0 IHRoZSBzaWduYWxpbmcgb2Ygc3ltYm9saWMgbmFtZXMgZm9yIGNhbmRpZGF0ZSBwYXRocy4NCj4g QWx0aG91Z2ggeW91IGFyZSBjYXJlZnVsIHRvIHNheSB0aGF0IHN1Y2ggc3ltYm9saWMgbmFtZXMg YXJlIG9ubHkgdXNlZCBmb3INCj4gcHJlc2VudGF0aW9uIHB1cnBvc2VzLCBpdCBzZWVtcyB0byBt ZSB0aGV5IHN0aWxsIGNvdWxkIGJlIGNvbnNpZGVyZWQgYSBuZXcNCj4gcG90ZW50aWFsIHNvdXJj ZSBvZiB2dWxuZXJhYmlsaXR5LCBzaW5jZSBhIHN0cmluZyB0aGF0IGhhcyBubyBzYW5pdHktY2hl Y2tpbmcNCj4gd2hhdHNvZXZlciBhcHBsaWVkIGJ5IHRoZSBwcm90b2NvbCBjYW4gZGlzcGxheSBs aXRlcmFsbHkgYW55dGhpbmcgdG8gYW4NCj4gb3BlcmF0b3Igdmlld2luZyBpdC4gU2hvdWxkbuKA mXQgdGhpcyBiZSBhZGRyZXNzZWQgaW4geW91ciBTZWN1cml0eQ0KPiBDb25zaWRlcmF0aW9ucz8g KEZvciBhbiBleGFtcGxlIG9mIGEgcmVsYXRlZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgc2Vl IFJGQw0KPiA5MDAzLiBJdOKAmXMgcHJvYmFibHkgbm90IHRoZSBiZXN0IGV4YW1wbGUsIGJ1dCBp dOKAmXMgdGhlIG9uZSBJIGhhZCBhdCBteQ0KPiBmaW5nZXJ0aXBz4oCmKQ0KPiANCj4gS1Q+IFJG QzkwMDMgdXNlcyBVVEYtOCB3aGlsZSB0aGlzIGRvY3VtZW50IHVzZXMgcHJpbnRhYmxlIEFTQ0lJ LiBBcyBzdWNoLCBJIGFtIG5vdCBhd2FyZSBvZiBzZWN1cml0eSBpc3N1ZXMgYXJvdW5kIHByaW50 YWJsZSBBU0NJSSAtIHBsZWFzZSBkbyBwb2ludCBtZSB0byBhbnkgcmVmZXJlbmNlcy4NCg0KWW91 4oCZcmUgdGhpbmtpbmcgdG9vIG11Y2ggbGlrZSBhIHByb3RvY29sIGRlc2lnbmVyLiBUaGUga2lu ZCBvZiBjb25jZXJuIEnigJltIHRoaW5raW5nIGFib3V0IGhhcyB0byBkbyB3aXRoIHVzaW5nIHRo ZSBzdHJpbmcgYXMgYSB2ZWN0b3IgdG8gcHV0IHNvbWUgd29yZHMgaW4gZnJvbnQgb2YgYW4gb3Bl cmF0b3IsIGFzIHBhcnQgb2YgYSBsYXJnZXIgc29jaWFsIGVuZ2luZWVyaW5nIGF0dGVtcHQuIEkg ZG9u4oCZdCBoYXZlIGEgZGV0YWlsZWQgYXR0YWNrIHNjZW5hcmlvIHRvIHBhaW50IGZvciB5b3Us IGJ1dCBhIHF1aWNrIHNrZXRjaCBpcyBhbG9uZyB0aGUgbGluZXMgb2YgDQoNCi0gQXR0YWNrZXIg bWFuYWdlcyB0byBpbmplY3QgYSBjYW5kaWRhdGUgcGF0aCB3aXRoIHRoZSBuYW1lIOKAnEJpZ19C YW5rX0xvd19MYXRlbmN54oCdDQoJLSBQcm9UaXA6IHRoZSBjYW5kaWRhdGUgcGF0aCBkb2VzIG5v dCBhY3R1YWxseSB0ZXJtaW5hdGUgYXQgQmlnX0JhbmsNCi0gQXR0YWNrZXIgdGhlbiBwaG9uZXMg Tk9DLCBmZWlnbnMgdXJnZW5jeSwgYXNrcyBOT0MgdG8gcmVkaXJlY3QgQmlnX0JhbmsgdHJhZmZp YyBvbnRvIHRoYXQgcGF0aA0KDQpZb3UgZ2V0IHRoZSBpZGVhLCBJIGhvcGUuDQoNCj4gQWxzbyBu b3RlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IHByb3RvY29sIGVuY29kaW5n cyB3aGVyZSBzb21lIGV4dHJhIHZlcmJpYWdlIGlzIG5vcm1hbGx5IHJlcXVpcmVkIChlLmcuIHRo YXQgaXQgaXMgc2lnbmFsZWQgd2l0aG91dCBOVUxMLCBoYW5kbGluZyB0cnVuY2F0aW9uL292ZXJy dW5zLCBldGMuKS4NCg0KQnV0IHlldCBpdCBkb2VzIHNwZWNpZnkgdGhlIHByZWNpc2UgY2hhcmFj dGVyIHNldCB0byBiZSB1c2VkLCBhbmQgYSBuZWFyLW9ic29sZXNjZW50IG9uZSBhdCB0aGF0LiBX aHkgaXMgdGhhdD8gSSBtZWFuLCBJIGRvbuKAmXQgaGF0ZSBBU0NJSSwgYnV0IEkganVzdCBmaW5k IGl0IG9kZCBhbmQgYXNzdW1lIHlvdSBhY3R1YWxseSBoYXZlIGEgcmVhc29uIGZvciBpdCwgaW5z dGVhZCBvZiB0YWtpbmcgZWl0aGVyIHRoZSBvcHRpb24gb2YgbGVhdmluZyB0aGUgY2hhcmFjdGVy IHNldCB1bnNwZWNpZmllZCAoYXMgeW91IHBvaW50IG91dCB0aGVyZSBhcmUgbWFueSBzdWNoIGRl dGFpbHMgeW91IGRvbuKAmXQgY29uY2VybiB5b3Vyc2VsZiB3aXRoIGluIHRoaXMgZG9jdW1lbnQp IG9yIGlmIHNwZWNpZnlpbmcgaXQsIHVzaW5nIFVURi04IG9yIHNpbWlsYXIuDQoNCj4gS1Q+IEFz IGRpc2N1c3NlZCBpbiB0aGUgV0csIHdlIGFyZSBzdGlja2luZyB0byBwcmludGFibGUgQVNDSUku IFdoZW4gdGhlIGVuY29kaW5nIGlzIHNwZWNpZmllZCB0byBiZSBwcmludGFibGUgQVNDSUksIGl0 IGlzIGV4cGVjdGVkIHRoYXQgaW1wbGVtZW50YXRpb25zIHZhbGlkIHRoYXQuDQoNCkkgYWRtaXJl IHlvdXIgb3B0aW1pc20uDQoNCuKAlEpvaG4= From nobody Wed Feb 16 13:59:21 2022 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 5DD423A16E8; Wed, 16 Feb 2022 13:59:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <164504875164.5704.16596621622345086808@ietfa.amsl.com> Date: Wed, 16 Feb 2022 13:59:12 -0800 Archived-At: Subject: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 16 Feb 2022 21:59:13 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) This specification should formally Update rfc8402. What is the relationship between this document and rfc8402? If this document details the concept introduced in rfc8402, why isn't there a formal Update relationship? Even the initial definition of SR Policy in this document (§2) doesn't match what rfc8402 says. This document defines it as "a framework that enables the instantiation of an ordered list of segments", while rfc8402 states it is "an ordered list of segments." In §2.2, this document uses the term "segment-list" for that. Besides the general topic of clarifying and updating what an SR Policy is, this document also includes other items that were not present in rfc8402; the list includes: §2.1: "SR Policy MUST be identified through the tuple ." There's not even a mention of "color" in rfc8402. §2.1: "The headend is specified as an IPv4 or IPv6 address and is expected to be unique in the domain." Neither the mechanism to identify a node nor the expectation is present in rfc8402. §2.1: "The endpoint is specified as an IPv4 or IPv6 address and is expected to be unique in the domain." Same as above. The SR Database is a new element not in the base architecture. The text in §3 says that "use of the SR-DB for computation and validation of SR Policies is outside the scope of this document", but it is then mentioned and used in §5.1/§5.2. Accordingly, the added details require additional Security and Manageability considerations. I couldn't find a related discussion in the archive. If I missed it, please point me in the right direction. (2) §5.1: Types A or B MUST be used for the SIDs for which the reachability cannot be verified. Note that the first SID MUST always be reachable regardless of its type. These two requirements and the text in the description of these types ("...does not require the headend to perform SID resolution.") results in a contradiction: Types A and B are not to be resolved, but if they are the first SID then they MUST. If it's not a contradiction, then Types A and B would not be allowed to be the first SID, which is not correct because the most straightforward mechanism to define a path is to list SR-MPLS Labels or SRv6 SIDs. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (0) I support John's DISCUSS. (1) Is the specification of a headend/endpoint mandatory? IOW, should the text in §2.1 about the headend/endpoint being identified by a unique IPv4 or IPv6 address be normative? (2) §2.1: "An implementation MAY allow the assignment of a symbolic name comprising of printable ASCII [RFC0020] [RFC5234] characters" Why are you normatively limiting the name to be represented in ASCII? Please internationalize it - use UTF-8. §2.6 also has similar text. (3) §2.1: "Such symbolic names MAY identify an SR Policy when the naming scheme ensures uniqueness." In this case, the "MAY" is just stating a fact. s/MAY/may (4) §2.1: "An SR Policy MAY have multiple names...in the scenario where the headend receives different SR Policy names" Describing multiple names as the case where multiple names are received is not helpful. (5) §2.2: "the endpoints of the constituent SR Policies and the parent SR Policy MUST be identical" To avoid confusion, by "endpoints" you mean "headend and endpoint", right? (6) §2.3: A headend MAY be informed about a candidate path for an SR Policy by various means including... It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may (7) §2.4: "When signaling is via PCEP...the AS number SHOULD be set to 0 by default when not available or known." When is it ok for the ASN to not be set to 0 (when not available or known)? If that possibility exists, the PCE can use any value (including the real number or a random one). What issues exist with uncoordinated (or rogue) PCEs using potentially arbitrary ASNs? Why is this action recommended and not required? (8) This paragraph in §2.5 seems to be missing something" The Discriminator is a 32-bit value associated with a candidate path that uniquely identifies it within the context of an SR Policy from a specific Protocol-Origin as specified below: "below" where? I guess you may mean "below in §2.6 (Identification of a Candidate Path)", but that section says that the "tuple uniquely identifies a candidate path" and not just the discriminator as above. Also, the ":" leads to some text about the default and specific protocols. Given that this document intends to provide an architecture, I would expect general consideration about the discriminator, and not pointers to how it can be signaled or, much less, the process in BGP. In general, I would expect the architecture to not rely on solution documents to explain how pieces of the architecture are derived. (9) Given the description, it seems possible for a PCE (for example) to advertise multiple candidate paths with the same Preference, Originator, and Discriminator. If that occurs, what is the result of the selection in §2.9? Would this situation result in multiple active candidate paths? (10) §2.11: "Only the active candidate path SHOULD be used for forwarding traffic that is being steered onto that policy." When is it ok to use non-active paths? Why is this action recommended and not required? (11) §2.12: Several of the "MAY" statements in this section express a fact, not a normative statement: s/MAY/may The operator MAY set this field... An SR Policy MAY comprise multiple... (12) §4: When the algorithm is not specified for the SID types above which optionally allow for it, the headend SHOULD use the Strict Shortest Path algorithm if available; otherwise, it SHOULD use the default Shortest Path algorithm. In this sentence, you're recommending both algorithms. When should one or the other be used? There are no qualifiers that lead to the "otherwise" statement. (13) §4: What is the purpose of enumerating the types of segment-descriptors? Should the type be indicated when the Segment-List is signaled? I assume the answer is yes, but I didn't see that specified anywhere. (14) §5.1: "The headend detects a mismatch between the SID value and its context provided for SIDs of type C-through-K" What does having a mismatch mean? Please be specific. (15) §5.2: When the local computation is not possible (e.g., a policy's tail-end is outside the topology known to the headend) or not desired, the headend MAY send path computation request to a PCE supporting PCEP extension specified in [RFC8664]. This action (ask the PCE) is a solution, not an architectural description. Are there other external mechanisms that can find a "solution Segment-List"? It seems to me that one such mechanism would be in the form of a configured Segment-List. If that is correct, please generalize the normative statement above -- where using PCEP can be an example. (16) §7: Which are valid states? Active is one, the text mentions an "administrative state", what else? Interoperability is a good reason to specify the states and not assume that implementations might do the right thing. (17) §7: "The SR Policy state MUST also reflect the reason when a policy and/or its candidate path is not active due to validation errors or not being preferred." Given that this is a requirement, please provide a list of reasons. The need for interoperability (by using rfc2119 language) can only be achieved if the reasons are standardized. (18) In general, the text contains a mixture of normative language (rfc2119) and descriptions that make the contents inconsistent and confusing. For example, my interpretation of "an SR Policy and its BSID are removed from the forwarding plane" (from §8.1) is that it is an absolute requirement. However, §8.2 presents the optional "Drop-Upon-Invalid behavior" which then indicates that there can be cases where my interpretation was not correct. The point here is that the text in a Standards Track document should not be up for interpretation. There are too many cases in the text to list that would have benefitted from using Normative Language -- I mentioned a couple above. Ideally, the authors would make one more pass for clarity. However, I will probably end up ABSTAINing because of it. This point was also raised in the rtg-dir review, which is why I'm not including it as part of a DISCUSS. From nobody Wed Feb 16 14:06:06 2022 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 A9CFF3A0B5F; Wed, 16 Feb 2022 14:06:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <164504916365.5606.17077981996669554325@ietfa.amsl.com> Date: Wed, 16 Feb 2022 14:06:03 -0800 Archived-At: Subject: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 16 Feb 2022 22:06:04 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There appear to be a few places where additional pointers or specification is needed to ensure interoperability. ** Section 2.5 When signaling is via PCEP, the method to uniquely signal an individual candidate path along with its discriminator is described in [I-D.ietf-pce-segment-routing-policy-cp]. Where is the explanation of discriminator in this reference? “Discriminator†appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2. In the first three section it is simply named but not explained. In the last section, it isn’t explained beyond being defined as 32-bits. ** Section 2.6. Candidate paths MAY also be assigned or signaled with a symbolic name comprising printable ASCII [RFC0020] [RFC5234] characters How these candidate paths names are signaled isn’t defined. I believe it is per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2.4.7 of draft-ietf-idr-segment-routing-te-policy. ** Section 2.7. How is the candidate path preference signaled? Is that draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support John Scudder and Alvaro Retana's DISCUSS positions. ** Section 2.1. The color is an unsigned non-zero 32-bit numerical value that associates the SR Policy with an intent or objective (e.g. low- latency). Should “numeric value†be “integerâ€? ** Section 2.1 The SR Policy name MAY also be signaled along with a candidate path of the SR Policy (refer to Section 2.2). -- It would be helpful to explicitly state either here or in Section 2.2 that Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section 5.2.1 of [I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how this naming is signaled. Section 2.2 doesn’t discuss signaling the name. -- Both of these document need to be normative reference since there is dependency on them for interoperable behavior. ** Section 2.2. Typo. s/heirarchical/hierarchical/ ** Section 2.3. It would be helpful if the precise mechanism to signal the Protocol-Origin was cited. -- I believe it is Section 5.2.2 of [I-D.ietf-pce-segment-routing-policy-cp] -- I didn’t find any reference to a “Protocol Origin†or this section in [I-D.ietf-idr-segment-routing-te-policy]. ** Section 2.4. When signaling is via BGP SR Policy, the ASN and Node Address are provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) on the headend. [I-D.ietf-idr-segment-routing-te-policy] needs to be a normative reference (as stated before due to the text in Section 2.1) ** Section 2.5. Per “When provisioning is via configuration, this is an implementation's configuration model-specific unique identifier for a candidate pathâ€, what is a “configuration model-model-specific unique identifier? What scope of the uniqueness? ** Section 2.13. This section says “the information model is the followingâ€, but I don’t follow where that information model (IM) is per the definition in RFC3444. The text here appears be an example with hard-coded parameter values. ** Section 4. Based on the desired dataplane, either the MPLS label stack or the SRv6 Segment Routing Header [RFC8754] is built from the Segment- List. Do SRv6 SRH and MPLS label stacks support all the segment types enumerated here? For example, does Type E and F, IPv4 segments, work with a SRv6 SRH? ** Section 4. When the algorithm is not specified for the SID types above which optionally allow for it, the headend SHOULD use the Strict Shortest Path algorithm if available; otherwise, it SHOULD use the default Shortest Path algorithm. The specification of the algorithm enables the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in SR Policy. Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative reference? ** Section 10. Given that this document has a dependency on [I-D.ietf-idr-segment-routing-te-policy] and [I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy, their security considerations should apply. From nobody Wed Feb 16 18:08:50 2022 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 8ED3F3A1161; Wed, 16 Feb 2022 18:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbg1yJjaGRPq; Wed, 16 Feb 2022 18:08:45 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2383A1152; Wed, 16 Feb 2022 18:08:45 -0800 (PST) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JzdRd2gndz6801q; Thu, 17 Feb 2022 10:04:13 +0800 (CST) Received: from canpemm500005.china.huawei.com (7.192.104.229) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 17 Feb 2022 03:08:42 +0100 Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 17 Feb 2022 10:08:40 +0800 Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2308.021; Thu, 17 Feb 2022 10:08:40 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: IETF 113 Slot Requests Collection Thread-Index: AdgjoxCwfywpFY7xSCStbRd/s3xF5g== Date: Thu, 17 Feb 2022 02:08:40 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.237.234] Content-Type: multipart/alternative; boundary="_000_e5f6c1da15334e16819e614372163dc3huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] IETF 113 Slot Requests Collection 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, 17 Feb 2022 02:08:49 -0000 --_000_e5f6c1da15334e16819e614372163dc3huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, For building the IETF 113 SPRING agenda, we will continue to using the Goog= le Form to collect presentation slot requests. Please submit your requests = in the following form up to 2022-03-04 EOD. https://docs.google.com/forms/d/e/1FAIpQLSfxY7TXAl53aMSpclmHjH-90ZTLsWoaZz7= _BvHvlYcewJeaFw/viewform If there is any issue for you to access this Form, please send your request= directly to spring-chairs@ietf.org. Thank you! Best regards, Shuping --_000_e5f6c1da15334e16819e614372163dc3huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

For building the IETF 113 SP= RING agenda, we will continue to using the Google Form to collect presentat= ion slot requests. Please submit your requests in the following form up to = 2022-03-04 EOD.

 

https://docs.google.com/forms/d/e/1FAIpQLSfxY7TXAl53aMSpclmHjH-90ZTLs= WoaZz7_BvHvlYcewJeaFw/viewform

 

If there is any issue for you t= o access this Form, please send your request directly to spring-chairs@ietf.org.<= /o:p>

 

Thank you!

 

Best regards,=

Shuping

 

--_000_e5f6c1da15334e16819e614372163dc3huaweicom_-- From nobody Wed Feb 16 22:16:56 2022 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 D9FBE3A121C; Wed, 16 Feb 2022 22:16:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <164507858486.11948.7818447548279924153@ietfa.amsl.com> Date: Wed, 16 Feb 2022 22:16:24 -0800 Archived-At: Subject: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 06:16:25 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I may just be misunderstanding things, but I'd like to pull on a thread in §8.4 a bit more. We say that the headend H learns a BGP route that has a VPN label V, but then the following procedures seem to say that we install a route on the appropriate SR Policy P and that when we receive a packet that matches the route in question, push a label stack including the VPN label, and send the resulting packet out. Nowhere do we say to check the VPN status of the incoming packet, so this seems like it would open a hole in the VPN by allowing "arbitrary" incoming traffic (not marked as specific to V) to enter that VPN. Is the label V filling some other role than identifying a specific VPN of many VPNs that could run along the route R/r? (This is the only instance of the phrase "VPN label" in the document, and no reference is given, so I'm relying heavily on instinct to ascertain the intent here.) (2) The security considerations says that this document does not define any new protocol extensions and (accordingly) does not introduce any further security considerations. The first part of this seems false, not least since we define the meaning of the "CO" bits in the Color Extended Community. I'm pretty sure that makes the second part also false, and we need to discuss the security considerations relating to imposing SR Policies based only on color and not next-hop. Alvaro has also noted additional aspects where security considerations are missing. (3) The Discriminator as defined in §2.5 does not seem wide enough to be able to provide the needed properties. Some later clarification in §2.6 implies that the definition in §2.5 is incomplete and the width is actually appropriate, but in either case §2.5 seems inadequate in its current form. (Details in the COMMENT.) (4) Section 2.11 contains the statement, "A valid SR Policy is instantiated in the forwarding plane." Is this a statement of fact (i.e., a consequence of the definition of "valid") or a mandate for something (e.g., the headend) to take action to make it so? Given that the point of SR is to be stateless on nodes other than the headend, I suspect the former, but if we are relying on the headend (or some other entity) to take action to ensure this is the case, that needs to be a clearly stated normative requirement. (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." There's nothing in the IANA registry for SAFI (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml) about LISP, and RFC 6830 doesn't talk about SAFI. What is this referring to? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There's a lot of this document that feels like just some informational discussion of "here are some things that many people do", "here are some possible things you can do with SR", etc.. There are also a small handful of places in the document that look to actually be specifying parts of protocol behavior (I suspect that John has already identified them in his enumeration), and the overall impression ends up being a bit jumbled, like there are a bunch of topics stuck together without an overarching theme. I think the overall content would be more valuable if divided into a tight "protocol specification" portion that could stay at proposed standard, plus an informational "architecture details" document that contains the in-depth exposition that didn't make it into 8402. This draft would benefit greatly from a terminology section. I note in the section-by-section comments several places where a term is first used without sufficient background/definition, leaving the matter at hand underspecified for the reader. Section 2 An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing Really, an SR policy is a *framework*? I thought an SR policy was a specific instantiation of a list of segments, or at least that's what I'm getting from RFC 8402. Perhaps we should say that the general concept of SR Policy provides a framework? Section 2.1 An SR Policy MUST be identified through the tuple . In the context of a specific headend, an SR policy MUST be identified by the tuple. These two MUSTs appear to be in (nominal) conflict. Maybe start the first one with "absent further context" or "absent the context of a known headend node"? The headend is the node where the policy is instantiated/implemented. The headend is specified as an IPv4 or IPv6 address and is expected to be unique in the domain. This is the first instance of the word "domain" in this document. I suggest using the introduction to introduce what is meant by the word, even if just by reference to RFC 8402. An implementation MAY allow the assignment of a symbolic name comprising printable ASCII [RFC0020] characters (i.e. 0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute for debugging and troubleshooting purposes. [...] I agree with the other ADs that limiting to US-ASCII is not actually user-friendly for many users, and that the likelihood of some implementations not properly enforcing such a limitation to be high. (Likewise for the other places where symbolic names are admitted.) Section 2.2 A dynamic candidate path expresses an optimization objective and a set of constraints. [...] Down in §5.2 when we discuss validation procedures for dynamic candidate paths, we say that the optimization problem is solved "for either the SR-MPLS or the SRv6 data-plane as specified". Does the data plane need to be specified as part of the dynamic candidate path itself? Section 2.3 in Section 2.9. The table below specifies the RECOMMENDED default values of Protocol-Origin: I feel like it would be useful to provide some justification for why the recommended default behavior prefers BGP SR configuration over PCEP, even if that justification is just "we need to have a clear ordering and this one is arbitrary". Section 2.4 o Node Address : represented as a 128-bit value. IPv4 addresses MUST be encoded in the lowest 32 bits, and the high-order bits MUST be set to zero. Its application in the candidate path selection is described in Section 2.9. The tie-breaker procedure for path selection described in §2.9 seems to always prefer IPv4 originators over IPv6 ones (by virtue of preferring the smaller value). I guess if we wanted to change that to prefer IPv6 we have the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped unicast) from BCP 153, but it's a bit hard to justify either of those as appropriate on technical grounds, and since this is just a tie-breaker and the Preference is explicitly preferred, it seems like this is probably "good enough" as-is. Section 2.5 The Discriminator is a 32-bit value associated with a candidate path that uniquely identifies it within the context of an SR Policy from a specific Protocol-Origin as specified below: What are the constraints that underlie the 32-bit requirement here? It looks like some of the scenarios are going to involve uncoordinated (random) assignment of these discriminator values (e.g., with the BGP distribution mechanism, when coming from different BGP peers), and the birthday-bound collision probability is not negligible for this few bits. That, in turn, calls into question the "uniquely identifies" property being claimed. Or is there some other property that means that only discriminators from a single issuer will ever need to be compared with each other (making the allocation "coordinated"), such as being additionally associated with the originator? If my initial analysis was incorrect and these are indeed allocated in a "coordinated" fashion, would it be typical/expected for the allocation to occur by incrementing a local counter on the originator? In some situations such allocation by counter can have security considerations, which draft-gont-numeric-ids-sec-considerations attempts to cover. Section 2.8 A candidate path is usable when it is valid. A common path validity criterion is the validity of any of its constituent Segment-Lists. The validation rules are specified in Section 5. This document claims to target Proposed Standard status; are we really content to say only that this is "a common" criterion? Even when we also go on to flat-out state "the validation rules are specified [below]"? Section 2.9 The candidate path selection process operates primarily on the candidate path Preference. A candidate path is selected when it is valid and it has the highest preference value among all the candidate paths of the SR Policy. Should this be "among all the valid candidate paths"? A path that's invalid is still invalid, even if it has the highest preference value. 2. If specified by configuration, prefer the existing installed path. Does "if specified by configuration" refer to the act of applying this rule at all, or that the existing installed path was one specified by configuration? Section 2.11 The fraction of the flows associated with a given Segment-List is w/ Sw, where w is the weight of the Segment-List and Sw is the sum of the weights of the Segment-Lists of the selected path of the SR Policy. Thank you for stating this clearly! Section 3 o TE Link Attributes (such as TE metric, Shared Risk Link Groups, attribute-flag, extended admin group) [RFC5305] [RFC3630]. Is RFC 5329 applicable here as well? Section 4 Type E: IPv4 Prefix with Local Interface ID: This type allows identification of Adjacency SID or BGP Peer Adjacency SID (as defined in [RFC8402]) SR-MPLS label for point-to-point links including IP unnumbered links. The headend is required to resolve the specified IPv4 Prefix Address to the Node originating it and then use the Local Interface ID to identify the point-to-point link whose adjacency is being referred to. The Local Interface ID link descriptor follows semantics as specified in [RFC7752]. This The phrase "local interface ID" does not appear in RFC 7752 (and even "local interface" appears just once"; please use terminology actually present in the referred-to document to clarify what is being referenced. Section 4.1 When steering unlabeled IPv6 BGP destination traffic using an SR policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit Null Label Policy is processed as specified in [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an It looks like this is §2.4.5, not 2.4.4, in the referenced document. Section 5.1 The computation/logic that leads to the choice of the Segment-List is external to the SR Policy headend. The SR Policy headend does not compute the Segment-List. The SR Policy headend only confirms its validity. Does the headend actually have to confirm validity? Is it okay to just trust the controller and blindly use what is provided? Section 6.2 When the active candidate path has a specified BSID, the SR Policy uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is available (i.e., not associated with any other usage: e.g. to another MPLS client, to another SRv6 client, to another SID, to another SR Policy, outside the range of SRv6 Locators). I don't think I understand what is meant by "client" here (for "another client"). This sentence is the only place where the word "client" appears in this document... Optionally, instead of only checking that the BSID of the active path is available, a headend MAY check that it is available within a given SID range i.e., Segment Routing Local Block (SRLB) as specified in [RFC8402]. Is the only allowed range to check the SRLB? If not, I think we need to s/i.e./e.g./. When the specified BSID is not available (optionally is not in the SRLB), an alert message MUST be generated. This is the first time (of only two) the word "alert" appears in this document, and there is no prior expalanation of what entity might be receiving alerts generated by a headend. Please clarify. Assuming that at time t the BSID of the SR Policy is B1, if at time t+dt a different candidate path becomes active and this new active path does not have a specified BSID or its BSID is specified but is not available (e.g. it is in use by something else), then the SR Policy MAY keep the previous BSID B1. Is there a strict bound on or other guidance for what values of dt are allowable for this purpose? Is the intent that there be an atomic transition from BSID=B1;active-path=P1 to BSID=B1;active-path=P2? The association of an SR Policy with a BSID thus MAY change over the life of the SR Policy (e.g., upon active path change). Hence, the BSID SHOULD NOT be used as an identification of an SR Policy. Is there any guidance available on how long to wait with a given BSID value unused before binding it to a new SR Policy? Section 6.2.3 An implementation MAY support the configuration of the Specified- BSID-only restrictive behavior on the headend for all SR Policies or individual SR Policies. Further, this restrictive behavior MAY also be signaled on a per SR Policy basis to the headend. Elsewhere in the document we discuss specific potential signaling mechanisms/protocols, but here we say nothing. Is that vagueness intentional? Section 6.3 A valid SR Policy installs a BSID-keyed entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the SR Policy. I don't think this is stated properly. An SR Policy is the list of segments; it isn't the entity that's installing entries in the forwarding plane. Some other entity is installing an entry in the forwarding plane to realize the SR Policy in question, and we should make our writing reflect that. Section 6.4 An implementation MAY choose to associate a Binding SID with any type of interface (e.g. a layer 3 termination of an Optical Circuit) or a tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE tunnel, etc). This enables the use of other non-SR enabled Should we have some discussion that contrasts this scenario against the End.X behavior from RFC 8986 (for the "interface" case)? Section 7 The SR Policy State is maintained on the headend to represent the state of the policy and its candidate paths. [...] I confess I don't really understand why we need to have the current, minimal, description of SR Policy State in this document. What would be lost if we deferred its discussion entirely until there is a more comprehensive discussion available? The SR Policy state can be reported by the headend node via BGP-LS [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and [I-D.ietf-pce-binding-label-sid]. The functionality of draft-ietf-pce-binding-label-sid seems much more limited than that of draft-ietf-idr-te-lsp-distribution; in particular, the former does not seem to actually report SR Policy state to the headed at all; rather, it only concerns itself with BSID association to path, with no information about "active", "not preferred", etc. Section 8.3 If the SR Policy P is invalid, the BSID B is not in the forwarding plane and hence the packet K is dropped by H. We literally just in the previous section talked about a scenario where the BSDI is kept in the forwarding plane (but with the action to drop, so the overall outcome is not changed from what this text describes). Nonetheless, it's inaccurate to state that "the BSID B is not in the forwarding plane" here. Section 8.4.1 When a BGP route has multiple Color Extended communities each with a valid SR Policy, the BGP process installs the route on the SR Policy giving preference to the color with the highest numerical value. Do we want to say anything about this being an arbitrary tiebreaker (rather than an intentional preference), or is that thought to be implicitly clear? Section 8.5 In this section, independent of the a-priori existence of any explicit candidate path of the SR policy (C, N), it is to be noted that the BGP process at headend node H triggers the instantiation of a dynamic candidate path for the SR policy (C, N) as soon as: I strongly suggest providing a more explicit framework of what the assumptions and preconditions are for the mechanism described in this section. My intuition says that it's a fairly optional thing that would need to be specifically configured, but trying to wrap that sentiment into the long bullet point involving "a local policy" seems like a very confusing way to express the desired behavior. Section 8.6 o is configured to instantiate an array of paths to N where the entry 0 is the IGP path to N, color C1 is the first entry and Color C2 is the second entry. The index into the array is called a Forwarding Class (FC). The index can have values 0 to 7. Why are the only allowed values 0 to 7? Where does this restriction arise from? It is because of some protocol element? If the local configuration does not specify any explicit forwarding information for an entry of the array, then this entry is filled with the same information as entry 0 (i.e. the IGP shortest path). If the SR Policy mapped to an entry of the array becomes invalid, then this entry is filled with the same information as entry 0. When all the array entries have the same information as entry0, the forwarding entry for N is updated to bypass the array and point directly to its outgoing interface and next-hop. I can't tell how much of this is supposed to be protocol specification and how much an illustrative example. Is A(0) always the IGP shortest path? Are these protocol requirements to fall back to the IGP shortest path when an entry is otherwise unpopulated or the associated SR Policy becomes invalid? Section 8.8.2 The steering preference is first based on the highest color value and then CO-dependent for the color. [...] This seems to contradict what I assumed earlier about the "highest color" rule being a tiebreaker, e.g., the word "preference" is used here. Is it actually intended to be a deliberately configured priority/preference scheme? If so, that would seem to require some wide-ranging reworking throughout the document. Section 9.3 the most appropriate alternative for the active candidate path. A fast re-route mechanism MAY then be used to trigger sub 50msec switchover from the active to the backup candidate path in the forwarding plane. Mechanisms like Bidirectional Forwarding Detection (BFD) MAY be used for fast detection of such failures. Why is the specific 50msec value important here? Is there some other requirement that imposes it? Section 10 I think we also want to mention the security considerations of several more documents, including (but not limited to) draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986. Section 15.2 I agree with John that draft-ietf-idr-segment-routing-te-policy must be classified as a normative reference. It also seems that RFC 7752 should be classified as normative, as we incorporate its definition for the semantics of several of the segment type descriptions. NITS Section 1 Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of segments (i.e. instructions) that represent a source-routed policy. /Segment/A Segment/ The headend node is said to steer a flow into a SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. [...] In a certain sense this can be read as saying that the packets that "carry an ordered list of segments" are the ones prior to being steered into an SR policy, which would make this statement not true. Perhaps we want to say "after being steered into an SR Policy, packets carry an ordered list ..."? (I also went back and forth with myself about whether "packets ... carry" implies in the payload or not. I settled on "not" but make this note just in case I am missing an aspect of that question.) Section 2 An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing It's easy to read this as saying that all of the segments in the list instantiated on the single node in question, which I assume is not the intent. Probably the easiest way to aid readability here is to split the sentence up into multiple smaller sentences that are easier to parse. Section 2.2 A dynamic candidate path expresses an optimization objective and a set of constraints. The headend (potentially with the help of a PCE) computes the solution Segment-List (or set of Segment-Lists) that solves the optimization problem. I'd suggest computes the solution/computes a solution/ for genericity. A stateful PCE might end up computing a path that is not the optimal one for this specific optimization problem, due to a desire to cooperate with other paths in the network, and the "Min-Metric with margin and maximum number of SIDs" objective in draft-filsfils-spring-sr-policy-considerations doesn't even have a guaranteed unique best solution. Section 2.5 When provisioning is via configuration, this is an implementation's configuration model-specific unique identifier for a candidate path. The default value is 0. I'm having a lot of trouble parsing this. Did we perhaps mean to hyphenate as "configuration-model-specific"? Section 2.13 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is identified by a tuple . I suggest (for the last sentence) "identified within the scope of POL1" forwarding instantiation of SR policy POL1. Traffic steered on POL1 is flow-based hashed on Segment-List with a ratio W1/(W1+W2). If I read "ratio" I would instinctively think of the ratio of (traffic on segment list 1)/(traffic on segment list 2), as opposed to the proportion of all traffic, that would be measured as the indicated W1/(W1+W2). Section 3 The attached domain topology may be learned via IGP, BGP-LS or NETCONF. A non-attached (remote) domain topology may be learned via BGP-LS or NETCONF. I think these are both probably not exhaustive lists, so "e.g." or similar may be appropriate. Section 4 Type C: IPv4 Prefix with optional SR Algorithm: The headend is required to resolve the specified IPv4 Prefix Address to the SR-MPLS label corresponding to a Prefix SID segment (as defined in [RFC8402]). The SR algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY also be provided. Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: In this case, the headend is required to resolve the specified IPv6 Global Prefix Address to the SR-MPLS label corresponding to its Prefix SID segment (as defined in [RFC8402]). The SR Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY These are effectively just the IPv4 and IPv6 incarnations of the same underlying procedure, right? Can't we minimize the diff between the paragraphs further? Section 5.1 Additionally, a Segment-List MAY be declared invalid when: We probably want another word here ("both"?), to specify how the two conditions are combined. Section 5.2 When the local computation is not possible (e.g., a policy's tail-end is outside the topology known to the headend) or not desired, the headend MAY send path computation request to a PCE supporting PCEP extension specified in [RFC8664]. missing article ("the PCEP extension"). I forget if it should be "extensions" plural. Section 8.7 Finally, headend H MAY be configured with a local routing policy which overrides any BGP/IGP path and steer a specified packet on an singular/plural mismatch -- s/steer/steers/ From nobody Wed Feb 16 22:25:25 2022 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 C94073A0C4C; Wed, 16 Feb 2022 22:25:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <164507910578.23097.16832974293707785519@ietfa.amsl.com> Date: Wed, 16 Feb 2022 22:25:05 -0800 Archived-At: Subject: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 06:25:09 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I may just be misunderstanding things, but I'd like to pull on a thread in §8.4 a bit more. We say that the headend H learns a BGP route that has a VPN label V, but then the following procedures seem to say that we install a route on the appropriate SR Policy P and that when we receive a packet that matches the route in question, push a label stack including the VPN label, and send the resulting packet out. Nowhere do we say to check the VPN status of the incoming packet, so this seems like it would open a hole in the VPN by allowing "arbitrary" incoming traffic (not marked as specific to V) to enter that VPN. Is the label V filling some other role than identifying a specific VPN of many VPNs that could run along the route R/r? (This is the only instance of the phrase "VPN label" in the document, and no reference is given, so I'm relying heavily on instinct to ascertain the intent here.) (2) The security considerations says that this document does not define any new protocol extensions and (accordingly) does not introduce any further security considerations. The first part of this seems false, not least since we define the meaning of the "CO" bits in the Color Extended Community. I'm pretty sure that makes the second part also false, and we need to discuss the security considerations relating to imposing SR Policies based only on color and not next-hop. Alvaro has also noted additional aspects where security considerations are missing. (3) The Discriminator as defined in §2.5 does not seem wide enough to be able to provide the needed properties. Some later clarification in §2.6 implies that the definition in §2.5 is incomplete and the width is actually appropriate, but in either case §2.5 seems inadequate in its current form. (Details in the COMMENT.) (4) Section 2.11 contains the statement, "A valid SR Policy is instantiated in the forwarding plane." Is this a statement of fact (i.e., a consequence of the definition of "valid") or a mandate for something (e.g., the headend) to take action to make it so? Given that the point of SR is to be stateless on nodes other than the headend, I suspect the former, but if we are relying on the headend (or some other entity) to take action to ensure this is the case, that needs to be a clearly stated normative requirement. (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." There's nothing in the IANA registry for SAFI (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml) about LISP, and RFC 6830 doesn't talk about SAFI. What is this referring to? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [updated to add another note on the security considerations] There's a lot of this document that feels like just some informational discussion of "here are some things that many people do", "here are some possible things you can do with SR", etc.. There are also a small handful of places in the document that look to actually be specifying parts of protocol behavior (I suspect that John has already identified them in his enumeration), and the overall impression ends up being a bit jumbled, like there are a bunch of topics stuck together without an overarching theme. I think the overall content would be more valuable if divided into a tight "protocol specification" portion that could stay at proposed standard, plus an informational "architecture details" document that contains the in-depth exposition that didn't make it into 8402. This draft would benefit greatly from a terminology section. I note in the section-by-section comments several places where a term is first used without sufficient background/definition, leaving the matter at hand underspecified for the reader. Section 2 An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing Really, an SR policy is a *framework*? I thought an SR policy was a specific instantiation of a list of segments, or at least that's what I'm getting from RFC 8402. Perhaps we should say that the general concept of SR Policy provides a framework? Section 2.1 An SR Policy MUST be identified through the tuple . In the context of a specific headend, an SR policy MUST be identified by the tuple. These two MUSTs appear to be in (nominal) conflict. Maybe start the first one with "absent further context" or "absent the context of a known headend node"? The headend is the node where the policy is instantiated/implemented. The headend is specified as an IPv4 or IPv6 address and is expected to be unique in the domain. This is the first instance of the word "domain" in this document. I suggest using the introduction to introduce what is meant by the word, even if just by reference to RFC 8402. An implementation MAY allow the assignment of a symbolic name comprising printable ASCII [RFC0020] characters (i.e. 0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute for debugging and troubleshooting purposes. [...] I agree with the other ADs that limiting to US-ASCII is not actually user-friendly for many users, and that the likelihood of some implementations not properly enforcing such a limitation to be high. (Likewise for the other places where symbolic names are admitted.) Section 2.2 A dynamic candidate path expresses an optimization objective and a set of constraints. [...] Down in §5.2 when we discuss validation procedures for dynamic candidate paths, we say that the optimization problem is solved "for either the SR-MPLS or the SRv6 data-plane as specified". Does the data plane need to be specified as part of the dynamic candidate path itself? Section 2.3 in Section 2.9. The table below specifies the RECOMMENDED default values of Protocol-Origin: I feel like it would be useful to provide some justification for why the recommended default behavior prefers BGP SR configuration over PCEP, even if that justification is just "we need to have a clear ordering and this one is arbitrary". Section 2.4 o Node Address : represented as a 128-bit value. IPv4 addresses MUST be encoded in the lowest 32 bits, and the high-order bits MUST be set to zero. Its application in the candidate path selection is described in Section 2.9. The tie-breaker procedure for path selection described in §2.9 seems to always prefer IPv4 originators over IPv6 ones (by virtue of preferring the smaller value). I guess if we wanted to change that to prefer IPv6 we have the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped unicast) from BCP 153, but it's a bit hard to justify either of those as appropriate on technical grounds, and since this is just a tie-breaker and the Preference is explicitly preferred, it seems like this is probably "good enough" as-is. Section 2.5 The Discriminator is a 32-bit value associated with a candidate path that uniquely identifies it within the context of an SR Policy from a specific Protocol-Origin as specified below: What are the constraints that underlie the 32-bit requirement here? It looks like some of the scenarios are going to involve uncoordinated (random) assignment of these discriminator values (e.g., with the BGP distribution mechanism, when coming from different BGP peers), and the birthday-bound collision probability is not negligible for this few bits. That, in turn, calls into question the "uniquely identifies" property being claimed. Or is there some other property that means that only discriminators from a single issuer will ever need to be compared with each other (making the allocation "coordinated"), such as being additionally associated with the originator? If my initial analysis was incorrect and these are indeed allocated in a "coordinated" fashion, would it be typical/expected for the allocation to occur by incrementing a local counter on the originator? In some situations such allocation by counter can have security considerations, which draft-gont-numeric-ids-sec-considerations attempts to cover. Section 2.8 A candidate path is usable when it is valid. A common path validity criterion is the validity of any of its constituent Segment-Lists. The validation rules are specified in Section 5. This document claims to target Proposed Standard status; are we really content to say only that this is "a common" criterion? Even when we also go on to flat-out state "the validation rules are specified [below]"? Section 2.9 The candidate path selection process operates primarily on the candidate path Preference. A candidate path is selected when it is valid and it has the highest preference value among all the candidate paths of the SR Policy. Should this be "among all the valid candidate paths"? A path that's invalid is still invalid, even if it has the highest preference value. 2. If specified by configuration, prefer the existing installed path. Does "if specified by configuration" refer to the act of applying this rule at all, or that the existing installed path was one specified by configuration? Section 2.11 The fraction of the flows associated with a given Segment-List is w/ Sw, where w is the weight of the Segment-List and Sw is the sum of the weights of the Segment-Lists of the selected path of the SR Policy. Thank you for stating this clearly! Section 3 o TE Link Attributes (such as TE metric, Shared Risk Link Groups, attribute-flag, extended admin group) [RFC5305] [RFC3630]. Is RFC 5329 applicable here as well? Section 4 Type E: IPv4 Prefix with Local Interface ID: This type allows identification of Adjacency SID or BGP Peer Adjacency SID (as defined in [RFC8402]) SR-MPLS label for point-to-point links including IP unnumbered links. The headend is required to resolve the specified IPv4 Prefix Address to the Node originating it and then use the Local Interface ID to identify the point-to-point link whose adjacency is being referred to. The Local Interface ID link descriptor follows semantics as specified in [RFC7752]. This The phrase "local interface ID" does not appear in RFC 7752 (and even "local interface" appears just once"; please use terminology actually present in the referred-to document to clarify what is being referenced. Section 4.1 When steering unlabeled IPv6 BGP destination traffic using an SR policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit Null Label Policy is processed as specified in [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an It looks like this is §2.4.5, not 2.4.4, in the referenced document. Section 5.1 The computation/logic that leads to the choice of the Segment-List is external to the SR Policy headend. The SR Policy headend does not compute the Segment-List. The SR Policy headend only confirms its validity. Does the headend actually have to confirm validity? Is it okay to just trust the controller and blindly use what is provided? Section 6.2 When the active candidate path has a specified BSID, the SR Policy uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is available (i.e., not associated with any other usage: e.g. to another MPLS client, to another SRv6 client, to another SID, to another SR Policy, outside the range of SRv6 Locators). I don't think I understand what is meant by "client" here (for "another client"). This sentence is the only place where the word "client" appears in this document... Optionally, instead of only checking that the BSID of the active path is available, a headend MAY check that it is available within a given SID range i.e., Segment Routing Local Block (SRLB) as specified in [RFC8402]. Is the only allowed range to check the SRLB? If not, I think we need to s/i.e./e.g./. When the specified BSID is not available (optionally is not in the SRLB), an alert message MUST be generated. This is the first time (of only two) the word "alert" appears in this document, and there is no prior expalanation of what entity might be receiving alerts generated by a headend. Please clarify. Assuming that at time t the BSID of the SR Policy is B1, if at time t+dt a different candidate path becomes active and this new active path does not have a specified BSID or its BSID is specified but is not available (e.g. it is in use by something else), then the SR Policy MAY keep the previous BSID B1. Is there a strict bound on or other guidance for what values of dt are allowable for this purpose? Is the intent that there be an atomic transition from BSID=B1;active-path=P1 to BSID=B1;active-path=P2? The association of an SR Policy with a BSID thus MAY change over the life of the SR Policy (e.g., upon active path change). Hence, the BSID SHOULD NOT be used as an identification of an SR Policy. Is there any guidance available on how long to wait with a given BSID value unused before binding it to a new SR Policy? Section 6.2.3 An implementation MAY support the configuration of the Specified- BSID-only restrictive behavior on the headend for all SR Policies or individual SR Policies. Further, this restrictive behavior MAY also be signaled on a per SR Policy basis to the headend. Elsewhere in the document we discuss specific potential signaling mechanisms/protocols, but here we say nothing. Is that vagueness intentional? Section 6.3 A valid SR Policy installs a BSID-keyed entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the SR Policy. I don't think this is stated properly. An SR Policy is the list of segments; it isn't the entity that's installing entries in the forwarding plane. Some other entity is installing an entry in the forwarding plane to realize the SR Policy in question, and we should make our writing reflect that. Section 6.4 An implementation MAY choose to associate a Binding SID with any type of interface (e.g. a layer 3 termination of an Optical Circuit) or a tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE tunnel, etc). This enables the use of other non-SR enabled Should we have some discussion that contrasts this scenario against the End.X behavior from RFC 8986 (for the "interface" case)? Section 7 The SR Policy State is maintained on the headend to represent the state of the policy and its candidate paths. [...] I confess I don't really understand why we need to have the current, minimal, description of SR Policy State in this document. What would be lost if we deferred its discussion entirely until there is a more comprehensive discussion available? The SR Policy state can be reported by the headend node via BGP-LS [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and [I-D.ietf-pce-binding-label-sid]. The functionality of draft-ietf-pce-binding-label-sid seems much more limited than that of draft-ietf-idr-te-lsp-distribution; in particular, the former does not seem to actually report SR Policy state to the headed at all; rather, it only concerns itself with BSID association to path, with no information about "active", "not preferred", etc. Section 8.3 If the SR Policy P is invalid, the BSID B is not in the forwarding plane and hence the packet K is dropped by H. We literally just in the previous section talked about a scenario where the BSDI is kept in the forwarding plane (but with the action to drop, so the overall outcome is not changed from what this text describes). Nonetheless, it's inaccurate to state that "the BSID B is not in the forwarding plane" here. Section 8.4.1 When a BGP route has multiple Color Extended communities each with a valid SR Policy, the BGP process installs the route on the SR Policy giving preference to the color with the highest numerical value. Do we want to say anything about this being an arbitrary tiebreaker (rather than an intentional preference), or is that thought to be implicitly clear? Section 8.5 In this section, independent of the a-priori existence of any explicit candidate path of the SR policy (C, N), it is to be noted that the BGP process at headend node H triggers the instantiation of a dynamic candidate path for the SR policy (C, N) as soon as: I strongly suggest providing a more explicit framework of what the assumptions and preconditions are for the mechanism described in this section. My intuition says that it's a fairly optional thing that would need to be specifically configured, but trying to wrap that sentiment into the long bullet point involving "a local policy" seems like a very confusing way to express the desired behavior. Section 8.6 o is configured to instantiate an array of paths to N where the entry 0 is the IGP path to N, color C1 is the first entry and Color C2 is the second entry. The index into the array is called a Forwarding Class (FC). The index can have values 0 to 7. Why are the only allowed values 0 to 7? Where does this restriction arise from? It is because of some protocol element? If the local configuration does not specify any explicit forwarding information for an entry of the array, then this entry is filled with the same information as entry 0 (i.e. the IGP shortest path). If the SR Policy mapped to an entry of the array becomes invalid, then this entry is filled with the same information as entry 0. When all the array entries have the same information as entry0, the forwarding entry for N is updated to bypass the array and point directly to its outgoing interface and next-hop. I can't tell how much of this is supposed to be protocol specification and how much an illustrative example. Is A(0) always the IGP shortest path? Are these protocol requirements to fall back to the IGP shortest path when an entry is otherwise unpopulated or the associated SR Policy becomes invalid? Section 8.8.2 The steering preference is first based on the highest color value and then CO-dependent for the color. [...] This seems to contradict what I assumed earlier about the "highest color" rule being a tiebreaker, e.g., the word "preference" is used here. Is it actually intended to be a deliberately configured priority/preference scheme? If so, that would seem to require some wide-ranging reworking throughout the document. Section 9.3 the most appropriate alternative for the active candidate path. A fast re-route mechanism MAY then be used to trigger sub 50msec switchover from the active to the backup candidate path in the forwarding plane. Mechanisms like Bidirectional Forwarding Detection (BFD) MAY be used for fast detection of such failures. Why is the specific 50msec value important here? Is there some other requirement that imposes it? Section 10 I think we also want to mention the security considerations of several more documents, including (but not limited to) draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986. It seems that having a centralized "SR DB" would present an attractive target that (if compromised) would allow an attacker to construct very damaging attacks on the SR domain. Accordingly, we should say that the realization (if any) of the SR DB needs to be strongly protected at rest (and if transit, if it is ever conveyed around). There are probably also some things to say about risk due to reuse of BSID for different SR Policies. The techniques described in section 8 for steering traffic into SR Policy seem to have some considerations about the risks incurred by misdirected traffic (e.g., due to misconfiguration). There is perhaps also risk of misuse for per-flow steering, though it is hard to say much that is not vague on this topic. ("A single user's flows might get redirected to a node where illegal traffic inspection, e.g., that violates BCP 188, is performed" is an obvious bugbear, but not always the strongest argument to make.) Section 15.2 I agree with John that draft-ietf-idr-segment-routing-te-policy must be classified as a normative reference. It also seems that RFC 7752 should be classified as normative, as we incorporate its definition for the semantics of several of the segment type descriptions. NITS Section 1 Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of segments (i.e. instructions) that represent a source-routed policy. /Segment/A Segment/ The headend node is said to steer a flow into a SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. [...] In a certain sense this can be read as saying that the packets that "carry an ordered list of segments" are the ones prior to being steered into an SR policy, which would make this statement not true. Perhaps we want to say "after being steered into an SR Policy, packets carry an ordered list ..."? (I also went back and forth with myself about whether "packets ... carry" implies in the payload or not. I settled on "not" but make this note just in case I am missing an aspect of that question.) Section 2 An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing It's easy to read this as saying that all of the segments in the list instantiated on the single node in question, which I assume is not the intent. Probably the easiest way to aid readability here is to split the sentence up into multiple smaller sentences that are easier to parse. Section 2.2 A dynamic candidate path expresses an optimization objective and a set of constraints. The headend (potentially with the help of a PCE) computes the solution Segment-List (or set of Segment-Lists) that solves the optimization problem. I'd suggest computes the solution/computes a solution/ for genericity. A stateful PCE might end up computing a path that is not the optimal one for this specific optimization problem, due to a desire to cooperate with other paths in the network, and the "Min-Metric with margin and maximum number of SIDs" objective in draft-filsfils-spring-sr-policy-considerations doesn't even have a guaranteed unique best solution. Section 2.5 When provisioning is via configuration, this is an implementation's configuration model-specific unique identifier for a candidate path. The default value is 0. I'm having a lot of trouble parsing this. Did we perhaps mean to hyphenate as "configuration-model-specific"? Section 2.13 The SR Policy POL1 is identified by the tuple . It has two candidate paths CP1 and CP2. Each is identified by a tuple . I suggest (for the last sentence) "identified within the scope of POL1" forwarding instantiation of SR policy POL1. Traffic steered on POL1 is flow-based hashed on Segment-List with a ratio W1/(W1+W2). If I read "ratio" I would instinctively think of the ratio of (traffic on segment list 1)/(traffic on segment list 2), as opposed to the proportion of all traffic, that would be measured as the indicated W1/(W1+W2). Section 3 The attached domain topology may be learned via IGP, BGP-LS or NETCONF. A non-attached (remote) domain topology may be learned via BGP-LS or NETCONF. I think these are both probably not exhaustive lists, so "e.g." or similar may be appropriate. Section 4 Type C: IPv4 Prefix with optional SR Algorithm: The headend is required to resolve the specified IPv4 Prefix Address to the SR-MPLS label corresponding to a Prefix SID segment (as defined in [RFC8402]). The SR algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY also be provided. Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: In this case, the headend is required to resolve the specified IPv6 Global Prefix Address to the SR-MPLS label corresponding to its Prefix SID segment (as defined in [RFC8402]). The SR Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY These are effectively just the IPv4 and IPv6 incarnations of the same underlying procedure, right? Can't we minimize the diff between the paragraphs further? Section 5.1 Additionally, a Segment-List MAY be declared invalid when: We probably want another word here ("both"?), to specify how the two conditions are combined. Section 5.2 When the local computation is not possible (e.g., a policy's tail-end is outside the topology known to the headend) or not desired, the headend MAY send path computation request to a PCE supporting PCEP extension specified in [RFC8664]. missing article ("the PCEP extension"). I forget if it should be "extensions" plural. Section 8.7 Finally, headend H MAY be configured with a local routing policy which overrides any BGP/IGP path and steer a specified packet on an singular/plural mismatch -- s/steer/steers/ From nobody Wed Feb 16 22:36:18 2022 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 4F8FF3A1296; Wed, 16 Feb 2022 22:36:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <164507977558.18479.8326591988168272569@ietfa.amsl.com> Date: Wed, 16 Feb 2022 22:36:16 -0800 Archived-At: Subject: [spring] Murray Kucherawy's No Objection on draft-ietf-spring-segment-routing-policy-17: (with COMMENT) 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, 17 Feb 2022 06:36:17 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Cullen Jennings for his ARTART review. I'm hardly an expert on the technologies described here, but most of the SHOULDs I ran into left me wondering why they aren't MUSTs. There's no obvious (to me) implementation guidance present about when one might legitimately do something other than what the SHOULD says. Should Section 2.1 stipulate that symbolic names, if used, should be unique? Thanks for the attention to detail in Section 12. From nobody Wed Feb 16 22:46:22 2022 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 95D293A1337 for ; Wed, 16 Feb 2022 22:46:20 -0800 (PST) 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, CTE_8BIT_MISMATCH=0.001, RCVD_IN_MSPIKE_H5=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 t4cBUH28eZJ4 for ; Wed, 16 Feb 2022 22:46:15 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CABE3A132D for ; Wed, 16 Feb 2022 22:46:15 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Jzlj13dVZz8MwFG for ; Thu, 17 Feb 2022 14:46:13 +0800 (CST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4JzlhR3KNfz501Qj; Thu, 17 Feb 2022 14:45:43 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id 21H6jQRG099425; Thu, 17 Feb 2022 14:45:26 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn) Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Thu, 17 Feb 2022 14:45:26 +0800 (CST) Date: Thu, 17 Feb 2022 14:45:26 +0800 (CST) X-Zmail-TransId: 2afc620def0656bd4140 X-Mailer: Zmail v1.0 Message-ID: <202202171445262421849@zte.com.cn> In-Reply-To: References: 164223793434.20409.9148647733388794281@ietfa.amsl.com, 202202071741403841025@zte.com.cn, ZRAP278MB01762D679126CFE9800E4ABE89319@ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM Mime-Version: 1.0 From: To: Cc: Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl1.zte.com.cn 21H6jQRG099425 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 620DEF35.000 by FangMail milter! X-FangMail-Envelope: 1645080373/4Jzlj13dVZz8MwFG/620DEF35.000/192.168.251.13/[192.168.251.13]/mxct.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 620DEF35.000/4Jzlj13dVZz8MwFG Archived-At: Subject: Re: [spring] =?utf-8?q?New_Version_Notification_for_draft-tgraf-opsa?= =?utf-8?q?wg-ipfix-srv6-srh-00=2Etxt?= 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, 17 Feb 2022 06:46:21 -0000 Hi Thomas, I've read it and this revision addresses all my comments. Thanks, Yao ------------------原始邮件------------------ å‘件人：Thomas.Graf@swisscom.com 收件人：刘尧00165286; 抄é€äººï¼šspring@ietf.org; æ—¥ 期 ：2022å¹´02月12æ—¥ 16:10 主 题 ：RE: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Dear Yao, Thanks a lot for the detailed description. Both understood, acknowledged and being merged to the -01 version. Feedback welcome. https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-01.txt I will publish -01 in the upcoming weeks before IETF 113. Best wishes Thomas -----Original Message----- From: liu.yao71@zte.com.cn Sent: Monday, February 7, 2022 10:42 AM To: Graf Thomas, INI-NET-TCZ-ZH1 Cc: spring@ietf.org Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, Sorry for the late reply. Please see inline [Yao2]. > [Yao] Segments left is one of the elements to identify an SRH. For example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also useful when exporting SRv6 information. Would you agree that ipv6SRHSegmentList at node egress would be equal to Segments left? Or in other words segments left would only differ at ingress to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would you please describe me what kind of use case you have in mind. [Yao2] I mean without segment left, it's difficult to distinguish between packets of the same segment list in some cases. Below is one scenario I can think of. The corresponding segment list of path 1--A--2--3--1--A--4 is . 3 / \ / \ 1 2 \ / \ / A-----4 The flow passes node A twice. The first time, the packet is (SA,DA=SID-A). The second time, the packet is (SA,DA=SID-A). If one wants to collect the info of these two traffic separately, the segment left element is needed. But to be honest, I'm not sure whether this requirement is strong. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined. What if the user want to export the SRH TLV info of the packets? You mean the entire SRH header without disassemble the dimensions into IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes a lot of sense and I consider this to the -01 version of the document. [Yao2] Yes, that's what I mean. Best Regards, Yao ------------------原始邮件------------------ å‘件人：Thomas.Graf@swisscom.com 收件人：刘尧00165286; 抄é€äººï¼šspring@ietf.org; æ—¥ 期 ：2022å¹´01月30æ—¥ 14:17 主 题 ：Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Yao Thanks a lot for your input. > [Yao] Segments left is one of the elements to identify an SRH. For example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also useful when exporting SRv6 information. Would you agree that ipv6SRHSegmentList at node egress would be equal to Segments left? Or in other words segments left would only differ at ingress to ipv6SRHSegmentList. Correct? If yes, than I think I got your point. Would you please describe me what kind of use case you have in mind. > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined. What if the user want to export the SRH TLV info of the packets? You mean the entire SRH header without disassemble the dimensions into IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this makes a lot of sense and I consider this to the -01 version of the document. Looking forward to your clarifications. Best wishes Thomas -----Original Message----- From: liu.yao71@zte.com.cn Sent: Tuesday, January 25, 2022 10:27 AM To: Graf Thomas, INI-NET-TCZ-ZH1 Cc: spring@ietf.org Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, Please see inline [Yao]. Best Regards, Yao ------------------原始邮件------------------ å‘件人：Thomas.Graf@swisscom.com 收件人：刘尧00165286; 抄é€äººï¼šspring@ietf.org; æ—¥ 期 ：2022å¹´01月23æ—¥ 01:16 主 题 ：Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Yao, Many thanks for the review and feedback. > 1) But this draft describes the routing protocol where the last SRv6 segment has been learned from, instead of the SRv6 segment to be processed by the current hop. I am going to rephrase the sentences to refer to the active segment. Which should make it less ambiguous. > 2) but in SRv6, segment list and segments left(currently not defined in the draft) are both needed to provide the similar information. Could you elaborate the use case for segments left in this context. This document covers all dimensions being present in the SRv6 segment routing header described in section of RFC8754 (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8754%23section-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n6Y0xX3DT1BmusOLbuUXDZHb2CQ%2BiJlY%2FSOPxIcTr7c%3D&reserved=0) with the exception of "Last Entry". [Yao] Segments left is one of the elements to identify an SRH. For example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also useful when exporting SRv6 information. > 3) Element for SRH TLV is not defined in the draft, what's the consideration about that? Could you elaborate further please. The document refers to RFC 8754 where the SRH TLV is being described. [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are defined. What if the user want to export the SRH TLV info of the packets? Best wishes Thomas -----Original Message----- From: liu.yao71@zte.com.cn Sent: Thursday, January 20, 2022 10:23 AM To: Graf Thomas, INI-NET-TCZ-ZH1 Cc: spring@ietf.org Subject: Re:[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Hi Thomas, I've read the draft and have some questions. 1) RFC 9160 introduces new protocol types for SR-MPLS top label. Considering that the MPLS top label is always the label to be processed, the user can know which protocol the SR-MPLS SID to be processed is learned from. But this draft describes the routing protocol where the last SRv6 segment has been learned from, instead of the SRv6 segment to be processed by the current hop. As for my understanding, the current draft is inconsistent with RFC 9160 in this aspect. 2) Related to point 1，in SR-MPLS, exporting the top label can provide the information of the segment to be processed, but in SRv6, segment list and segments left(currently not defined in the draft) are both needed to provide the similar information. 2) Element for SRH TLV is not defined in the draft, what's the consideration about that? Best Regards, Yao ------------------原始邮件------------------ å‘件人：Thomas.Graf@swisscom.com 收件人：spring@ietf.org; æ—¥ 期 ：2022å¹´01月15æ—¥ 17:27 主 题 ：[spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Dear SPRING working group, Following up on just released RFC 9160 (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9160&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZRYzSkFXCDSSUYprLXjgHAdfQHPLFnTl6sA8xMW2Ur4%3D&reserved=0), IPFIX code points for MPLS Segment Routing, https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&reserved=0 has been submitted for the SRV6 data-plane. The document aims to be on par with MPLS-SR. Describe the routing protocol or PCEP extension where the last SRv6 segment has been learned from, the SRv6 segment list and all other properties from the Segment Routing header. I would appreciate your document review and feedback. I aim to present at IETF 113 at OPSAWG and SPRING and request adoption at OPSAWG. Best wishes Thomas -----Original Message----- From: internet-drafts@ietf.org Sent: Saturday, January 15, 2022 10:12 AM To: Graf Thomas, INI-NET-TCZ-ZH1 Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-00.txt has been successfully submitted by Thomas Graf and posted to the IETF repository. Name: draft-tgraf-opsawg-ipfix-srv6-srh Revision: 00 Title: Export of Segment Routing IPv6 Information in IP Flow Information Export (IPFIX) Document date: 2022-01-15 Group: Individual Submission Pages: 9 URL: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tgraf-opsawg-ipfix-srv6-srh-00.txt&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XSp7znVjIkQqPZLpCUx04tD1eaH9RoOHT6xJlX1cMq0%3D&reserved=0 Status: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-opsawg-ipfix-srv6-srh%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=e80kd7Krk7V4yiw6jtjyh7O144HPwwAlJkUMNYcOzXc%3D&reserved=0 Htmlized: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tgraf-opsawg-ipfix-srv6-srh&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OWgQAA7bC98QKCgmdmzjUI%2BsURx0clBvu4GVbHw0TuE%3D&reserved=0 Abstract: This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded with which Segemnt Routing Header dimensions based on which SRv6 control plane protocol. The IETF Secretariat _______________________________________________ spring mailing list spring@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0 _______________________________________________ spring mailing list spring@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0 _______________________________________________ spring mailing list spring@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7CThomas.Graf%40swisscom.com%7C009389a3c7af4e53da8208d9ea1e1e43%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637798237339522077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2mFSurxEShGDJGIxvqOiwO8pvpvFE7bIoW9M%2BY5lTcg%3D&reserved=0 From nobody Thu Feb 17 06:53:04 2022 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 78BC63A09AC; Thu, 17 Feb 2022 06:52:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, spring@ietf.org, james.n.guichard@futurewei.com, james.n.guichard@futurewei.com, cjbc@it.uc3m.es X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <164510957258.2791.18164721824342351003@ietfa.amsl.com> Date: Thu, 17 Feb 2022 06:52:53 -0800 Archived-At: Subject: [spring] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-spring-segment-routing-policy-17=3A_=28with_COMMENT=29?= 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, 17 Feb 2022 14:53:02 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I am afraid that, due to lack of available time, I only quickly reviewed this document and I will rely on the INT directorate review. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Jim Guichard for the shepherd's write-up including the section about the WG consensus and discussion. Thanks also to Carlos Bernardos for the INT directorate review dated 13th of March. I have also seen that authors are in an email discussion with Carlos and I appreciate that Carlos was acknowledged in the acknowledgment section. See . I hope that this helps to improve the document, Regards, -éric Generic comment: this document uses the term "headend", which is not used in other SRv6-related documents. Not really important though. ## Abstract Mostly cosmetic, but the abstract would benefit from being more concise and straight to the point. ## Section 2.1 Please use "::" rather than "::0" to respect RFC 5952. Also for section 8.8.1 I also share the concern of other AD for an ASCII-only symbolic name. ## Section 2.3 Why are the values 10, 20, and 30 only RECOMMENDED in a standard track document and are not a MUST ? If this is about distance, then let's be clear and name this value as "distance" or "origin-precedence". ## Section 2.13 Rather than using 1.1.1.1 or 2.2.2.2 please use the documentation addresses for IPv4 / IPv6. Same reasoning for using the example ASN. # NITS Probably a topic beaten to death but isn't "ISIS" spelled "IS-IS" ? Usually, "i.e." is always followed by a "," From nobody Thu Feb 17 06:54:12 2022 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 A303C3A092F; Thu, 17 Feb 2022 06:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 39lpNVdT3MOw; Thu, 17 Feb 2022 06:53:59 -0800 (PST) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 190793A093A; Thu, 17 Feb 2022 06:53:33 -0800 (PST) Received: by mail-vk1-xa2b.google.com with SMTP id v192so3186271vkv.4; Thu, 17 Feb 2022 06:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1JscceX6jLgCJbEwEKBrBZAT9W08NHaw0stJWs1S1HU=; b=OFdT40W7sG98rTuCKtFHseHYlN9lL1emAUs98SZrmsHADK8DdhnSXfKAs1BnWNY+Un eoc5j+NtdiG5z6Aln24i77dNfUSInPoC6xVa5hdzGloaRbIthnQpsXD7y1cNZdmt4apf s+uzbfpqx9jkm8vPRDrki2DI+jfwwPXKI9ZxEXmQ+gx5KWBK55bvyZ0FEj/wCy9yEJDG T86YeGk0rqTz3pTEN5nrlHwfeyIBiDTNMH1lmuB+/g6jOdoGseUnN+bYK0P0r5o/twha eyjLnwY67Kphe8bUlQCEfyAevCoH3d7z6wwMLk1pr1ldV0HKZdmnMMQVwU96ia6mBcXu +dAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1JscceX6jLgCJbEwEKBrBZAT9W08NHaw0stJWs1S1HU=; b=BaQZgYIqFErkIZ+6IXaXA7Am6C6xqJIsxB8FATuY8Q0jdaKVA8+lcPxZ0NTH+ep1ql wo096cg35ouUFLJEiCPgrcf7WqnxRvAifTEAvHscbscxHtHLJSLyr0AudIRA/HPFPvI3 KZiXBJ/lPyLtiizsgFPG8VsB4037JTgsDJYR1eJjiKTaVmUIXicyntOw4P7diM1+szut JwtqBtR/WW1OTm/cVTc7Zd1hAYQiHXZypjISLA01Jq4jvdoHbSxakVRqGVrKcvAK5X9o lWUMd7vvAattBAjuYm6EGkcGAhD6UXcVDXutZQj20VvWBdqCDWx3G4kLk3YQb6EQB3l3 +AbQ== X-Gm-Message-State: AOAM532QXOUVbpA0p6mXHUlmG+zw6XVs7yJ9N2KufT1brNgEarPSiLnn hCPi2fIIUqlQ9BNXcQC2xwFv24xTqw7hh9Ic67HdmsYq X-Google-Smtp-Source: ABdhPJwt9MLnDpO+srspip5qeg/wBzqQy/XA1DjUM4f+wesX6q0KcKomjLTgXDfJNF7T3Z28EGu5JyrQC/9ZCytValU= X-Received: by 2002:ac5:c2c8:0:b0:320:3b50:58db with SMTP id i8-20020ac5c2c8000000b003203b5058dbmr1274771vkk.7.1645109611735; Thu, 17 Feb 2022 06:53:31 -0800 (PST) MIME-Version: 1.0 References: <164503960643.17290.6124629269242232565@ietfa.amsl.com> In-Reply-To: <164503960643.17290.6124629269242232565@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 20:23:19 +0530 Message-ID: To: Zaheduzzaman Sarker Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="00000000000006301f05d837ee4e" Archived-At: Subject: Re: [spring] Zaheduzzaman Sarker's No Objection on draft-ietf-spring-segment-routing-policy-17: (with COMMENT) 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, 17 Feb 2022 14:54:01 -0000 --00000000000006301f05d837ee4e Content-Type: text/plain; charset="UTF-8" Hi Zaheduzzaman, Thanks for your review and please check inline below for response. On Thu, Feb 17, 2022 at 12:56 AM Zaheduzzaman Sarker via Datatracker < noreply@ietf.org> wrote: > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the efforts on this specification. > > This might be due to my lack of expertise on SR policy but it is not clear > to > me how to resolve policy conflicts where preferences and priority are same > for > policies. It would be nice if you point me information I am missing as I > could > not resolve it by reading this specification. This might be that the > scenario I > am having in mind never occurs. > KT> I am not sure if I understand what you mean by policy conflicts. An SR Policy is used to realize a segment routed path through a network. As such, I am unable to understand the nature of a conflict that could arise between paths in the network. When you refer to preferences, perhaps you are referring to the active candidate path selection criteria that are specified in section 2.9? Some illustrations of this selection process are described in https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-08#section-4 which might help. KT> It is quite possible that I've misunderstood your comment completely; in which case, please do clarify. Thanks, Ketan --00000000000006301f05d837ee4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Zaheduzzaman,

Thank= s for your review and please check inline below for response.

On Thu, Feb 17, 2022 at 12:56 AM Zaheduzzaman Sarker via Datatracker= <noreply@ietf.org= > wrote:
= Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the efforts on this specification.

This might be due to my lack of expertise on SR policy but it is not clear = to
me how to resolve policy conflicts where preferences and priority are same = for
policies. It would be nice if you point me information I am missing as I co= uld
not resolve it by reading this specification. This might be that the scenar= io I
am having in mind never occurs.

KT> = I am not sure if I understand what you mean by policy conflicts. An SR Poli= cy is used to realize a segment routed path through a network. As such, I a= m unable to understand the nature of a conflict that could arise between pa= ths in the network. When you refer to preferences, perhaps you are referrin= g to the active candidate path selection criteria that are specified in sec= tion 2.9? Some illustrations of this selection process are described in=C2= =A0https://datatracker= .ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-08#sectio= n-4 which might help.=C2=A0

KT> It is quite= possible that I've misunderstood your comment completely; in which cas= e, please do clarify.

Thanks,
Ketan

=C2=A0
--00000000000006301f05d837ee4e-- From nobody Thu Feb 17 06:55:10 2022 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 9C5813A0934; Thu, 17 Feb 2022 06:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=KpBqZt7F; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UZ8k3ZLe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HU9BzN95Zsd; Thu, 17 Feb 2022 06:54:58 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F29E3A092F; Thu, 17 Feb 2022 06:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2788; q=dns/txt; s=iport; t=1645109698; x=1646319298; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TU6MRtifJ6NFbeIyxOWOuFTcivb8uXnxnOWUY8VPq0A=; b=KpBqZt7FlNM8Xk5Euff28g1/zS9f8DAdWgIqYZV7L677DIGXKLucdTYz 7PfqG1FFyI1ieMx39RkXDi0cMjHnQqfwbCUoCJnYE1GCWGk3Xma33fAI6 RTDlabJNCi9siL0438758L0yHQ5awMz8SsZVVlrDKI0Slg29ryvFc1Vnc Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3AB8EBNByr5GkG/0TXCzPZngc9DxPP8534PQ8Qv?= =?us-ascii?q?5wgjb8GMqGu5I/rM0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJX?= =?us-ascii?q?gUO3MMRmQFoCcWZCEr9efjtaSFyHMlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv?= IronPort-Data: =?us-ascii?q?A9a23=3AVREELKvM6OVj9LGYRouECnut4efnVKJcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKWHVOa6MN2f0eox2YYm3/UhV7ZODnIBmSgZppC4zE?= =?us-ascii?q?CIXgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmM9n9BDpC79SMmjfvQH?= =?us-ascii?q?+KlYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?= =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j83Ad+j1738aEBPG/jZPBOFjTxdXK3Kbhpq/3NplP1kcqtHLx4K0V1ln?= =?us-ascii?q?PgpoDlJnZGuWAEiPaDkk+UGWB4eGCZ7VUFD0O6WcCnj6ZXJlSUqdFOpmZ2CF?= =?us-ascii?q?noeJpUC++B4KWBD6fJeLyoCBjiPneu43Pe6R/Viw987NsjtM8YEt35lwDfFS?= =?us-ascii?q?OwhXIzCRaqP/dhc3TwhwMlKGd7fatYXLz11Y3zoYhtTf1sWEro/kfumwH7lf?= =?us-ascii?q?FVwo1CfroI2/y7Ox1d0lrX2WOc50PTiqd59hE2UoCfN+H70R0hcP92Ewj3D+?= =?us-ascii?q?XWp7tIjVBjTAOo6fIBUPNY36LFL+lEuNQ=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AK9FhBaGcH3EF9tGBpLqFuJLXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5Vp2RvnhN5ICPoqTMmftW?= =?us-ascii?q?7dySiVxeBZnMrfKljbexEWmdQtrpuIH5IObeEYSGIK8foSgzPIUerIouP3ip?= =?us-ascii?q?xA7N22pxwGIG0aCNAD0+46MHfnLqQcfnghOXNNLuvl2iMxnUvYRZ14VLXeOl?= =?us-ascii?q?A1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPIf2FmAtza8yr?= =?us-ascii?q?Sosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcBcsvy5zXcISdOUmQ?= =?us-ascii?q?8Xeer30k8d1gNImijsl1SO0F3QMs/boWwTAjHZuAKlaDDY0L3ErXoBerp8bM?= =?us-ascii?q?RiA0fkA45KhqAj7EqNtFjp6Ka/RCmw7hgUrbLzJmJXv1vxrnw4neEJiXtDFY?= =?us-ascii?q?MYdb9KtIQauFhYCZEaAUvBmcwa+cRVfYvhDcxtAB6nhrHizx9S6c3pWm52Eg?= =?us-ascii?q?aNQ0AEtMDQ2z9KnGphx09dwMAEhH8P+J80VpEBvo3/Q+pVvaALStVTYbN2Be?= =?us-ascii?q?8HT8fyAmvRQQjUOGbXJVj8DqkIN3/Etpay6rQo4+OhfoAO0fIJ6dv8eUIdsX?= =?us-ascii?q?R3d1PlCMWI0pEO+hfRQH+lVTCo0c1a74gRgMy2eFMqC1zKdLkDqbrVnxwvOL?= =?us-ascii?q?yTZx/oAuMiPxbKFxqYJbp0?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyBgByHvlh/5hdJa1aHgEBCxIMQIF?= =?us-ascii?q?PC4FSVgd3WjcxhEmDRwOFOYUOgwKbJ4EuFIERA1QLAQEBDQEBKgsMBAEBhQU?= =?us-ascii?q?CF4NIAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIEJE4VoDYZDAgEDAQEQEREMAQE?= =?us-ascii?q?sCwEPAgEGAg4MAiYCAgIlCxUQAgQBDQUigmIBgmUDLgEOknWPNgGBOgKKH3q?= =?us-ascii?q?BMYEBgggBAQYEBIUNGII3AwaBECqDDoJ+VEyHByccgUlEgRQoHIJnPoJjAQE?= =?us-ascii?q?DgUMxgwE3gi6TCwRTFA45IARlJAuSUYNiqiEKg0aLAY5nhXUFLqgHlkogjG+?= =?us-ascii?q?UJwSFCAIEAgQFAg4BAQaBYTyBWXAVOyoBggoBM1EZD44gN4M6hRSFSnQ4AgY?= =?us-ascii?q?BCgEBAwmNTAEB?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208";a="999940122" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Feb 2022 14:54:55 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 21HEstNq001406 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 17 Feb 2022 14:54:55 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 17 Feb 2022 08:54:55 -0600 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 17 Feb 2022 09:54:54 -0500 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 17 Feb 2022 08:54:54 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A+YPBOIgLQjUEXk+YVEa4DdUNjhBW1D6s9eALR6h8CgXaszBCmUU21eXQkObw8CuyUa24NVwRYCa2klODxfSCg9Mc5g4jG0nJdYFzVkbmlY4Z1PKe0w4GnFPEaDJ0dYkBGq5zeH3pbrQ3UnAqtt5Y9HQkcy/hxVlRWTb2oCKSqZ1Oeu3tLeH5ztAN8Qzb8iMzrIyye2dgPemY3jv+uBq3Aa+VX20flt777KcchA1Tlt6xIDAaU+wAQjj9f1quq8V1hKJ0jJLUDKahVI6p8UBfnlOmmdzNFQve16ZTEKBlGOLwE6HPVpDvz1kIE/QbUwB2JxaVa+tNXIxwTJupuCXFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TU6MRtifJ6NFbeIyxOWOuFTcivb8uXnxnOWUY8VPq0A=; b=MnDVz8sFWwbvgBG0lqpfrt7XYcednzMy02NIvv0MS4Jsfm7yz36VbYnJMxSFij+j3tb4KLtPa8xJpwsxqq/ZpVBr+9WQLkwTCgPg7Jh8Znp591f+K9REVK4KJQbJTD4llbyovZMQM347SpsSSptyEgWNHtUCZE9DTdlfM+OrOs0A0xwUz5N7TYF8ohxfUc+I9rbQu7Uh1K1RAGluNWAjImaXl8Qq3a5rveohpuQx53wED8lazgYOpkrCsc8q6suluec8U9h804vvhuzAYfMk9qkqY0Nmkq9VcqCGDuteGiy5dMLL/3bQLrMBXkpCShLkU31GXsbtHl5b7MUjrQMl3g== 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=TU6MRtifJ6NFbeIyxOWOuFTcivb8uXnxnOWUY8VPq0A=; b=UZ8k3ZLeKGzw742qio/UbgPA+MJyGmtiLa8iQ7AgW9R5jL1EWzs/+0vIb/vTz60TnUlJdtkCcXdQILvvM84xOSX3Q6G9QcfXAkS5YoNWUzCER+fnJNr3zymxWT2PW1LVkJCyqwNxVAsQF3UeAnz7vEeEgIwnR4KEluZIYVQFoos= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by BN6PR11MB4033.namprd11.prod.outlook.com (2603:10b6:405:78::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.17; Thu, 17 Feb 2022 14:54:53 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::1929:3b1b:99a3:312]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::1929:3b1b:99a3:312%7]) with mapi id 15.20.4995.016; Thu, 17 Feb 2022 14:54:53 +0000 From: "Eric Vyncke (evyncke)" To: Carlos Bernardos , "int-dir@ietf.org" CC: "draft-ietf-spring-segment-routing-policy.all@ietf.org" , "spring@ietf.org" Thread-Topic: [Int-dir] Intdir telechat review of draft-ietf-spring-segment-routing-policy-16 Thread-Index: AQHYISAOGC4cNdxYA0qWXVJNZiOyR6yX6yYA Date: Thu, 17 Feb 2022 14:54:53 +0000 Message-ID: <2C662ED4-0E3D-4BCF-8D9E-E5CA7CD4A699@cisco.com> References: <164478742540.12952.13879543917832873504@ietfa.amsl.com> In-Reply-To: <164478742540.12952.13879543917832873504@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.57.22011101 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32276e2b-c24b-41a1-bb09-08d9f2257490 x-ms-traffictypediagnostic: BN6PR11MB4033:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hy9gc9RtE5cY4lYwS9zQsillF0qbp9dOhEnENAcWPsGYxtFcVwpu5tx2wlhxPerVWSU5+vTsjuAIO4zVP6RIKsMuf/OAkistmnftHwiWvN6oTNj668QlgeVoawHPykHWfbbyk7b9g04nvgCPcmp1NlOgcblZRd6qgsLaTLLH8wPXrHKiepF6eOd1PDsnTr15+h7Ij2J77U3MwsTGUeKDltbtP7KcVQ9H1ZK6WSpFUJ5rVpkNcj4LlVdSCnV3wplAU/t5gYR3riEQzSHhLApQ3GfnVwsmmz67hYrbAmdHO+QIgadXat4FaSkCz4yPQTUoHnST0GpS0K+th8D4zAs6itbSvllre3DIYQg9QNbJn+Y1Ahqr2YPBouKoU8VNfpsfjAJa69EG6eOACDjT+ILYGKJH40sw+1aVSX0o6vmRLwTPRPI5Ue9te594ia7qIwutPxReNU7HQhq4bdxyHAnGsGdiKQ7UJpSgTsZi7Qq/95nOcoMnoFYVK5czzFQbxmHWkl6MkRB7UH5gs20vEXZtiw4tTZS3B7CS+InUHI4qXA8CBElPauTMtDq/Bnf6+RdFGbarH19UHnYCA0B1csvaLzRyrWe9tYn7fPTk3AbALBUwkvqLsSBxccCB9s8+BdjioBN1ubakQV8tmhTwc8eHH6wPtAfDaBL1wDW7qmujhNRMS2BV3ep14dj8k0uIL5qujV0Pz6tfxXgbFxW6dY7YVMtMrOKV2jFme2mOmwssYLfOqnxcf7v8Ba6R1ZvoHs6t8Xvk1TlYPTFnxPxft7ZIgIoZrUSDLnOUBIAbEnY51EvQYqenUBFqqvdX7DrIbGgLYBbVs07HYSeG02DPMDwTtZDtyHvbDdRtk9yXHg0a+Ds= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(38100700002)(122000001)(38070700005)(86362001)(8936002)(2906002)(5660300002)(2616005)(6512007)(91956017)(186003)(36756003)(71200400001)(54906003)(110136005)(316002)(6506007)(66574015)(966005)(6486002)(508600001)(33656002)(8676002)(4326008)(64756008)(66446008)(76116006)(66556008)(66476007)(66946007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SFZWNVcwa096NExiLy9KSGdTOHpQbGdTazI5RGRVcUpPdGZYZGlvbVFZQVJz?= =?utf-8?B?ekRjT013ZENyc24vY0JkNDJBSkVRd08vV1Y2TGM0M2lZZi85OXZjUDJYTGNu?= =?utf-8?B?RlBTWEE0dFdYUW0yd0FqMEJSL3gzSmk5SCtibUFVODVDTkxPalRIRUFPbUl2?= =?utf-8?B?UFJFUEh3VWl3WjAzNWdlbCs1RXVBaitoQnpUQVNhTkJYelpPQlIxa21sZFQy?= =?utf-8?B?c0xJMHY0YWZJUytaTGFCUlRlaytlMm9GWHFwd3dkQzVNRG53SGRGM3BPbjJ3?= =?utf-8?B?ajFJZjV4bWZvZmtkYjhXVHkyZDhWUm9lcUk4U0tDdUExaHB2ZEw2bkgxY2dE?= =?utf-8?B?QVJCNTd4TnBJOUIxcmVvcmFOcHNDemRRK09TVSt2QnJGOHNteXMxL2d6ai9l?= =?utf-8?B?Z1lQaloyb0U1dEFlem5QSGJ6WlJ0aHNhTEU5ZlpHNVM3SU5tSVFIMjJMd3Bq?= =?utf-8?B?UHZveTJ1UllYamRENlZrYUE0enF5bDhrRElhZDhhZkRPTGpETlJ0OFJGSExi?= =?utf-8?B?c0EwM2dIWHo3NGdVb05XNHFhcE5TVnIvcnplZGlsQjVJTDI0b21PdjBRSExI?= =?utf-8?B?RTlTVnpnaUZsSjlKSTZNRkR5cUpIek5XSGVFcHg3KyttSEUzY3hwcURLWkJh?= =?utf-8?B?eVdZVURVME9oQWNUdmhtd2hrT3lOd3dMelNWekdSdlJkRVpDZXBicFYxTWpR?= =?utf-8?B?ZnZzTHRBQVAvRjJFbzRsUldJSUN6ZTJLUHg5Q003RHArR0RVcEVqM1BiSlAv?= =?utf-8?B?QkVsYkxKa1JRdUJySWQ0ak5XQTBYRGpEOXNTY0JHaGtoU3NzdlRTb21qemQ3?= =?utf-8?B?QWRHQ2R4MjdUbTNVMWttQU9vNitzSUpwZml6VEZNdlF2QTJWY2RqMForZnBV?= =?utf-8?B?UkFRMjBhdXk5ZXFkc1NEQWFoeFp4WnEvWWtqWmc0bzVJNlJQdnBZemd6UWpI?= =?utf-8?B?c1NicTVCRzhXUHFCU0FBVUNsRmlsS3RVL1lCcXhYZytwaU0yb3U4SldyWk1N?= =?utf-8?B?d2txc2Q4YU5rU21OV0hKNFMxTFoxYWllT1JnNFJEMUlKZElEa0krT2ZEeWFP?= =?utf-8?B?SVFFVlZ0bW1lSW5MeE0wRUdaYlQ5QWRDVFUvM2lMUExVOGcrdUdaYTZ0aGs5?= =?utf-8?B?VFVZa3NldzFRck5KdER4SnhtQnZCOFhHdXZVS1V1SlRpUzQ5ZUk1M2xQQ3pY?= =?utf-8?B?c1l0NTBjekcyZTN3d1FxcW5TcE8yWmE1NFVXYzZtSHpYQkhqbGpkdys1NjFU?= =?utf-8?B?NGhNMWJjQTJidHNsRDZBSkhTZUc0REdrZ3Ryc1V6SEo2ZHlXeGZralVQZSs3?= =?utf-8?B?RmFOZzNJUXRTeVhkaUtVNjNuRzNjOGhZb0lnem5rVEJkN0RFczQzYUdTWita?= =?utf-8?B?N2ZsVk1oNkpyUVEzRzJTbzhLYlVGdXR4UGQvRUl3NTlQQThIYmZDc2loNS9M?= =?utf-8?B?bVlRYXlnaUlLM2RJYWJWM2l4R0JnMzZxdmViNXZ5WmI1bW15Y094enlLdnJk?= =?utf-8?B?czcvQ2RJWmEvYVRkdXNyK3JRclIxN3BKZk9PYktIWjlaRmF4OEIrWXN1ZmZ0?= =?utf-8?B?TGZNS3FtcjZ1WERLa00rbU5GWnBIbmdFUUtwaDNucWxnZlNpc1liM0dzdFNi?= =?utf-8?B?UmorMVltVFM4RzRxSS83cmh1M1JySG8yRTNTK05mcExrTm9iUXZjYzl2ZlE1?= =?utf-8?B?c3U0NVBWdHBmVXdSa2xTbk9xZHorMmtJUlR1WG9rdDZ0WmE4ZXROTCsrWWNp?= =?utf-8?B?VzJHZjlVUE5QVUY5NHhidEZKOXprVE9aMUk3M2thODVVUHM0V1QzYk1USlFz?= =?utf-8?B?U1NTRkpTejVhaUxSR3JQdGxEYkRITEowSE00VEs4MjQweVpsTHREYXlBelZO?= =?utf-8?B?YmFmVy9Ub0RSRVBIdlFUSGNMVWlJTkVHQTRqSVY2NUxDcmRnYVRKQkcxMnBI?= =?utf-8?B?a0p1VVRhckFDTUllWUNvZ3FTV05sa2ZLazBFbDNucUhzQmlsT1h3bnhiQkUv?= =?utf-8?B?alFKNUpQSVdtUHFxWWNZL0NIeGhXc1FnUWJ6Z1FaZTlGejJVa1Zteko0ME0v?= =?utf-8?B?ZzhIZWVCTmlBOTVNNG5VSG5TS3IrUCt0VWJFYlVwajhpV1Axbm5WaHV0Vkhq?= =?utf-8?B?WFQzVUtXaUU0eldEUjRSZFg0b3UraTVqc05IdmExbEZTMEdPM3ljWDBuV1hF?= =?utf-8?B?b01QQVBMb3JsZ2E5TnVLV1c0ZXFrbzl1eUd3SWpsSUJ1a2ttNXk0aFpwS2c5?= =?utf-8?Q?D7Gmu534t3dm2IXOpF5r50akfS1mbKljOk0u/OaRmc=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <83203B542E6CC94BB7CFE553D306C4D3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32276e2b-c24b-41a1-bb09-08d9f2257490 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2022 14:54:53.1427 (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: 0Ztr1IZRWnIxtm8HM2xI4YKKRQmc7jbo3AcDuU+ch+XdHoW8oYuTZaWOJk1IKysu07QM1H/9TxDBB9lvRR/X0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4033 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] [Int-dir] Intdir telechat review of draft-ietf-spring-segment-routing-policy-16 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, 17 Feb 2022 14:55:04 -0000 SGVsbG8gQ2FybG9zLA0KDQpUaGFuayB5b3UgYWdhaW4gZm9yIHlvdXIgSU5UIGRpcmVjdG9yYXRl IHJldmlldywgaXQgaXMgYWx3YXlzIGltcG9ydGFudCB0byBoYXZlIG11bHRpcGxlIHBhaXJzIG9m IGV5ZXMgd2hlbiByZXZpZXdpbmcgYSBkb2N1bWVudC4NCg0KQXMgeW91IG1heSBoYXZlIHNlZW4g aW4gdGhlIHNwcmluZyBtYWlsaW5nIGxpc3QsIEkgaGF2ZSByZWxpZWQgaGVhdmlseSBvbiB5b3Vy IHJldmlldy4NCg0KwqFNdWNob3MgZ3JhY2lhcyAhDQoNCi3DqXJpYw0KDQrvu79PbiAxMy8wMi8y MDIyLCAyMjoyNCwgIkludC1kaXIgb24gYmVoYWxmIG9mIENhcmxvcyBCZXJuYXJkb3MgdmlhIERh dGF0cmFja2VyIiA8aW50LWRpci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBub3JlcGx5 QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBDYXJsb3MgQmVybmFyZG9zDQogICAg UmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQoNCiAgICBJIGFtIGFuIGFzc2lnbmVkIElO VCBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCiAgICBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctcG9saWN5LiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5DQog ICAgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBJbnRlcm5ldCBBcmVhIERpcmVjdG9ycy4gRG9jdW1l bnQgZWRpdG9ycyBhbmQNCiAgICBzaGVwaGVyZChzKSBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIHRoZXkgd291bGQgdHJlYXQgY29tbWVudHMNCiAgICBmcm9tIGFueSBvdGhl ciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQgcmVzb2x2ZSB0aGVtIGFsb25nIHdpdGggYW55IG90aGVy IExhc3QNCiAgICBDYWxsIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIHJlY2VpdmVkLiBGb3IgbW9y ZSBkZXRhaWxzIG9uIHRoZSBJTlQgRGlyZWN0b3JhdGUsDQogICAgc2VlIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZ3JvdXAvaW50ZGlyL2Fib3V0Lw0KICAgIDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2dyb3VwL2ludGRpci9hYm91dC8+Lg0KDQogICAgVGhlIGRvY3VtZW50IGlz IHZlcnkgd2VsbCB3cml0dGVuIGFuZCBJIGp1c3QgaGF2ZSBhIGNvdXBsZSBvZiBzbWFsbCBjb21t ZW50cy4NCg0KICAgIEJhc2VkIG9uIG15IHJldmlldywgaWYgSSB3YXMgb24gdGhlIElFU0cgSSB3 b3VsZCBiYWxsb3QgdGhpcyBkb2N1bWVudCBhcyBOTw0KICAgIE9CSkVDVElPTi4NCg0KICAgIFRo ZSBmb2xsb3dpbmcgYXJlIG90aGVyIGlzc3VlcyBJIGZvdW5kIHdpdGggdGhpcyBkb2N1bWVudCB0 aGF0IFNIT1VMRCBiZQ0KICAgIGNvcnJlY3RlZCBiZWZvcmUgcHVibGljYXRpb246DQoNCiAgICBT ZWN0aW9uIDMgbWFrZXMgdXNlIG9mIGEgbG90IG9mIHBvdGVudGlhbGx5IG5vcm1hdGl2ZSDigJxt YXnigJ0gd2hpY2ggaXMgbm90IGNsZWFyDQogICAgaWYgdGhleSBhcmUgbWVhbnQgdG8gYmUgbm9y bWF0aXZlIG9yIG5vdC4NCg0KICAgIFRoZSBmb2xsb3dpbmcgYXJlIG1pbm9yIGlzc3VlcyAodHlw b3MsIG1pc3NwZWxsaW5nLCBtaW5vciB0ZXh0IGltcHJvdmVtZW50cykNCiAgICB3aXRoIHRoZSBk b2N1bWVudDoNCg0KICAgIEluIHNlY3Rpb24gMywgd2hlbiBkZXNjcmliaW5nIHRoZSBTUi1EQiwg dHdvIElHUCBwcm90b2NvbHMgYXJlIG1lbnRpb25lZCAoSVNJUw0KICAgIGFuZCBPU1BGKS4gQXJl IHRob3NlIHRoZSBvbmx5IG9uZXMgbWVhbnQgdG8gYmUgc3VwcG9ydGVkPw0KDQogICAg4oCcd2l0 aCB0aGUgRW5kIGJlaGF2aW9yIChhcyBkZWZpbmVkIGluIFtSRkM4OTg2XSksIG9mIHRoZSBub2Rl 4oCdIOKAlD4gSSB0aGluayB0aGUNCiAgICDigJws4oCdIHNob3VsZCBiZSByZW1vdmVkDQoNCg0K DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBJbnQtZGlyIG1haWxpbmcgbGlzdA0KICAgIEludC1kaXJAaWV0Zi5vcmcNCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1kaXINCg0K From nobody Thu Feb 17 07:06:47 2022 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 21D333A02F9; Thu, 17 Feb 2022 07:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 g-f4FNZLUqe3; Thu, 17 Feb 2022 07:06:41 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 BFB5E3A0124; Thu, 17 Feb 2022 07:06:40 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id d26so1757408vsh.0; Thu, 17 Feb 2022 07:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+N7UWm5W0mvEWUL1w0rxJxH2RdWupUZkq6N1dBTQH4c=; b=c/NQarOe86BPe90HTHPU40N5hqYeH8bgpgnNPvJx97lR5bYljky3da/pkAPTj87JGT 3XCgZ3uQfw/C1Cs1pPqWMafbNo5tZjDrS+3EsBKe25Ks5B0UoQR4Qb8+JeNuA7NoQGov vRiFP/NF5walqgAtlbPJe98yKBkpKZT/6zQNQKVJYJlaCRU4cYvBteIr08/7HYLeKKyQ JDHZk4Vc1TQOf0P3RDj3SoogM7U2239SY2ad85j+nvVJjNnWI3onUZrYoMEQox9HYVwJ mkmAzpNTDknHw2MPKoUIylO1uSpUg1tQL0AJxZ32LrLc77XdzBnHhKPSzpYdkLeDHY/s 5M4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+N7UWm5W0mvEWUL1w0rxJxH2RdWupUZkq6N1dBTQH4c=; b=u33PT/d1V/3uiwgBMPjXCo7Ru8ui2RWAb+HrOIzvjuUZe2CP4l2vG6GQR2iNb/1zmI gBWiXKAprWsfjUuWOBhHtxDAzoP2+ACH2E0p2NYkUcAPZhG3/FpwpczK6qO8dJAFqq+c lTmxBC2KVZV/Izf3xVn3gCOdj9XWOBmwouryG+lABjNeKg52I0lj9mEaZqirNPRHIzVN F/YLbM6O5wOzhjl0ObBIV5H6UxOsYNhZj423l9pnodVeGNmbcGf9BtkjEyCiy3d6PGcI 6HhGN7sUNKDM555BxdclgrSbTaDBcsAgkRhYP8pFDeH5n6tWve3ndUwrTgBQ3BRVi/Q8 Ow0w== X-Gm-Message-State: AOAM530w3q1KurBuB1Cere6g/vPXXUHKCf8o2COA8Qe9+q7stGp5lrA6 nARVV21W/Sz4WQkUykcuFK/WYBGLfLbX+YGTFYLV8YNK X-Google-Smtp-Source: ABdhPJxINUoQHasThxlUrbTy2wfCW8kh7q7HULsxSSgUx5EFBBmLs8ioLui0xAC0T+vbvA+DJit7Ycu/a6NQlL1ZGWc= X-Received: by 2002:a05:6102:3e95:b0:30f:9865:e97e with SMTP id m21-20020a0561023e9500b0030f9865e97emr1410315vsv.15.1645110399344; Thu, 17 Feb 2022 07:06:39 -0800 (PST) MIME-Version: 1.0 References: <164504875164.5704.16596621622345086808@ietfa.amsl.com> In-Reply-To: <164504875164.5704.16596621622345086808@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 20:36:26 +0530 Message-ID: To: Alvaro Retana Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000f825cb05d8381cf4" Archived-At: Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 15:06:45 -0000 --000000000000f825cb05d8381cf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thanks for your review and comments/inputs. Please check inline below for responses. On Thu, Feb 17, 2022 at 3:29 AM Alvaro Retana via Datatracker < noreply@ietf.org> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) This specification should formally Update rfc8402. > > What is the relationship between this document and rfc8402? If this > document > details the concept introduced in rfc8402, why isn't there a formal Updat= e > relationship? > > Even the initial definition of SR Policy in this document (=C2=A72) doesn= 't > match > what rfc8402 says. This document defines it as "a framework that enables > the > instantiation of an ordered list of segments", while rfc8402 states it is > "an > ordered list of segments." In =C2=A72.2, this document uses the term > "segment-list" for that. > KT> There were similar comments from Rob for which we have recently posted updated text in v17. I believe, this document does not need to update RFC8402 because it is not changing anything in that document. RFC8402 simply introduces SR Policy while this document specifies its internal constructs, how it is realized/instantiated, and steering mechanisms over it. At least, that is the objective/view of the authors/WG and we are open to inputs to update and further clarify the same. > > Besides the general topic of clarifying and updating what an SR Policy is= , > this > document also includes other items that were not present in rfc8402; the > list > includes: > > =C2=A72.1: "SR Policy MUST be identified through the tuple endpoint>." There's not even a mention of "color" in rfc8402. > > =C2=A72.1: "The headend is specified as an IPv4 or IPv6 address and is > expected > to be unique in the domain." Neither the mechanism to identify a node > nor > the expectation is present in rfc8402. > > =C2=A72.1: "The endpoint is specified as an IPv4 or IPv6 address and i= s > expected > to be unique in the domain." Same as above. > KT> Yes, these are the constructs of SR Policy that are specified by this document. > > > The SR Database is a new element not in the base architecture. The text > in =C2=A73 > says that "use of the SR-DB for computation and validation of SR Policies > is > outside the scope of this document", but it is then mentioned and used in > =C2=A75.1/=C2=A75.2. > KT> The computation algorithm and related discussions about the use of SR-DB were asked to be moved out of this standards track document during the WG process. Those informational sections were moved into draft-filsfils-spring-sr-policy-considerations and kept as a reference in this document. The reference in 5.1 and 5.2 is about validation of segments and as a result the segment-list and candidate path. The validation of the "objective" and constraints of the SR Policy was deemed to be outside the scope of the document. There were several discussions on and off-list at the IETF meetings in this regard. Perhaps this thread gives a good summary: https://mailarchive.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/ > > > Accordingly, the added details require additional Security and > Manageability > considerations. > KT> Could you please clarify/explain a bit further what you feel is missing= ? > > > I couldn't find a related discussion in the archive. If I missed it, > please > point me in the right direction. > > > > (2) =C2=A75.1: > > Types A or B MUST be used for the SIDs for which the reachability > cannot be verified. Note that the first SID MUST always be reachable > regardless of its type. > > These two requirements and the text in the description of these types > ("...does > not require the headend to perform SID resolution.") results in a > contradiction: Types A and B are not to be resolved, but if they are the > first > SID then they MUST. If it's not a contradiction, then Types A and B woul= d > not > be allowed to be the first SID, which is not correct because the most > straightforward mechanism to define a path is to list SR-MPLS Labels or > SRv6 > SIDs. > KT> I don't see a contradiction here. "Types A or B MUST be used for the SIDs for which the reachability cannot be verified." is not the same as saying "Type A or B are not to be resolved". > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (0) I support John's DISCUSS. > > > (1) Is the specification of a headend/endpoint mandatory? IOW, should th= e > text > in =C2=A72.1 about the headend/endpoint being identified by a unique IPv4= or > IPv6 > address be normative? > KT> It is not normative since we have the case of an unspecified address as an endpoint. We could use SHOULD though, if that clarifies. > > > (2) =C2=A72.1: "An implementation MAY allow the assignment of a symbolic = name > comprising of printable ASCII [RFC0020] [RFC5234] characters" > > Why are you normatively limiting the name to be represented in ASCII? > Please > internationalize it - use UTF-8. > > =C2=A72.6 also has similar text. > KT> My understanding is that there is no compulsion to use UTF-8 for such purposes. This was discussed in the WG. Please check: https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/ > > > (3) =C2=A72.1: "Such symbolic names MAY identify an SR Policy when the na= ming > scheme > ensures uniqueness." In this case, the "MAY" is just stating a fact. > s/MAY/may > KT> Ack. Will fix. > > > (4) =C2=A72.1: "An SR Policy MAY have multiple names...in the scenario wh= ere the > headend receives different SR Policy names" Describing multiple names a= s > the > case where multiple names are received is not helpful. > KT> When CPs for the same SR Policy are provisioned via different sources, then such a scenario may occur. > > > (5) =C2=A72.2: "the endpoints of the constituent SR Policies and the pare= nt SR > Policy > MUST be identical" To avoid confusion, by "endpoints" you mean "headend > and > endpoint", right? > KT> We mean the endpoint as in "the tail-end". We are speaking from within the context of a headend here so the headend is the same. > > > (6) =C2=A72.3: > > A headend MAY be informed about a candidate path for an SR Policy > by various means including... > > It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may > KT> Ack. Will fix. > > > (7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD be set = to 0 by > default when not available or known." > > When is it ok for the ASN to not be set to 0 (when not available or known= )? > If that possibility exists, the PCE can use any value (including the real > number or a random one). What issues exist with uncoordinated (or rogue) > PCEs > using potentially arbitrary ASNs? > > Why is this action recommended and not required? > KT> AFAIR PCEP signaling does not carry AS number. So this is a recommendation, though a local policy or a future PCEP extension could change that and we don't want to preclude it. > > > (8) This paragraph in =C2=A72.5 seems to be missing something" > > The Discriminator is a 32-bit value associated with a candidate path > that uniquely identifies it within the context of an SR Policy from a > specific Protocol-Origin as specified below: > > "below" where? I guess you may mean "below in =C2=A72.6 (Identification= of a > Candidate Path)", but that section says that the "tuple > uniquely identifies a > candidate > path" and not just the discriminator as above. > KT> The next three paragraphs that begin with "When .." should be a bullet list. Looks like it got missed out. > > Also, the ":" leads to some text about the default and specific protocols= . > Given that this document intends to provide an architecture, I would expe= ct > general consideration about the discriminator, and not pointers to how it > can > be signaled or, much less, the process in BGP. In general, I would expec= t > the > architecture to not rely on solution documents to explain how pieces of t= he > architecture are derived. > KT> These are informational pointers to the respective protocol specs to help the reader. > > > (9) Given the description, it seems possible for a PCE (for example) to > advertise multiple candidate paths with the same Preference, Originator, > and > Discriminator. If that occurs, what is the result of the selection in > =C2=A72.9? > Would this situation result in multiple active candidate paths? > KT> The ability to signal multiple CPs via PCEP is being introduced via draft-ietf-pce-segment-routing-policy-cp. The default is for use when not using that draft and in that case, there would be only a single CP. > > > (10) =C2=A72.11: "Only the active candidate path SHOULD be used for forwa= rding > traffic that is being steered onto that policy." When is it ok to use > non-active paths? Why is this action recommended and not required? > KT> The condition was for path protection as described in section 9.3. The "backup" path is programmed and hence may be used for forwarding while FRR is active. > > > (11) =C2=A72.12: Several of the "MAY" statements in this section express = a > fact, not > a normative statement: s/MAY/may > > The operator MAY set this field... > An SR Policy MAY comprise multiple... > KT> Ack. Will fix those. > > > (12) =C2=A74: > > When the algorithm is not specified for the SID types above which > optionally allow for it, the headend SHOULD use the Strict Shortest > Path algorithm if available; otherwise, it SHOULD use the default > Shortest Path algorithm. > > In this sentence, you're recommending both algorithms. When should one o= r > the > other be used? There are no qualifiers that lead to the "otherwise" > statement. > KT> Ack. The semicolon needs to be replaced by "and" before "otherwise". > > > (13) =C2=A74: What is the purpose of enumerating the types of > segment-descriptors? > Should the type be indicated when the Segment-List is signaled? I assume > the > answer is yes, but I didn't see that specified anywhere. > KT> It is used in the protocol specs for reference - e.g draft-ietf-idr-segment-routing-te-policy > > > (14) =C2=A75.1: "The headend detects a mismatch between the SID value and= its > context provided for SIDs of type C-through-K" What does having a mismat= ch > mean? Please be specific. > KT> The value of the SID provided does not match the value of the SID determined through the provided context. Will clarify. > > > (15) =C2=A75.2: > > When the local computation is not possible (e.g., a policy's tail-end > is outside the topology known to the headend) or not desired, the > headend MAY send path computation request to a PCE supporting PCEP > extension specified in [RFC8664]. > > This action (ask the PCE) is a solution, not an architectural > description. Are > there other external mechanisms that can find a "solution Segment-List"? > It > seems to me that one such mechanism would be in the form of a configured > Segment-List. If that is correct, please generalize the normative > statement > above -- where using PCEP can be an example. > KT> Agree and will change that to an example. > > > (16) =C2=A77: Which are valid states? Active is one, the text mentions a= n > "administrative state", what else? Interoperability is a good reason to > specify the states and not assume that implementations might do the right > thing. > KT> The state here does not mean a single one like up/down. It is referring to the operational state. Those aspects are covered in the draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP when those protocols are in use. We'll add a reference to draft-ietf-spring-sr-policy-yang. > > > (17) =C2=A77: "The SR Policy state MUST also reflect the reason when a po= licy > and/or > its candidate path is not active due to validation errors or not being > preferred." > > Given that this is a requirement, please provide a list of reasons. The > need > for interoperability (by using rfc2119 language) can only be achieved if > the > reasons are standardized. > KT> The reason is for debugging and troubleshooting. If something is down or invalid, then it helps to know why. > > > (18) In general, the text contains a mixture of normative language > (rfc2119) > and descriptions that make the contents inconsistent and confusing. For > example, my interpretation of "an SR Policy and its BSID are removed from > the > forwarding plane" (from =C2=A78.1) is that it is an absolute requirement. > However, > =C2=A78.2 presents the optional "Drop-Upon-Invalid behavior" which then > indicates > that there can be cases where my interpretation was not correct. > > The point here is that the text in a Standards Track document should not > be up > for interpretation. > > There are too many cases in the text to list that would have benefitted > from > using Normative Language -- I mentioned a couple above. Ideally, the > authors > would make one more pass for clarity. However, I will probably end up > ABSTAINing because of it. > > This point was also raised in the rtg-dir review, which is why I'm not > including it as part of a DISCUSS. > KT> Authors will take a pass and get back on this. Thanks, Ketan --000000000000f825cb05d8381cf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

Thanks for = your review and comments/inputs. Please check inline below for responses.


On Thu, Feb 17, 2022 at 3:29 AM Alvaro Retana via Datatr= acker <noreply@iet= f.org> wrote:
Alvaro Retana has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) This specification should formally Update rfc8402.

What is the relationship between this document and rfc8402?=C2=A0 If this d= ocument
details the concept introduced in rfc8402, why isn't there a formal Upd= ate
relationship?

Even the initial definition of SR Policy in this document (=C2=A72) doesn&#= 39;t match
what rfc8402 says.=C2=A0 This document defines it as "a framework that= enables the
instantiation of an ordered list of segments", while rfc8402 states it= is "an
ordered list of segments."=C2=A0 In =C2=A72.2, this document uses the = term
"segment-list" for that.

KT&g= t; There were similar comments from Rob for which we have recently posted u= pdated text in v17. I believe, this document does not need to update RFC840= 2 because it is not changing anything in that document. RFC8402 simply intr= oduces SR Policy while this document specifies its internal constructs, how= it is realized/instantiated, and steering mechanisms over it. At least, th= at is the objective/view of the authors/WG and we are open to inputs to upd= ate and further clarify the same.
=C2=A0

Besides the general topic of clarifying and updating what an SR Policy is, = this
document also includes other items that were not present in rfc8402; the li= st
includes:

=C2=A0 =C2=A0=C2=A72.1: "SR Policy MUST be identified through the tupl= e <headend, color,
=C2=A0 =C2=A0endpoint>."=C2=A0 =C2=A0There's not even a mention= of "color" in rfc8402.

=C2=A0 =C2=A0=C2=A72.1: "The headend is specified as an IPv4 or IPv6 a= ddress and is expected
=C2=A0 =C2=A0to be unique in the domain."=C2=A0 Neither the mechanism = to identify a node nor
=C2=A0 =C2=A0the expectation is present in rfc8402.

=C2=A0 =C2=A0=C2=A72.1: "The endpoint is specified as an IPv4 or IPv6 = address and is expected
=C2=A0 =C2=A0to be unique in the domain."=C2=A0 =C2=A0Same as above.

KT> Yes, these are the constructs of = SR Policy that are specified by this document.
=C2=A0


The SR Database is a new element not in the base architecture.=C2=A0 The te= xt in =C2=A73
says that "use of the SR-DB for computation and validation of SR Polic= ies is
outside the scope of this document", but it is then mentioned and used= in
=C2=A75.1/=C2=A75.2.

KT> The computa= tion algorithm and related discussions about the use of SR-DB were asked to= be moved out of this standards track document during the WG process. Those= informational sections were moved into draft-filsfils-spring-sr-policy-considerations=C2=A0and kept as a= reference in this document. The reference in 5.1 and 5.2 is about validati= on of segments and as a result the segment-list and candidate path. The val= idation of the "objective" and constraints of the SR Policy was d= eemed to be outside the scope of the document. There were several discussio= ns on and off-list at the IETF meetings in this regard. Perhaps this thread= gives a good summary:=C2=A0https://mailarchiv= e.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/=C2=A0
=C2=A0


Accordingly, the added details require additional Security and Manageabilit= y
considerations.

KT> Could you please= clarify/explain a bit further what you feel is missing?
=C2=A0


I couldn't find a related discussion in the archive.=C2=A0 If I missed = it, please
point me in the right direction.



(2) =C2=A75.1:

=C2=A0 =C2=A0Types A or B MUST be used for the SIDs for which the reachabil= ity
=C2=A0 =C2=A0cannot be verified.=C2=A0 Note that the first SID MUST always = be reachable
=C2=A0 =C2=A0regardless of its type.

These two requirements and the text in the description of these types (&quo= t;...does
not require the headend to perform SID resolution.") results in a
contradiction: Types A and B are not to be resolved, but if they are the fi= rst
SID then they MUST.=C2=A0 If it's not a contradiction, then Types A and= B would not
be allowed to be the first SID, which is not correct because the most
straightforward mechanism to define a path is to list SR-MPLS Labels or SRv= 6
SIDs.

KT> I don't see a contradi= ction here. "Types A or B MUST be used for the SIDs for which the reac= hability cannot be verified." is not the same as saying "Type A o= r B are not to be resolved".=C2=A0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) I support John's DISCUSS.


(1) Is the specification of a headend/endpoint mandatory?=C2=A0 IOW, should= the text
in =C2=A72.1 about the headend/endpoint being identified by a unique IPv4 o= r IPv6
address be normative?

KT> It is not = normative since we have the case of an unspecified address as an endpoint. = We could use SHOULD though, if that clarifies.
=C2=A0


(2) =C2=A72.1: "An implementation MAY allow the assignment of a symbol= ic name
comprising of printable ASCII [RFC0020] [RFC5234] characters"

Why are you normatively limiting the name to be represented in ASCII?=C2=A0= Please
internationalize it - use UTF-8.

=C2=A72.6 also has similar text.

KT>= My understanding is that there is no compulsion to use UTF-8 for such purp= oses. This was discussed in the WG. Please check:=C2=A0https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIl= J2Yq_w/=C2=A0
=C2=A0


(3) =C2=A72.1: "Such symbolic names MAY identify an SR Policy when the= naming scheme
ensures uniqueness."=C2=A0 In this case, the "MAY" is just s= tating a fact.
s/MAY/may

KT> Ack. Will fix.
=C2=A0


(4) =C2=A72.1: "An SR Policy MAY have multiple names...in the scenario= where the
headend receives different SR Policy names"=C2=A0 =C2=A0Describing mul= tiple names as the
case where multiple names are received is not helpful.

KT> When CPs for the same SR Policy are provisioned via = different sources, then such a scenario may occur.
=C2=A0


(5) =C2=A72.2: "the endpoints of the constituent SR Policies and the p= arent SR Policy
MUST be identical"=C2=A0 To avoid confusion, by "endpoints" = you mean "headend and
endpoint", right?

KT> We mean t= he endpoint as in "the tail-end". We are speaking from within the= context of a headend here so the headend is the same.
=C2=A0


(6) =C2=A72.3:

=C2=A0 =C2=A0A headend MAY be informed about a candidate path for an SR Pol= icy
=C2=A0 =C2=A0<color, endpoint> by various means including...

It seems like the "MAY" is only stating a fact -- if so, then s/M= AY/may

KT> Ack. Will fix.
= =C2=A0


(7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD be s= et to 0 by
default when not available or known."

When is it ok for the ASN to not be set to 0 (when not available or known)?=
If that possibility exists, the PCE can use any value (including the real number or a random one).=C2=A0 What issues exist with uncoordinated (or rog= ue) PCEs
using potentially arbitrary ASNs?

Why is this action recommended and not required?

<= /div>
KT> AFAIR PCEP signaling does not carry AS number. So this is = a recommendation, though a local policy or a future PCEP extension could ch= ange that and we don't want to preclude it.
=C2=A0


(8) This paragraph in =C2=A72.5 seems to be missing something"

=C2=A0 =C2=A0The Discriminator is a 32-bit value associated with a candidat= e path
=C2=A0 =C2=A0that uniquely identifies it within the context of an SR Policy= from a
=C2=A0 =C2=A0specific Protocol-Origin as specified below:

"below" where?=C2=A0 =C2=A0I guess you may mean "below in = =C2=A72.6 (Identification of a
Candidate Path)", but that section says that the "tuple
<Protocol-Origin, originator, discriminator> uniquely identifies a ca= ndidate
path" and not just the discriminator as above.
KT> The next three paragraphs that begin with "When ..= " should be a bullet list. Looks like it got missed out.
=C2= =A0

Also, the ":" leads to some text about the default and specific p= rotocols.
Given that this document intends to provide an architecture, I would expect=
general consideration about the discriminator, and not pointers to how it c= an
be signaled or, much less, the process in BGP.=C2=A0 In general, I would ex= pect the
architecture to not rely on solution documents to explain how pieces of the=
architecture are derived.

KT> These = are informational pointers to the respective protocol specs to help the rea= der.
=C2=A0


(10) =C2=A72.11: "Only the active candidate path SHOULD be used for fo= rwarding
traffic that is being steered onto that policy."=C2=A0 =C2=A0When is i= t ok to use
non-active paths?=C2=A0 Why is this action recommended and not required?

KT> The condition was for path protect= ion as described in section 9.3. The "backup" path is programmed = and hence may be used for forwarding while FRR is active.
=C2=A0<= /div>


(11) =C2=A72.12: Several of the "MAY" statements in this section = express a fact, not
a normative statement:=C2=A0 s/MAY/may

The operator MAY set this field...
An SR Policy MAY comprise multiple...

K= T> Ack. Will fix those.=C2=A0


(12) =C2=A74:

=C2=A0 =C2=A0When the algorithm is not specified for the SID types above wh= ich
=C2=A0 =C2=A0optionally allow for it, the headend SHOULD use the Strict Sho= rtest
=C2=A0 =C2=A0Path algorithm if available; otherwise, it SHOULD use the defa= ult
=C2=A0 =C2=A0Shortest Path algorithm.

In this sentence, you're recommending both algorithms.=C2=A0 When shoul= d one or the
other be used?=C2=A0 There are no qualifiers that lead to the "otherwi= se" statement.

KT> Ack. The sem= icolon needs to be replaced=C2=A0by "and"=C2=A0 before "othe= rwise".
=C2=A0


(13) =C2=A74: What is the purpose of enumerating the types of segment-descr= iptors?
Should the type be indicated when the Segment-List is signaled?=C2=A0 I ass= ume the
answer is yes, but I didn't see that specified anywhere.

KT> It is used in the protocol specs for reference= - e.g=C2=A0draft-ietf-idr-segment-routing-te-policy
=C2=A0
=


(14) =C2=A75.1: "The headend detects a mismatch between the SID value = and its
context provided for SIDs of type C-through-K"=C2=A0 What does having = a mismatch
mean?=C2=A0 Please be specific.

KT> = The value of the SID provided does not match the value of the SID determine= d through the provided context. Will clarify.
=C2=A0


(15) =C2=A75.2:

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy'= ;s tail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, = the
=C2=A0 =C2=A0headend MAY send path computation request to a PCE supporting = PCEP
=C2=A0 =C2=A0extension specified in [RFC8664].

This action (ask the PCE) is a solution, not an architectural description.= =C2=A0 Are
there other external mechanisms that can find a "solution Segment-List= "?=C2=A0 It
seems to me that one such mechanism would be in the form of a configured Segment-List.=C2=A0 If that is correct, please generalize the normative sta= tement
above -- where using PCEP can be an example.

KT> Agree and will change that to an example.=C2=A0


(16) =C2=A77: Which are valid states?=C2=A0 Active is one, the text mention= s an
"administrative state", what else?=C2=A0 =C2=A0Interoperability i= s a good reason to
specify the states and not assume that implementations might do the right t= hing.

KT> The state here does not me= an a single one like up/down. It is referring to the operational state. Tho= se aspects are covered in the=C2=A0draft-ietf-spring-sr-policy-yang but als= o reported via BGP and PCEP when those protocols are in use. We'll add = a reference to=C2=A0draft-ietf-spring-sr-policy-yang.
=C2=A0


(17) =C2=A77: "The SR Policy state MUST also reflect the reason when a= policy and/or
its candidate path is not active due to validation errors or not being
preferred."

Given that this is a requirement, please provide a list of reasons.=C2=A0 T= he need
for interoperability (by using rfc2119 language) can only be achieved if th= e
reasons are standardized.

KT> The re= ason is for debugging and troubleshooting. If something is down or invalid,= then it helps to know why.
=C2=A0


(18) In general, the text contains a mixture of normative language (rfc2119= )
and descriptions that make the contents inconsistent and confusing.=C2=A0 F= or
example, my interpretation of "an SR Policy and its BSID are removed f= rom the
forwarding plane" (from =C2=A78.1) is that it is an absolute requireme= nt.=C2=A0 However,
=C2=A78.2 presents the optional "Drop-Upon-Invalid behavior" whic= h then indicates
that there can be cases where my interpretation was not correct.

The point here is that the text in a Standards Track document should not be= up
for interpretation.

There are too many cases in the text to list that would have benefitted fro= m
using Normative Language -- I mentioned a couple above.=C2=A0 Ideally, the = authors
would make one more pass for clarity.=C2=A0 However, I will probably end up=
ABSTAINing because of it.

This point was also raised in the rtg-dir review, which is why I'm not<= br> including it as part of a DISCUSS.

KT&g= t; Authors will take a pass and get back on this.=C2=A0

Thanks,
Ketan

=C2=A0
--000000000000f825cb05d8381cf4-- From nobody Thu Feb 17 07:09:13 2022 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 78D423A05D0; Thu, 17 Feb 2022 07:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 YcxpPybUT47T; Thu, 17 Feb 2022 07:09:03 -0800 (PST) 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 570FD3A0100; Thu, 17 Feb 2022 07:09:03 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id e26so6596309vso.3; Thu, 17 Feb 2022 07:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GHPiyDcMsGTCJ5KdczM2dTj11kz5Jne117g5AMMRHp0=; b=PIbGK94whY9OVQVzvSxEclcIJYQgk+HdsAZnWOXZDo4H6aCejKFT3FnIrEgCRX3g6Y xEgvc9TrmyNrfsA0ePQ5QVubntVO407EyzJ+u9w34QYlzf/nLPBc32qvVooxUbfMbIPx tGehz8xkeC7O88dNNzc0oFfRiYVV8hyEjYcxzL34B1IK+Fs/kcl6RNKYqaIOJKEkjtFb 5c9DV1XVATjcsHMvDLrIJqgBZZfZd0Ck8C3dMpXvnRQnDbVX5/nU0sM/vbF5zJ6dNnty hS+JOnVf9C90WjW0wCdSp5qwoE0OU/N4St0OGdtNy2jyrHzcpzspQvKKWpPhV/7gkdnS +ycA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GHPiyDcMsGTCJ5KdczM2dTj11kz5Jne117g5AMMRHp0=; b=QGGKCWKbirc/FIYc3AhCc6kvFIiAFNnaBGk3llsqIzvzhs0QWT+N2lp45wsI7JhKIj 5gK+UBRho++/TwX7Et3oCji/aCiJ3rknseP1tYqlMmQWvJ5aF6MhyDaWyDtTpLOWyQfs u+zOTOvIothQoE36aAnDoxrvzE1iGjoDnG7u8P9QCEuslrhJsDCBVI6Iq+M3kvLXTl3B Dp3xXWtQjo2+o4XJB/Zrk5V8/+iIKzOpxQmpn6Br4OAfG7Xu78hqreNQPbPy0pJ3OzLU IhvITfjye9jjRVNLPKrd5pfT5Bbw8Vao5xEjBt3RndFcxSj614kKR0wScvBX0br8ggQ8 Qlpw== X-Gm-Message-State: AOAM530CYK0qQQO1POFpPD6UQVCXQZdRtIBQj6nmr3JESuQVJ/uwPV2V OWUcqHTTpgzA1O3g5eTQppyN/AeGO+uuROIoNv7sffTu X-Google-Smtp-Source: ABdhPJyMKNhCmKxuHYZh9l4gOkzpUoSXJd54AYWccNDIe6DmnALeGp3nhpxOxNfuDBSiagUU4TTFkaZ7Hu5JFtzvRBU= X-Received: by 2002:a05:6102:34f4:b0:31b:9861:7cfa with SMTP id bi20-20020a05610234f400b0031b98617cfamr1358566vsb.64.1645110541995; Thu, 17 Feb 2022 07:09:01 -0800 (PST) MIME-Version: 1.0 References: <164504916365.5606.17077981996669554325@ietfa.amsl.com> In-Reply-To: <164504916365.5606.17077981996669554325@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 20:38:49 +0530 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="00000000000078d8e105d838254d" Archived-At: Subject: Re: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 15:09:07 -0000 --00000000000078d8e105d838254d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks for your review and comments/inputs. Please check inline below for responses. On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > There appear to be a few places where additional pointers or specificatio= n > is > needed to ensure interoperability. > > ** Section 2.5 > When signaling is via PCEP, the method to uniquely signal an > individual candidate path along with its discriminator is described > in [I-D.ietf-pce-segment-routing-policy-cp]. > > Where is the explanation of discriminator in this reference? > =E2=80=9CDiscriminator=E2=80=9D > appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2. In the first three > section it > is simply named but not explained. In the last section, it isn=E2=80=99t= explained > beyond being defined as 32-bits. > KT> I have not yet reviewed that document and will do so to pass the comments to the authors of that document. As a reminder, this is an architecture document in SPRING that is then realized using protocol extensions/mechanisms that are specified in their respective WG documents. > > ** Section 2.6. > Candidate paths MAY also be assigned or signaled with a symbolic name > comprising printable ASCII [RFC0020] [RFC5234] characters > > How these candidate paths names are signaled isn=E2=80=99t defined. I be= lieve it > is > per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section > 2.4.7 > of draft-ietf-idr-segment-routing-te-policy. > ** Section 2.7. How is the candidate path preference signaled? Is that > draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-p= olicy-14#section-2.4.1 > ? > KT> Those protocol specs normatively refer to this document. Your understanding is correct about the parts of those documents. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support John Scudder and Alvaro Retana's DISCUSS positions. > > ** Section 2.1. > The color is an unsigned non-zero 32-bit numerical value that > associates the SR Policy with an intent or objective (e.g. low- > latency). > > Should =E2=80=9Cnumeric value=E2=80=9D be =E2=80=9Cinteger=E2=80=9D? > KT> Ack. Will clarify. > > ** Section 2.1 > The SR Policy name > MAY also be signaled along with a candidate path of the SR Policy > (refer to Section 2.2). > > -- It would be helpful to explicitly state either here or in Section 2.2 > that > Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section > 5.2.1 of > [I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how th= is > naming is signaled. Section 2.2 doesn=E2=80=99t discuss signaling the nam= e. > > -- Both of these document need to be normative reference since there is > dependency on them for interoperable behavior. > KT> Please see one of my previous responses on the architecture and protocol specifications split across documents. > > ** Section 2.2. Typo. s/heirarchical/hierarchical/ > KT> Ack. > > ** Section 2.3. It would be helpful if the precise mechanism to signal t= he > Protocol-Origin was cited. > KT> It is not something that is signaled - refer to "The head-end assigns different Protocol-Origin values to each source of SR Policy information.". It is like an "administrative distance" that is used to attach preference to routes learned via different protocols like OSPF, IS-IS, and BGP. This is local on the headend. > > -- I believe it is Section 5.2.2 of > [I-D.ietf-pce-segment-routing-policy-cp] > KT> Ack but likely we'll need to remove section number references or revalidate them at publication given how these documents have been moving along and their interdependencies. > > -- I didn=E2=80=99t find any reference to a =E2=80=9CProtocol Origin=E2= =80=9D or this section in > [I-D.ietf-idr-segment-routing-te-policy]. > KT> Please check my previous comment. > > ** Section 2.4. > When signaling is via BGP SR Policy, the ASN and Node Address are > provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) > on the headend. > > [I-D.ietf-idr-segment-routing-te-policy] needs to be a normative referenc= e > (as > stated before due to the text in Section 2.1) > > ** Section 2.5. Per =E2=80=9CWhen provisioning is via configuration, t= his is an > implementation's configuration model-specific unique identifier for a > candidate > path=E2=80=9D, what is a =E2=80=9Cconfiguration model-model-specific uniq= ue identifier? > What > scope of the uniqueness? > KT> Please refer to draft-ietf-spring-sr-policy-yang - we could not be more specific or provide exact pointer here since that document is still under development. > > ** Section 2.13. This section says =E2=80=9Cthe information model is the > following=E2=80=9D, > but I don=E2=80=99t follow where that information model (IM) is per the d= efinition > in > RFC3444. The text here appears be an example with hard-coded parameter > values. > KT> This is an overview and the actual model is being specified in draft-ietf-spring-sr-policy-yang > > ** Section 4. > Based on the desired dataplane, either the MPLS label stack or the > SRv6 Segment Routing Header [RFC8754] is built from the Segment- > List. > > Do SRv6 SRH and MPLS label stacks support all the segment types enumerate= d > here? For example, does Type E and F, IPv4 segments, work with a SRv6 SR= H? > KT> What goes into the packet, at the end of the day, are MPLS labels or SRv6 SIDs. The segment types introduce the different context types that are used to specify a segment especially in the signaling protocols. > > ** Section 4. > When the algorithm is not specified for the SID types above which > optionally allow for it, the headend SHOULD use the Strict Shortest > Path algorithm if available; otherwise, it SHOULD use the default > Shortest Path algorithm. The specification of the algorithm enables > the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific > SIDs in SR Policy. > > Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative > reference? > KT> We enable the specification of an algorithm that was introduced by RFC8402. A later enhancement carved out a range of algos from there for IGP Flexible Algorithm. The reference is informative to indicate that one could use IGP Flex Algo as well. > > ** Section 10. Given that this document has a dependency on > [I-D.ietf-idr-segment-routing-te-policy] and > [I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy, > their > security considerations should apply. > KT> I refer again to the dependency between this SPRING and the other protocol specs. Thanks, Ketan --00000000000078d8e105d838254d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Thanks for y= our review and comments/inputs. Please check inline below for responses.


On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatra= cker <noreply@ietf= .org> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There appear to be a few places where additional pointers or specification = is
needed to ensure interoperability.

** Section 2.5
=C2=A0 =C2=A0When signaling is via PCEP, the method to uniquely signal an =C2=A0 =C2=A0individual candidate path along with its discriminator is desc= ribed
=C2=A0 =C2=A0in [I-D.ietf-pce-segment-routing-policy-cp].

Where is the explanation of discriminator in this reference?=C2=A0 =E2=80= =9CDiscriminator=E2=80=9D
appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2.=C2=A0 In the first three se= ction it
is simply named but not explained.=C2=A0 In the last section, it isn=E2=80= =99t explained
beyond being defined as 32-bits.

KT>= I have not yet reviewed that document and will do so to pass the comments = to the authors of that document. As a reminder, this is an architecture doc= ument in SPRING that is then realized using protocol extensions/mechanisms = that are specified in their respective WG documents.
=C2=A0
=

** Section 2.6.
=C2=A0 Candidate paths MAY also be assigned or signaled with a symbolic nam= e
=C2=A0 =C2=A0comprising printable ASCII [RFC0020] [RFC5234] characters

How these candidate paths names are signaled isn=E2=80=99t defined.=C2=A0 I= believe it is
per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2= .4.7
of draft-ietf-idr-segment-routing-te-policy.=C2=A0

** Section 2.7.=C2=A0 How is the candidate path preference signaled?=C2=A0 = Is that
draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and
https= ://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-1= 4#section-2.4.1?

KT> Those proto= col specs normatively refer to this document. Your understanding is correct= about the parts of those documents.=C2=A0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support John Scudder and Alvaro Retana's DISCUSS positions.

** Section 2.1.
=C2=A0 =C2=A0The color is an unsigned non-zero 32-bit numerical value that<= br> =C2=A0 =C2=A0associates the SR Policy with an intent or objective (e.g.=C2= =A0 low-
=C2=A0 =C2=A0latency).

Should =E2=80=9Cnumeric value=E2=80=9D be =E2=80=9Cinteger=E2=80=9D?

KT> Ack. Will clarify.
=C2=A0

** Section 2.1
=C2=A0 =C2=A0The SR Policy name
=C2=A0 =C2=A0MAY also be signaled along with a candidate path of the SR Pol= icy
=C2=A0 =C2=A0(refer to Section 2.2).

-- It would be helpful to explicitly state either here or in Section 2.2 th= at
Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section 5.2.1= of
[I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how this=
naming is signaled. Section 2.2 doesn=E2=80=99t discuss signaling the name.=

-- Both of these document need to be normative reference since there is
dependency on them for interoperable behavior.

KT> Please see one of my previous responses on the architecture = and protocol specifications split across documents.
=C2=A0
<= 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">
** Section 2.2. Typo. s/heirarchical/hierarchical/
KT> Ack.
=C2=A0

** Section 2.3.=C2=A0 It would be helpful if the precise mechanism to signa= l the
Protocol-Origin was cited.

KT> It is= not something that is signaled - refer to "The head-end assigns diffe= rent Protocol-Origin values to each source of SR Policy information.".= It is like an "administrative distance" that is used to attach p= reference to routes learned via different protocols like OSPF, IS-IS, and B= GP.=C2=A0 This is local on the headend.
=C2=A0

-- I believe it is Section 5.2.2 of [I-D.ietf-pce-segment-routing-policy-cp= ]

KT> Ack but likely we'll need = to remove section number references or revalidate them at publication given= how these documents have been moving along and their interdependencies.=C2= =A0
=C2=A0

-- I didn=E2=80=99t find any reference to a =E2=80=9CProtocol Origin=E2=80= =9D or this section in
[I-D.ietf-idr-segment-routing-te-policy].

KT> Please check my previous comment.
=C2=A0

** Section 2.4.
=C2=A0 =C2=A0When signaling is via BGP SR Policy, the ASN and Node Address = are
=C2=A0 =C2=A0provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-pol= icy])
=C2=A0 =C2=A0on the headend.

[I-D.ietf-idr-segment-routing-te-policy] needs to be a normative reference = (as
stated before due to the text in Section 2.1)

** Section 2.5.=C2=A0 =C2=A0 Per =E2=80=9CWhen provisioning is via configur= ation, this is an
implementation's configuration model-specific unique identifier for a c= andidate
path=E2=80=9D, what is a =E2=80=9Cconfiguration model-model-specific unique= identifier?=C2=A0 What
scope of the uniqueness?

KT> Please = refer to=C2=A0draft-ietf-spring-sr-policy-yang - we could not be more speci= fic or provide exact pointer here since that document is still under develo= pment.=C2=A0

** Section 2.13.=C2=A0 This section says =E2=80=9Cthe information model is = the following=E2=80=9D,
but I don=E2=80=99t follow where that information model (IM) is per the def= inition in
RFC3444.=C2=A0 The text here appears be an example with hard-coded paramete= r values.

KT> This is an overview an= d the actual model is being specified in=C2=A0draft-ietf-spring-sr-policy-y= ang
=C2=A0

** Section 4.
=C2=A0 =C2=A0Based on the desired dataplane, either the MPLS label stack or= the
=C2=A0 =C2=A0SRv6 Segment Routing Header [RFC8754] is built from the Segmen= t-
=C2=A0 =C2=A0 List.

Do SRv6 SRH and MPLS label stacks support all the segment types enumerated<= br> here?=C2=A0 For example, does Type E and F, IPv4 segments, work with a SRv6= SRH?

KT> What goes into the packet,= at the end of the day, are MPLS labels or SRv6 SIDs. The segment types int= roduce the different context types that are used to specify a segment espec= ially in the signaling protocols.
=C2=A0

** Section 4.
=C2=A0 =C2=A0When the algorithm is not specified for the SID types above wh= ich
=C2=A0 =C2=A0optionally allow for it, the headend SHOULD use the Strict Sho= rtest
=C2=A0 =C2=A0Path algorithm if available; otherwise, it SHOULD use the defa= ult
=C2=A0 =C2=A0Shortest Path algorithm.=C2=A0 The specification of the algori= thm enables
=C2=A0 =C2=A0the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] spe= cific
=C2=A0 =C2=A0SIDs in SR Policy.

Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative referen= ce?

KT>=C2=A0 We enable the specific= ation of an algorithm that was introduced by RFC8402. A later enhancement c= arved out a range of algos from there for IGP Flexible Algorithm. The refer= ence is informative to=C2=A0indicate that one could use IGP Flex Algo as we= ll.
=C2=A0

** Section 10.=C2=A0 Given that this document has a dependency on
[I-D.ietf-idr-segment-routing-te-policy] and
[I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy, t= heir
security considerations should apply.

K= T> I refer again to the dependency between this SPRING and the other pro= tocol specs.

Thanks,
Ketan
=C2= =A0
--00000000000078d8e105d838254d-- From nobody Thu Feb 17 07:51:35 2022 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 C59FD3A0949; Thu, 17 Feb 2022 07:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 41tHMGJKOnsR; Thu, 17 Feb 2022 07:51:18 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 4F5823A0940; Thu, 17 Feb 2022 07:51:18 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id t22so6741076vsa.4; Thu, 17 Feb 2022 07:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AIYY3QFRo+KZ+RzSEFkfKIcC26Pp/l0jgnZ5mgZgrtM=; b=F28+eyfQNQVKTZA5Dlyqw5uOHWhxcCMe/74YratvOi3K/LYgg/LgkOykRPHKVAm9GC aNtKUV5QxPxe400yWRgGiAZfNZIrfVuLThS6Nc8jZkNmiH4TQgemW60njNLnpM2AfW6k YSWspJXWcUakZPc0nU55ddmZ1yfc6vp4/Y23ND4TTCzdYlA7ZGlgnIDHn8ZAy2xMWqGK zPnOt2cK1cNdChIHMmA/JBAcg/3jkNIpQctM7fcOvsCboBniualuaakGzD2/9mcqseI+ BqN16SjQ/WYKz6Nm74Ju4rZJ3OfsR+IcGcOUC25IJnt0X4n91veeJg+nLX1bwIcEXvUY 58mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AIYY3QFRo+KZ+RzSEFkfKIcC26Pp/l0jgnZ5mgZgrtM=; b=oPAWwxzTSsGEbJot7dgOIipxpAxhfMjbYgRLNLJdBxZe97mu+AYSopuFjoKSHpRQwa Lka4mZ+maiUnIc74zuxXI8C1LcAi5qnI262ejAzrga8+/Q8nq+MZRQmhc1OQZDcOHtPn eaBkI7yIRAEzBTvO5XBU5zpvy/Acgwd3r7tSzrS1d3CDahX4nzJGA67UVFLHFdRP6bge /2Ycyle2mV4G1cRDAW4+1B1Sz1laCpmuFpnjwx6SNJHQNl6KwrlU281RpwNt54jSf7FF lXALzn37Y2L0dvhjxhMxy1quWUfU1CLyQ1aO4X1HW79+SplZPACfEZz4Soq72GfaD+1W oWzg== X-Gm-Message-State: AOAM530s9j5xZVyspIUBfvxYwWDUn5EKka4U52wxHDsNAdh0iPNanY/G JkLRLVWKUhtuJ97ilCJ9xdCuDI0q29WJmfFzhewx3kUY X-Google-Smtp-Source: ABdhPJypldKTsp9PviapCueHoL7z/WoCwOlBM9h/GuDyeVUBpkgl2bnLIjQELE0nES+WNy+Gs8RJsEIjLfPpBCL5/gc= X-Received: by 2002:a05:6102:3e95:b0:30f:9865:e97e with SMTP id m21-20020a0561023e9500b0030f9865e97emr1526748vsv.15.1645113076863; Thu, 17 Feb 2022 07:51:16 -0800 (PST) MIME-Version: 1.0 References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> In-Reply-To: <164507858486.11948.7818447548279924153@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 21:21:04 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="0000000000008fd70305d838bcd4" Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 15:51:26 -0000 --0000000000008fd70305d838bcd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Thanks for your detailed review and your comments/inputs. Please check inline for responses. On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) I may just be misunderstanding things, but I'd like to pull on a thre= ad > in =C2=A78.4 a bit more. We say that the headend H learns a BGP route th= at has > a > VPN label V, but then the following procedures seem to say that we instal= l > a > route on the appropriate SR Policy P and that when we receive a packet th= at > matches the route in question, push a label stack including the VPN label= , > and send the resulting packet out. KT> Note that we are sending the packet to the selected BGP NH (i.e. egress PE) that advertised the route. The SR Policy is enabling the packets to traverse a path that is different from (perhaps) the best-effort IGP routing. > Nowhere do we say to check the VPN > status of the incoming packet, KT> That is the ingress part of the forwarding entry which maps the incoming traffic over a customer interface to their specific VPN context and then performs a lookup in their VPN specific table. This all is unchanged. > so this seems like it would open a hole in > the VPN by allowing "arbitrary" incoming traffic (not marked as specific = to > V) to enter that VPN. Is the label V filling some other role than > identifying a specific VPN of many VPNs that could run along the route R/= r? > (This is the only instance of the phrase "VPN label" in the document, and > no > reference is given, so I'm relying heavily on instinct to ascertain the > intent here.) > KT> I hope my responses clarified that the only thing that is changed here by the steering over the SR Policy is the path taken through the network to get to the egress PE. Rest is as today. And yes, of course, we have the ability to indicate the need for such steering via the matching Color Extended community to the BGP route. > > (2) The security considerations says that this document does not define a= ny > new protocol extensions and (accordingly) does not introduce any further > security considerations. The first part of this seems false, not least > since we define the meaning of the "CO" bits in the Color Extended > Community. I'm pretty sure that makes the second part also false, and we > need to discuss the security considerations relating to imposing SR > Policies > based only on color and not next-hop. Alvaro has also noted additional > aspects where security considerations are missing. > KT> Ack. We will add text in the security consideration sections for the CO steering modes. > > (3) The Discriminator as defined in =C2=A72.5 does not seem wide enough t= o be > able to provide the needed properties. Some later clarification in =C2= =A72.6 > implies that the definition in =C2=A72.5 is incomplete and the width is a= ctually > appropriate, but in either case =C2=A72.5 seems inadequate in its current= form. > (Details in the COMMENT.) > KT> 32 bit is wide enough and please see further response below. > > (4) Section 2.11 contains the statement, "A valid SR Policy is instantiat= ed > in the forwarding plane." > > Is this a statement of fact (i.e., a consequence of the definition of > "valid") or a mandate for something (e.g., the headend) to take action to > make it so? Given that the point of SR is to be stateless on nodes other > than the headend, I suspect the former, but if we are relying on the > headend > (or some other entity) to take action to ensure this is the case, that > needs > to be a clearly stated normative requirement. > KT> The validity of a candidate path and as an extension, the SR Policy is discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its constructs are instantiated in the forwarding plane. > > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." > There's nothing in the IANA registry for SAFI > (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml) > about > LISP, and RFC 6830 doesn't talk about SAFI. What is this referring to? > KT> Ack - there is no SAFI in LISP and the reference was meant to be for routing of both IPv4 and IPv6 packets with LISP. Will fix this. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > There's a lot of this document that feels like just some informational > discussion of "here are some things that many people do", "here are some > possible things you can do with SR", etc.. There are also a small handfu= l > of places in the document that look to actually be specifying parts of > protocol behavior (I suspect that John has already identified them in his > enumeration), and the overall impression ends up being a bit jumbled, > like there are a bunch of topics stuck together without an overarching > theme. > I think the overall content would be more valuable if divided into a tigh= t > "protocol specification" portion that could stay at proposed standard, pl= us > an informational "architecture details" document that contains the > in-depth exposition that didn't make it into 8402. > > This draft would benefit greatly from a terminology section. I note in t= he > section-by-section comments several places where a term is first used > without sufficient background/definition, leaving the matter at hand > underspecified for the reader. > > Section 2 > > An SR Policy is a framework that enables the instantiation of an > ordered list of segments on a node for implementing a source routing > > Really, an SR policy is a *framework*? I thought an SR policy was a > specific instantiation of a list of segments, or at least that's what I'm > getting from RFC 8402. Perhaps we should say that the general concept of > SR > Policy provides a framework? > KT> Ack. Will rephrase. > > Section 2.1 > > An SR Policy MUST be identified through the tuple endpoint>. In the context of a specific headend, an SR policy MUST > be identified by the tuple. > > These two MUSTs appear to be in (nominal) conflict. Maybe start the firs= t > one with "absent further context" or "absent the context of a known heade= nd > node"? > KT> It is not "absence of context" but "within the context of a specific headend". > > The headend is the node where the policy is instantiated/implemented. > The headend is specified as an IPv4 or IPv6 address and is expected > to be unique in the domain. > > This is the first instance of the word "domain" in this document. I > suggest > using the introduction to introduce what is meant by the word, even if ju= st > by reference to RFC 8402. > KT> Ack. It should be SR Domain. > > An implementation MAY allow the assignment of a symbolic name > comprising printable ASCII [RFC0020] characters (i.e. 0x20 to 0x7E) > to an SR Policy to serve as a user-friendly attribute for debugging > and troubleshooting purposes. [...] > > I agree with the other ADs that limiting to US-ASCII is not actually > user-friendly for many users, and that the likelihood of some > implementations not properly enforcing such a limitation to be high. > (Likewise for the other places where symbolic names are admitted.) > KT> Please see the response to the other reviews on this point. > > Section 2.2 > > A dynamic candidate path expresses an optimization objective and a > set of constraints. [...] > > Down in =C2=A75.2 when we discuss validation procedures for dynamic candi= date > paths, we say that the optimization problem is solved "for either the > SR-MPLS or the SRv6 data-plane as specified". Does the data plane need t= o > be specified as part of the dynamic candidate path itself? > KT> Yes. > > Section 2.3 > > in Section 2.9. The table below specifies the RECOMMENDED default > values of Protocol-Origin: > > I feel like it would be useful to provide some justification for why the > recommended default behavior prefers BGP SR configuration over PCEP, even > if > that justification is just "we need to have a clear ordering and this one > is > arbitrary". > KT> Ack. Will clarify that. > > Section 2.4 > > o Node Address : represented as a 128-bit value. IPv4 addresses > MUST be encoded in the lowest 32 bits, and the high-order bits > MUST be set to zero. > > Its application in the candidate path selection is described in > Section 2.9. > > The tie-breaker procedure for path selection described in =C2=A72.9 seems= to > always prefer IPv4 originators over IPv6 ones (by virtue of preferring th= e > smaller value). I guess if we wanted to change that to prefer IPv6 we ha= ve > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped unicast) > from BCP 153, but it's a bit hard to justify either of those as appropria= te > on technical grounds, and since this is just a tie-breaker and the > Preference is explicitly preferred, it seems like this is probably "good > enough" as-is. > KT> Ack. As clarified in a recent text update in v17, preference is the key parameter really. > > Section 2.5 > > The Discriminator is a 32-bit value associated with a candidate path > that uniquely identifies it within the context of an SR Policy from a > specific Protocol-Origin as specified below: > > What are the constraints that underlie the 32-bit requirement here? > It looks like some of the scenarios are going to involve uncoordinated > (random) assignment of these discriminator values (e.g., with the BGP > distribution mechanism, when coming from different BGP peers), and the > birthday-bound collision probability is not negligible for this few bits. > That, in turn, calls into question the "uniquely identifies" property bei= ng > claimed. Or is there some other property that means that only > discriminators from a single issuer will ever need to be compared with ea= ch > other (making the allocation "coordinated"), such as being additionally > associated with the originator? > If my initial analysis was incorrect and these are indeed allocated in a > "coordinated" fashion, would it be typical/expected for the allocation to > occur by incrementing a local counter on the originator? In some > situations > such allocation by counter can have security considerations, which > draft-gont-numeric-ids-sec-considerations attempts to cover. > KT> The discriminator is scoped to a particular originating node for the candidate path and as such, there is no requirement for coordination across sources/nodes. Therefore, 32-bit is more than sufficient. > > Section 2.8 > > A candidate path is usable when it is valid. A common path validity > criterion is the validity of any of its constituent Segment-Lists. > The validation rules are specified in Section 5. > > This document claims to target Proposed Standard status; are we really > content to say only that this is "a common" criterion? Even when we also > go > on to flat-out state "the validation rules are specified [below]"? > KT> We will change this to introduce the word RECOMMENDED. There are deployments where an operator might need a local policy to declare the candidate path invalid when the number of valid SLs drops below a certain threshold (for b/w or load-balancing considerations). > > Section 2.9 > > The candidate path selection process operates primarily on the > candidate path Preference. A candidate path is selected when it is > valid and it has the highest preference value among all the candidate > paths of the SR Policy. > > Should this be "among all the valid candidate paths"? A path that's > invalid > is still invalid, even if it has the highest preference value. > KT> Ack - will clarify this. > > 2. If specified by configuration, prefer the existing installed > path. > > Does "if specified by configuration" refer to the act of applying this ru= le > at all, or that the existing installed path was one specified by > configuration? > KT> The existing installed path. The rationale was that in some deployment designs an operator may not want to disturb/churn an active and valid/working path that has been installed in the forwarding. > > Section 2.11 > > The fraction of the flows associated with a given Segment-List is w/ > Sw, where w is the weight of the Segment-List and Sw is the sum of > the weights of the Segment-Lists of the selected path of the SR > Policy. > > Thank you for stating this clearly! > > Section 3 > > o TE Link Attributes (such as TE metric, Shared Risk Link Groups, > attribute-flag, extended admin group) [RFC5305] [RFC3630]. > > Is RFC 5329 applicable here as well? > KT> Yes, will add that. Thanks. > > Section 4 > > Type E: IPv4 Prefix with Local Interface ID: > This type allows identification of Adjacency SID or BGP Peer > Adjacency SID (as defined in [RFC8402]) SR-MPLS label for > point-to-point links including IP unnumbered links. The > headend is required to resolve the specified IPv4 Prefix > Address to the Node originating it and then use the Local > Interface ID to identify the point-to-point link whose > adjacency is being referred to. The Local Interface ID link > descriptor follows semantics as specified in [RFC7752]. This > > The phrase "local interface ID" does not appear in RFC 7752 (and even > "local > interface" appears just once"; please use terminology actually present in > the referred-to document to clarify what is being referenced. > KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn references RFC5307 which in turn RFC4202. We use RFC7752 since it covers and explains the use of the various link descriptors that we use for various segment types. > > Section 4.1 > > When steering unlabeled IPv6 BGP destination traffic using an SR > policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit > Null Label Policy is processed as specified in > [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an > > It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced document. > KT> Ack. Will fix. > > Section 5.1 > > The computation/logic that leads to the choice of the Segment-List is > external to the SR Policy headend. The SR Policy headend does not > compute the Segment-List. The SR Policy headend only confirms its > validity. > > Does the headend actually have to confirm validity? Is it okay to just > trust the controller and blindly use what is provided? > KT> At least the first segment needs to be validated from a resolvability perspective. The subsequent segments depend on how (i.e., using what segment types) the controller has signalled the path to the headend. If it is indicated by just referring to a Prefix (e.g. loopback) of a node, then the headend will need to resolve and as such validate. While if specified as a label, then no resolution is required. > > Section 6.2 > > When the active candidate path has a specified BSID, the SR Policy > uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is > available (i.e., not associated with any other usage: e.g. to another > MPLS client, to another SRv6 client, to another SID, to another SR > Policy, outside the range of SRv6 Locators). > > I don't think I understand what is meant by "client" here (for "another > client"). This sentence is the only place where the word "client" appear= s > in this document... > KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be IS-IS enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from a "label manager" within the router. > > Optionally, instead of only checking that the BSID of the active path > is available, a headend MAY check that it is available within a given > SID range i.e., Segment Routing Local Block (SRLB) as specified in > [RFC8402]. > > Is the only allowed range to check the SRLB? If not, I think we need to > s/i.e./e.g./. > KT> Yes, SRLB is the one to check/allocate from for such usage. > > When the specified BSID is not available (optionally is not in the > SRLB), an alert message MUST be generated. > > This is the first time (of only two) the word "alert" appears in this > document, and there is no prior expalanation of what entity might be > receiving alerts generated by a headend. Please clarify. > KT> Alert mechanism could be one or more of syslog, Netconf notification, a telemetry mechanism, etc.. > > Assuming that at time t the BSID of the SR Policy is B1, if at time > t+dt a different candidate path becomes active and this new active > path does not have a specified BSID or its BSID is specified but is > not available (e.g. it is in use by something else), then the SR > Policy MAY keep the previous BSID B1. > > Is there a strict bound on or other guidance for what values of dt are > allowable for this purpose? KT> None > Is the intent that there be an atomic > transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-path=3DP2? > KT> There is no atomicity requirement. A switch from one active CP to another will vary depending on the cause of the switch - e.g. if it is due to a failure or because a more preferred path came up. > > The association of an SR Policy with a BSID thus MAY change over the > life of the SR Policy (e.g., upon active path change). Hence, the > BSID SHOULD NOT be used as an identification of an SR Policy. > > Is there any guidance available on how long to wait with a given BSID val= ue > unused before binding it to a new SR Policy? > KT> None. These depend on the implementation and scenarios like resource availability e.g., a BSID might get re-used sooner if the system is running short of labels. > > Section 6.2.3 > > An implementation MAY support the configuration of the Specified- > BSID-only restrictive behavior on the headend for all SR Policies or > individual SR Policies. Further, this restrictive behavior MAY also > be signaled on a per SR Policy basis to the headend. > > Elsewhere in the document we discuss specific potential signaling > mechanisms/protocols, but here we say nothing. Is that vagueness > intentional? > KT> Since this isn't a protocol specification the mechanism is not described here. However, you can look at https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-pol= icy-14#section-2.4.2 and that document refers back to this specification. > > Section 6.3 > > A valid SR Policy installs a BSID-keyed entry in the forwarding plane > with the action of steering the packets matching this entry to the > selected path of the SR Policy. > > I don't think this is stated properly. An SR Policy is the list of > segments; it isn't the entity that's installing entries in the forwarding > plane. Some other entity is installing an entry in the forwarding plane = to > realize the SR Policy in question, and we should make our writing reflect > that. > KT> Ack. s/installs/results in the installation of > > Section 6.4 > > An implementation MAY choose to associate a Binding SID with any type > of interface (e.g. a layer 3 termination of an Optical Circuit) or a > tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE > tunnel, etc). This enables the use of other non-SR enabled > > Should we have some discussion that contrasts this scenario against the > End.X behavior from RFC 8986 (for the "interface" case)? > KT> What this document says is that a BSID may be also associated to direct over these other types of interfaces/tunnels. We can look at them as having no other segment being imposed but just redirecting to an interface. In that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID in SR-MPLS). However, those tend to be associated with protocol adjacencies. I am not sure that I've followed your point though and please do let me know if I've not. > > Section 7 > > The SR Policy State is maintained on the headend to represent the > state of the policy and its candidate paths. [...] > > I confess I don't really understand why we need to have the current, > minimal, description of SR Policy State in this document. What would be > lost if we deferred its discussion entirely until there is a more > comprehensive discussion available? > KT> We will add an informational pointer to the SR Policy YANG model. What this document calls out is the requirement for reporting the operational state and provides pointers to other specs where this is being worked out. > > The SR Policy state can be reported by the headend node via BGP-LS > [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and > [I-D.ietf-pce-binding-label-sid]. > > The functionality of draft-ietf-pce-binding-label-sid seems much more > limited than that of draft-ietf-idr-te-lsp-distribution; in particular, t= he > former does not seem to actually report SR Policy state to the headed at > all; rather, it only concerns itself with BSID association to path, with = no > information about "active", "not preferred", etc. > KT> The PCEP work might be spread out over different documents but we do need to cover these requirements. That is one of the objectives of having this document coordinate work across protocol WGs. > > Section 8.3 > > If the SR Policy P is invalid, the BSID B is not in the forwarding > plane and hence the packet K is dropped by H. > > We literally just in the previous section talked about a scenario where t= he > BSDI is kept in the forwarding plane (but with the action to drop, so the > overall outcome is not changed from what this text describes). > Nonetheless, > it's inaccurate to state that "the BSID B is not in the forwarding plane" > here. > KT> There is a difference between the drop being referred to in 8.2 and 8.3. What we have in 8.2 is like a route pointing to null where we may advertise and get packets but will drop it with normal counters associated with that specific entry. While 8.3 is like we are dropping because we have no route (ideally we shouldn't have got the packet) and we increment a generic lookup failed counter. The use-cases for both are different. > > Section 8.4.1 > > When a BGP route has multiple Color Extended communities each with a > valid SR Policy, the BGP process installs the route on the SR Policy > giving preference to the color with the highest numerical value. > > Do we want to say anything about this being an arbitrary tiebreaker (rath= er > than an intentional preference), or is that thought to be implicitly clea= r? > KT> It is an intentional preference. > > Section 8.5 > > In this section, independent of the a-priori existence of any > explicit candidate path of the SR policy (C, N), it is to be noted > that the BGP process at headend node H triggers the instantiation of > a dynamic candidate path for the SR policy (C, N) as soon as: > > I strongly suggest providing a more explicit framework of what the > assumptions and preconditions are for the mechanism described in this > section. My intuition says that it's a fairly optional thing that would > need to be specifically configured, but trying to wrap that sentiment int= o > the long bullet point involving "a local policy" seems like a very > confusing > way to express the desired behavior. > KT> It is actually a matter of local policy with perhaps some template and configuration to drive this. I believe this should get covered in the SR Policy YANG model at some point in time. > > Section 8.6 > > o is configured to instantiate an array of paths to N where the > entry 0 is the IGP path to N, color C1 is the first entry and > Color C2 is the second entry. The index into the array is called > a Forwarding Class (FC). The index can have values 0 to 7. > > Why are the only allowed values 0 to 7? Where does this restriction aris= e > from? It is because of some protocol element? > KT> There is text further in the section to indicated that these ranges/values are implementation-specific. Historically, the 8 values have come from the MPLS EXP bits. > > If the local configuration does not specify any explicit forwarding > information for an entry of the array, then this entry is filled with > the same information as entry 0 (i.e. the IGP shortest path). > > If the SR Policy mapped to an entry of the array becomes invalid, > then this entry is filled with the same information as entry 0. When > all the array entries have the same information as entry0, the > forwarding entry for N is updated to bypass the array and point > directly to its outgoing interface and next-hop. > > I can't tell how much of this is supposed to be protocol specification an= d > how much an illustrative example. Is A(0) always the IGP shortest path? > Are these protocol requirements to fall back to the IGP shortest path whe= n > an entry is otherwise unpopulated or the associated SR Policy becomes > invalid? > KT> The specifics are for illustration purposes. Most of these are policy knobs/options. > > Section 8.8.2 > > The steering preference is first based on the highest color value and > then CO-dependent for the color. [...] > > This seems to contradict what I assumed earlier about the "highest color" > rule being a tiebreaker, e.g., the word "preference" is used here. Is it > actually intended to be a deliberately configured priority/preference > scheme? If so, that would seem to require some wide-ranging reworking > throughout the document. > KT> There is the color that is in the identification of an SR Policy - (color, endpoint). This does not get into any tiebreaker or selection logic. All that (sec 2.9) is about the selection of a candidate path within an SR Policy. Then there is the color value signaled via the Color Extended community on the BGP routes and here, we have the preference for higher color when the route is advertised with multiple colors tagged to it. > > Section 9.3 > > the most appropriate alternative for the active candidate path. A > fast re-route mechanism MAY then be used to trigger sub 50msec > switchover from the active to the backup candidate path in the > forwarding plane. Mechanisms like Bidirectional Forwarding Detection > (BFD) MAY be used for fast detection of such failures. > > Why is the specific 50msec value important here? Is there some other > requirement that imposes it? > KT> This comes from "typical" expectations from fast-reroute mechanisms. > > Section 10 > > I think we also want to mention the security considerations of several mo= re > documents, including (but not limited to) > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986. > KT> Ack on the three RFCs, but convinced about the draft-ietf-idr-segment-routing-te-policy since that depends on this and not the other way around. > > Section 15.2 > > I agree with John that draft-ietf-idr-segment-routing-te-policy must be > classified as a normative reference. > > It also seems that RFC 7752 should be classified as normative, as we > incorporate its definition for the semantics of several of the segment ty= pe > descriptions. > KT> Ack > > > NITS > > Section 1 > > Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of > segments (i.e. instructions) that represent a source-routed policy. > > /Segment/A Segment/ > KT> Ack > > The headend node is said to steer a flow into a SR Policy. The > packets steered into an SR Policy carry an ordered list of segments > associated with that SR Policy. [...] > > In a certain sense this can be read as saying that the packets that "carr= y > an ordered list of segments" are the ones prior to being steered into an = SR > policy, which would make this statement not true. Perhaps we want to say > "after being steered into an SR Policy, packets carry an ordered list ...= "? > (I also went back and forth with myself about whether "packets ... carry" > implies in the payload or not. I settled on "not" but make this note jus= t > in case I am missing an aspect of that question.) > KT> Ack. Will rephrase. > > Section 2 > > An SR Policy is a framework that enables the instantiation of an > ordered list of segments on a node for implementing a source routing > > It's easy to read this as saying that all of the segments in the list > instantiated on the single node in question, which I assume is not the > intent. Probably the easiest way to aid readability here is to split the > sentence up into multiple smaller sentences that are easier to parse. > KT> Will rephrase. > > Section 2.2 > > A dynamic candidate path expresses an optimization objective and a > set of constraints. The headend (potentially with the help of a PCE) > computes the solution Segment-List (or set of Segment-Lists) that > solves the optimization problem. > > I'd suggest computes the solution/computes a solution/ for genericity. > KT> Ack. > A stateful PCE might end up computing a path that is not the optimal one > for > this specific optimization problem, due to a desire to cooperate with oth= er > paths in the network, and the "Min-Metric with margin and maximum number = of > SIDs" objective in draft-filsfils-spring-sr-policy-considerations doesn't > even have a guaranteed unique best solution. > > Section 2.5 > > When provisioning is via configuration, this is an implementation's > configuration model-specific unique identifier for a candidate path. > The default value is 0. > > I'm having a lot of trouble parsing this. Did we perhaps mean to hyphena= te > as "configuration-model-specific"? > KT> Ack > > Section 2.13 > > The SR Policy POL1 is identified by the tuple endpoint>. It has two candidate paths CP1 and CP2. Each is > identified by a tuple . > > I suggest (for the last sentence) "identified within the scope of POL1" > KT> Ack > > forwarding instantiation of SR policy POL1. Traffic steered on POL1 > is flow-based hashed on Segment-List with a ratio > W1/(W1+W2). > > If I read "ratio" I would instinctively think of the ratio of (traffic on > segment list 1)/(traffic on segment list 2), as opposed to the proportion > of > all traffic, that would be measured as the indicated W1/(W1+W2). > KT> Ack. s/ratio/proportion > > Section 3 > > The attached domain topology may be learned via IGP, BGP-LS or > NETCONF. > > A non-attached (remote) domain topology may be learned via BGP-LS or > NETCONF. > > I think these are both probably not exhaustive lists, so "e.g." or simila= r > may be appropriate. > KT> Ack. > > Section 4 > > Type C: IPv4 Prefix with optional SR Algorithm: > The headend is required to resolve the specified IPv4 Prefix > Address to the SR-MPLS label corresponding to a Prefix SID > segment (as defined in [RFC8402]). The SR algorithm (refer to > Section 3.1.1 of [RFC8402]) to be used MAY also be provided. > > Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: > In this case, the headend is required to resolve the specified > IPv6 Global Prefix Address to the SR-MPLS label corresponding > to its Prefix SID segment (as defined in [RFC8402]). The SR > Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY > > These are effectively just the IPv4 and IPv6 incarnations of the same > underlying procedure, right? Can't we minimize the diff between the > paragraphs further? > KT> Ack > > Section 5.1 > > Additionally, a Segment-List MAY be declared invalid when: > > We probably want another word here ("both"?), to specify how the two > conditions are combined. > KT> Ack - will rephrase. > > Section 5.2 > > When the local computation is not possible (e.g., a policy's tail-end > is outside the topology known to the headend) or not desired, the > headend MAY send path computation request to a PCE supporting PCEP > extension specified in [RFC8664]. > > missing article ("the PCEP extension"). I forget if it should be > "extensions" plural. > KT> Ack > > Section 8.7 > > Finally, headend H MAY be configured with a local routing policy > which overrides any BGP/IGP path and steer a specified packet on an > > singular/plural mismatch -- s/steer/steers/ > KT> Ack. Thanks, Ketan --0000000000008fd70305d838bcd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks for you= r detailed review and your comments/inputs. Please check inline for respons= es.


On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via= Datatracker <nore= ply@ietf.org> wrote:
Benjamin Kaduk has entered the following ballot position for draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I may just be misunderstanding things, but I'd like to pull on a th= read
in =C2=A78.4 a bit more.=C2=A0 We say that the headend H learns a BGP route= that has a
VPN label V, but then the following procedures seem to say that we install = a
route on the appropriate SR Policy P and that when we receive a packet that=
matches the route in question, push a label stack including the VPN label,<= br> and send the resulting packet out.=C2=A0

KT= > Note that we are sending the packet to the selected BGP NH (i.e. egres= s PE) that advertised the route. The SR Policy is enabling the packets to t= raverse a path that is different from (perhaps) the best-effort IGP routing= .
=C2=A0
= Nowhere do we say to check the VPN
status of the incoming packet,

KT> That= is the ingress part of the forwarding entry which maps the incoming traffi= c over a customer interface to their specific VPN context and then performs= a lookup in their VPN specific table. This all is unchanged.
=C2= =A0
so this seems li= ke it would open a hole in
the VPN by allowing "arbitrary" incoming traffic (not marked as s= pecific to
V) to enter that VPN.=C2=A0 Is the label V filling some other role than
identifying a specific VPN of many VPNs that could run along the route R/r?=
(This is the only instance of the phrase "VPN label" in the docum= ent, and no
reference is given, so I'm relying heavily on instinct to ascertain the=
intent here.)

KT> I hope my response= s clarified that the only thing that is changed here by the steering over t= he SR Policy is the path taken through the network to get to the egress PE.= Rest is as today. And yes, of course, we have the ability to indicate the = need for such steering via the matching Color Extended community to the BGP= route.
=C2=A0

(2) The security considerations says that this document does not define any=
new protocol extensions and (accordingly) does not introduce any further security considerations.=C2=A0 The first part of this seems false, not leas= t
since we define the meaning of the "CO" bits in the Color Extende= d
Community.=C2=A0 I'm pretty sure that makes the second part also false,= and we
need to discuss the security considerations relating to imposing SR Policie= s
based only on color and not next-hop.=C2=A0 Alvaro has also noted additiona= l
aspects where security considerations are missing.
KT> Ack. We will add text in the security consideration sect= ions for the CO steering modes.
=C2=A0

(3) The Discriminator as defined in =C2=A72.5 does not seem wide enough to = be
able to provide the needed properties.=C2=A0 Some later clarification in = =C2=A72.6
implies that the definition in =C2=A72.5 is incomplete and the width is act= ually
appropriate, but in either case =C2=A72.5 seems inadequate in its current f= orm.
(Details in the COMMENT.)

KT> 32 bit= is wide enough and please see further response below.
=C2=A0

(4) Section 2.11 contains the statement, "A valid SR Policy is instant= iated
in the forwarding plane."

Is this a statement of fact (i.e., a consequence of the definition of
"valid") or a mandate for something (e.g., the headend) to take a= ction to
make it so?=C2=A0 Given that the point of SR is to be stateless on nodes ot= her
than the headend, I suspect the former, but if we are relying on the headen= d
(or some other entity) to take action to ensure this is the case, that need= s
to be a clearly stated normative requirement.

KT> The validity of a candidate path and as an extension, the SR = Policy is discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and = its constructs are instantiated in the forwarding plane.
=C2=A0

(5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]."=
There's nothing in the IANA registry for SAFI
(https://www.iana.org/assignment= s/safi-namespace/safi-namespace.xhtml) about
LISP, and RFC 6830 doesn't talk about SAFI.=C2=A0 What is this referrin= g to?

KT> Ack - there is no SAFI in = LISP and the reference was meant to be for routing of both IPv4 and IPv6 pa= ckets with LISP. Will fix this.
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There's a lot of this document that feels like just some informational<= br> discussion of "here are some things that many people do", "h= ere are some
possible things you can do with SR", etc..=C2=A0 There are also a smal= l handful
of places in the document that look to actually be specifying parts of
protocol behavior (I suspect that John has already identified them in his enumeration), and the overall impression ends up being a bit jumbled,
like there are a bunch of topics stuck together without an overarching them= e.
I think the overall content would be more valuable if divided into a tight<= br> "protocol specification" portion that could stay at proposed stan= dard, plus
an informational "architecture details" document that contains th= e
in-depth exposition that didn't make it into 8402.

This draft would benefit greatly from a terminology section.=C2=A0 I note i= n the
section-by-section comments several places where a term is first used
without sufficient background/definition, leaving the matter at hand
underspecified for the reader.

Section 2

=C2=A0 =C2=A0An SR Policy is a framework that enables the instantiation of = an
=C2=A0 =C2=A0ordered list of segments on a node for implementing a source r= outing

Really, an SR policy is a *framework*?=C2=A0 I thought an SR policy was a specific instantiation of a list of segments, or at least that's what I= 'm
getting from RFC 8402.=C2=A0 Perhaps we should say that the general concept= of SR
Policy provides a framework?

KT> Ack= . Will rephrase.
=C2=A0

Section 2.1

=C2=A0 =C2=A0An SR Policy MUST be identified through the tuple <headend,= color,
=C2=A0 =C2=A0endpoint>.=C2=A0 In the context of a specific headend, an S= R policy MUST
=C2=A0 =C2=A0be identified by the <color, endpoint> tuple.

These two MUSTs appear to be in (nominal) conflict.=C2=A0 Maybe start the f= irst
one with "absent further context" or "absent the context of = a known headend
node"?

KT> It is not "abse= nce of context" but "within the context of a specific headend&quo= t;.
=C2=A0

=C2=A0 =C2=A0The headend is the node where the policy is instantiated/imple= mented.
=C2=A0 =C2=A0The headend is specified as an IPv4 or IPv6 address and is exp= ected
=C2=A0 =C2=A0to be unique in the domain.

This is the first instance of the word "domain" in this document.= =C2=A0 I suggest
using the introduction to introduce what is meant by the word, even if just=
by reference to RFC 8402.

KT> Ack. I= t should be SR Domain.
=C2=A0

=C2=A0 =C2=A0An implementation MAY allow the assignment of a symbolic name<= br> =C2=A0 =C2=A0comprising printable ASCII [RFC0020] characters (i.e.=C2=A0 0x= 20 to 0x7E)
=C2=A0 =C2=A0to an SR Policy to serve as a user-friendly attribute for debu= gging
=C2=A0 =C2=A0and troubleshooting purposes.=C2=A0 [...]

I agree with the other ADs that limiting to US-ASCII is not actually
user-friendly for many users, and that the likelihood of some
implementations not properly enforcing such a limitation to be high.
(Likewise for the other places where symbolic names are admitted.)

KT> Please see the response to the other rev= iews on this point.
=C2=A0

Section 2.2

=C2=A0 =C2=A0A dynamic candidate path expresses an optimization objective a= nd a
=C2=A0 =C2=A0set of constraints.=C2=A0 [...]

Down in =C2=A75.2 when we discuss validation procedures for dynamic candida= te
paths, we say that the optimization problem is solved "for either the<= br> SR-MPLS or the SRv6 data-plane as specified".=C2=A0 Does the data plan= e need to
be specified as part of the dynamic candidate path itself?
=

KT> Yes.
=C2=A0

Section 2.3

=C2=A0 =C2=A0in Section 2.9.=C2=A0 The table below specifies the RECOMMENDE= D default
=C2=A0 =C2=A0values of Protocol-Origin:

I feel like it would be useful to provide some justification for why the recommended default behavior prefers BGP SR configuration over PCEP, even i= f
that justification is just "we need to have a clear ordering and this = one is
arbitrary".

KT> Ack. Will clari= fy that.
=C2=A0

Section 2.4

=C2=A0 =C2=A0o=C2=A0 Node Address : represented as a 128-bit value.=C2=A0 I= Pv4 addresses
=C2=A0 =C2=A0 =C2=A0 MUST be encoded in the lowest 32 bits, and the high-or= der bits
=C2=A0 =C2=A0 =C2=A0 MUST be set to zero.

=C2=A0 =C2=A0Its application in the candidate path selection is described i= n
=C2=A0 =C2=A0Section 2.9.

The tie-breaker procedure for path selection described in =C2=A72.9 seems t= o
always prefer IPv4 originators over IPv6 ones (by virtue of preferring the<= br> smaller value).=C2=A0 I guess if we wanted to change that to prefer IPv6 we= have
the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped unicast) from BCP 153, but it's a bit hard to justify either of those as appropr= iate
on technical grounds, and since this is just a tie-breaker and the
Preference is explicitly preferred, it seems like this is probably "go= od
enough" as-is.

KT> Ack. As clar= ified in a recent text update in v17, preference is the key parameter reall= y.
=C2=A0

Section 2.5

=C2=A0 =C2=A0The Discriminator is a 32-bit value associated with a candidat= e path
=C2=A0 =C2=A0that uniquely identifies it within the context of an SR Policy= from a
=C2=A0 =C2=A0specific Protocol-Origin as specified below:

What are the constraints that underlie the 32-bit requirement here?
It looks like some of the scenarios are going to involve uncoordinated
(random) assignment of these discriminator values (e.g., with the BGP
distribution mechanism, when coming from different BGP peers), and the
birthday-bound collision probability is not negligible for this few bits. That, in turn, calls into question the "uniquely identifies" prop= erty being
claimed.=C2=A0 Or is there some other property that means that only
discriminators from a single issuer will ever need to be compared with each=
other (making the allocation "coordinated"), such as being additi= onally
associated with the originator?
If my initial analysis was incorrect and these are indeed allocated in a "coordinated" fashion, would it be typical/expected for the alloc= ation to
occur by incrementing a local counter on the originator?=C2=A0 In some situ= ations
such allocation by counter can have security considerations, which
draft-gont-numeric-ids-sec-considerations attempts to cover.

KT> The discriminator is scoped to a particular or= iginating node for the candidate path and as such, there is no requirement = for coordination across sources/nodes. Therefore, 32-bit is more than suffi= cient.
=C2=A0

Section 2.8

=C2=A0 =C2=A0A candidate path is usable when it is valid.=C2=A0 A common pa= th validity
=C2=A0 =C2=A0criterion is the validity of any of its constituent Segment-Li= sts.
=C2=A0 =C2=A0The validation rules are specified in Section 5.

This document claims to target Proposed Standard status; are we really
content to say only that this is "a common" criterion?=C2=A0 Even= when we also go
on to flat-out state "the validation rules are specified [below]"= ?

KT> We will change this to introdu= ce the word RECOMMENDED. There are deployments where an operator might need= a local policy to declare the candidate path invalid when the number of va= lid SLs drops below a certain threshold (for b/w or load-balancing consider= ations).=C2=A0
=C2=A0

Section 2.9

=C2=A0 =C2=A0The candidate path selection process operates primarily on the=
=C2=A0 =C2=A0candidate path Preference.=C2=A0 A candidate path is selected = when it is
=C2=A0 =C2=A0valid and it has the highest preference value among all the ca= ndidate
=C2=A0 =C2=A0paths of the SR Policy.

Should this be "among all the valid candidate paths"?=C2=A0 A pat= h that's invalid
is still invalid, even if it has the highest preference value.

KT> Ack - will clarify this.
=C2=A0

=C2=A0 =C2=A02.=C2=A0 If specified by configuration, prefer the existing in= stalled
=C2=A0 =C2=A0 =C2=A0 =C2=A0path.

Does "if specified by configuration" refer to the act of applying= this rule
at all, or that the existing installed path was one specified by
configuration?

KT> The existing inst= alled path. The rationale was that in some deployment designs an operator m= ay not want to disturb/churn an active and valid/working path that has been= installed in the forwarding.
=C2=A0

Section 2.11

=C2=A0 =C2=A0The fraction of the flows associated with a given Segment-List= is w/
=C2=A0 =C2=A0Sw, where w is the weight of the Segment-List and Sw is the su= m of
=C2=A0 =C2=A0the weights of the Segment-Lists of the selected path of the S= R
=C2=A0 =C2=A0Policy.

Thank you for stating this clearly!

Section 3

=C2=A0 =C2=A0o=C2=A0 TE Link Attributes (such as TE metric, Shared Risk Lin= k Groups,
=C2=A0 =C2=A0 =C2=A0 attribute-flag, extended admin group) [RFC5305] [RFC36= 30].

Is RFC 5329 applicable here as well?

KT= > Yes, will add that. Thanks.
=C2=A0

Section 4

=C2=A0 =C2=A0Type E: IPv4 Prefix with Local Interface ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This type allows identification of Adjace= ncy SID or BGP Peer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adjacency SID (as defined in [RFC8402]) S= R-MPLS label for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0point-to-point links including IP unnumbe= red links.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0headend is required to resolve the specif= ied IPv4 Prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Address to the Node originating it and th= en use the Local
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Interface ID to identify the point-to-poi= nt link whose
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adjacency is being referred to.=C2=A0 The= Local Interface ID link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0descriptor follows semantics as specified= in [RFC7752].=C2=A0 This

The phrase "local interface ID" does not appear in RFC 7752 (and = even "local
interface" appears just once"; please use terminology actually pr= esent in
the referred-to document to clarify what is being referenced.

KT> This one is a bit complicated since RFC7752 (= sec 3.2.2) in turn references RFC5307 which in turn RFC4202. We use RFC7752= since it covers and explains the use of the various link descriptors that = we use for various segment types.
=C2=A0

Section 4.1

=C2=A0 =C2=A0When steering unlabeled IPv6 BGP destination traffic using an = SR
=C2=A0 =C2=A0policy composed of Segment-List(s) based on IPv4 SIDs, the Exp= licit
=C2=A0 =C2=A0Null Label Policy is processed as specified in
=C2=A0 =C2=A0[I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4.=C2=A0= When an

It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced document.

KT> Ack. Will fix.
=C2=A0

Section 5.1

=C2=A0 =C2=A0The computation/logic that leads to the choice of the Segment-= List is
=C2=A0 =C2=A0external to the SR Policy headend.=C2=A0 The SR Policy headend= does not
=C2=A0 =C2=A0compute the Segment-List.=C2=A0 The SR Policy headend only con= firms its
=C2=A0 =C2=A0validity.

Does the headend actually have to confirm validity?=C2=A0 Is it okay to jus= t
trust the controller and blindly use what is provided?

KT> At least the first segment needs to be validated fro= m a resolvability perspective. The subsequent segments depend on how (i.e.,= using what segment types) the controller has signalled the path to the hea= dend. If it is indicated by just referring to a Prefix (e.g. loopback) of a= node, then the headend will need to resolve and as such validate. While if= specified as a label, then no resolution is required.
=C2=A0

Section 6.2

=C2=A0 =C2=A0When the active candidate path has a specified BSID, the SR Po= licy
=C2=A0 =C2=A0uses that BSID if this value (label in MPLS, IPv6 address in S= Rv6) is
=C2=A0 =C2=A0available (i.e., not associated with any other usage: e.g. to = another
=C2=A0 =C2=A0MPLS client, to another SRv6 client, to another SID, to anothe= r SR
=C2=A0 =C2=A0Policy, outside the range of SRv6 Locators).

I don't think I understand what is meant by "client" here (fo= r "another
client").=C2=A0 This sentence is the only place where the word "c= lient" appears
in this document...

KT> The term is = "MPLS client" or "SRv6 client". MPLS clients can be IS-= IS enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from a = "label manager" within the router.=C2=A0
=C2=A0

=C2=A0 =C2=A0Optionally, instead of only checking that the BSID of the acti= ve path
=C2=A0 =C2=A0is available, a headend MAY check that it is available within = a given
=C2=A0 =C2=A0SID range i.e., Segment Routing Local Block (SRLB) as specifie= d in
=C2=A0 =C2=A0[RFC8402].

Is the only allowed range to check the SRLB?=C2=A0 If not, I think we need = to
s/i.e./e.g./.

KT> Yes, SRLB is the o= ne to check/allocate from for such usage.
=C2=A0

=C2=A0 =C2=A0When the specified BSID is not available (optionally is not in= the
=C2=A0 =C2=A0SRLB), an alert message MUST be generated.

This is the first time (of only two) the word "alert" appears in = this
document, and there is no prior expalanation of what entity might be
receiving alerts generated by a headend.=C2=A0 Please clarify.

KT> Alert mechanism could be one or more of sysl= og, Netconf notification, a telemetry mechanism, etc..=C2=A0
=C2= =A0

=C2=A0 =C2=A0Assuming that at time t the BSID of the SR Policy is B1, if at= time
=C2=A0 =C2=A0t+dt a different candidate path becomes active and this new ac= tive
=C2=A0 =C2=A0path does not have a specified BSID or its BSID is specified b= ut is
=C2=A0 =C2=A0not available (e.g. it is in use by something else), then the = SR
=C2=A0 =C2=A0Policy MAY keep the previous BSID B1.

Is there a strict bound on or other guidance for what values of dt are
allowable for this purpose?

KT> None
=C2=A0
=C2=A0= Is the intent that there be an atomic
transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-path=3DP2?

KT> There is no atomicity requirement= . A switch from one active CP to another will vary depending on the cause o= f the switch - e.g. if it is due to a failure or because a more preferred p= ath came up.
=C2=A0

=C2=A0 =C2=A0The association of an SR Policy with a BSID thus MAY change ov= er the
=C2=A0 =C2=A0life of the SR Policy (e.g., upon active path change).=C2=A0 H= ence, the
=C2=A0 =C2=A0BSID SHOULD NOT be used as an identification of an SR Policy.<= br>
Is there any guidance available on how long to wait with a given BSID value=
unused before binding it to a new SR Policy?

KT> None. These depend on the implementation and scenarios like re= source availability e.g., a BSID might get re-used sooner if the system is = running short of labels.
=C2=A0

Section 6.2.3

=C2=A0 =C2=A0An implementation MAY support the configuration of the Specifi= ed-
=C2=A0 =C2=A0BSID-only restrictive behavior on the headend for all SR Polic= ies or
=C2=A0 =C2=A0individual SR Policies.=C2=A0 Further, this restrictive behavi= or MAY also
=C2=A0 =C2=A0be signaled on a per SR Policy basis to the headend.

Elsewhere in the document we discuss specific potential signaling
mechanisms/protocols, but here we say nothing.=C2=A0 Is that vagueness
intentional?

KT> Since this isn'= t a protocol specification the mechanism is not described here. However, yo= u can look at=C2=A0https= ://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-1= 4#section-2.4.2 and that document refers back to this specification.=C2= =A0
=C2=A0

Section 6.3

=C2=A0 =C2=A0A valid SR Policy installs a BSID-keyed entry in the forwardin= g plane
=C2=A0 =C2=A0with the action of steering the packets matching this entry to= the
=C2=A0 =C2=A0selected path of the SR Policy.

I don't think this is stated properly.=C2=A0 An SR Policy is the list o= f
segments; it isn't the entity that's installing entries in the forw= arding
plane.=C2=A0 Some other entity is installing an entry in the forwarding pla= ne to
realize the SR Policy in question, and we should make our writing reflect that.

KT> Ack. s/installs/results in= the installation of
=C2=A0

Section 6.4

=C2=A0 =C2=A0An implementation MAY choose to associate a Binding SID with a= ny type
=C2=A0 =C2=A0of interface (e.g. a layer 3 termination of an Optical Circuit= ) or a
=C2=A0 =C2=A0tunnel (e.g.=C2=A0 IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS = RSVP-TE
=C2=A0 =C2=A0tunnel, etc).=C2=A0 This enables the use of other non-SR enabl= ed

Should we have some discussion that contrasts this scenario against the
End.X behavior from RFC 8986 (for the "interface" case)?

KT> What this document says is that a BSID m= ay be also associated to direct over these other types of interfaces/tunnel= s. We can look at them as having no other segment being imposed but just re= directing to an interface. In that sense, it is somewhat similar to End.X i= n SRv6 (or Adjacency SID in SR-MPLS). However, those tend to be associated = with protocol adjacencies. I am not sure that I've followed your point = though and please do let me know if I've not.
=C2=A0

Section 7

=C2=A0 =C2=A0The SR Policy State is maintained on the headend to represent = the
=C2=A0 =C2=A0state of the policy and its candidate paths.=C2=A0 [...]

I confess I don't really understand why we need to have the current, minimal, description of SR Policy State in this document.=C2=A0 What would = be
lost if we deferred its discussion entirely until there is a more
comprehensive discussion available?

KT&= gt; We will add an informational pointer to the SR Policy YANG model. What = this document calls out is the requirement for reporting the operational st= ate and provides pointers to other specs where this is being worked out.
=C2=A0

=C2=A0 =C2=A0The SR Policy state can be reported by the headend node via BG= P-LS
=C2=A0 =C2=A0[I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and
=C2=A0 =C2=A0[I-D.ietf-pce-binding-label-sid].

The functionality of draft-ietf-pce-binding-label-sid seems much more
limited than that of draft-ietf-idr-te-lsp-distribution; in particular, the=
former does not seem to actually report SR Policy state to the headed at all; rather, it only concerns itself with BSID association to path, with no=
information about "active", "not preferred", etc.

KT> The PCEP work might be spread out ove= r different documents but we do need to cover these requirements. That is o= ne of the objectives of having this document coordinate work across protoco= l WGs.
=C2=A0

Section 8.3

=C2=A0 =C2=A0If the SR Policy P is invalid, the BSID B is not in the forwar= ding
=C2=A0 =C2=A0plane and hence the packet K is dropped by H.

We literally just in the previous section talked about a scenario where the=
BSDI is kept in the forwarding plane (but with the action to drop, so the overall outcome is not changed from what this text describes).=C2=A0 Noneth= eless,
it's inaccurate to state that "the BSID B is not in the forwarding= plane"
here.

KT> There is a difference betw= een the drop being referred to in 8.2 and 8.3. What we have in 8.2 is like = a route pointing to null where we may advertise and get packets but will dr= op it with normal counters associated with that specific entry. While 8.3 i= s like we are dropping because we have no route (ideally we shouldn't h= ave got the packet) and we increment a generic lookup failed counter. The u= se-cases for both are different.
=C2=A0

Section 8.4.1

=C2=A0 =C2=A0When a BGP route has multiple Color Extended communities each = with a
=C2=A0 =C2=A0valid SR Policy, the BGP process installs the route on the SR = Policy
=C2=A0 =C2=A0giving preference to the color with the highest numerical valu= e.

Do we want to say anything about this being an arbitrary tiebreaker (rather=
than an intentional preference), or is that thought to be implicitly clear?=

KT> It is an intentional preference= .
=C2=A0

Section 8.5

=C2=A0 =C2=A0In this section, independent of the a-priori existence of any<= br> =C2=A0 =C2=A0explicit candidate path of the SR policy (C, N), it is to be n= oted
=C2=A0 =C2=A0that the BGP process at headend node H triggers the instantiat= ion of
=C2=A0 =C2=A0a dynamic candidate path for the SR policy (C, N) as soon as:<= br>
I strongly suggest providing a more explicit framework of what the
assumptions and preconditions are for the mechanism described in this
section.=C2=A0 My intuition says that it's a fairly optional thing that= would
need to be specifically configured, but trying to wrap that sentiment into<= br> the long bullet point involving "a local policy" seems like a ver= y confusing
way to express the desired behavior.

KT= > It is actually a matter of local policy with perhaps some template and= configuration to drive this. I believe this should get covered in the SR P= olicy YANG model at some point in time.
=C2=A0

Section 8.6

=C2=A0 =C2=A0o=C2=A0 is configured to instantiate an array of paths to N wh= ere the
=C2=A0 =C2=A0 =C2=A0 entry 0 is the IGP path to N, color C1 is the first en= try and
=C2=A0 =C2=A0 =C2=A0 Color C2 is the second entry.=C2=A0 The index into the= array is called
=C2=A0 =C2=A0 =C2=A0 a Forwarding Class (FC).=C2=A0 The index can have valu= es 0 to 7.

Why are the only allowed values 0 to 7?=C2=A0 Where does this restriction a= rise
from?=C2=A0 It is because of some protocol element?
KT> There is text further in the section to indicated that = these ranges/values are implementation-specific. Historically, the 8 values= have come from the MPLS EXP bits.
=C2=A0

=C2=A0 =C2=A0If the local configuration does not specify any explicit forwa= rding
=C2=A0 =C2=A0information for an entry of the array, then this entry is fill= ed with
=C2=A0 =C2=A0the same information as entry 0 (i.e. the IGP shortest path).<= br>
=C2=A0 =C2=A0If the SR Policy mapped to an entry of the array becomes inval= id,
=C2=A0 =C2=A0then this entry is filled with the same information as entry 0= .=C2=A0 When
=C2=A0 =C2=A0all the array entries have the same information as entry0, the=
=C2=A0 =C2=A0forwarding entry for N is updated to bypass the array and poin= t
=C2=A0 =C2=A0directly to its outgoing interface and next-hop.

I can't tell how much of this is supposed to be protocol specification = and
how much an illustrative example.=C2=A0 Is A(0) always the IGP shortest pat= h?
Are these protocol requirements to fall back to the IGP shortest path when<= br> an entry is otherwise unpopulated or the associated SR Policy becomes
invalid?

KT> The specifics are for i= llustration purposes. Most of these are policy knobs/options.
=C2= =A0

Section 8.8.2

=C2=A0 =C2=A0The steering preference is first based on the highest color va= lue and
=C2=A0 =C2=A0then CO-dependent for the color.=C2=A0 [...]

This seems to contradict what I assumed earlier about the "highest col= or"
rule being a tiebreaker, e.g., the word "preference" is used here= .=C2=A0 Is it
actually intended to be a deliberately configured priority/preference
scheme?=C2=A0 If so, that would seem to require some wide-ranging reworking=
throughout the document.

KT> There i= s the color that is in the identification of an SR Policy - (color, endpoin= t). This does not get into any tiebreaker or selection logic. All that (sec= 2.9) is about the selection of a candidate path within an SR Policy. Then = there is the color value signaled via the Color Extended community on the B= GP routes and here, we have the preference for higher color when the route = is advertised with multiple colors tagged to it.
=C2=A0

Section 9.3

=C2=A0 =C2=A0the most appropriate alternative for the active candidate path= .=C2=A0 A
=C2=A0 =C2=A0fast re-route mechanism MAY then be used to trigger sub 50msec=
=C2=A0 =C2=A0switchover from the active to the backup candidate path in the=
=C2=A0 =C2=A0forwarding plane.=C2=A0 Mechanisms like Bidirectional Forwardi= ng Detection
=C2=A0 =C2=A0(BFD) MAY be used for fast detection of such failures.

Why is the specific 50msec value important here?=C2=A0 Is there some other<= br> requirement that imposes it?

KT> Thi= s comes from "typical" expectations from fast-reroute mechanisms.=
=C2=A0

Section 10

I think we also want to mention the security considerations of several more=
documents, including (but not limited to)
draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986.
=

KT> Ack on the three RFCs, but convince= d about the draft-ietf-idr-segment-routing-te-policy since that depends on = this and not the other way around.
=C2=A0

Section 15.2

I agree with John that draft-ietf-idr-segment-routing-te-policy must be
classified as a normative reference.

It also seems that RFC 7752 should be classified as normative, as we
incorporate its definition for the semantics of several of the segment type=
descriptions.

KT> Ack
=C2= =A0


NITS

Section 1

=C2=A0 =C2=A0Segment Routing Policy (SR Policy) [RFC8402] is an ordered lis= t of
=C2=A0 =C2=A0segments (i.e. instructions) that represent a source-routed po= licy.

/Segment/A Segment/

KT> Ack
=C2=A0

=C2=A0 =C2=A0The headend node is said to steer a flow into a SR Policy.=C2= =A0 The
=C2=A0 =C2=A0packets steered into an SR Policy carry an ordered list of seg= ments
=C2=A0 =C2=A0associated with that SR Policy.=C2=A0 [...]

In a certain sense this can be read as saying that the packets that "c= arry
an ordered list of segments" are the ones prior to being steered into = an SR
policy, which would make this statement not true.=C2=A0 Perhaps we want to = say
"after being steered into an SR Policy, packets carry an ordered list = ..."?
(I also went back and forth with myself about whether "packets ... car= ry"
implies in the payload or not.=C2=A0 I settled on "not" but make = this note just
in case I am missing an aspect of that question.)

=
KT> Ack. Will rephrase.
=C2=A0

Section 2

=C2=A0 =C2=A0An SR Policy is a framework that enables the instantiation of = an
=C2=A0 =C2=A0ordered list of segments on a node for implementing a source r= outing

It's easy to read this as saying that all of the segments in the list instantiated on the single node in question, which I assume is not the
intent.=C2=A0 Probably the easiest way to aid readability here is to split = the
sentence up into multiple smaller sentences that are easier to parse.

KT> Will rephrase.
=C2=A0
=

Section 2.2

=C2=A0 =C2=A0A dynamic candidate path expresses an optimization objective a= nd a
=C2=A0 =C2=A0set of constraints.=C2=A0 The headend (potentially with the he= lp of a PCE)
=C2=A0 =C2=A0computes the solution Segment-List (or set of Segment-Lists) t= hat
=C2=A0 =C2=A0solves the optimization problem.

I'd suggest computes the solution/computes a solution/ for genericity.<= br>

KT> Ack.
=C2=A0
A stateful PCE might end up computing a path that is not the optimal one fo= r
this specific optimization problem, due to a desire to cooperate with other=
paths in the network, and the "Min-Metric with margin and maximum numb= er of
SIDs" objective in draft-filsfils-spring-sr-policy-considerations does= n't
even have a guaranteed unique best solution.

Section 2.5

=C2=A0 =C2=A0When provisioning is via configuration, this is an implementat= ion's
=C2=A0 =C2=A0configuration model-specific unique identifier for a candidate= path.
=C2=A0 =C2=A0The default value is 0.

I'm having a lot of trouble parsing this.=C2=A0 Did we perhaps mean to = hyphenate
as "configuration-model-specific"?

KT> Ack
=C2=A0

Section 2.13

=C2=A0 =C2=A0The SR Policy POL1 is identified by the tuple <headend, col= or,
=C2=A0 =C2=A0endpoint>.=C2=A0 It has two candidate paths CP1 and CP2.=C2= =A0 Each is
=C2=A0 =C2=A0identified by a tuple <protocol-origin, originator, discrim= inator>.

I suggest (for the last sentence) "identified within the scope of POL1= "

KT> Ack
=C2=A0

=C2=A0 =C2=A0forwarding instantiation of SR policy POL1.=C2=A0 Traffic stee= red on POL1
=C2=A0 =C2=A0is flow-based hashed on Segment-List <SID11...SID1i> wit= h a ratio
=C2=A0 =C2=A0W1/(W1+W2).

If I read "ratio" I would instinctively think of the ratio of (tr= affic on
segment list 1)/(traffic on segment list 2), as opposed to the proportion o= f
all traffic, that would be measured as the indicated W1/(W1+W2).

KT> Ack. s/ratio/proportion
=C2=A0

Section 3

=C2=A0 =C2=A0The attached domain topology may be learned via IGP, BGP-LS or=
=C2=A0 =C2=A0NETCONF.

=C2=A0 =C2=A0A non-attached (remote) domain topology may be learned via BGP= -LS or
=C2=A0 =C2=A0NETCONF.

I think these are both probably not exhaustive lists, so "e.g." o= r similar
may be appropriate.

KT> Ack.
=C2=A0

Section 4

=C2=A0 =C2=A0Type C: IPv4 Prefix with optional SR Algorithm:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The headend is required to resolve the sp= ecified IPv4 Prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Address to the SR-MPLS label correspondin= g to a Prefix SID
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0segment (as defined in [RFC8402]).=C2=A0 = The SR algorithm (refer to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.1.1 of [RFC8402]) to be used MA= Y also be provided.

=C2=A0 =C2=A0Type D: IPv6 Global Prefix with optional SR Algorithm for SR-M= PLS:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In this case, the headend is required to = resolve the specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 Global Prefix Address to the SR-MPLS= label corresponding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to its Prefix SID segment (as defined in = [RFC8402]).=C2=A0 The SR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Algorithm (refer to Section 3.1.1 of [RFC= 8402]) to be used MAY

These are effectively just the IPv4 and IPv6 incarnations of the same
underlying procedure, right?=C2=A0 Can't we minimize the diff between t= he
paragraphs further?

KT> Ack
=C2=A0

Section 5.1

=C2=A0 =C2=A0Additionally, a Segment-List MAY be declared invalid when:

We probably want another word here ("both"?), to specify how the = two
conditions are combined.

KT> Ack - w= ill rephrase.
=C2=A0

Section 5.2

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy'= ;s tail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, = the
=C2=A0 =C2=A0headend MAY send path computation request to a PCE supporting = PCEP
=C2=A0 =C2=A0extension specified in [RFC8664].

missing article ("the PCEP extension").=C2=A0 I forget if it shou= ld be
"extensions" plural.

KT> A= ck
=C2=A0

Section 8.7

=C2=A0 =C2=A0Finally, headend H MAY be configured with a local routing poli= cy
=C2=A0 =C2=A0which overrides any BGP/IGP path and steer a specified packet = on an

singular/plural mismatch -- s/steer/steers/

=
KT> Ack.

Thanks,
Ketan
=C2=A0
--0000000000008fd70305d838bcd4-- From nobody Thu Feb 17 07:52:55 2022 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 725083A0A87; Thu, 17 Feb 2022 07:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 uxOW-vVI9Hx0; Thu, 17 Feb 2022 07:52:44 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858EA3A098C; Thu, 17 Feb 2022 07:52:44 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id d26so1931388vsh.0; Thu, 17 Feb 2022 07:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hVDiSLUmYptC/wZCW7Qm6LgHNzvp5lJnFJvUDS6GCXE=; b=YavcJGvRwFkDY6Jr073bRjVlhHojAGezhoCRjVWiKWoNwPo0K5kY7U0jT91yagbh1W +G3X8ihRNxDMjtodeKP9K7KsF5x+qDJ482jSMHT/N/gEXJvQR5zleQ0bmj4TppV0ht4E xPwvSb6Fq5+nvWtqvdYkN7y0I4MHvAOmd3CHDv0FMI2xGnbZpFeU927tRxW51OaOZml+ hg5obcq8cJPmVaqZY3xtHP2MhWA8bcjEC0Fsy8L03pWHeuK/Z28RB7YfYXwzKuN6AmNx SaUQdKmsmizn3qi4E34o4S3JR2tKBwQ1QobyMb7m6C5WYiA15T+IyMmtrAJkk+UkNAeT a5lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hVDiSLUmYptC/wZCW7Qm6LgHNzvp5lJnFJvUDS6GCXE=; b=pMHrJUgnl1Ph2gEg04OmD89s2+1cklJkJa2yZcMNAVl8Cf90eJHF0tefDBB2pgwasN W+tydW4+P/F+zzKR3QE9WGvBPvVvsBaYUtoNyj+3UeHwVac+FfpYdgi+XZiaSyFKCgni pRBhc0Fncc43o3v0y2YlOhz1o0HPgZvfgZm1qombE+Zy71jAFLf8sjGD/h8hHbfPWye7 xDGpw1pVHGW1eYX+unKTVIxNKiNwGlhxv+4FHWmqc5H056b3FLHU5D6qOvnh6iEra5pu iK8imaKFKW/sGPFjkaCBayF7LN57eowY6hwl+EvGsZfgxGFfVJCXvy6pZnZEtxyuopXl t3gQ== X-Gm-Message-State: AOAM532crzmdObyYfqjCeuvwsCT/iDrl+DG+MmMeD3pZ4Y9ALepEEwuI 9Ile4xv7bAo+BUBVv2q97QBxUSpVAb/KDuKVTgqTMPCA X-Google-Smtp-Source: ABdhPJwS+K2AWIa42QC4ppuYpfqI+WQ5mpej+CXQbtKkCHVV9mKfG9IGfns+WSZ6Do/o8m3Kfp+2P+8th61jbtNOiX4= X-Received: by 2002:a67:d317:0:b0:31b:9b12:dd6b with SMTP id a23-20020a67d317000000b0031b9b12dd6bmr1410450vsj.27.1645113163272; Thu, 17 Feb 2022 07:52:43 -0800 (PST) MIME-Version: 1.0 References: <164507977558.18479.8326591988168272569@ietfa.amsl.com> In-Reply-To: <164507977558.18479.8326591988168272569@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 21:22:30 +0530 Message-ID: To: Murray Kucherawy Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000b656b505d838c1b8" Archived-At: Subject: Re: [spring] Murray Kucherawy's No Objection on draft-ietf-spring-segment-routing-policy-17: (with COMMENT) 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, 17 Feb 2022 15:52:53 -0000 --000000000000b656b505d838c1b8 Content-Type: text/plain; charset="UTF-8" Hi Murray, Thanks for your review and your comments. Please check inline below for responses. On Thu, Feb 17, 2022 at 12:06 PM Murray Kucherawy via Datatracker < noreply@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Cullen Jennings for his ARTART review. > > I'm hardly an expert on the technologies described here, but most of the > SHOULDs I ran into left me wondering why they aren't MUSTs. There's no > obvious > (to me) implementation guidance present about when one might legitimately > do > something other than what the SHOULD says. > KT> At the risk of getting things wrong in generalizing this, there are deployment scenarios/designs where operators and vendors want flexibility in having different behaviors than what would be 'a typical deployment design". The use of SHOULD is to provide guidance while allowing flexibility where needed. > > Should Section 2.1 stipulate that symbolic names, if used, should be > unique? > KT> We do cover the uniqueness aspect, but there was no need to stipulate it as this is something entirely operator controlled and determined by their requirements. > > Thanks for the attention to detail in Section 12. > Thanks, Ketan --000000000000b656b505d838c1b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray,

Thanks for = your review and your comments. Please check inline below for responses.


On Thu, Feb 17, 2022 at 12:06 PM Murray Kucherawy via Data= tracker <noreply@i= etf.org> wrote:
Murray Kucherawy has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Cullen Jennings for his ARTART review.

I'm hardly an expert on the technologies described here, but most of th= e
SHOULDs I ran into left me wondering why they aren't MUSTs.=C2=A0 There= 's no obvious
(to me) implementation guidance present about when one might legitimately d= o
something other than what the SHOULD says.

<= div>KT> At the risk of getting things wrong in generalizing this, there = are deployment scenarios/designs where operators and vendors want flexibili= ty in having different behaviors than what would be 'a typical deployme= nt design". The use of SHOULD is to provide guidance while allowing fl= exibility where needed.
=C2=A0

Should Section 2.1 stipulate that symbolic names, if used, should be unique= ?

KT> We do cover the uniqueness asp= ect, but there was no need to stipulate it as this is something entirely op= erator controlled and determined by their requirements.
=C2=A0

Thanks for the attention to detail in Section 12.

=
Thanks,
Ketan
=C2=A0
--000000000000b656b505d838c1b8-- From nobody Thu Feb 17 10:13:33 2022 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 B1E483A0E4E; Thu, 17 Feb 2022 10:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 I4lsuBLjoo5F; Thu, 17 Feb 2022 10:13:22 -0800 (PST) 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 739A83A0E3A; Thu, 17 Feb 2022 10:13:10 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id m24so7223508vsp.7; Thu, 17 Feb 2022 10:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=93DVN5GMtRJ6Lplwium143pTqQDX8aCLtJTkf+fA5n8=; b=E4+zAfY73gVqP4MIQ+RFFJShPdgOQ3XLRyKQk1RMRbrkiyXLli72OpuWabyj2hcspL enIlNDa5o8GO1+keO32ohbzHBRAsmJ1pECmYISY/609fRnoM2/2MDm4xQw3sfUlv/lnU 3JXuuDABVja4Cilrn9GJMRVQOvmZc5X3nuofG+oJlmcakp32ImZJlP3+riyTuMrkEEic Ayzc2UhxFmjDSmDD/42XyEfykCODEamD5OueV6RaTziwyHfMo/x3ChG6IPYrr6dRF596 Gpeo6A+BTGduxaFXTAB/UoAGpDQnK/t3VG1MDWkqscY0q/mQB3cZCAlG4FO8O0NLYJ0r SXag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=93DVN5GMtRJ6Lplwium143pTqQDX8aCLtJTkf+fA5n8=; b=QnowjeOGPiPwRrP1QVFUS5ozypKI7dO4Fv46A02zNJ0pnb/MJATe1JHxEf7qFKSIJl bkpvmshaeHJ95BDCOMUNOwpKcXftyWuNHtUTXGs+ugwpqUNy/XhMHcz3iaDHqLBn/HWF c/t+6YFmv2BnsUdvetpl9Jr4n60U+5WRRj3689Gac7TkRxXOUYaAKUIHm/LCTUTe6Qoi LlaPSFdZj4IBUpwcQ9ZRvif7OpIjE72LqxFjP7A7g+3/phVsPQosuhX0cArBM2LfNBAg ms3AeQfZ5qtXBkAkkFygnRLndK501Y+MGPqvZjj8kuGumuvPsyca28W+V1UOGdAvN8KQ f6Jw== X-Gm-Message-State: AOAM530X6sssIl3VQvNTxnE/zdN0iS+/wbhyEdA/cNvKk2HKTl7vIR7r KRd/vHJyBvbh+Iy8tkbatQc4nSRlvQCPZPkprR8= X-Google-Smtp-Source: ABdhPJwiZcolR5Io43DroUI5XJt0vQE3vTBvU507KOYw89kA/cFqyOj7jfNf0pzgKOj0L8qXOWI09IGcQN/hb/WOhvA= X-Received: by 2002:a05:6102:3591:b0:310:ef5d:d2be with SMTP id h17-20020a056102359100b00310ef5dd2bemr1746359vsu.34.1645121589383; Thu, 17 Feb 2022 10:13:09 -0800 (PST) MIME-Version: 1.0 References: <164510957258.2791.18164721824342351003@ietfa.amsl.com> In-Reply-To: <164510957258.2791.18164721824342351003@ietfa.amsl.com> From: Ketan Talaulikar Date: Thu, 17 Feb 2022 23:42:57 +0530 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com, Carlos Bernardos Content-Type: multipart/alternative; boundary="000000000000f2929a05d83ab799" Archived-At: Subject: Re: [spring] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-spring-segment-routing-policy-17=3A_=28with_COMMENT=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: Thu, 17 Feb 2022 18:13:25 -0000 --000000000000f2929a05d83ab799 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for your review and your comments. Please check inline below for responses. On Thu, Feb 17, 2022 at 8:23 PM =C3=89ric Vyncke via Datatracker < noreply@ietf.org> wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. I am afraid that, due to > lack of > available time, I only quickly reviewed this document and I will rely on > the > INT directorate review. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Jim Guichard for the shepherd's write-up including the > section about the WG consensus and discussion. > > Thanks also to Carlos Bernardos for the INT directorate review dated 13th > of > March. I have also seen that authors are in an email discussion with > Carlos and > I appreciate that Carlos was acknowledged in the acknowledgment section. > See > < > https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-polic= y-16-intdir-telechat-bernardos-2022-02-13/ > >. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > Generic comment: this document uses the term "headend", which is not used > in > other SRv6-related documents. Not really important though. > KT> It is used in RFC8402 and is base SR - i.e. not SRv6 specific. We'll try to explain that term when first used in the abstract similar to how it is in the Introduction section. > > ## Abstract > > Mostly cosmetic, but the abstract would benefit from being more concise a= nd > straight to the point. > KT> Will rephrase. We have some text trying to give a brief overview of what SR Policy based on previous feedback during WG phase. > > ## Section 2.1 > > Please use "::" rather than "::0" to respect RFC 5952. Also for section > 8.8.1 > KT> Ack. > > I also share the concern of other AD for an ASCII-only symbolic name. > KT> Please see my response to other ADs. > > ## Section 2.3 > > Why are the values 10, 20, and 30 only RECOMMENDED in a standard track > document > and are not a MUST ? KT> It cannot be a MUST since operators want the flexibility to determine the precedence of the source protocols/mechanisms that they use. > If this is about distance, then let's be clear and name > this value as "distance" or "origin-precedence". > KT> "origin-precedence" is indeed a good suggestion and it is unfortunate that this didn't come earlier in the WG process. I am ok to change it, but it will have repercussions not only on this document but in other protocol specifications as well. Let me hold off from making this change for some time to give chance if anyone has concerns and if not, I will make the change in an upcoming version. > > ## Section 2.13 > > Rather than using 1.1.1.1 or 2.2.2.2 please use the documentation > addresses for > IPv4 / IPv6. Same reasoning for using the example ASN. > KT> Ack > > # NITS > > Probably a topic beaten to death but isn't "ISIS" spelled "IS-IS" ? > KT> Ack > > Usually, "i.e." is always followed by a "," > KT> Ack. Thanks, Ketan --000000000000f2929a05d83ab799 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Thanks for yo= ur review and your comments. Please check inline below for responses.
=


On Thu, Feb 17, 2022 at 8:23 PM =C3=89ric Vyncke via Datatr= acker <noreply@iet= f.org> wrote:
=C3=89ric Vyncke has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. I am afraid that, due to lac= k of
available time, I only quickly reviewed this document and I will rely on th= e
INT directorate review.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jim Guichard for the shepherd's write-up including th= e
section about the WG consensus and discussion.

Thanks also to Carlos Bernardos for the INT directorate review dated 13th o= f
March. I have also seen that authors are in an email discussion with Carlos= and
I appreciate that Carlos was acknowledged in the acknowledgment section. Se= e
<https://datatracker.ietf.org/doc/review-ietf-spring-segm= ent-routing-policy-16-intdir-telechat-bernardos-2022-02-13/>.

I hope that this helps to improve the document,

Regards,

-=C3=A9ric

Generic comment: this document uses the term "headend", which is = not used in
other SRv6-related documents. Not really important though.
=

KT> It is used in RFC8402 and is base SR - i.e. not = SRv6 specific. We'll try to explain that term when first used in the ab= stract similar to how it is in the Introduction section.
=C2=A0

## Abstract

Mostly cosmetic, but the abstract would benefit from being more concise and=
straight to the point.

KT> Will reph= rase. We have some text trying to give a brief overview of what SR Policy b= ased on previous feedback during WG phase.
=C2=A0

## Section 2.1

Please use "::" rather than "::0" to respect RFC 5952. = Also for section 8.8.1

KT> Ack.
=C2=A0

I also share the concern of other AD for an ASCII-only symbolic name.

KT> Please see my response to other ADs.<= /div>
=C2=A0

## Section 2.3

Why are the values 10, 20, and 30 only RECOMMENDED in a standard track docu= ment
and are not a MUST ?

KT> It cannot be a= MUST since operators want the flexibility to determine the precedence of t= he source protocols/mechanisms that they use.
=C2=A0
If this is about distance, then = let's be clear and name
this value as "distance" or "origin-precedence".

KT> "origin-precedence" is indee= d a good suggestion and it is unfortunate that this didn't come earlier= in the WG process. I am ok to change it, but it will have repercussions no= t only on this document but in other protocol specifications as well. Let m= e hold off from making this change for some time to give chance if anyone h= as concerns and if not, I will make the change in an upcoming version.
=C2=A0

## Section 2.13

Rather than using 1.1.1.1 or 2.2.2.2 please use the documentation addresses= for
IPv4 / IPv6. Same reasoning for using the example ASN.

KT> Ack
=C2=A0

# NITS

Probably a topic beaten to death but isn't "ISIS" spelled &qu= ot;IS-IS" ?

KT> Ack
= =C2=A0

Usually, "i.e." is always followed by a ","

KT> Ack.

Thanks,
=
Ketan
=C2=A0
--000000000000f2929a05d83ab799-- From nobody Thu Feb 17 10:19:47 2022 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 5449D3A0E60; Thu, 17 Feb 2022 10:19:46 -0800 (PST) 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.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164512198606.15573.10255828849393873414@ietfa.amsl.com> Date: Thu, 17 Feb 2022 10:19:46 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-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, 17 Feb 2022 18:19:46 -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 : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-18.txt Pages : 39 Date : 2022-02-17 Abstract: Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into a SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC8402 as it details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-18 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Feb 17 10:22:15 2022 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 8ACA23A0E31; Thu, 17 Feb 2022 10:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.904 X-Spam-Level: ** X-Spam-Status: No, score=2.904 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, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=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 CfeWNlTF2-as; Thu, 17 Feb 2022 10:22:07 -0800 (PST) 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 953EE3A0E58; Thu, 17 Feb 2022 10:22:06 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id d11so3243915vsm.5; Thu, 17 Feb 2022 10:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1V2Ve/QNxO39kjiqAkZZibZoueokvwtg9iREvLt8Rv8=; b=nMRmbJKcENq7fCiFvSO4yJtSToT/20zv2F41e+yOXP9H5eAgK/zviiKefTianCq0Rz RTSZbjqglDXqEd3ZKFGe3QJrEo6jt4TvcgxNRKJQPr0IKVH2CBf1cykytsI4myfrH70V kyl/Sr9l0D9GSNhuvphnXTapMBywk/7geTeFKkXiqIjIEowBlhxQmzjupBpt9lvmr2vj dFmkhAGcFc9aSzeS0vRvbNqWSKD3kuA6VAfmW/2ywnqqT6BIOxHpWHBHpRqG1HYNHM8a 1CeoCDiZr/29xg9p6wt2xXGTGNpaQwAWHRDJRi6G+WzZCd11yoxcoh0YLk/4tKM4jV2U Xf2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1V2Ve/QNxO39kjiqAkZZibZoueokvwtg9iREvLt8Rv8=; b=AOGd7vsrfAVyn+PHN3R7TZuv1KGBkPuqqHeVLe2EOoB73LHBkkEYUTPE8kFOleMZuP 55qNHcH7N+ti9UrZ5oKM/E07O8geN9DMjp+fozUwi/GQgKokdKBnBFpd+YCFhF36afKN PPWPahaKQEV/8nn2/VbAQWzvHiNcsYXDCFE9ow6A2svgEnpfw+PZWz+gmCPyzDZwMmPu UxAzY2SzA0ZUacHT+ZWr+a21H6HrIjOEngK/iblJ03sDQvsM7rZayqHTvv0aDUrOXEMs pEwwmZVHsBqbGV6HKQVQNuf0zT82qNJdPYbEfEV3fejBw+coYQqIpiXBINVBA4A1uUrm KAeA== X-Gm-Message-State: AOAM530iHpHc4E2j3xhNIZ/R0UhT/knQgy6wUiIMQSRxx12J7Gc83j4e x2oWsAXqvknrauRUoAz7NKaiD5/0Ytp0xmBti+q1gN3thHg= X-Google-Smtp-Source: ABdhPJwEsel3sVCoq8A3LweK+gMvGV+E9frF8V+/Qlr/WhG1y+r/yO2moXll2pWRa3dhY7uht+w7zKBIwGCroUiizFs= X-Received: by 2002:a67:d317:0:b0:31b:9b12:dd6b with SMTP id a23-20020a67d317000000b0031b9b12dd6bmr1775112vsj.27.1645122125072; Thu, 17 Feb 2022 10:22:05 -0800 (PST) MIME-Version: 1.0 References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Thu, 17 Feb 2022 23:51:52 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000e08d9905d83ad760" Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 18:22:13 -0000 --000000000000e08d9905d83ad760 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, We've just posted an update to address the comments raised by you and other ADs: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-18 Thanks, Ketan On Thu, Feb 17, 2022 at 9:21 PM Ketan Talaulikar wrote: > Hi Ben, > > Thanks for your detailed review and your comments/inputs. Please check > inline for responses. > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-spring-segment-routing-policy-17: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions= / >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-polic= y/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> (1) I may just be misunderstanding things, but I'd like to pull on a >> thread >> in =C2=A78.4 a bit more. We say that the headend H learns a BGP route t= hat >> has a >> VPN label V, but then the following procedures seem to say that we >> install a >> route on the appropriate SR Policy P and that when we receive a packet >> that >> matches the route in question, push a label stack including the VPN labe= l, >> and send the resulting packet out. > > > KT> Note that we are sending the packet to the selected BGP NH (i.e. > egress PE) that advertised the route. The SR Policy is enabling the packe= ts > to traverse a path that is different from (perhaps) the best-effort IGP > routing. > > >> Nowhere do we say to check the VPN >> status of the incoming packet, > > > KT> That is the ingress part of the forwarding entry which maps the > incoming traffic over a customer interface to their specific VPN context > and then performs a lookup in their VPN specific table. This all is > unchanged. > > >> so this seems like it would open a hole in >> the VPN by allowing "arbitrary" incoming traffic (not marked as specific >> to >> V) to enter that VPN. Is the label V filling some other role than >> identifying a specific VPN of many VPNs that could run along the route >> R/r? >> (This is the only instance of the phrase "VPN label" in the document, an= d >> no >> reference is given, so I'm relying heavily on instinct to ascertain the >> intent here.) >> > > KT> I hope my responses clarified that the only thing that is changed her= e > by the steering over the SR Policy is the path taken through the network = to > get to the egress PE. Rest is as today. And yes, of course, we have the > ability to indicate the need for such steering via the matching Color > Extended community to the BGP route. > > >> >> (2) The security considerations says that this document does not define >> any >> new protocol extensions and (accordingly) does not introduce any further >> security considerations. The first part of this seems false, not least >> since we define the meaning of the "CO" bits in the Color Extended >> Community. I'm pretty sure that makes the second part also false, and w= e >> need to discuss the security considerations relating to imposing SR >> Policies >> based only on color and not next-hop. Alvaro has also noted additional >> aspects where security considerations are missing. >> > > KT> Ack. We will add text in the security consideration sections for the > CO steering modes. > > >> >> (3) The Discriminator as defined in =C2=A72.5 does not seem wide enough = to be >> able to provide the needed properties. Some later clarification in =C2= =A72.6 >> implies that the definition in =C2=A72.5 is incomplete and the width is >> actually >> appropriate, but in either case =C2=A72.5 seems inadequate in its curren= t form. >> (Details in the COMMENT.) >> > > KT> 32 bit is wide enough and please see further response below. > > >> >> (4) Section 2.11 contains the statement, "A valid SR Policy is >> instantiated >> in the forwarding plane." >> >> Is this a statement of fact (i.e., a consequence of the definition of >> "valid") or a mandate for something (e.g., the headend) to take action t= o >> make it so? Given that the point of SR is to be stateless on nodes othe= r >> than the headend, I suspect the former, but if we are relying on the >> headend >> (or some other entity) to take action to ensure this is the case, that >> needs >> to be a clearly stated normative requirement. >> > > KT> The validity of a candidate path and as an extension, the SR Policy i= s > discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its > constructs are instantiated in the forwarding plane. > > >> >> (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." >> There's nothing in the IANA registry for SAFI >> (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml) >> about >> LISP, and RFC 6830 doesn't talk about SAFI. What is this referring to? >> > > KT> Ack - there is no SAFI in LISP and the reference was meant to be for > routing of both IPv4 and IPv6 packets with LISP. Will fix this. > > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> There's a lot of this document that feels like just some informational >> discussion of "here are some things that many people do", "here are some >> possible things you can do with SR", etc.. There are also a small handf= ul >> of places in the document that look to actually be specifying parts of >> protocol behavior (I suspect that John has already identified them in hi= s >> enumeration), and the overall impression ends up being a bit jumbled, >> like there are a bunch of topics stuck together without an overarching >> theme. >> I think the overall content would be more valuable if divided into a tig= ht >> "protocol specification" portion that could stay at proposed standard, >> plus >> an informational "architecture details" document that contains the >> in-depth exposition that didn't make it into 8402. >> >> This draft would benefit greatly from a terminology section. I note in >> the >> section-by-section comments several places where a term is first used >> without sufficient background/definition, leaving the matter at hand >> underspecified for the reader. >> >> Section 2 >> >> An SR Policy is a framework that enables the instantiation of an >> ordered list of segments on a node for implementing a source routing >> >> Really, an SR policy is a *framework*? I thought an SR policy was a >> specific instantiation of a list of segments, or at least that's what I'= m >> getting from RFC 8402. Perhaps we should say that the general concept o= f >> SR >> Policy provides a framework? >> > > KT> Ack. Will rephrase. > > >> >> Section 2.1 >> >> An SR Policy MUST be identified through the tuple > endpoint>. In the context of a specific headend, an SR policy MUST >> be identified by the tuple. >> >> These two MUSTs appear to be in (nominal) conflict. Maybe start the fir= st >> one with "absent further context" or "absent the context of a known >> headend >> node"? >> > > KT> It is not "absence of context" but "within the context of a specific > headend". > > >> >> The headend is the node where the policy is instantiated/implemented. >> The headend is specified as an IPv4 or IPv6 address and is expected >> to be unique in the domain. >> >> This is the first instance of the word "domain" in this document. I >> suggest >> using the introduction to introduce what is meant by the word, even if >> just >> by reference to RFC 8402. >> > > KT> Ack. It should be SR Domain. > > >> >> An implementation MAY allow the assignment of a symbolic name >> comprising printable ASCII [RFC0020] characters (i.e. 0x20 to 0x7E) >> to an SR Policy to serve as a user-friendly attribute for debugging >> and troubleshooting purposes. [...] >> >> I agree with the other ADs that limiting to US-ASCII is not actually >> user-friendly for many users, and that the likelihood of some >> implementations not properly enforcing such a limitation to be high. >> (Likewise for the other places where symbolic names are admitted.) >> > > KT> Please see the response to the other reviews on this point. > > >> >> Section 2.2 >> >> A dynamic candidate path expresses an optimization objective and a >> set of constraints. [...] >> >> Down in =C2=A75.2 when we discuss validation procedures for dynamic cand= idate >> paths, we say that the optimization problem is solved "for either the >> SR-MPLS or the SRv6 data-plane as specified". Does the data plane need = to >> be specified as part of the dynamic candidate path itself? >> > > KT> Yes. > > >> >> Section 2.3 >> >> in Section 2.9. The table below specifies the RECOMMENDED default >> values of Protocol-Origin: >> >> I feel like it would be useful to provide some justification for why the >> recommended default behavior prefers BGP SR configuration over PCEP, eve= n >> if >> that justification is just "we need to have a clear ordering and this on= e >> is >> arbitrary". >> > > KT> Ack. Will clarify that. > > >> >> Section 2.4 >> >> o Node Address : represented as a 128-bit value. IPv4 addresses >> MUST be encoded in the lowest 32 bits, and the high-order bits >> MUST be set to zero. >> >> Its application in the candidate path selection is described in >> Section 2.9. >> >> The tie-breaker procedure for path selection described in =C2=A72.9 seem= s to >> always prefer IPv4 originators over IPv6 ones (by virtue of preferring t= he >> smaller value). I guess if we wanted to change that to prefer IPv6 we >> have >> the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped unicast) >> from BCP 153, but it's a bit hard to justify either of those as >> appropriate >> on technical grounds, and since this is just a tie-breaker and the >> Preference is explicitly preferred, it seems like this is probably "good >> enough" as-is. >> > > KT> Ack. As clarified in a recent text update in v17, preference is the > key parameter really. > > >> >> Section 2.5 >> >> The Discriminator is a 32-bit value associated with a candidate path >> that uniquely identifies it within the context of an SR Policy from a >> specific Protocol-Origin as specified below: >> >> What are the constraints that underlie the 32-bit requirement here? >> It looks like some of the scenarios are going to involve uncoordinated >> (random) assignment of these discriminator values (e.g., with the BGP >> distribution mechanism, when coming from different BGP peers), and the >> birthday-bound collision probability is not negligible for this few bits= . >> That, in turn, calls into question the "uniquely identifies" property >> being >> claimed. Or is there some other property that means that only >> discriminators from a single issuer will ever need to be compared with >> each >> other (making the allocation "coordinated"), such as being additionally >> associated with the originator? >> If my initial analysis was incorrect and these are indeed allocated in a >> "coordinated" fashion, would it be typical/expected for the allocation t= o >> occur by incrementing a local counter on the originator? In some >> situations >> such allocation by counter can have security considerations, which >> draft-gont-numeric-ids-sec-considerations attempts to cover. >> > > KT> The discriminator is scoped to a particular originating node for the > candidate path and as such, there is no requirement for coordination acro= ss > sources/nodes. Therefore, 32-bit is more than sufficient. > > >> >> Section 2.8 >> >> A candidate path is usable when it is valid. A common path validity >> criterion is the validity of any of its constituent Segment-Lists. >> The validation rules are specified in Section 5. >> >> This document claims to target Proposed Standard status; are we really >> content to say only that this is "a common" criterion? Even when we als= o >> go >> on to flat-out state "the validation rules are specified [below]"? >> > > KT> We will change this to introduce the word RECOMMENDED. There are > deployments where an operator might need a local policy to declare the > candidate path invalid when the number of valid SLs drops below a certain > threshold (for b/w or load-balancing considerations). > > >> >> Section 2.9 >> >> The candidate path selection process operates primarily on the >> candidate path Preference. A candidate path is selected when it is >> valid and it has the highest preference value among all the candidate >> paths of the SR Policy. >> >> Should this be "among all the valid candidate paths"? A path that's >> invalid >> is still invalid, even if it has the highest preference value. >> > > KT> Ack - will clarify this. > > >> >> 2. If specified by configuration, prefer the existing installed >> path. >> >> Does "if specified by configuration" refer to the act of applying this >> rule >> at all, or that the existing installed path was one specified by >> configuration? >> > > KT> The existing installed path. The rationale was that in some deploymen= t > designs an operator may not want to disturb/churn an active and > valid/working path that has been installed in the forwarding. > > >> >> Section 2.11 >> >> The fraction of the flows associated with a given Segment-List is w/ >> Sw, where w is the weight of the Segment-List and Sw is the sum of >> the weights of the Segment-Lists of the selected path of the SR >> Policy. >> >> Thank you for stating this clearly! >> >> Section 3 >> >> o TE Link Attributes (such as TE metric, Shared Risk Link Groups, >> attribute-flag, extended admin group) [RFC5305] [RFC3630]. >> >> Is RFC 5329 applicable here as well? >> > > KT> Yes, will add that. Thanks. > > >> >> Section 4 >> >> Type E: IPv4 Prefix with Local Interface ID: >> This type allows identification of Adjacency SID or BGP Peer >> Adjacency SID (as defined in [RFC8402]) SR-MPLS label for >> point-to-point links including IP unnumbered links. The >> headend is required to resolve the specified IPv4 Prefix >> Address to the Node originating it and then use the Local >> Interface ID to identify the point-to-point link whose >> adjacency is being referred to. The Local Interface ID link >> descriptor follows semantics as specified in [RFC7752]. This >> >> The phrase "local interface ID" does not appear in RFC 7752 (and even >> "local >> interface" appears just once"; please use terminology actually present i= n >> the referred-to document to clarify what is being referenced. >> > > KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn > references RFC5307 which in turn RFC4202. We use RFC7752 since it covers > and explains the use of the various link descriptors that we use for > various segment types. > > >> >> Section 4.1 >> >> When steering unlabeled IPv6 BGP destination traffic using an SR >> policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit >> Null Label Policy is processed as specified in >> [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an >> >> It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced document= . >> > > KT> Ack. Will fix. > > >> >> Section 5.1 >> >> The computation/logic that leads to the choice of the Segment-List is >> external to the SR Policy headend. The SR Policy headend does not >> compute the Segment-List. The SR Policy headend only confirms its >> validity. >> >> Does the headend actually have to confirm validity? Is it okay to just >> trust the controller and blindly use what is provided? >> > > KT> At least the first segment needs to be validated from a resolvability > perspective. The subsequent segments depend on how (i.e., using what > segment types) the controller has signalled the path to the headend. If i= t > is indicated by just referring to a Prefix (e.g. loopback) of a node, the= n > the headend will need to resolve and as such validate. While if specified > as a label, then no resolution is required. > > >> >> Section 6.2 >> >> When the active candidate path has a specified BSID, the SR Policy >> uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is >> available (i.e., not associated with any other usage: e.g. to another >> MPLS client, to another SRv6 client, to another SID, to another SR >> Policy, outside the range of SRv6 Locators). >> >> I don't think I understand what is meant by "client" here (for "another >> client"). This sentence is the only place where the word "client" appea= rs >> in this document... >> > > KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be IS-IS > enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from a > "label manager" within the router. > > >> >> Optionally, instead of only checking that the BSID of the active path >> is available, a headend MAY check that it is available within a given >> SID range i.e., Segment Routing Local Block (SRLB) as specified in >> [RFC8402]. >> >> Is the only allowed range to check the SRLB? If not, I think we need to >> s/i.e./e.g./. >> > > KT> Yes, SRLB is the one to check/allocate from for such usage. > > >> >> When the specified BSID is not available (optionally is not in the >> SRLB), an alert message MUST be generated. >> >> This is the first time (of only two) the word "alert" appears in this >> document, and there is no prior expalanation of what entity might be >> receiving alerts generated by a headend. Please clarify. >> > > KT> Alert mechanism could be one or more of syslog, Netconf notification, > a telemetry mechanism, etc.. > > >> >> Assuming that at time t the BSID of the SR Policy is B1, if at time >> t+dt a different candidate path becomes active and this new active >> path does not have a specified BSID or its BSID is specified but is >> not available (e.g. it is in use by something else), then the SR >> Policy MAY keep the previous BSID B1. >> >> Is there a strict bound on or other guidance for what values of dt are >> allowable for this purpose? > > > KT> None > > >> Is the intent that there be an atomic >> transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-path=3DP2= ? >> > > KT> There is no atomicity requirement. A switch from one active CP to > another will vary depending on the cause of the switch - e.g. if it is du= e > to a failure or because a more preferred path came up. > > >> >> The association of an SR Policy with a BSID thus MAY change over the >> life of the SR Policy (e.g., upon active path change). Hence, the >> BSID SHOULD NOT be used as an identification of an SR Policy. >> >> Is there any guidance available on how long to wait with a given BSID >> value >> unused before binding it to a new SR Policy? >> > > KT> None. These depend on the implementation and scenarios like resource > availability e.g., a BSID might get re-used sooner if the system is runni= ng > short of labels. > > >> >> Section 6.2.3 >> >> An implementation MAY support the configuration of the Specified- >> BSID-only restrictive behavior on the headend for all SR Policies or >> individual SR Policies. Further, this restrictive behavior MAY also >> be signaled on a per SR Policy basis to the headend. >> >> Elsewhere in the document we discuss specific potential signaling >> mechanisms/protocols, but here we say nothing. Is that vagueness >> intentional? >> > > KT> Since this isn't a protocol specification the mechanism is not > described here. However, you can look at > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-p= olicy-14#section-2.4.2 > and that document refers back to this specification. > > >> >> Section 6.3 >> >> A valid SR Policy installs a BSID-keyed entry in the forwarding plane >> with the action of steering the packets matching this entry to the >> selected path of the SR Policy. >> >> I don't think this is stated properly. An SR Policy is the list of >> segments; it isn't the entity that's installing entries in the forwardin= g >> plane. Some other entity is installing an entry in the forwarding plane >> to >> realize the SR Policy in question, and we should make our writing reflec= t >> that. >> > > KT> Ack. s/installs/results in the installation of > > >> >> Section 6.4 >> >> An implementation MAY choose to associate a Binding SID with any type >> of interface (e.g. a layer 3 termination of an Optical Circuit) or a >> tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE >> tunnel, etc). This enables the use of other non-SR enabled >> >> Should we have some discussion that contrasts this scenario against the >> End.X behavior from RFC 8986 (for the "interface" case)? >> > > KT> What this document says is that a BSID may be also associated to > direct over these other types of interfaces/tunnels. We can look at them = as > having no other segment being imposed but just redirecting to an interfac= e. > In that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID = in > SR-MPLS). However, those tend to be associated with protocol adjacencies.= I > am not sure that I've followed your point though and please do let me kno= w > if I've not. > > >> >> Section 7 >> >> The SR Policy State is maintained on the headend to represent the >> state of the policy and its candidate paths. [...] >> >> I confess I don't really understand why we need to have the current, >> minimal, description of SR Policy State in this document. What would be >> lost if we deferred its discussion entirely until there is a more >> comprehensive discussion available? >> > > KT> We will add an informational pointer to the SR Policy YANG model. Wha= t > this document calls out is the requirement for reporting the operational > state and provides pointers to other specs where this is being worked out= . > > >> >> The SR Policy state can be reported by the headend node via BGP-LS >> [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and >> [I-D.ietf-pce-binding-label-sid]. >> >> The functionality of draft-ietf-pce-binding-label-sid seems much more >> limited than that of draft-ietf-idr-te-lsp-distribution; in particular, >> the >> former does not seem to actually report SR Policy state to the headed at >> all; rather, it only concerns itself with BSID association to path, with >> no >> information about "active", "not preferred", etc. >> > > KT> The PCEP work might be spread out over different documents but we do > need to cover these requirements. That is one of the objectives of having > this document coordinate work across protocol WGs. > > >> >> Section 8.3 >> >> If the SR Policy P is invalid, the BSID B is not in the forwarding >> plane and hence the packet K is dropped by H. >> >> We literally just in the previous section talked about a scenario where >> the >> BSDI is kept in the forwarding plane (but with the action to drop, so th= e >> overall outcome is not changed from what this text describes). >> Nonetheless, >> it's inaccurate to state that "the BSID B is not in the forwarding plane= " >> here. >> > > KT> There is a difference between the drop being referred to in 8.2 and > 8.3. What we have in 8.2 is like a route pointing to null where we may > advertise and get packets but will drop it with normal counters associate= d > with that specific entry. While 8.3 is like we are dropping because we ha= ve > no route (ideally we shouldn't have got the packet) and we increment a > generic lookup failed counter. The use-cases for both are different. > > >> >> Section 8.4.1 >> >> When a BGP route has multiple Color Extended communities each with a >> valid SR Policy, the BGP process installs the route on the SR Policy >> giving preference to the color with the highest numerical value. >> >> Do we want to say anything about this being an arbitrary tiebreaker >> (rather >> than an intentional preference), or is that thought to be implicitly >> clear? >> > > KT> It is an intentional preference. > > >> >> Section 8.5 >> >> In this section, independent of the a-priori existence of any >> explicit candidate path of the SR policy (C, N), it is to be noted >> that the BGP process at headend node H triggers the instantiation of >> a dynamic candidate path for the SR policy (C, N) as soon as: >> >> I strongly suggest providing a more explicit framework of what the >> assumptions and preconditions are for the mechanism described in this >> section. My intuition says that it's a fairly optional thing that would >> need to be specifically configured, but trying to wrap that sentiment in= to >> the long bullet point involving "a local policy" seems like a very >> confusing >> way to express the desired behavior. >> > > KT> It is actually a matter of local policy with perhaps some template an= d > configuration to drive this. I believe this should get covered in the SR > Policy YANG model at some point in time. > > >> >> Section 8.6 >> >> o is configured to instantiate an array of paths to N where the >> entry 0 is the IGP path to N, color C1 is the first entry and >> Color C2 is the second entry. The index into the array is called >> a Forwarding Class (FC). The index can have values 0 to 7. >> >> Why are the only allowed values 0 to 7? Where does this restriction ari= se >> from? It is because of some protocol element? >> > > KT> There is text further in the section to indicated that these > ranges/values are implementation-specific. Historically, the 8 values hav= e > come from the MPLS EXP bits. > > >> >> If the local configuration does not specify any explicit forwarding >> information for an entry of the array, then this entry is filled with >> the same information as entry 0 (i.e. the IGP shortest path). >> >> If the SR Policy mapped to an entry of the array becomes invalid, >> then this entry is filled with the same information as entry 0. When >> all the array entries have the same information as entry0, the >> forwarding entry for N is updated to bypass the array and point >> directly to its outgoing interface and next-hop. >> >> I can't tell how much of this is supposed to be protocol specification a= nd >> how much an illustrative example. Is A(0) always the IGP shortest path? >> Are these protocol requirements to fall back to the IGP shortest path wh= en >> an entry is otherwise unpopulated or the associated SR Policy becomes >> invalid? >> > > KT> The specifics are for illustration purposes. Most of these are policy > knobs/options. > > >> >> Section 8.8.2 >> >> The steering preference is first based on the highest color value and >> then CO-dependent for the color. [...] >> >> This seems to contradict what I assumed earlier about the "highest color= " >> rule being a tiebreaker, e.g., the word "preference" is used here. Is i= t >> actually intended to be a deliberately configured priority/preference >> scheme? If so, that would seem to require some wide-ranging reworking >> throughout the document. >> > > KT> There is the color that is in the identification of an SR Policy - > (color, endpoint). This does not get into any tiebreaker or selection > logic. All that (sec 2.9) is about the selection of a candidate path with= in > an SR Policy. Then there is the color value signaled via the Color Extend= ed > community on the BGP routes and here, we have the preference for higher > color when the route is advertised with multiple colors tagged to it. > > >> >> Section 9.3 >> >> the most appropriate alternative for the active candidate path. A >> fast re-route mechanism MAY then be used to trigger sub 50msec >> switchover from the active to the backup candidate path in the >> forwarding plane. Mechanisms like Bidirectional Forwarding Detection >> (BFD) MAY be used for fast detection of such failures. >> >> Why is the specific 50msec value important here? Is there some other >> requirement that imposes it? >> > > KT> This comes from "typical" expectations from fast-reroute mechanisms. > > >> >> Section 10 >> >> I think we also want to mention the security considerations of several >> more >> documents, including (but not limited to) >> draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986. >> > > KT> Ack on the three RFCs, but convinced about the > draft-ietf-idr-segment-routing-te-policy since that depends on this and n= ot > the other way around. > > >> >> Section 15.2 >> >> I agree with John that draft-ietf-idr-segment-routing-te-policy must be >> classified as a normative reference. >> >> It also seems that RFC 7752 should be classified as normative, as we >> incorporate its definition for the semantics of several of the segment >> type >> descriptions. >> > > KT> Ack > > >> >> >> NITS >> >> Section 1 >> >> Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of >> segments (i.e. instructions) that represent a source-routed policy. >> >> /Segment/A Segment/ >> > > KT> Ack > > >> >> The headend node is said to steer a flow into a SR Policy. The >> packets steered into an SR Policy carry an ordered list of segments >> associated with that SR Policy. [...] >> >> In a certain sense this can be read as saying that the packets that "car= ry >> an ordered list of segments" are the ones prior to being steered into an >> SR >> policy, which would make this statement not true. Perhaps we want to sa= y >> "after being steered into an SR Policy, packets carry an ordered list >> ..."? >> (I also went back and forth with myself about whether "packets ... carry= " >> implies in the payload or not. I settled on "not" but make this note ju= st >> in case I am missing an aspect of that question.) >> > > KT> Ack. Will rephrase. > > >> >> Section 2 >> >> An SR Policy is a framework that enables the instantiation of an >> ordered list of segments on a node for implementing a source routing >> >> It's easy to read this as saying that all of the segments in the list >> instantiated on the single node in question, which I assume is not the >> intent. Probably the easiest way to aid readability here is to split th= e >> sentence up into multiple smaller sentences that are easier to parse. >> > > KT> Will rephrase. > > >> >> Section 2.2 >> >> A dynamic candidate path expresses an optimization objective and a >> set of constraints. The headend (potentially with the help of a PCE) >> computes the solution Segment-List (or set of Segment-Lists) that >> solves the optimization problem. >> >> I'd suggest computes the solution/computes a solution/ for genericity. >> > > KT> Ack. > > >> A stateful PCE might end up computing a path that is not the optimal one >> for >> this specific optimization problem, due to a desire to cooperate with >> other >> paths in the network, and the "Min-Metric with margin and maximum number >> of >> SIDs" objective in draft-filsfils-spring-sr-policy-considerations doesn'= t >> even have a guaranteed unique best solution. >> >> Section 2.5 >> >> When provisioning is via configuration, this is an implementation's >> configuration model-specific unique identifier for a candidate path. >> The default value is 0. >> >> I'm having a lot of trouble parsing this. Did we perhaps mean to >> hyphenate >> as "configuration-model-specific"? >> > > KT> Ack > > >> >> Section 2.13 >> >> The SR Policy POL1 is identified by the tuple > endpoint>. It has two candidate paths CP1 and CP2. Each is >> identified by a tuple . >> >> I suggest (for the last sentence) "identified within the scope of POL1" >> > > KT> Ack > > >> >> forwarding instantiation of SR policy POL1. Traffic steered on POL1 >> is flow-based hashed on Segment-List with a ratio >> W1/(W1+W2). >> >> If I read "ratio" I would instinctively think of the ratio of (traffic o= n >> segment list 1)/(traffic on segment list 2), as opposed to the proportio= n >> of >> all traffic, that would be measured as the indicated W1/(W1+W2). >> > > KT> Ack. s/ratio/proportion > > >> >> Section 3 >> >> The attached domain topology may be learned via IGP, BGP-LS or >> NETCONF. >> >> A non-attached (remote) domain topology may be learned via BGP-LS or >> NETCONF. >> >> I think these are both probably not exhaustive lists, so "e.g." or simil= ar >> may be appropriate. >> > > KT> Ack. > > >> >> Section 4 >> >> Type C: IPv4 Prefix with optional SR Algorithm: >> The headend is required to resolve the specified IPv4 Prefix >> Address to the SR-MPLS label corresponding to a Prefix SID >> segment (as defined in [RFC8402]). The SR algorithm (refer to >> Section 3.1.1 of [RFC8402]) to be used MAY also be provided. >> >> Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: >> In this case, the headend is required to resolve the specified >> IPv6 Global Prefix Address to the SR-MPLS label corresponding >> to its Prefix SID segment (as defined in [RFC8402]). The SR >> Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY >> >> These are effectively just the IPv4 and IPv6 incarnations of the same >> underlying procedure, right? Can't we minimize the diff between the >> paragraphs further? >> > > KT> Ack > > >> >> Section 5.1 >> >> Additionally, a Segment-List MAY be declared invalid when: >> >> We probably want another word here ("both"?), to specify how the two >> conditions are combined. >> > > KT> Ack - will rephrase. > > >> >> Section 5.2 >> >> When the local computation is not possible (e.g., a policy's tail-end >> is outside the topology known to the headend) or not desired, the >> headend MAY send path computation request to a PCE supporting PCEP >> extension specified in [RFC8664]. >> >> missing article ("the PCEP extension"). I forget if it should be >> "extensions" plural. >> > > KT> Ack > > >> >> Section 8.7 >> >> Finally, headend H MAY be configured with a local routing policy >> which overrides any BGP/IGP path and steer a specified packet on an >> >> singular/plural mismatch -- s/steer/steers/ >> > > KT> Ack. > > Thanks, > Ketan > > --000000000000e08d9905d83ad760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

We've just poste= d an update to address the comments raised by you and other ADs:=C2=A0https://datatracker.ietf= .org/doc/html/draft-ietf-spring-segment-routing-policy-18
Thanks,
Ketan


On Thu, Feb 17, 2022 at 9= :21 PM Ketan Talaulikar <ketant= .ietf@gmail.com> wrote:
Hi Ben,

Thanks for your detailed review and your comments/inputs. Please check inl= ine for responses.


On Thu, Feb 17, 2022 at 11:46 AM Ben= jamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the following ballot= position for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I may just be misunderstanding things, but I'd like to pull on a th= read
in =C2=A78.4 a bit more.=C2=A0 We say that the headend H learns a BGP route= that has a
VPN label V, but then the following procedures seem to say that we install = a
route on the appropriate SR Policy P and that when we receive a packet that=
matches the route in question, push a label stack including the VPN label,<= br> and send the resulting packet out.=C2=A0

KT= > Note that we are sending the packet to the selected BGP NH (i.e. egres= s PE) that advertised the route. The SR Policy is enabling the packets to t= raverse a path that is different from (perhaps) the best-effort IGP routing= .
=C2=A0
= Nowhere do we say to check the VPN
status of the incoming packet,

KT> That= is the ingress part of the forwarding entry which maps the incoming traffi= c over a customer interface to their specific VPN context and then performs= a lookup in their VPN specific table. This all is unchanged.
=C2= =A0
so this seems li= ke it would open a hole in
the VPN by allowing "arbitrary" incoming traffic (not marked as s= pecific to
V) to enter that VPN.=C2=A0 Is the label V filling some other role than
identifying a specific VPN of many VPNs that could run along the route R/r?=
(This is the only instance of the phrase "VPN label" in the docum= ent, and no
reference is given, so I'm relying heavily on instinct to ascertain the=
intent here.)

KT> I hope my response= s clarified that the only thing that is changed here by the steering over t= he SR Policy is the path taken through the network to get to the egress PE.= Rest is as today. And yes, of course, we have the ability to indicate the = need for such steering via the matching Color Extended community to the BGP= route.
=C2=A0

(2) The security considerations says that this document does not define any=
new protocol extensions and (accordingly) does not introduce any further security considerations.=C2=A0 The first part of this seems false, not leas= t
since we define the meaning of the "CO" bits in the Color Extende= d
Community.=C2=A0 I'm pretty sure that makes the second part also false,= and we
need to discuss the security considerations relating to imposing SR Policie= s
based only on color and not next-hop.=C2=A0 Alvaro has also noted additiona= l
aspects where security considerations are missing.
KT> Ack. We will add text in the security consideration sect= ions for the CO steering modes.
=C2=A0

(3) The Discriminator as defined in =C2=A72.5 does not seem wide enough to = be
able to provide the needed properties.=C2=A0 Some later clarification in = =C2=A72.6
implies that the definition in =C2=A72.5 is incomplete and the width is act= ually
appropriate, but in either case =C2=A72.5 seems inadequate in its current f= orm.
(Details in the COMMENT.)

KT> 32 bit= is wide enough and please see further response below.
=C2=A0

(4) Section 2.11 contains the statement, "A valid SR Policy is instant= iated
in the forwarding plane."

Is this a statement of fact (i.e., a consequence of the definition of
"valid") or a mandate for something (e.g., the headend) to take a= ction to
make it so?=C2=A0 Given that the point of SR is to be stateless on nodes ot= her
than the headend, I suspect the former, but if we are relying on the headen= d
(or some other entity) to take action to ensure this is the case, that need= s
to be a clearly stated normative requirement.

KT> The validity of a candidate path and as an extension, the SR = Policy is discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and = its constructs are instantiated in the forwarding plane.
=C2=A0

(5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]."=
There's nothing in the IANA registry for SAFI
(https://www.iana.org/assignment= s/safi-namespace/safi-namespace.xhtml) about
LISP, and RFC 6830 doesn't talk about SAFI.=C2=A0 What is this referrin= g to?

KT> Ack - there is no SAFI in = LISP and the reference was meant to be for routing of both IPv4 and IPv6 pa= ckets with LISP. Will fix this.
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There's a lot of this document that feels like just some informational<= br> discussion of "here are some things that many people do", "h= ere are some
possible things you can do with SR", etc..=C2=A0 There are also a smal= l handful
of places in the document that look to actually be specifying parts of
protocol behavior (I suspect that John has already identified them in his enumeration), and the overall impression ends up being a bit jumbled,
like there are a bunch of topics stuck together without an overarching them= e.
I think the overall content would be more valuable if divided into a tight<= br> "protocol specification" portion that could stay at proposed stan= dard, plus
an informational "architecture details" document that contains th= e
in-depth exposition that didn't make it into 8402.

This draft would benefit greatly from a terminology section.=C2=A0 I note i= n the
section-by-section comments several places where a term is first used
without sufficient background/definition, leaving the matter at hand
underspecified for the reader.

Section 2

=C2=A0 =C2=A0An SR Policy is a framework that enables the instantiation of = an
=C2=A0 =C2=A0ordered list of segments on a node for implementing a source r= outing

Really, an SR policy is a *framework*?=C2=A0 I thought an SR policy was a specific instantiation of a list of segments, or at least that's what I= 'm
getting from RFC 8402.=C2=A0 Perhaps we should say that the general concept= of SR
Policy provides a framework?

KT> Ack= . Will rephrase.
=C2=A0

Section 2.1

=C2=A0 =C2=A0An SR Policy MUST be identified through the tuple <headend,= color,
=C2=A0 =C2=A0endpoint>.=C2=A0 In the context of a specific headend, an S= R policy MUST
=C2=A0 =C2=A0be identified by the <color, endpoint> tuple.

These two MUSTs appear to be in (nominal) conflict.=C2=A0 Maybe start the f= irst
one with "absent further context" or "absent the context of = a known headend
node"?

KT> It is not "abse= nce of context" but "within the context of a specific headend&quo= t;.
=C2=A0

=C2=A0 =C2=A0The headend is the node where the policy is instantiated/imple= mented.
=C2=A0 =C2=A0The headend is specified as an IPv4 or IPv6 address and is exp= ected
=C2=A0 =C2=A0to be unique in the domain.

This is the first instance of the word "domain" in this document.= =C2=A0 I suggest
using the introduction to introduce what is meant by the word, even if just=
by reference to RFC 8402.

KT> Ack. I= t should be SR Domain.
=C2=A0

=C2=A0 =C2=A0An implementation MAY allow the assignment of a symbolic name<= br> =C2=A0 =C2=A0comprising printable ASCII [RFC0020] characters (i.e.=C2=A0 0x= 20 to 0x7E)
=C2=A0 =C2=A0to an SR Policy to serve as a user-friendly attribute for debu= gging
=C2=A0 =C2=A0and troubleshooting purposes.=C2=A0 [...]

I agree with the other ADs that limiting to US-ASCII is not actually
user-friendly for many users, and that the likelihood of some
implementations not properly enforcing such a limitation to be high.
(Likewise for the other places where symbolic names are admitted.)

KT> Please see the response to the other rev= iews on this point.
=C2=A0

Section 2.2

=C2=A0 =C2=A0A dynamic candidate path expresses an optimization objective a= nd a
=C2=A0 =C2=A0set of constraints.=C2=A0 [...]

Down in =C2=A75.2 when we discuss validation procedures for dynamic candida= te
paths, we say that the optimization problem is solved "for either the<= br> SR-MPLS or the SRv6 data-plane as specified".=C2=A0 Does the data plan= e need to
be specified as part of the dynamic candidate path itself?
=

KT> Yes.
=C2=A0

Section 2.3

=C2=A0 =C2=A0in Section 2.9.=C2=A0 The table below specifies the RECOMMENDE= D default
=C2=A0 =C2=A0values of Protocol-Origin:

I feel like it would be useful to provide some justification for why the recommended default behavior prefers BGP SR configuration over PCEP, even i= f
that justification is just "we need to have a clear ordering and this = one is
arbitrary".

KT> Ack. Will clari= fy that.
=C2=A0

Section 2.4

=C2=A0 =C2=A0o=C2=A0 Node Address : represented as a 128-bit value.=C2=A0 I= Pv4 addresses
=C2=A0 =C2=A0 =C2=A0 MUST be encoded in the lowest 32 bits, and the high-or= der bits
=C2=A0 =C2=A0 =C2=A0 MUST be set to zero.

=C2=A0 =C2=A0Its application in the candidate path selection is described i= n
=C2=A0 =C2=A0Section 2.9.

The tie-breaker procedure for path selection described in =C2=A72.9 seems t= o
always prefer IPv4 originators over IPv6 ones (by virtue of preferring the<= br> smaller value).=C2=A0 I guess if we wanted to change that to prefer IPv6 we= have
the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped unicast) from BCP 153, but it's a bit hard to justify either of those as appropr= iate
on technical grounds, and since this is just a tie-breaker and the
Preference is explicitly preferred, it seems like this is probably "go= od
enough" as-is.

KT> Ack. As clar= ified in a recent text update in v17, preference is the key parameter reall= y.
=C2=A0

Section 2.5

=C2=A0 =C2=A0The Discriminator is a 32-bit value associated with a candidat= e path
=C2=A0 =C2=A0that uniquely identifies it within the context of an SR Policy= from a
=C2=A0 =C2=A0specific Protocol-Origin as specified below:

What are the constraints that underlie the 32-bit requirement here?
It looks like some of the scenarios are going to involve uncoordinated
(random) assignment of these discriminator values (e.g., with the BGP
distribution mechanism, when coming from different BGP peers), and the
birthday-bound collision probability is not negligible for this few bits. That, in turn, calls into question the "uniquely identifies" prop= erty being
claimed.=C2=A0 Or is there some other property that means that only
discriminators from a single issuer will ever need to be compared with each=
other (making the allocation "coordinated"), such as being additi= onally
associated with the originator?
If my initial analysis was incorrect and these are indeed allocated in a "coordinated" fashion, would it be typical/expected for the alloc= ation to
occur by incrementing a local counter on the originator?=C2=A0 In some situ= ations
such allocation by counter can have security considerations, which
draft-gont-numeric-ids-sec-considerations attempts to cover.

KT> The discriminator is scoped to a particular or= iginating node for the candidate path and as such, there is no requirement = for coordination across sources/nodes. Therefore, 32-bit is more than suffi= cient.
=C2=A0

Section 2.8

=C2=A0 =C2=A0A candidate path is usable when it is valid.=C2=A0 A common pa= th validity
=C2=A0 =C2=A0criterion is the validity of any of its constituent Segment-Li= sts.
=C2=A0 =C2=A0The validation rules are specified in Section 5.

This document claims to target Proposed Standard status; are we really
content to say only that this is "a common" criterion?=C2=A0 Even= when we also go
on to flat-out state "the validation rules are specified [below]"= ?

KT> We will change this to introdu= ce the word RECOMMENDED. There are deployments where an operator might need= a local policy to declare the candidate path invalid when the number of va= lid SLs drops below a certain threshold (for b/w or load-balancing consider= ations).=C2=A0
=C2=A0

Section 2.9

=C2=A0 =C2=A0The candidate path selection process operates primarily on the=
=C2=A0 =C2=A0candidate path Preference.=C2=A0 A candidate path is selected = when it is
=C2=A0 =C2=A0valid and it has the highest preference value among all the ca= ndidate
=C2=A0 =C2=A0paths of the SR Policy.

Should this be "among all the valid candidate paths"?=C2=A0 A pat= h that's invalid
is still invalid, even if it has the highest preference value.

KT> Ack - will clarify this.
=C2=A0

=C2=A0 =C2=A02.=C2=A0 If specified by configuration, prefer the existing in= stalled
=C2=A0 =C2=A0 =C2=A0 =C2=A0path.

Does "if specified by configuration" refer to the act of applying= this rule
at all, or that the existing installed path was one specified by
configuration?

KT> The existing inst= alled path. The rationale was that in some deployment designs an operator m= ay not want to disturb/churn an active and valid/working path that has been= installed in the forwarding.
=C2=A0

Section 2.11

=C2=A0 =C2=A0The fraction of the flows associated with a given Segment-List= is w/
=C2=A0 =C2=A0Sw, where w is the weight of the Segment-List and Sw is the su= m of
=C2=A0 =C2=A0the weights of the Segment-Lists of the selected path of the S= R
=C2=A0 =C2=A0Policy.

Thank you for stating this clearly!

Section 3

=C2=A0 =C2=A0o=C2=A0 TE Link Attributes (such as TE metric, Shared Risk Lin= k Groups,
=C2=A0 =C2=A0 =C2=A0 attribute-flag, extended admin group) [RFC5305] [RFC36= 30].

Is RFC 5329 applicable here as well?

KT= > Yes, will add that. Thanks.
=C2=A0

Section 4

=C2=A0 =C2=A0Type E: IPv4 Prefix with Local Interface ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This type allows identification of Adjace= ncy SID or BGP Peer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Adjacency SID (as defined in [RFC8402]) S= R-MPLS label for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0point-to-point links including IP unnumbe= red links.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0headend is required to resolve the specif= ied IPv4 Prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Address to the Node originating it and th= en use the Local
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Interface ID to identify the point-to-poi= nt link whose
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adjacency is being referred to.=C2=A0 The= Local Interface ID link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0descriptor follows semantics as specified= in [RFC7752].=C2=A0 This

The phrase "local interface ID" does not appear in RFC 7752 (and = even "local
interface" appears just once"; please use terminology actually pr= esent in
the referred-to document to clarify what is being referenced.

KT> This one is a bit complicated since RFC7752 (= sec 3.2.2) in turn references RFC5307 which in turn RFC4202. We use RFC7752= since it covers and explains the use of the various link descriptors that = we use for various segment types.
=C2=A0

Section 4.1

=C2=A0 =C2=A0When steering unlabeled IPv6 BGP destination traffic using an = SR
=C2=A0 =C2=A0policy composed of Segment-List(s) based on IPv4 SIDs, the Exp= licit
=C2=A0 =C2=A0Null Label Policy is processed as specified in
=C2=A0 =C2=A0[I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4.=C2=A0= When an

It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced document.

KT> Ack. Will fix.
=C2=A0

Section 5.1

=C2=A0 =C2=A0The computation/logic that leads to the choice of the Segment-= List is
=C2=A0 =C2=A0external to the SR Policy headend.=C2=A0 The SR Policy headend= does not
=C2=A0 =C2=A0compute the Segment-List.=C2=A0 The SR Policy headend only con= firms its
=C2=A0 =C2=A0validity.

Does the headend actually have to confirm validity?=C2=A0 Is it okay to jus= t
trust the controller and blindly use what is provided?

KT> At least the first segment needs to be validated fro= m a resolvability perspective. The subsequent segments depend on how (i.e.,= using what segment types) the controller has signalled the path to the hea= dend. If it is indicated by just referring to a Prefix (e.g. loopback) of a= node, then the headend will need to resolve and as such validate. While if= specified as a label, then no resolution is required.
=C2=A0

Section 6.2

=C2=A0 =C2=A0When the active candidate path has a specified BSID, the SR Po= licy
=C2=A0 =C2=A0uses that BSID if this value (label in MPLS, IPv6 address in S= Rv6) is
=C2=A0 =C2=A0available (i.e., not associated with any other usage: e.g. to = another
=C2=A0 =C2=A0MPLS client, to another SRv6 client, to another SID, to anothe= r SR
=C2=A0 =C2=A0Policy, outside the range of SRv6 Locators).

I don't think I understand what is meant by "client" here (fo= r "another
client").=C2=A0 This sentence is the only place where the word "c= lient" appears
in this document...

KT> The term is = "MPLS client" or "SRv6 client". MPLS clients can be IS-= IS enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from a = "label manager" within the router.=C2=A0
=C2=A0

=C2=A0 =C2=A0Optionally, instead of only checking that the BSID of the acti= ve path
=C2=A0 =C2=A0is available, a headend MAY check that it is available within = a given
=C2=A0 =C2=A0SID range i.e., Segment Routing Local Block (SRLB) as specifie= d in
=C2=A0 =C2=A0[RFC8402].

Is the only allowed range to check the SRLB?=C2=A0 If not, I think we need = to
s/i.e./e.g./.

KT> Yes, SRLB is the o= ne to check/allocate from for such usage.
=C2=A0

=C2=A0 =C2=A0When the specified BSID is not available (optionally is not in= the
=C2=A0 =C2=A0SRLB), an alert message MUST be generated.

This is the first time (of only two) the word "alert" appears in = this
document, and there is no prior expalanation of what entity might be
receiving alerts generated by a headend.=C2=A0 Please clarify.

KT> Alert mechanism could be one or more of sysl= og, Netconf notification, a telemetry mechanism, etc..=C2=A0
=C2= =A0

=C2=A0 =C2=A0Assuming that at time t the BSID of the SR Policy is B1, if at= time
=C2=A0 =C2=A0t+dt a different candidate path becomes active and this new ac= tive
=C2=A0 =C2=A0path does not have a specified BSID or its BSID is specified b= ut is
=C2=A0 =C2=A0not available (e.g. it is in use by something else), then the = SR
=C2=A0 =C2=A0Policy MAY keep the previous BSID B1.

Is there a strict bound on or other guidance for what values of dt are
allowable for this purpose?

KT> None
=C2=A0
=C2=A0= Is the intent that there be an atomic
transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-path=3DP2?

KT> There is no atomicity requirement= . A switch from one active CP to another will vary depending on the cause o= f the switch - e.g. if it is due to a failure or because a more preferred p= ath came up.
=C2=A0

=C2=A0 =C2=A0The association of an SR Policy with a BSID thus MAY change ov= er the
=C2=A0 =C2=A0life of the SR Policy (e.g., upon active path change).=C2=A0 H= ence, the
=C2=A0 =C2=A0BSID SHOULD NOT be used as an identification of an SR Policy.<= br>
Is there any guidance available on how long to wait with a given BSID value=
unused before binding it to a new SR Policy?

KT> None. These depend on the implementation and scenarios like re= source availability e.g., a BSID might get re-used sooner if the system is = running short of labels.
=C2=A0

Section 6.2.3

=C2=A0 =C2=A0An implementation MAY support the configuration of the Specifi= ed-
=C2=A0 =C2=A0BSID-only restrictive behavior on the headend for all SR Polic= ies or
=C2=A0 =C2=A0individual SR Policies.=C2=A0 Further, this restrictive behavi= or MAY also
=C2=A0 =C2=A0be signaled on a per SR Policy basis to the headend.

Elsewhere in the document we discuss specific potential signaling
mechanisms/protocols, but here we say nothing.=C2=A0 Is that vagueness
intentional?

KT> Since this isn'= t a protocol specification the mechanism is not described here. However, yo= u can look at=C2=A0https= ://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-1= 4#section-2.4.2 and that document refers back to this specification.=C2= =A0
=C2=A0

Section 6.3

=C2=A0 =C2=A0A valid SR Policy installs a BSID-keyed entry in the forwardin= g plane
=C2=A0 =C2=A0with the action of steering the packets matching this entry to= the
=C2=A0 =C2=A0selected path of the SR Policy.

I don't think this is stated properly.=C2=A0 An SR Policy is the list o= f
segments; it isn't the entity that's installing entries in the forw= arding
plane.=C2=A0 Some other entity is installing an entry in the forwarding pla= ne to
realize the SR Policy in question, and we should make our writing reflect that.

KT> Ack. s/installs/results in= the installation of
=C2=A0

Section 6.4

=C2=A0 =C2=A0An implementation MAY choose to associate a Binding SID with a= ny type
=C2=A0 =C2=A0of interface (e.g. a layer 3 termination of an Optical Circuit= ) or a
=C2=A0 =C2=A0tunnel (e.g.=C2=A0 IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS = RSVP-TE
=C2=A0 =C2=A0tunnel, etc).=C2=A0 This enables the use of other non-SR enabl= ed

Should we have some discussion that contrasts this scenario against the
End.X behavior from RFC 8986 (for the "interface" case)?

KT> What this document says is that a BSID m= ay be also associated to direct over these other types of interfaces/tunnel= s. We can look at them as having no other segment being imposed but just re= directing to an interface. In that sense, it is somewhat similar to End.X i= n SRv6 (or Adjacency SID in SR-MPLS). However, those tend to be associated = with protocol adjacencies. I am not sure that I've followed your point = though and please do let me know if I've not.
=C2=A0

Section 7

=C2=A0 =C2=A0The SR Policy State is maintained on the headend to represent = the
=C2=A0 =C2=A0state of the policy and its candidate paths.=C2=A0 [...]

I confess I don't really understand why we need to have the current, minimal, description of SR Policy State in this document.=C2=A0 What would = be
lost if we deferred its discussion entirely until there is a more
comprehensive discussion available?

KT&= gt; We will add an informational pointer to the SR Policy YANG model. What = this document calls out is the requirement for reporting the operational st= ate and provides pointers to other specs where this is being worked out.
=C2=A0

=C2=A0 =C2=A0The SR Policy state can be reported by the headend node via BG= P-LS
=C2=A0 =C2=A0[I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and
=C2=A0 =C2=A0[I-D.ietf-pce-binding-label-sid].

The functionality of draft-ietf-pce-binding-label-sid seems much more
limited than that of draft-ietf-idr-te-lsp-distribution; in particular, the=
former does not seem to actually report SR Policy state to the headed at all; rather, it only concerns itself with BSID association to path, with no=
information about "active", "not preferred", etc.

KT> The PCEP work might be spread out ove= r different documents but we do need to cover these requirements. That is o= ne of the objectives of having this document coordinate work across protoco= l WGs.
=C2=A0

Section 8.3

=C2=A0 =C2=A0If the SR Policy P is invalid, the BSID B is not in the forwar= ding
=C2=A0 =C2=A0plane and hence the packet K is dropped by H.

We literally just in the previous section talked about a scenario where the=
BSDI is kept in the forwarding plane (but with the action to drop, so the overall outcome is not changed from what this text describes).=C2=A0 Noneth= eless,
it's inaccurate to state that "the BSID B is not in the forwarding= plane"
here.

KT> There is a difference betw= een the drop being referred to in 8.2 and 8.3. What we have in 8.2 is like = a route pointing to null where we may advertise and get packets but will dr= op it with normal counters associated with that specific entry. While 8.3 i= s like we are dropping because we have no route (ideally we shouldn't h= ave got the packet) and we increment a generic lookup failed counter. The u= se-cases for both are different.
=C2=A0

Section 8.4.1

=C2=A0 =C2=A0When a BGP route has multiple Color Extended communities each = with a
=C2=A0 =C2=A0valid SR Policy, the BGP process installs the route on the SR = Policy
=C2=A0 =C2=A0giving preference to the color with the highest numerical valu= e.

Do we want to say anything about this being an arbitrary tiebreaker (rather=
than an intentional preference), or is that thought to be implicitly clear?=

KT> It is an intentional preference= .
=C2=A0

Section 8.5

=C2=A0 =C2=A0In this section, independent of the a-priori existence of any<= br> =C2=A0 =C2=A0explicit candidate path of the SR policy (C, N), it is to be n= oted
=C2=A0 =C2=A0that the BGP process at headend node H triggers the instantiat= ion of
=C2=A0 =C2=A0a dynamic candidate path for the SR policy (C, N) as soon as:<= br>
I strongly suggest providing a more explicit framework of what the
assumptions and preconditions are for the mechanism described in this
section.=C2=A0 My intuition says that it's a fairly optional thing that= would
need to be specifically configured, but trying to wrap that sentiment into<= br> the long bullet point involving "a local policy" seems like a ver= y confusing
way to express the desired behavior.

KT= > It is actually a matter of local policy with perhaps some template and= configuration to drive this. I believe this should get covered in the SR P= olicy YANG model at some point in time.
=C2=A0

Section 8.6

=C2=A0 =C2=A0o=C2=A0 is configured to instantiate an array of paths to N wh= ere the
=C2=A0 =C2=A0 =C2=A0 entry 0 is the IGP path to N, color C1 is the first en= try and
=C2=A0 =C2=A0 =C2=A0 Color C2 is the second entry.=C2=A0 The index into the= array is called
=C2=A0 =C2=A0 =C2=A0 a Forwarding Class (FC).=C2=A0 The index can have valu= es 0 to 7.

Why are the only allowed values 0 to 7?=C2=A0 Where does this restriction a= rise
from?=C2=A0 It is because of some protocol element?
KT> There is text further in the section to indicated that = these ranges/values are implementation-specific. Historically, the 8 values= have come from the MPLS EXP bits.
=C2=A0

=C2=A0 =C2=A0If the local configuration does not specify any explicit forwa= rding
=C2=A0 =C2=A0information for an entry of the array, then this entry is fill= ed with
=C2=A0 =C2=A0the same information as entry 0 (i.e. the IGP shortest path).<= br>
=C2=A0 =C2=A0If the SR Policy mapped to an entry of the array becomes inval= id,
=C2=A0 =C2=A0then this entry is filled with the same information as entry 0= .=C2=A0 When
=C2=A0 =C2=A0all the array entries have the same information as entry0, the=
=C2=A0 =C2=A0forwarding entry for N is updated to bypass the array and poin= t
=C2=A0 =C2=A0directly to its outgoing interface and next-hop.

I can't tell how much of this is supposed to be protocol specification = and
how much an illustrative example.=C2=A0 Is A(0) always the IGP shortest pat= h?
Are these protocol requirements to fall back to the IGP shortest path when<= br> an entry is otherwise unpopulated or the associated SR Policy becomes
invalid?

KT> The specifics are for i= llustration purposes. Most of these are policy knobs/options.
=C2= =A0

Section 8.8.2

=C2=A0 =C2=A0The steering preference is first based on the highest color va= lue and
=C2=A0 =C2=A0then CO-dependent for the color.=C2=A0 [...]

This seems to contradict what I assumed earlier about the "highest col= or"
rule being a tiebreaker, e.g., the word "preference" is used here= .=C2=A0 Is it
actually intended to be a deliberately configured priority/preference
scheme?=C2=A0 If so, that would seem to require some wide-ranging reworking=
throughout the document.

KT> There i= s the color that is in the identification of an SR Policy - (color, endpoin= t). This does not get into any tiebreaker or selection logic. All that (sec= 2.9) is about the selection of a candidate path within an SR Policy. Then = there is the color value signaled via the Color Extended community on the B= GP routes and here, we have the preference for higher color when the route = is advertised with multiple colors tagged to it.
=C2=A0

Section 9.3

=C2=A0 =C2=A0the most appropriate alternative for the active candidate path= .=C2=A0 A
=C2=A0 =C2=A0fast re-route mechanism MAY then be used to trigger sub 50msec=
=C2=A0 =C2=A0switchover from the active to the backup candidate path in the=
=C2=A0 =C2=A0forwarding plane.=C2=A0 Mechanisms like Bidirectional Forwardi= ng Detection
=C2=A0 =C2=A0(BFD) MAY be used for fast detection of such failures.

Why is the specific 50msec value important here?=C2=A0 Is there some other<= br> requirement that imposes it?

KT> Thi= s comes from "typical" expectations from fast-reroute mechanisms.=
=C2=A0

Section 10

I think we also want to mention the security considerations of several more=
documents, including (but not limited to)
draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986.
=

KT> Ack on the three RFCs, but convince= d about the draft-ietf-idr-segment-routing-te-policy since that depends on = this and not the other way around.
=C2=A0

Section 15.2

I agree with John that draft-ietf-idr-segment-routing-te-policy must be
classified as a normative reference.

It also seems that RFC 7752 should be classified as normative, as we
incorporate its definition for the semantics of several of the segment type=
descriptions.

KT> Ack
=C2= =A0


NITS

Section 1

=C2=A0 =C2=A0Segment Routing Policy (SR Policy) [RFC8402] is an ordered lis= t of
=C2=A0 =C2=A0segments (i.e. instructions) that represent a source-routed po= licy.

/Segment/A Segment/

KT> Ack
=C2=A0

=C2=A0 =C2=A0The headend node is said to steer a flow into a SR Policy.=C2= =A0 The
=C2=A0 =C2=A0packets steered into an SR Policy carry an ordered list of seg= ments
=C2=A0 =C2=A0associated with that SR Policy.=C2=A0 [...]

In a certain sense this can be read as saying that the packets that "c= arry
an ordered list of segments" are the ones prior to being steered into = an SR
policy, which would make this statement not true.=C2=A0 Perhaps we want to = say
"after being steered into an SR Policy, packets carry an ordered list = ..."?
(I also went back and forth with myself about whether "packets ... car= ry"
implies in the payload or not.=C2=A0 I settled on "not" but make = this note just
in case I am missing an aspect of that question.)

=
KT> Ack. Will rephrase.
=C2=A0

Section 2

=C2=A0 =C2=A0An SR Policy is a framework that enables the instantiation of = an
=C2=A0 =C2=A0ordered list of segments on a node for implementing a source r= outing

It's easy to read this as saying that all of the segments in the list instantiated on the single node in question, which I assume is not the
intent.=C2=A0 Probably the easiest way to aid readability here is to split = the
sentence up into multiple smaller sentences that are easier to parse.

KT> Will rephrase.
=C2=A0
=

Section 2.2

=C2=A0 =C2=A0A dynamic candidate path expresses an optimization objective a= nd a
=C2=A0 =C2=A0set of constraints.=C2=A0 The headend (potentially with the he= lp of a PCE)
=C2=A0 =C2=A0computes the solution Segment-List (or set of Segment-Lists) t= hat
=C2=A0 =C2=A0solves the optimization problem.

I'd suggest computes the solution/computes a solution/ for genericity.<= br>

KT> Ack.
=C2=A0
A stateful PCE might end up computing a path that is not the optimal one fo= r
this specific optimization problem, due to a desire to cooperate with other=
paths in the network, and the "Min-Metric with margin and maximum numb= er of
SIDs" objective in draft-filsfils-spring-sr-policy-considerations does= n't
even have a guaranteed unique best solution.

Section 2.5

=C2=A0 =C2=A0When provisioning is via configuration, this is an implementat= ion's
=C2=A0 =C2=A0configuration model-specific unique identifier for a candidate= path.
=C2=A0 =C2=A0The default value is 0.

I'm having a lot of trouble parsing this.=C2=A0 Did we perhaps mean to = hyphenate
as "configuration-model-specific"?

KT> Ack
=C2=A0

Section 2.13

=C2=A0 =C2=A0The SR Policy POL1 is identified by the tuple <headend, col= or,
=C2=A0 =C2=A0endpoint>.=C2=A0 It has two candidate paths CP1 and CP2.=C2= =A0 Each is
=C2=A0 =C2=A0identified by a tuple <protocol-origin, originator, discrim= inator>.

I suggest (for the last sentence) "identified within the scope of POL1= "

KT> Ack
=C2=A0

=C2=A0 =C2=A0forwarding instantiation of SR policy POL1.=C2=A0 Traffic stee= red on POL1
=C2=A0 =C2=A0is flow-based hashed on Segment-List <SID11...SID1i> wit= h a ratio
=C2=A0 =C2=A0W1/(W1+W2).

If I read "ratio" I would instinctively think of the ratio of (tr= affic on
segment list 1)/(traffic on segment list 2), as opposed to the proportion o= f
all traffic, that would be measured as the indicated W1/(W1+W2).

KT> Ack. s/ratio/proportion
=C2=A0

Section 3

=C2=A0 =C2=A0The attached domain topology may be learned via IGP, BGP-LS or=
=C2=A0 =C2=A0NETCONF.

=C2=A0 =C2=A0A non-attached (remote) domain topology may be learned via BGP= -LS or
=C2=A0 =C2=A0NETCONF.

I think these are both probably not exhaustive lists, so "e.g." o= r similar
may be appropriate.

KT> Ack.
=C2=A0

Section 4

=C2=A0 =C2=A0Type C: IPv4 Prefix with optional SR Algorithm:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The headend is required to resolve the sp= ecified IPv4 Prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Address to the SR-MPLS label correspondin= g to a Prefix SID
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0segment (as defined in [RFC8402]).=C2=A0 = The SR algorithm (refer to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.1.1 of [RFC8402]) to be used MA= Y also be provided.

=C2=A0 =C2=A0Type D: IPv6 Global Prefix with optional SR Algorithm for SR-M= PLS:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In this case, the headend is required to = resolve the specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 Global Prefix Address to the SR-MPLS= label corresponding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to its Prefix SID segment (as defined in = [RFC8402]).=C2=A0 The SR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Algorithm (refer to Section 3.1.1 of [RFC= 8402]) to be used MAY

These are effectively just the IPv4 and IPv6 incarnations of the same
underlying procedure, right?=C2=A0 Can't we minimize the diff between t= he
paragraphs further?

KT> Ack
=C2=A0

Section 5.1

=C2=A0 =C2=A0Additionally, a Segment-List MAY be declared invalid when:

We probably want another word here ("both"?), to specify how the = two
conditions are combined.

KT> Ack - w= ill rephrase.
=C2=A0

Section 5.2

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy'= ;s tail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, = the
=C2=A0 =C2=A0headend MAY send path computation request to a PCE supporting = PCEP
=C2=A0 =C2=A0extension specified in [RFC8664].

missing article ("the PCEP extension").=C2=A0 I forget if it shou= ld be
"extensions" plural.

KT> A= ck
=C2=A0

Section 8.7

=C2=A0 =C2=A0Finally, headend H MAY be configured with a local routing poli= cy
=C2=A0 =C2=A0which overrides any BGP/IGP path and steer a specified packet = on an

singular/plural mismatch -- s/steer/steers/

=
KT> Ack.

Thanks,
Ketan
=C2=A0
--000000000000e08d9905d83ad760-- From nobody Thu Feb 17 10:23:28 2022 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 089AA3A0E58; Thu, 17 Feb 2022 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 D_enl1Wob_mk; Thu, 17 Feb 2022 10:23:19 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 0E6053A0E63; Thu, 17 Feb 2022 10:23:19 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id m24so7255897vsp.7; Thu, 17 Feb 2022 10:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7UQPN7fkMN/j/pjoEAl0HZdh9EOtlxNsKmuq66NQ5Kg=; b=hnwM9/eIl9fy2wjCgbHlkiebV/p5QVk1I8MTwCcLecT1ZftuLkiPW9F1k7F/INVEdw M4zWXSo8L9eTnv0LqtBw2XKoaMRlQh5F8nsmiSVgKZj6hAdiXXhgYrPI8m7kC9tUEbNg 9tqOEqv56WRD47y59QH6QimKYPzERIPs2vlEPvZ8hzmGVgd/RIa4cA3885BjGoEyjU7U vd+96cPOjmDUHXxbb8JoO0Km2XMtDFdnuoJwS9oFbiseGMMverNQQ+USzSFh0quWVvem OAPIS/md7VDY61fnmZE663n7kqp7cRqAoc3VjcYNpM/796eQITAO7PqW8QHokZ2jyizU Kqjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7UQPN7fkMN/j/pjoEAl0HZdh9EOtlxNsKmuq66NQ5Kg=; b=TUsX7Z7Bgb9pKdGXRshmki+ettZltm3DCjIOjyy8G9wObnSO8p0JumggmIadhLFTcN Pd7xCly+P35c9bPBZpSDP1dplIkRLz6WNBzis6YlJh+eKRhzK1Wl4xjgJC3zdSq3CkHF Lf8MIt07eCELZI1BFwyo/5k63H8VCxEPtRL+zTZ/z6cDiQfK0QhI8n3HcoRPz1EhMLBj wcPypF/so0EYT6oW/7YW6thlcD4SQCI6zJsofmcApQZyFhbyzUt7DgxFbnPFmBYk9Cvz lhagLEFDvdY4ZgCsfIOK/7ziokspWs6LSl7muq66zqZINQIfBsNHwQfwBpKdcZ5iNSZu GcPQ== X-Gm-Message-State: AOAM531l/SUOWA77c/Zw6h3NfLjkrx67PxkZbCafoswWABo+ecukOGRn DHxQ9cnP69BHHbv1sk7bSZ02CQAJUF6t3LKxA23F2a4lp1g= X-Google-Smtp-Source: ABdhPJxScEJ0W5hG6CLU5JtKFLug7Tlv/qjemhfIFnbSjVsEDpcWIEfcwfUoCEQMQfYOavoZ/KfZpfY1V/pXQPwb4zI= X-Received: by 2002:a05:6102:3591:b0:310:ef5d:d2be with SMTP id h17-20020a056102359100b00310ef5dd2bemr1766382vsu.34.1645122197816; Thu, 17 Feb 2022 10:23:17 -0800 (PST) MIME-Version: 1.0 References: <164504916365.5606.17077981996669554325@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Thu, 17 Feb 2022 23:53:05 +0530 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000368af505d83adc52" Archived-At: Subject: Re: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 18:23:23 -0000 --000000000000368af505d83adc52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, We've just posted an update for the document to address the comments raised by you and other ADs: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-18 Thanks, Ketan On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar wrote: > Hi Roman, > > Thanks for your review and comments/inputs. Please check inline below for > responses. > > > On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker < > noreply@ietf.org> wrote: > >> Roman Danyliw has entered the following ballot position for >> draft-ietf-spring-segment-routing-policy-17: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions= / >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-polic= y/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> There appear to be a few places where additional pointers or >> specification is >> needed to ensure interoperability. >> >> ** Section 2.5 >> When signaling is via PCEP, the method to uniquely signal an >> individual candidate path along with its discriminator is described >> in [I-D.ietf-pce-segment-routing-policy-cp]. >> >> Where is the explanation of discriminator in this reference? >> =E2=80=9CDiscriminator=E2=80=9D >> appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2. In the first three >> section it >> is simply named but not explained. In the last section, it isn=E2=80=99= t >> explained >> beyond being defined as 32-bits. >> > > KT> I have not yet reviewed that document and will do so to pass the > comments to the authors of that document. As a reminder, this is an > architecture document in SPRING that is then realized using protocol > extensions/mechanisms that are specified in their respective WG documents= . > > >> >> ** Section 2.6. >> Candidate paths MAY also be assigned or signaled with a symbolic name >> comprising printable ASCII [RFC0020] [RFC5234] characters >> >> How these candidate paths names are signaled isn=E2=80=99t defined. I b= elieve it >> is >> per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Sectio= n >> 2.4.7 >> of draft-ietf-idr-segment-routing-te-policy. > > >> ** Section 2.7. How is the candidate path preference signaled? Is that >> draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and >> >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-= policy-14#section-2.4.1 >> ? >> > > KT> Those protocol specs normatively refer to this document. Your > understanding is correct about the parts of those documents. > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I support John Scudder and Alvaro Retana's DISCUSS positions. >> >> ** Section 2.1. >> The color is an unsigned non-zero 32-bit numerical value that >> associates the SR Policy with an intent or objective (e.g. low- >> latency). >> >> Should =E2=80=9Cnumeric value=E2=80=9D be =E2=80=9Cinteger=E2=80=9D? >> > > KT> Ack. Will clarify. > > >> >> ** Section 2.1 >> The SR Policy name >> MAY also be signaled along with a candidate path of the SR Policy >> (refer to Section 2.2). >> >> -- It would be helpful to explicitly state either here or in Section 2.2 >> that >> Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section >> 5.2.1 of >> [I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how >> this >> naming is signaled. Section 2.2 doesn=E2=80=99t discuss signaling the na= me. >> >> -- Both of these document need to be normative reference since there is >> dependency on them for interoperable behavior. >> > > KT> Please see one of my previous responses on the architecture and > protocol specifications split across documents. > > >> >> ** Section 2.2. Typo. s/heirarchical/hierarchical/ >> > > KT> Ack. > > >> >> ** Section 2.3. It would be helpful if the precise mechanism to signal >> the >> Protocol-Origin was cited. >> > > KT> It is not something that is signaled - refer to "The head-end assigns > different Protocol-Origin values to each source of SR Policy information.= ". > It is like an "administrative distance" that is used to attach preference > to routes learned via different protocols like OSPF, IS-IS, and BGP. Thi= s > is local on the headend. > > >> >> -- I believe it is Section 5.2.2 of >> [I-D.ietf-pce-segment-routing-policy-cp] >> > > KT> Ack but likely we'll need to remove section number references or > revalidate them at publication given how these documents have been moving > along and their interdependencies. > > >> >> -- I didn=E2=80=99t find any reference to a =E2=80=9CProtocol Origin=E2= =80=9D or this section in >> [I-D.ietf-idr-segment-routing-te-policy]. >> > > KT> Please check my previous comment. > > >> >> ** Section 2.4. >> When signaling is via BGP SR Policy, the ASN and Node Address are >> provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) >> on the headend. >> >> [I-D.ietf-idr-segment-routing-te-policy] needs to be a normative >> reference (as >> stated before due to the text in Section 2.1) >> >> ** Section 2.5. Per =E2=80=9CWhen provisioning is via configuration, = this is an >> implementation's configuration model-specific unique identifier for a >> candidate >> path=E2=80=9D, what is a =E2=80=9Cconfiguration model-model-specific uni= que identifier? >> What >> scope of the uniqueness? >> > > KT> Please refer to draft-ietf-spring-sr-policy-yang - we could not be > more specific or provide exact pointer here since that document is still > under development. > >> >> ** Section 2.13. This section says =E2=80=9Cthe information model is th= e >> following=E2=80=9D, >> but I don=E2=80=99t follow where that information model (IM) is per the >> definition in >> RFC3444. The text here appears be an example with hard-coded parameter >> values. >> > > KT> This is an overview and the actual model is being specified > in draft-ietf-spring-sr-policy-yang > > >> >> ** Section 4. >> Based on the desired dataplane, either the MPLS label stack or the >> SRv6 Segment Routing Header [RFC8754] is built from the Segment- >> List. >> >> Do SRv6 SRH and MPLS label stacks support all the segment types enumerat= ed >> here? For example, does Type E and F, IPv4 segments, work with a SRv6 >> SRH? >> > > KT> What goes into the packet, at the end of the day, are MPLS labels or > SRv6 SIDs. The segment types introduce the different context types that a= re > used to specify a segment especially in the signaling protocols. > > >> >> ** Section 4. >> When the algorithm is not specified for the SID types above which >> optionally allow for it, the headend SHOULD use the Strict Shortest >> Path algorithm if available; otherwise, it SHOULD use the default >> Shortest Path algorithm. The specification of the algorithm enables >> the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific >> SIDs in SR Policy. >> >> Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative >> reference? >> > > KT> We enable the specification of an algorithm that was introduced by > RFC8402. A later enhancement carved out a range of algos from there for I= GP > Flexible Algorithm. The reference is informative to indicate that one cou= ld > use IGP Flex Algo as well. > > >> >> ** Section 10. Given that this document has a dependency on >> [I-D.ietf-idr-segment-routing-te-policy] and >> [I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy= , >> their >> security considerations should apply. >> > > KT> I refer again to the dependency between this SPRING and the other > protocol specs. > > Thanks, > Ketan > > --000000000000368af505d83adc52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

We've just posted an upda= te for the document to address the comments raised by you and other ADs:=C2= =A0https://datatrac= ker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18
=

Thanks,
Ketan


<= div class=3D"gmail_quote">
On Thu, Feb= 17, 2022 at 8:38 PM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
Hi Roman,
Thanks for your review and comments/inputs. Please check i= nline below for responses.


On Thu, Feb 17, 2022 at 3:36= AM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has entered the following ba= llot position for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There appear to be a few places where additional pointers or specification = is
needed to ensure interoperability.

** Section 2.5
=C2=A0 =C2=A0When signaling is via PCEP, the method to uniquely signal an =C2=A0 =C2=A0individual candidate path along with its discriminator is desc= ribed
=C2=A0 =C2=A0in [I-D.ietf-pce-segment-routing-policy-cp].

Where is the explanation of discriminator in this reference?=C2=A0 =E2=80= =9CDiscriminator=E2=80=9D
appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2.=C2=A0 In the first three se= ction it
is simply named but not explained.=C2=A0 In the last section, it isn=E2=80= =99t explained
beyond being defined as 32-bits.

KT>= I have not yet reviewed that document and will do so to pass the comments = to the authors of that document. As a reminder, this is an architecture doc= ument in SPRING that is then realized using protocol extensions/mechanisms = that are specified in their respective WG documents.
=C2=A0
=

** Section 2.6.
=C2=A0 Candidate paths MAY also be assigned or signaled with a symbolic nam= e
=C2=A0 =C2=A0comprising printable ASCII [RFC0020] [RFC5234] characters

How these candidate paths names are signaled isn=E2=80=99t defined.=C2=A0 I= believe it is
per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2= .4.7
of draft-ietf-idr-segment-routing-te-policy.=C2=A0

** Section 2.7.=C2=A0 How is the candidate path preference signaled?=C2=A0 = Is that
draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and
https= ://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-1= 4#section-2.4.1?

KT> Those proto= col specs normatively refer to this document. Your understanding is correct= about the parts of those documents.=C2=A0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support John Scudder and Alvaro Retana's DISCUSS positions.

** Section 2.1.
=C2=A0 =C2=A0The color is an unsigned non-zero 32-bit numerical value that<= br> =C2=A0 =C2=A0associates the SR Policy with an intent or objective (e.g.=C2= =A0 low-
=C2=A0 =C2=A0latency).

Should =E2=80=9Cnumeric value=E2=80=9D be =E2=80=9Cinteger=E2=80=9D?

KT> Ack. Will clarify.
=C2=A0

** Section 2.1
=C2=A0 =C2=A0The SR Policy name
=C2=A0 =C2=A0MAY also be signaled along with a candidate path of the SR Pol= icy
=C2=A0 =C2=A0(refer to Section 2.2).

-- It would be helpful to explicitly state either here or in Section 2.2 th= at
Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section 5.2.1= of
[I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how this=
naming is signaled. Section 2.2 doesn=E2=80=99t discuss signaling the name.=

-- Both of these document need to be normative reference since there is
dependency on them for interoperable behavior.

KT> Please see one of my previous responses on the architecture = and protocol specifications split across documents.
=C2=A0
<= 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">
** Section 2.2. Typo. s/heirarchical/hierarchical/
KT> Ack.
=C2=A0

** Section 2.3.=C2=A0 It would be helpful if the precise mechanism to signa= l the
Protocol-Origin was cited.

KT> It is= not something that is signaled - refer to "The head-end assigns diffe= rent Protocol-Origin values to each source of SR Policy information.".= It is like an "administrative distance" that is used to attach p= reference to routes learned via different protocols like OSPF, IS-IS, and B= GP.=C2=A0 This is local on the headend.
=C2=A0

-- I believe it is Section 5.2.2 of [I-D.ietf-pce-segment-routing-policy-cp= ]

KT> Ack but likely we'll need = to remove section number references or revalidate them at publication given= how these documents have been moving along and their interdependencies.=C2= =A0
=C2=A0

-- I didn=E2=80=99t find any reference to a =E2=80=9CProtocol Origin=E2=80= =9D or this section in
[I-D.ietf-idr-segment-routing-te-policy].

KT> Please check my previous comment.
=C2=A0

** Section 2.4.
=C2=A0 =C2=A0When signaling is via BGP SR Policy, the ASN and Node Address = are
=C2=A0 =C2=A0provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-pol= icy])
=C2=A0 =C2=A0on the headend.

[I-D.ietf-idr-segment-routing-te-policy] needs to be a normative reference = (as
stated before due to the text in Section 2.1)

** Section 2.5.=C2=A0 =C2=A0 Per =E2=80=9CWhen provisioning is via configur= ation, this is an
implementation's configuration model-specific unique identifier for a c= andidate
path=E2=80=9D, what is a =E2=80=9Cconfiguration model-model-specific unique= identifier?=C2=A0 What
scope of the uniqueness?

KT> Please = refer to=C2=A0draft-ietf-spring-sr-policy-yang - we could not be more speci= fic or provide exact pointer here since that document is still under develo= pment.=C2=A0

** Section 2.13.=C2=A0 This section says =E2=80=9Cthe information model is = the following=E2=80=9D,
but I don=E2=80=99t follow where that information model (IM) is per the def= inition in
RFC3444.=C2=A0 The text here appears be an example with hard-coded paramete= r values.

KT> This is an overview an= d the actual model is being specified in=C2=A0draft-ietf-spring-sr-policy-y= ang
=C2=A0

** Section 4.
=C2=A0 =C2=A0Based on the desired dataplane, either the MPLS label stack or= the
=C2=A0 =C2=A0SRv6 Segment Routing Header [RFC8754] is built from the Segmen= t-
=C2=A0 =C2=A0 List.

Do SRv6 SRH and MPLS label stacks support all the segment types enumerated<= br> here?=C2=A0 For example, does Type E and F, IPv4 segments, work with a SRv6= SRH?

KT> What goes into the packet,= at the end of the day, are MPLS labels or SRv6 SIDs. The segment types int= roduce the different context types that are used to specify a segment espec= ially in the signaling protocols.
=C2=A0

** Section 4.
=C2=A0 =C2=A0When the algorithm is not specified for the SID types above wh= ich
=C2=A0 =C2=A0optionally allow for it, the headend SHOULD use the Strict Sho= rtest
=C2=A0 =C2=A0Path algorithm if available; otherwise, it SHOULD use the defa= ult
=C2=A0 =C2=A0Shortest Path algorithm.=C2=A0 The specification of the algori= thm enables
=C2=A0 =C2=A0the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] spe= cific
=C2=A0 =C2=A0SIDs in SR Policy.

Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative referen= ce?

KT>=C2=A0 We enable the specific= ation of an algorithm that was introduced by RFC8402. A later enhancement c= arved out a range of algos from there for IGP Flexible Algorithm. The refer= ence is informative to=C2=A0indicate that one could use IGP Flex Algo as we= ll.
=C2=A0

** Section 10.=C2=A0 Given that this document has a dependency on
[I-D.ietf-idr-segment-routing-te-policy] and
[I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy, t= heir
security considerations should apply.

K= T> I refer again to the dependency between this SPRING and the other pro= tocol specs.

Thanks,
Ketan
=C2= =A0
--000000000000368af505d83adc52-- From nobody Thu Feb 17 10:25:12 2022 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 DF2023A0E59; Thu, 17 Feb 2022 10:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 lKFzj7WYoTAm; Thu, 17 Feb 2022 10:24:59 -0800 (PST) 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 EE7173A0E58; Thu, 17 Feb 2022 10:24:58 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id m24so7260928vsp.7; Thu, 17 Feb 2022 10:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gfszY3EIKqQIuUcUUcVbmlqp1q7ZWb0fILKp87nnbF0=; b=Isss7rzVDn+41DsIizPeDeoxqPGrZVQqq8gJ8GCl9MzkWPiGNGnSJiTqE495nK3kT8 wS8yAX2WhZXxyx3YKxXD6ElAVuHn+CvUhiu99V3Y9vU8G2N5Zf2sudfm3RwLNZFYpRfU 1NxI8zySpL/V9RGswpbqFGuLxR6zN/SrKzahUFFkO8eqUX2qcLe8PBnUqhRtuRJ8j+l9 dE359hDe065B8bOcA3VDIEZk2mjWkZjTe2I0awU6/c+9nbtOwwmwhmdYpnJXesHMS2kM ZxHPSG/59XdVIghUT8h9NInmnfqvXSLvZA5+MBh0uKnYqY+Jm2Ki0pfx/tSR0Q9SHB9d WTng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gfszY3EIKqQIuUcUUcVbmlqp1q7ZWb0fILKp87nnbF0=; b=YhaFIwS9csRqGOxgyw1zSGO5yDyB3Op2dsC/wf3O4Oa1vPTiltjKBlioc5xYjNiEb1 OE/7ljiPPVh4x9bqzb3ZSuQ18aw8WJuF7K/NoG5O6R/i7oeYZ/YwkkbfvdskJpe2jbcP sGL5gd2Pe5tAX3CXGMdM43KaqgjJG/bJ/pYkP2afr+ptasxgxR/zQzUgnUHgVEPEB3Y/ 3QScofWtTEx3wTmi3yvRWefEdLBnsZ65YiNu61L5Llezu6+aO7yVbXPVRs/n25BlK01i 7GsC91xP2XC55K2BlWQMq2kannefIq5QBorO7pXN5o2lMf+6jsygztxrouGiVAzx4HXC uNTQ== X-Gm-Message-State: AOAM531pPQqb43tEbM/q1ycQracUIwgMp/OCPBZqq3mCMqlWUn/O6D2G Hzoox26rgTmHHTrNqvHadC1Ec9Ab6Mmxl2RSd3D0TQdgft4= X-Google-Smtp-Source: ABdhPJxKsRUuCep4oKqILD7wTX2fXhps0/AfPu/XNnfIMvNoGwyAmpMlXCtt91LgKrz1KMhYxNp6ovvV4wyap8MtIao= X-Received: by 2002:a05:6102:32d1:b0:30e:5a67:8b7 with SMTP id o17-20020a05610232d100b0030e5a6708b7mr2032048vss.33.1645122297624; Thu, 17 Feb 2022 10:24:57 -0800 (PST) MIME-Version: 1.0 References: <164504875164.5704.16596621622345086808@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Thu, 17 Feb 2022 23:54:45 +0530 Message-ID: To: Alvaro Retana Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000297dc305d83ae226" Archived-At: Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) 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, 17 Feb 2022 18:25:04 -0000 --000000000000297dc305d83ae226 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, We've just posted an update to address the comments raised by you and other ADs: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-18 Note that we've now tagged the document as updating RFC8402 per the discussions and feedback from the Telechat earlier today. Thanks, Ketan On Thu, Feb 17, 2022 at 8:36 PM Ketan Talaulikar wrote: > Hi Alvaro, > > Thanks for your review and comments/inputs. Please check inline below for > responses. > > > On Thu, Feb 17, 2022 at 3:29 AM Alvaro Retana via Datatracker < > noreply@ietf.org> wrote: > >> Alvaro Retana has entered the following ballot position for >> draft-ietf-spring-segment-routing-policy-17: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions= / >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-polic= y/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> (1) This specification should formally Update rfc8402. >> >> What is the relationship between this document and rfc8402? If this >> document >> details the concept introduced in rfc8402, why isn't there a formal Upda= te >> relationship? >> >> Even the initial definition of SR Policy in this document (=C2=A72) does= n't >> match >> what rfc8402 says. This document defines it as "a framework that enable= s >> the >> instantiation of an ordered list of segments", while rfc8402 states it i= s >> "an >> ordered list of segments." In =C2=A72.2, this document uses the term >> "segment-list" for that. >> > > KT> There were similar comments from Rob for which we have recently poste= d > updated text in v17. I believe, this document does not need to update > RFC8402 because it is not changing anything in that document. RFC8402 > simply introduces SR Policy while this document specifies its internal > constructs, how it is realized/instantiated, and steering mechanisms over > it. At least, that is the objective/view of the authors/WG and we are ope= n > to inputs to update and further clarify the same. > > >> >> Besides the general topic of clarifying and updating what an SR Policy >> is, this >> document also includes other items that were not present in rfc8402; the >> list >> includes: >> >> =C2=A72.1: "SR Policy MUST be identified through the tuple > endpoint>." There's not even a mention of "color" in rfc8402. >> >> =C2=A72.1: "The headend is specified as an IPv4 or IPv6 address and i= s >> expected >> to be unique in the domain." Neither the mechanism to identify a nod= e >> nor >> the expectation is present in rfc8402. >> >> =C2=A72.1: "The endpoint is specified as an IPv4 or IPv6 address and = is >> expected >> to be unique in the domain." Same as above. >> > > KT> Yes, these are the constructs of SR Policy that are specified by this > document. > > >> >> >> The SR Database is a new element not in the base architecture. The text >> in =C2=A73 >> says that "use of the SR-DB for computation and validation of SR Policie= s >> is >> outside the scope of this document", but it is then mentioned and used i= n >> =C2=A75.1/=C2=A75.2. >> > > KT> The computation algorithm and related discussions about the use of > SR-DB were asked to be moved out of this standards track document during > the WG process. Those informational sections were moved into > draft-filsfils-spring-sr-policy-considerations > and > kept as a reference in this document. The reference in 5.1 and 5.2 is abo= ut > validation of segments and as a result the segment-list and candidate pat= h. > The validation of the "objective" and constraints of the SR Policy was > deemed to be outside the scope of the document. There were several > discussions on and off-list at the IETF meetings in this regard. Perhaps > this thread gives a good summary: > https://mailarchive.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/ > > >> >> >> Accordingly, the added details require additional Security and >> Manageability >> considerations. >> > > KT> Could you please clarify/explain a bit further what you feel is > missing? > > >> >> >> I couldn't find a related discussion in the archive. If I missed it, >> please >> point me in the right direction. >> >> >> >> (2) =C2=A75.1: >> >> Types A or B MUST be used for the SIDs for which the reachability >> cannot be verified. Note that the first SID MUST always be reachable >> regardless of its type. >> >> These two requirements and the text in the description of these types >> ("...does >> not require the headend to perform SID resolution.") results in a >> contradiction: Types A and B are not to be resolved, but if they are the >> first >> SID then they MUST. If it's not a contradiction, then Types A and B >> would not >> be allowed to be the first SID, which is not correct because the most >> straightforward mechanism to define a path is to list SR-MPLS Labels or >> SRv6 >> SIDs. >> > > KT> I don't see a contradiction here. "Types A or B MUST be used for the > SIDs for which the reachability cannot be verified." is not the same as > saying "Type A or B are not to be resolved". > > >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> (0) I support John's DISCUSS. >> >> >> (1) Is the specification of a headend/endpoint mandatory? IOW, should >> the text >> in =C2=A72.1 about the headend/endpoint being identified by a unique IPv= 4 or >> IPv6 >> address be normative? >> > > KT> It is not normative since we have the case of an unspecified address > as an endpoint. We could use SHOULD though, if that clarifies. > > >> >> >> (2) =C2=A72.1: "An implementation MAY allow the assignment of a symbolic= name >> comprising of printable ASCII [RFC0020] [RFC5234] characters" >> >> Why are you normatively limiting the name to be represented in ASCII? >> Please >> internationalize it - use UTF-8. >> >> =C2=A72.6 also has similar text. >> > > KT> My understanding is that there is no compulsion to use UTF-8 for such > purposes. This was discussed in the WG. Please check: > https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/ > > >> >> >> (3) =C2=A72.1: "Such symbolic names MAY identify an SR Policy when the n= aming >> scheme >> ensures uniqueness." In this case, the "MAY" is just stating a fact. >> s/MAY/may >> > > KT> Ack. Will fix. > > >> >> >> (4) =C2=A72.1: "An SR Policy MAY have multiple names...in the scenario w= here >> the >> headend receives different SR Policy names" Describing multiple names >> as the >> case where multiple names are received is not helpful. >> > > KT> When CPs for the same SR Policy are provisioned via different sources= , > then such a scenario may occur. > > >> >> >> (5) =C2=A72.2: "the endpoints of the constituent SR Policies and the par= ent SR >> Policy >> MUST be identical" To avoid confusion, by "endpoints" you mean "headend >> and >> endpoint", right? >> > > KT> We mean the endpoint as in "the tail-end". We are speaking from withi= n > the context of a headend here so the headend is the same. > > >> >> >> (6) =C2=A72.3: >> >> A headend MAY be informed about a candidate path for an SR Policy >> by various means including... >> >> It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may >> > > KT> Ack. Will fix. > > >> >> >> (7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD be set= to 0 >> by >> default when not available or known." >> >> When is it ok for the ASN to not be set to 0 (when not available or >> known)? >> If that possibility exists, the PCE can use any value (including the rea= l >> number or a random one). What issues exist with uncoordinated (or rogue= ) >> PCEs >> using potentially arbitrary ASNs? >> >> Why is this action recommended and not required? >> > > KT> AFAIR PCEP signaling does not carry AS number. So this is a > recommendation, though a local policy or a future PCEP extension could > change that and we don't want to preclude it. > > >> >> >> (8) This paragraph in =C2=A72.5 seems to be missing something" >> >> The Discriminator is a 32-bit value associated with a candidate path >> that uniquely identifies it within the context of an SR Policy from a >> specific Protocol-Origin as specified below: >> >> "below" where? I guess you may mean "below in =C2=A72.6 (Identificatio= n of a >> Candidate Path)", but that section says that the "tuple >> uniquely identifies a >> candidate >> path" and not just the discriminator as above. >> > > KT> The next three paragraphs that begin with "When .." should be a bulle= t > list. Looks like it got missed out. > > >> >> Also, the ":" leads to some text about the default and specific protocol= s. >> Given that this document intends to provide an architecture, I would >> expect >> general consideration about the discriminator, and not pointers to how i= t >> can >> be signaled or, much less, the process in BGP. In general, I would >> expect the >> architecture to not rely on solution documents to explain how pieces of >> the >> architecture are derived. >> > > KT> These are informational pointers to the respective protocol specs to > help the reader. > > >> >> >> (9) Given the description, it seems possible for a PCE (for example) to >> advertise multiple candidate paths with the same Preference, Originator, >> and >> Discriminator. If that occurs, what is the result of the selection in >> =C2=A72.9? >> Would this situation result in multiple active candidate paths? >> > > KT> The ability to signal multiple CPs via PCEP is being introduced > via draft-ietf-pce-segment-routing-policy-cp. The default is for use when > not using that draft and in that case, there would be only a single CP. > > >> >> >> (10) =C2=A72.11: "Only the active candidate path SHOULD be used for forw= arding >> traffic that is being steered onto that policy." When is it ok to use >> non-active paths? Why is this action recommended and not required? >> > > KT> The condition was for path protection as described in section 9.3. Th= e > "backup" path is programmed and hence may be used for forwarding while FR= R > is active. > > >> >> >> (11) =C2=A72.12: Several of the "MAY" statements in this section express= a >> fact, not >> a normative statement: s/MAY/may >> >> The operator MAY set this field... >> An SR Policy MAY comprise multiple... >> > > KT> Ack. Will fix those. > >> >> >> (12) =C2=A74: >> >> When the algorithm is not specified for the SID types above which >> optionally allow for it, the headend SHOULD use the Strict Shortest >> Path algorithm if available; otherwise, it SHOULD use the default >> Shortest Path algorithm. >> >> In this sentence, you're recommending both algorithms. When should one >> or the >> other be used? There are no qualifiers that lead to the "otherwise" >> statement. >> > > KT> Ack. The semicolon needs to be replaced by "and" before "otherwise". > > >> >> >> (13) =C2=A74: What is the purpose of enumerating the types of >> segment-descriptors? >> Should the type be indicated when the Segment-List is signaled? I assum= e >> the >> answer is yes, but I didn't see that specified anywhere. >> > > KT> It is used in the protocol specs for reference - > e.g draft-ietf-idr-segment-routing-te-policy > > >> >> >> (14) =C2=A75.1: "The headend detects a mismatch between the SID value an= d its >> context provided for SIDs of type C-through-K" What does having a >> mismatch >> mean? Please be specific. >> > > KT> The value of the SID provided does not match the value of the SID > determined through the provided context. Will clarify. > > >> >> >> (15) =C2=A75.2: >> >> When the local computation is not possible (e.g., a policy's tail-end >> is outside the topology known to the headend) or not desired, the >> headend MAY send path computation request to a PCE supporting PCEP >> extension specified in [RFC8664]. >> >> This action (ask the PCE) is a solution, not an architectural >> description. Are >> there other external mechanisms that can find a "solution Segment-List"? >> It >> seems to me that one such mechanism would be in the form of a configured >> Segment-List. If that is correct, please generalize the normative >> statement >> above -- where using PCEP can be an example. >> > > KT> Agree and will change that to an example. > >> >> >> (16) =C2=A77: Which are valid states? Active is one, the text mentions = an >> "administrative state", what else? Interoperability is a good reason t= o >> specify the states and not assume that implementations might do the righ= t >> thing. >> > > KT> The state here does not mean a single one like up/down. It is > referring to the operational state. Those aspects are covered in > the draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP > when those protocols are in use. We'll add a reference > to draft-ietf-spring-sr-policy-yang. > > >> >> >> (17) =C2=A77: "The SR Policy state MUST also reflect the reason when a p= olicy >> and/or >> its candidate path is not active due to validation errors or not being >> preferred." >> >> Given that this is a requirement, please provide a list of reasons. The >> need >> for interoperability (by using rfc2119 language) can only be achieved if >> the >> reasons are standardized. >> > > KT> The reason is for debugging and troubleshooting. If something is down > or invalid, then it helps to know why. > > >> >> >> (18) In general, the text contains a mixture of normative language >> (rfc2119) >> and descriptions that make the contents inconsistent and confusing. For >> example, my interpretation of "an SR Policy and its BSID are removed fro= m >> the >> forwarding plane" (from =C2=A78.1) is that it is an absolute requirement= . >> However, >> =C2=A78.2 presents the optional "Drop-Upon-Invalid behavior" which then >> indicates >> that there can be cases where my interpretation was not correct. >> >> The point here is that the text in a Standards Track document should not >> be up >> for interpretation. >> >> There are too many cases in the text to list that would have benefitted >> from >> using Normative Language -- I mentioned a couple above. Ideally, the >> authors >> would make one more pass for clarity. However, I will probably end up >> ABSTAINing because of it. >> >> This point was also raised in the rtg-dir review, which is why I'm not >> including it as part of a DISCUSS. >> > > KT> Authors will take a pass and get back on this. > > Thanks, > Ketan > > > --000000000000297dc305d83ae226 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

We've just posted an upd= ate to address the comments raised by you and other ADs:=C2=A0https://datatracker.ietf.org/doc= /html/draft-ietf-spring-segment-routing-policy-18

<= div>Note that we've now tagged the document as updating RFC8402 per the= discussions and feedback from the Telechat earlier today.

Thanks,
Ketan


On Thu, Feb 17, 2022= at 8:36 PM Ketan Talaulikar <k= etant.ietf@gmail.com> wrote:
Hi Alvaro,

Thanks for your review and comments/inputs. Please check inline be= low for responses.


On Thu, Feb 17, 2022 at 3:29 AM Alva= ro Retana via Datatracker <noreply@ietf.org> wrote:
Alvaro Retana has entered the following ballot pos= ition for
draft-ietf-spring-segment-routing-policy-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) This specification should formally Update rfc8402.

What is the relationship between this document and rfc8402?=C2=A0 If this d= ocument
details the concept introduced in rfc8402, why isn't there a formal Upd= ate
relationship?

Even the initial definition of SR Policy in this document (=C2=A72) doesn&#= 39;t match
what rfc8402 says.=C2=A0 This document defines it as "a framework that= enables the
instantiation of an ordered list of segments", while rfc8402 states it= is "an
ordered list of segments."=C2=A0 In =C2=A72.2, this document uses the = term
"segment-list" for that.

KT&g= t; There were similar comments from Rob for which we have recently posted u= pdated text in v17. I believe, this document does not need to update RFC840= 2 because it is not changing anything in that document. RFC8402 simply intr= oduces SR Policy while this document specifies its internal constructs, how= it is realized/instantiated, and steering mechanisms over it. At least, th= at is the objective/view of the authors/WG and we are open to inputs to upd= ate and further clarify the same.
=C2=A0

Besides the general topic of clarifying and updating what an SR Policy is, = this
document also includes other items that were not present in rfc8402; the li= st
includes:

=C2=A0 =C2=A0=C2=A72.1: "SR Policy MUST be identified through the tupl= e <headend, color,
=C2=A0 =C2=A0endpoint>."=C2=A0 =C2=A0There's not even a mention= of "color" in rfc8402.

=C2=A0 =C2=A0=C2=A72.1: "The headend is specified as an IPv4 or IPv6 a= ddress and is expected
=C2=A0 =C2=A0to be unique in the domain."=C2=A0 Neither the mechanism = to identify a node nor
=C2=A0 =C2=A0the expectation is present in rfc8402.

=C2=A0 =C2=A0=C2=A72.1: "The endpoint is specified as an IPv4 or IPv6 = address and is expected
=C2=A0 =C2=A0to be unique in the domain."=C2=A0 =C2=A0Same as above.

KT> Yes, these are the constructs of = SR Policy that are specified by this document.
=C2=A0


The SR Database is a new element not in the base architecture.=C2=A0 The te= xt in =C2=A73
says that "use of the SR-DB for computation and validation of SR Polic= ies is
outside the scope of this document", but it is then mentioned and used= in
=C2=A75.1/=C2=A75.2.

KT> The computa= tion algorithm and related discussions about the use of SR-DB were asked to= be moved out of this standards track document during the WG process. Those= informational sections were moved into draft-filsfils-spring-sr-policy-considerations=C2=A0and kept as a= reference in this document. The reference in 5.1 and 5.2 is about validati= on of segments and as a result the segment-list and candidate path. The val= idation of the "objective" and constraints of the SR Policy was d= eemed to be outside the scope of the document. There were several discussio= ns on and off-list at the IETF meetings in this regard. Perhaps this thread= gives a good summary:=C2=A0https://mailarchiv= e.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/=C2=A0
=C2=A0


Accordingly, the added details require additional Security and Manageabilit= y
considerations.

KT> Could you please= clarify/explain a bit further what you feel is missing?
=C2=A0


I couldn't find a related discussion in the archive.=C2=A0 If I missed = it, please
point me in the right direction.



(2) =C2=A75.1:

=C2=A0 =C2=A0Types A or B MUST be used for the SIDs for which the reachabil= ity
=C2=A0 =C2=A0cannot be verified.=C2=A0 Note that the first SID MUST always = be reachable
=C2=A0 =C2=A0regardless of its type.

These two requirements and the text in the description of these types (&quo= t;...does
not require the headend to perform SID resolution.") results in a
contradiction: Types A and B are not to be resolved, but if they are the fi= rst
SID then they MUST.=C2=A0 If it's not a contradiction, then Types A and= B would not
be allowed to be the first SID, which is not correct because the most
straightforward mechanism to define a path is to list SR-MPLS Labels or SRv= 6
SIDs.

KT> I don't see a contradi= ction here. "Types A or B MUST be used for the SIDs for which the reac= hability cannot be verified." is not the same as saying "Type A o= r B are not to be resolved".=C2=A0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) I support John's DISCUSS.


(1) Is the specification of a headend/endpoint mandatory?=C2=A0 IOW, should= the text
in =C2=A72.1 about the headend/endpoint being identified by a unique IPv4 o= r IPv6
address be normative?

KT> It is not = normative since we have the case of an unspecified address as an endpoint. = We could use SHOULD though, if that clarifies.
=C2=A0


(2) =C2=A72.1: "An implementation MAY allow the assignment of a symbol= ic name
comprising of printable ASCII [RFC0020] [RFC5234] characters"

Why are you normatively limiting the name to be represented in ASCII?=C2=A0= Please
internationalize it - use UTF-8.

=C2=A72.6 also has similar text.

KT>= My understanding is that there is no compulsion to use UTF-8 for such purp= oses. This was discussed in the WG. Please check:=C2=A0https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIl= J2Yq_w/=C2=A0
=C2=A0


(3) =C2=A72.1: "Such symbolic names MAY identify an SR Policy when the= naming scheme
ensures uniqueness."=C2=A0 In this case, the "MAY" is just s= tating a fact.
s/MAY/may

KT> Ack. Will fix.
=C2=A0


(4) =C2=A72.1: "An SR Policy MAY have multiple names...in the scenario= where the
headend receives different SR Policy names"=C2=A0 =C2=A0Describing mul= tiple names as the
case where multiple names are received is not helpful.

KT> When CPs for the same SR Policy are provisioned via = different sources, then such a scenario may occur.
=C2=A0


(5) =C2=A72.2: "the endpoints of the constituent SR Policies and the p= arent SR Policy
MUST be identical"=C2=A0 To avoid confusion, by "endpoints" = you mean "headend and
endpoint", right?

KT> We mean t= he endpoint as in "the tail-end". We are speaking from within the= context of a headend here so the headend is the same.
=C2=A0


(6) =C2=A72.3:

=C2=A0 =C2=A0A headend MAY be informed about a candidate path for an SR Pol= icy
=C2=A0 =C2=A0<color, endpoint> by various means including...

It seems like the "MAY" is only stating a fact -- if so, then s/M= AY/may

KT> Ack. Will fix.
= =C2=A0


(7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD be s= et to 0 by
default when not available or known."

When is it ok for the ASN to not be set to 0 (when not available or known)?=
If that possibility exists, the PCE can use any value (including the real number or a random one).=C2=A0 What issues exist with uncoordinated (or rog= ue) PCEs
using potentially arbitrary ASNs?

Why is this action recommended and not required?

<= /div>
KT> AFAIR PCEP signaling does not carry AS number. So this is = a recommendation, though a local policy or a future PCEP extension could ch= ange that and we don't want to preclude it.
=C2=A0


(8) This paragraph in =C2=A72.5 seems to be missing something"

=C2=A0 =C2=A0The Discriminator is a 32-bit value associated with a candidat= e path
=C2=A0 =C2=A0that uniquely identifies it within the context of an SR Policy= from a
=C2=A0 =C2=A0specific Protocol-Origin as specified below:

"below" where?=C2=A0 =C2=A0I guess you may mean "below in = =C2=A72.6 (Identification of a
Candidate Path)", but that section says that the "tuple
<Protocol-Origin, originator, discriminator> uniquely identifies a ca= ndidate
path" and not just the discriminator as above.
KT> The next three paragraphs that begin with "When ..= " should be a bullet list. Looks like it got missed out.
=C2= =A0

Also, the ":" leads to some text about the default and specific p= rotocols.
Given that this document intends to provide an architecture, I would expect=
general consideration about the discriminator, and not pointers to how it c= an
be signaled or, much less, the process in BGP.=C2=A0 In general, I would ex= pect the
architecture to not rely on solution documents to explain how pieces of the=
architecture are derived.

KT> These = are informational pointers to the respective protocol specs to help the rea= der.
=C2=A0


(10) =C2=A72.11: "Only the active candidate path SHOULD be used for fo= rwarding
traffic that is being steered onto that policy."=C2=A0 =C2=A0When is i= t ok to use
non-active paths?=C2=A0 Why is this action recommended and not required?

KT> The condition was for path protect= ion as described in section 9.3. The "backup" path is programmed = and hence may be used for forwarding while FRR is active.
=C2=A0<= /div>


(11) =C2=A72.12: Several of the "MAY" statements in this section = express a fact, not
a normative statement:=C2=A0 s/MAY/may

The operator MAY set this field...
An SR Policy MAY comprise multiple...

K= T> Ack. Will fix those.=C2=A0


(12) =C2=A74:

=C2=A0 =C2=A0When the algorithm is not specified for the SID types above wh= ich
=C2=A0 =C2=A0optionally allow for it, the headend SHOULD use the Strict Sho= rtest
=C2=A0 =C2=A0Path algorithm if available; otherwise, it SHOULD use the defa= ult
=C2=A0 =C2=A0Shortest Path algorithm.

In this sentence, you're recommending both algorithms.=C2=A0 When shoul= d one or the
other be used?=C2=A0 There are no qualifiers that lead to the "otherwi= se" statement.

KT> Ack. The sem= icolon needs to be replaced=C2=A0by "and"=C2=A0 before "othe= rwise".
=C2=A0


(13) =C2=A74: What is the purpose of enumerating the types of segment-descr= iptors?
Should the type be indicated when the Segment-List is signaled?=C2=A0 I ass= ume the
answer is yes, but I didn't see that specified anywhere.

KT> It is used in the protocol specs for reference= - e.g=C2=A0draft-ietf-idr-segment-routing-te-policy
=C2=A0
=


(14) =C2=A75.1: "The headend detects a mismatch between the SID value = and its
context provided for SIDs of type C-through-K"=C2=A0 What does having = a mismatch
mean?=C2=A0 Please be specific.

KT> = The value of the SID provided does not match the value of the SID determine= d through the provided context. Will clarify.
=C2=A0


(15) =C2=A75.2:

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy'= ;s tail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, = the
=C2=A0 =C2=A0headend MAY send path computation request to a PCE supporting = PCEP
=C2=A0 =C2=A0extension specified in [RFC8664].

This action (ask the PCE) is a solution, not an architectural description.= =C2=A0 Are
there other external mechanisms that can find a "solution Segment-List= "?=C2=A0 It
seems to me that one such mechanism would be in the form of a configured Segment-List.=C2=A0 If that is correct, please generalize the normative sta= tement
above -- where using PCEP can be an example.

KT> Agree and will change that to an example.=C2=A0


(16) =C2=A77: Which are valid states?=C2=A0 Active is one, the text mention= s an
"administrative state", what else?=C2=A0 =C2=A0Interoperability i= s a good reason to
specify the states and not assume that implementations might do the right t= hing.

KT> The state here does not me= an a single one like up/down. It is referring to the operational state. Tho= se aspects are covered in the=C2=A0draft-ietf-spring-sr-policy-yang but als= o reported via BGP and PCEP when those protocols are in use. We'll add = a reference to=C2=A0draft-ietf-spring-sr-policy-yang.
=C2=A0


(17) =C2=A77: "The SR Policy state MUST also reflect the reason when a= policy and/or
its candidate path is not active due to validation errors or not being
preferred."

Given that this is a requirement, please provide a list of reasons.=C2=A0 T= he need
for interoperability (by using rfc2119 language) can only be achieved if th= e
reasons are standardized.

KT> The re= ason is for debugging and troubleshooting. If something is down or invalid,= then it helps to know why.
=C2=A0


(18) In general, the text contains a mixture of normative language (rfc2119= )
and descriptions that make the contents inconsistent and confusing.=C2=A0 F= or
example, my interpretation of "an SR Policy and its BSID are removed f= rom the
forwarding plane" (from =C2=A78.1) is that it is an absolute requireme= nt.=C2=A0 However,
=C2=A78.2 presents the optional "Drop-Upon-Invalid behavior" whic= h then indicates
that there can be cases where my interpretation was not correct.

The point here is that the text in a Standards Track document should not be= up
for interpretation.

There are too many cases in the text to list that would have benefitted fro= m
using Normative Language -- I mentioned a couple above.=C2=A0 Ideally, the = authors
would make one more pass for clarity.=C2=A0 However, I will probably end up=
ABSTAINing because of it.

This point was also raised in the rtg-dir review, which is why I'm not<= br> including it as part of a DISCUSS.

KT&g= t; Authors will take a pass and get back on this.=C2=A0

Thanks,
Ketan

=C2=A0
--000000000000297dc305d83ae226-- From nobody Thu Feb 17 23:15:24 2022 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 A80463A0C9F; Thu, 17 Feb 2022 23:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.639 X-Spam-Level: X-Spam-Status: No, score=-6.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZuSJ89JbseJ; Thu, 17 Feb 2022 23:15:10 -0800 (PST) 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 B27513A0C9E; Thu, 17 Feb 2022 23:15:07 -0800 (PST) Received: by mail.swisscom.com; Fri, 18 Feb 2022 08:15:03 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_1812520_661749683.1645168502914" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AD1RetDOOTtV2W1kBw5laxRiBgPEWcHg8FWFseyoebnu3oKcIXNYbxslMKyWBkgJCnpjY5cO00JJWPk565XJv9huNpxNQctul1KJb+qcYGnKM2MHD8PU7QITnYEddAafn9BXVi9khrPHqzxTAxrUualkoNDN0e7USJwQNBdulvHMUKSLnNrMHPI4wds03S090NNu0yfl8c8Shzx/EnwjLkQiLdXlTbGnUI4u8O50NzCRlYrFZsDBAcwqAs91cJVZuPZWcVAo56J2FHxhGl/0K7uTPoJYwyyl7ADZE5pu8MBiRxzz1WMCQeuGuyPqTpvjbDk1xAqkneqC/GKw57rvJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZvGSaY2a/yd9Y4ItIeB0yIumNTJ+Z6qfefwcDcS1s8Q=; b=DHZ59mJJG9jITfU0HN1owbfCdfC6yz8rC6jylz87f0ZQD4IewzredfTBQYihDP9sfLgAFoDXskQWgEIcQpLtFop8oiVICk6kcSjwpSKji4KUJ+ukwUezxn6WMXrMQeO4ANFoxj8V6T8mths9gBvvp0qgfrUJsMKVGhUM/4KqlQIXagotx/SPxcTSDeVfp3dXKFKIfRUOxNtSZ9Z7YVgqc6PbR0QZ9PM1dnMX/RenKahJ/rvBmGI75bTZnxJCmo5FwATfIgug3wN+PLmHJdH0t0xNCo4ezhbbxygdxglQDXWXzwULp7ghQuIFnm2S1wZDMFEwMJFtDBJXQEl45AoFVA== 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] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt Thread-Index: AQHYIR0+gSHeeGbwFkKWa3nMKTJYrayY69Gg Date: Fri, 18 Feb 2022 07:14:59 +0000 Message-ID: References: <202202071741403841025@zte.com.cn> 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_SetDate=2022-02-18T07:14:58Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=9dd5f59d-8767-4483-b824-923251c06500; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32af8640-cd00-4574-4e84-08d9f2ae5fc3 x-ms-traffictypediagnostic: GVAP278MB0295:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u/duPL/2mB9MvRAssxzyW04wGQVXhACberYfasyTo7coRyF7NvxBRe4PpQZp9rGo2UBCTaQs+7YaSgCTMuob1B1cibS2mdac2gCLbeiYDbt1+0uFGm74lpK4l17qwM3Iwat2SX10Shu+vNocFLL8sPwsHmKkIJQwYXkTd/IM3UviVGKvV0womb0Yzs+JFGU5w/dpteRLngzzUBpnC3FZjPfMbrkvPHFOtQmJxArLwdJB9jY5Fl3wQX+fnNrmM2DT4/TvxxHbgi4RnilkR3TS0/HlKFKoNcMPPaQ3APaVKQeN4vMXkkabDsztFh90do8alzo8uo5EHbSxSqGuy0eazA1+7NPBTZ+mI3lUANicSwLc8e9gQZHXSpXxwzQOZ9vtXiX7Lzii5wkRYmUn2XuTtlJprwUgcyls+4krqnFo27YhyMrwT+rIn5fMFTpjvLh5Nf7dIP049pKNDj1ghV+2sjpAgnzLye7s//ACkJf/EX0KTsewzsixU9J2wtpataUZerZ8RNCxb38enCcv7CDQdb5Gxa7vmKp/TqrWY9HtsCZsnvAbhKoCDBoAmTg4gVx/7G0P9ztbOKKM+NfXu7VYxVzAFenI1rYJdA5c3qDIF8rfnDltB0L1c1I+CTvkQVGe9LJazGmKVxy1zJBZbsQyN5Gfku7kdtRKIJgE21Wgnm0vGUWZlQ/dGpvLaoDj8bLvLQcU0rkBfGKGPuG8eL/30UFCH05hZNkLRQ+Wp1lkGT7jN9ojfzvKGZclBooVdcncOpk+anQqxGlNRwbC/3GoH6C8/TV4H7fIeZzr+pOoqtQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(316002)(19627235002)(66574015)(5660300002)(186003)(26005)(122000001)(82960400001)(6916009)(54906003)(8936002)(166002)(55016003)(83380400001)(53546011)(7696005)(6506007)(10300500001)(2906002)(966005)(10290500003)(10440500001)(508600001)(86362001)(38100700002)(30864003)(45080400002)(52536014)(71200400001)(9686003)(15650500001)(66946007)(8676002)(33656002)(66556008)(64756008)(66476007)(66446008)(76116006)(4326008)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YzlsaVlXemNnZ2huRmx2d2xoc3hSeXJHWmhwVGdVWTJoRWVMeE9tSG44d1JM?= =?utf-8?B?Y25LWDA4ZUl3Z1g0SnhkUnRKMEVVRXpCZG9RR1kyblZzRFBwdUNNMTl0RTF3?= =?utf-8?B?cmpaQzF3YkVUMmd2VHREeC9hYmdtVTFSZTdrTXJ5QUNrVFJSNy9rdlFTd0tL?= =?utf-8?B?ZjNXcTVnUkxKKzdubkY4eVZZbEJyYkJRNi8wNU9pZjhLQmtZL2JPOStxdUtp?= =?utf-8?B?Syt4Z3hWdnhwYTR3aisxRDdJOE45VHVrY0ZjRU9PdFVCbHZSMWNyVHBHOS9p?= =?utf-8?B?c0FmU1B3Q3ZuRGNKakRwL0xMYXRyUlgzWlhSU1F2Zmd3a0dXaTZ2K2xZRk1R?= =?utf-8?B?b0tEZnVRbnYycEFnamtxMTg4YlBFSWh2N0N3VEJoWjdYMHZ4OVplVE1Qei9V?= =?utf-8?B?RHlWc0NXeXB3Zkh4VWhvdDVDWUd6QWMyQTJKMzRiMXJMdkExTnZLbi9tT2Rz?= =?utf-8?B?d0EwbnRaVTdzY3ZnaFBySkpMVzVKbDJaQzBlM0hVaEwrN3RIWHNkU0kyeEpT?= =?utf-8?B?aytlTjAzUHpTblhGM2lVa1Bnek15dUp4aEg5cDFNVVVhL0F4YVpJRzEzTlZD?= =?utf-8?B?eGh6L2pmV1pCZXJNZFJvYUxLY0xkemF2TXU0VnlxaEZqUlhnSkM1UHJ2QzYv?= =?utf-8?B?K09qNDQxSjdEcGlLcXJSTm4vaWgwbGtvRXdqeklHaTdwNmcwdjFrSUtGQ2Qw?= =?utf-8?B?emEyQXc1Z2dyaU92UmNRZTRKdEh2elBhVml6SEx2bkR2RHFyOUFEeFFRbVps?= =?utf-8?B?TEJEYm5ZSm9QV1NQRVNiNExvdk9PUi9BRlZxaUE4ajJ6cHZlRWlsQ3U3QW9i?= =?utf-8?B?ZXdzWE84VGVzc0pIVy9Ba3p1TDRiSzZ3UGNFTTVZT01UWGk5dE5RYVlRNnRR?= =?utf-8?B?bVJZS3d1dk5QVVdpaDhpcy9qbXF4RmdNZWVkV2x2UXlJZ0VjU2NCdy9ENi81?= =?utf-8?B?U1NEQWw2RDJLcHp5ei9Vc2NkVWlQNHpkbHBPdEo1RldadGFjVlo0Q0hTQVZx?= =?utf-8?B?U1NwR2c2TjdaZVA4cVVnQTJ4bTZLamRBQldBRm1hUFVPZG5LWDEzNGZKY3JZ?= =?utf-8?B?ZjdoenJEN2tvL2J2R3oxekpoL1lOTVFNd2c3aldUdG9OS1VDaFg2QTlRQVJQ?= =?utf-8?B?Q3hhWjJOWGpzWnRweVJSOWNxV0hTOFF1QlE2cERhMStZTUJMb2I2c0pBM0Nh?= =?utf-8?B?SWpoa0hsOFdQK3pZY003RmlVRFVNc0tveDcwaWNwMWJtaEk1K3BwSFI4bTF3?= =?utf-8?B?Si82QjVGYWdCQVhvOUs0eGJjMzNqNVZIOGtCa0p4OTdJc0Vsenp2eXlCOGVo?= =?utf-8?B?Y0tSOGZnY1hBVXNBTjJPZDhTdCs3K1VMZmFBSFRkWjU5V2RHVVlIY2VqU3Nr?= =?utf-8?B?SDNTQUp4aUhieFlHOXYwUlM1cXI4UWRzVEhNdUNqUkZsaGYxZFllWTY2ZlZp?= =?utf-8?B?cGtvVFYzSTdsZ0xmVzlXZnlyamRWcWxzdE5vckJRQ3QrdUlyKzlMMWxQS2oz?= =?utf-8?B?RG9vWkV6V3RuT2RHVU9pSy9Na0xBNGN3dFVMWnYxVjc0Q3MxaVlOMDJRbVFs?= =?utf-8?B?YWlpcDRvVUZ4UTQ1OEtJczg4VUxWekFMTUE3SUdXb1AvVDRuRGtac2VKcnAx?= =?utf-8?B?bE01R3JXVU82ZkVzODNCZkxhTTExNWdYa3JMc2thRGFPdWQxbnYvUE50d05s?= =?utf-8?B?L0dXNHI4NVQzMnJrOUpXU1RZd0oybHBkYldFRVhiQlJBRVBuUlVwVnZsRjND?= =?utf-8?B?VTYrOFVrd0g4eFZKUDFNRjNSUWgvNGhGRHBmR0xyYjhvQ1dEM0M4SUlQc2dH?= =?utf-8?B?NWp3NEcwVm1RbHNSSFFpMlZxYmh4NWkvQURqM3ZOcnlSOVBWOStLdkdjd3Yy?= =?utf-8?B?VkZxVVBsUHJvMmRPRk91RWJucmdERStwL0dmL1A5NTBJV2c1ZDFOc09YZmg0?= =?utf-8?B?Nzd5MGFhLzkxZ2psYjBidnhkL2dYdjd1WUlJQjBGcitaMG1MbGYxSVBHQUFS?= =?utf-8?B?b2wzanp6cDVFdXphV2NUejkyazlHWDhMdEtQSGsvMDlyYUNjM1ViNndwMkIz?= =?utf-8?B?L21Ra05JS2kxUW1CTFY1bkVUUUlJVGE3VDlmQUdSa0dRTjJhNG9NeU50Uy9h?= =?utf-8?B?b0NKdFljQW5VbmVWSStGeGpOelBzYkJWWnRqTC9GcTA1YXlNMUl4M0s5OUZh?= =?utf-8?B?RENuQnBMWWlGbElDc1VVK1ZpeXpjSW1rZEE3RXdMdGFxY3hQMmtGY3JycHpR?= =?utf-8?B?ekFYcmJweVVxcU1WMHBxSmc5eGtRPT0=?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 32af8640-cd00-4574-4e84-08d9f2ae5fc3 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2022 07:14:59.3721 (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: RDaV4V8biguFdvPeikgmA2ekZnb0iQFZlmW5av+lnBhNszrLcQap/Y0He0r7AvFdQv23FINL6S7Qoz1JXUYGvUnf4DTybYeZ47yTCQLH5lU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVAP278MB0295 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.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: Fri, 18 Feb 2022 07:15:19 -0000 ------=_Part_1812520_661749683.1645168502914 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB017621DBE533D68302AF9D1089379ZRAP278MB0176CHEP_" Content-Language: en-US --_000_ZRAP278MB017621DBE533D68302AF9D1089379ZRAP278MB0176CHEP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmtzIGZvciBicmluZ2luZyB0aGF0IHF1ZXN0aW9uIHVwLiBJIGFscmVh ZHkgY29uc2lkZXJlZCB0aGlzIGFzcGVjdC4NCg0KDQpBcyBkZXNjcmliZWQgaW4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LXNyaC1j b21wcmVzc2lvbi0wMC5odG1sI3NlY3Rpb24tMiwgdGhlIGNvbXByZXNzZWQtU0lEIGNvbnRhaW5l ciAoQy1TSUQgY29udGFpbmVyKSBpcyAxMjgtYml0IGxvbmcgYW5kIGNvbnRhaW5zIGEgc2VxdWVu Y2Ugb2YgQy1TSURzLiBUaGVyZWZvcmUgdGhlIGlwdjZTUkhTZWdtZW50TGlzdA0KDQpjb250YWlu cyBlaXRoZXIgYSBsaXN0IG9mIElQdjYgU0lEJ3MsIGEgbGlzdCBvZiBjb21wcmVzc2VkLVNJRCBj b250YWluZXJzIG9yIGJvdGguIFRoZXkgYXJlIG5vdCBtdXR1YWxseSBleGNsdXNpdmUuDQoNCg0K DQpJdCBwcm9iYWJseSBtYWtlcyBzZW5zZSB0byBhZGQgYW4gb3BlcmF0aW9uYWwgY29uc2lkZXJh dGlvbiBzZWN0aW9uIGluIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaCB0byBkZXNj cmliZSB0aGUgdXNlIG9mIEMtU0lEIGNvbnRhaW5lcnMgYW5kIGl0cyBjb250ZXh0IHRvIGlwdjZT UkhTZWdtZW50VHlwZS4gRnJvbSB3aGF0IEkgdW5kZXJzdG9vZCwgYW5kIGhlcmUgSSB3b3VsZCBs aWtlIHRvIGhhdmUgZmVlZGJhY2sgZnJvbSB0aGUgbWFpbGluZyBsaXN0LCBpdCBkb2VzIG5vdCBi cmluZyBtdWNoIGFkZGVkIHZhbHVlIHRvIGRlY29tcG9zZSB0aGUgQy1TSUQgY29udGFpbmVyIGlu dG8gQ29tcHJlc3NlZC1TSUQgKEMtU0lEKSBpbiBJUEZJWC4NCg0KDQoNCkJlc3Qgd2lzaGVzDQoN ClRob21hcw0KDQpGcm9tOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KU2Vu dDogU3VuZGF5LCBGZWJydWFyeSAxMywgMjAyMiAxMDowNCBQTQ0KVG86IEdyYWYgVGhvbWFzLCBJ TkktTkVULVRDWi1aSDEgPFRob21hcy5HcmFmQHN3aXNzY29tLmNvbT4NCkNjOiBsaXUueWFvNzFA enRlLmNvbS5jbjsgc3ByaW5nIDxzcHJpbmdAaWV0Zi5vcmc+OyBvcHNhd2cgPG9wc2F3Z0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQNCg0KSGkgVGhvbWFzLCBl dCBhbC4sDQp3aGF0IGRvIHlvdSB0aGluayBvZiB0aGUgbmV3IFNQUklORyBXRyBkcmFmdCB0aGF0 IGludHJvZHVjZXMgdHdvIG1ldGhvZHMgb2YgdGhlIGNvbXByZXNzZWQgU1J2NiBTSUQgbGlzdCBl bmNvZGluZyBpbiB0aGUgU1JIPGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJG aHRtbCUyRmRyYWZ0LWlldGYtc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLTAwJmRhdGE9MDQl N0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMzg3NGQ1MGI0NzAyNGU1ODdhOWUw OGQ5ZWYzNDVmZWUlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdD NjM3ODAzODMwNDg4MjA4OTM4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMw MDAmc2RhdGE9a0hzRVZTdE9nZWk2dG0wT2dRMDBVZWFrSCUyRjJaZm5HZzNxbjU1R21hJTJCODQl M0QmcmVzZXJ2ZWQ9MD4/DQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFNhdCwgRmViIDEyLCAyMDIy IGF0IDEyOjEwIEFNIDxUaG9tYXMuR3JhZkBzd2lzc2NvbS5jb208bWFpbHRvOlRob21hcy5HcmFm QHN3aXNzY29tLmNvbT4+IHdyb3RlOg0KRGVhciBZYW8sDQoNClRoYW5rcyBhIGxvdCBmb3IgdGhl IGRldGFpbGVkIGRlc2NyaXB0aW9uLiBCb3RoIHVuZGVyc3Rvb2QsICBhY2tub3dsZWRnZWQgYW5k IGJlaW5nIG1lcmdlZCB0byB0aGUgLTAxIHZlcnNpb24uIEZlZWRiYWNrIHdlbGNvbWUuDQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1odHRwczovL3Jhdy5naXRodWJ1c2VyY29u dGVudC5jb20vZ3JhZjNuZXQvZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoL21haW4v ZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAwLnR4dCZ1cmwyPWh0dHBzOi8vcmF3 LmdpdGh1YnVzZXJjb250ZW50LmNvbS9ncmFmM25ldC9kcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgt c3J2Ni1zcmgvbWFpbi9kcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDEudHh0PGh0 dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRnJmY2RpZmYlM0Z1cmwxJTNEaHR0cHMlM0ElMkYlMkZyYXcu Z2l0aHVidXNlcmNvbnRlbnQuY29tJTJGZ3JhZjNuZXQlMkZkcmFmdC10Z3JhZi1vcHNhd2ctaXBm aXgtc3J2Ni1zcmglMkZtYWluJTJGZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAw LnR4dCUyNnVybDIlM0RodHRwcyUzQSUyRiUyRnJhdy5naXRodWJ1c2VyY29udGVudC5jb20lMkZn cmFmM25ldCUyRmRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaCUyRm1haW4lMkZkcmFm dC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDEudHh0JmRhdGE9MDQlN0MwMSU3Q1Rob21h cy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMzg3NGQ1MGI0NzAyNGU1ODdhOWUwOGQ5ZWYzNDVmZWUl N0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3ODAzODMwNDg4 MjA4OTM4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9VER4 bVZTN1ZBYUM1bUlsa1VrNTNJM2VuTXB0JTJGOCUyQkxwVjlxcmtwQ0FXS2clM0QmcmVzZXJ2ZWQ9 MD4NCg0KSSB3aWxsIHB1Ymxpc2ggLTAxIGluIHRoZSB1cGNvbWluZyB3ZWVrcyBiZWZvcmUgSUVU RiAxMTMuDQoNCkJlc3Qgd2lzaGVzDQpUaG9tYXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGxpdS55YW83MUB6dGUuY29tLmNuPG1haWx0bzpsaXUueWFvNzFAenRlLmNvbS5j bj4gPGxpdS55YW83MUB6dGUuY29tLmNuPG1haWx0bzpsaXUueWFvNzFAenRlLmNvbS5jbj4+DQpT ZW50OiBNb25kYXksIEZlYnJ1YXJ5IDcsIDIwMjIgMTA6NDIgQU0NClRvOiBHcmFmIFRob21hcywg SU5JLU5FVC1UQ1otWkgxIDxUaG9tYXMuR3JhZkBzd2lzc2NvbS5jb208bWFpbHRvOlRob21hcy5H cmFmQHN3aXNzY29tLmNvbT4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTpbc3ByaW5nXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQNCg0KSGkgVGhvbWFzLA0K DQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuIFBsZWFzZSBzZWUgaW5saW5lIFtZYW8yXS4NCj4g W1lhb10gU2VnbWVudHMgbGVmdCBpcyBvbmUgb2YgdGhlIGVsZW1lbnRzIHRvIGlkZW50aWZ5IGFu IFNSSC4gRm9yIGV4YW1wbGUsIChTQSxEQT1TSURCKSAoU0lEQixTSURDLFNJREIsU0lEQTsgU0w9 MikgYW5kIChTQSxEQT1TSURCKSAoU0lEQixTSURDLFNJREIsU0lEQTsgU0w9MCkgYXJlIGRpZmZl cmVudC4gU28gSSB0aGluayBzZWdtZW50cyBsZWZ0IGlzIGFsc28gdXNlZnVsIHdoZW4gZXhwb3J0 aW5nIFNSdjYgaW5mb3JtYXRpb24uDQpXb3VsZCB5b3UgYWdyZWUgdGhhdCBpcHY2U1JIU2VnbWVu dExpc3QgYXQgbm9kZSBlZ3Jlc3Mgd291bGQgYmUgZXF1YWwgdG8gU2VnbWVudHMgbGVmdD8gT3Ig aW4gb3RoZXIgd29yZHMgc2VnbWVudHMgbGVmdCB3b3VsZCBvbmx5IGRpZmZlciBhdCBpbmdyZXNz IHRvIGlwdjZTUkhTZWdtZW50TGlzdC4gQ29ycmVjdD8gSWYgeWVzLCB0aGFuIEkgdGhpbmsgSSBn b3QgeW91ciBwb2ludC4gV291bGQgeW91IHBsZWFzZSBkZXNjcmliZSBtZSB3aGF0IGtpbmQgb2Yg dXNlIGNhc2UgeW91IGhhdmUgaW4gbWluZC4NCltZYW8yXSBJIG1lYW4gd2l0aG91dCBzZWdtZW50 IGxlZnQsIGl0J3MgZGlmZmljdWx0IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gcGFja2V0cyBvZiB0 aGUgc2FtZSBzZWdtZW50IGxpc3QgaW4gc29tZSBjYXNlcy4NCkJlbG93IGlzIG9uZSBzY2VuYXJp byBJIGNhbiB0aGluayBvZi4gVGhlIGNvcnJlc3BvbmRpbmcgc2VnbWVudCBsaXN0IG9mIHBhdGgg MS0tQS0tMi0tMy0tMS0tQS0tNCBpcyA8U0lELTEsU0lELUEsU0lELTIsU0lELTMsU0lELTEsU0lE LUEsU0lELTQ+Lg0KICAgIDMNCiAgLyAgIFwNCiAvICAgICBcDQoxICAgICAgIDINCiBcICAgICAv DQogIFwgICAvDQogICAgQS0tLS0tNA0KVGhlIGZsb3cgcGFzc2VzIG5vZGUgQSB0d2ljZS4NClRo ZSBmaXJzdCB0aW1lLCB0aGUgcGFja2V0IGlzIChTQSxEQT1TSUQtQSk8U0lELTEsU0lELUEsU0lE LTIsU0lELTMsU0lELTEsU0lELUEsU0lELTQ7IHNlZ21lbnQgbGVmdD01Pi4NClRoZSBzZWNvbmQg dGltZSwgdGhlIHBhY2tldCBpcyAoU0EsREE9U0lELUEpPFNJRC0xLFNJRC1BLFNJRC0yLFNJRC0z LFNJRC0xLFNJRC1BLFNJRC00OyBzZWdtZW50IGxlZnQ9MT4uDQpJZiBvbmUgd2FudHMgdG8gY29s bGVjdCB0aGUgaW5mbyBvZiB0aGVzZSB0d28gdHJhZmZpYyBzZXBhcmF0ZWx5LCB0aGUgc2VnbWVu dCBsZWZ0IGVsZW1lbnQgaXMgbmVlZGVkLg0KQnV0IHRvIGJlIGhvbmVzdCwgSSdtIG5vdCBzdXJl IHdoZXRoZXIgdGhpcyByZXF1aXJlbWVudCBpcyBzdHJvbmcuDQoNCj4gW1lhb10gSSBtZWFuIHRo YXQgSVBGSVggSUUgZm9yIFNSSCBUTFYgaXMgbm90IGRlZmluZWQgaW4gdGhlIGRyYWZ0IHdoaWxl IG90aGVyIG1haW4gZWxlbWVudHMgb2YgU1JIKFNSSEZsYWdzLFNSSFRhZyxpcHY2U1JIU2VnbWVu dExpc3QuLi4pIGFyZSBkZWZpbmVkLiBXaGF0IGlmIHRoZSB1c2VyIHdhbnQgdG8gZXhwb3J0IHRo ZSBTUkggVExWIGluZm8gb2YgdGhlIHBhY2tldHM/DQpZb3UgbWVhbiB0aGUgZW50aXJlIFNSSCBo ZWFkZXIgd2l0aG91dCBkaXNhc3NlbWJsZSB0aGUgZGltZW5zaW9ucyBpbnRvIElQRklYIGVudGl0 aWVzLiBMaWtlIElFIDMxNiBtcGxzTGFiZWxTdGFja1NlY3Rpb24uIENvcnJlY3Q/IEkgdGhpbmsg dGhpcyBtYWtlcyBhIGxvdCBvZiBzZW5zZSBhbmQgSSBjb25zaWRlciB0aGlzIHRvIHRoZSAtMDEg dmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuDQpbWWFvMl0gWWVzLCB0aGF0J3Mgd2hhdCBJIG1lYW4u DQoNCkJlc3QgUmVnYXJkcywNCllhbw0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLeWOn+Wn i+mCruS7ti0tLS0tLS0tLS0tLS0tLS0tLQ0K5Y+R5Lu25Lq677yaVGhvbWFzLkdyYWZAc3dpc3Nj b20uY29tPG1haWx0bzpUaG9tYXMuR3JhZkBzd2lzc2NvbS5jb20+DQrmlLbku7bkurrvvJrliJjl sKcwMDE2NTI4NjsNCuaKhOmAgeS6uu+8mnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPjsNCuaXpSDmnJ8g77yaMjAyMuW5tDAx5pyIMzDml6UgMTQ6MTcNCuS4uyDpopgg77ya UmU6IFtzcHJpbmddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGdyYWYtb3Bz YXdnLWlwZml4LXNydjYtc3JoLTAwLnR4dA0KSGkgWWFvDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIg aW5wdXQuDQo+IFtZYW9dIFNlZ21lbnRzIGxlZnQgaXMgb25lIG9mIHRoZSBlbGVtZW50cyB0byBp ZGVudGlmeSBhbiBTUkguIEZvciBleGFtcGxlLCAoU0EsREE9U0lEQikgKFNJREIsU0lEQyxTSURC LFNJREE7IFNMPTIpIGFuZCAoU0EsREE9U0lEQikgKFNJREIsU0lEQyxTSURCLFNJREE7IFNMPTAp IGFyZSBkaWZmZXJlbnQuIFNvIEkgdGhpbmsgc2VnbWVudHMgbGVmdCBpcyBhbHNvIHVzZWZ1bCB3 aGVuIGV4cG9ydGluZyBTUnY2IGluZm9ybWF0aW9uLg0KV291bGQgeW91IGFncmVlIHRoYXQgaXB2 NlNSSFNlZ21lbnRMaXN0IGF0IG5vZGUgZWdyZXNzIHdvdWxkIGJlIGVxdWFsIHRvIFNlZ21lbnRz IGxlZnQ/IE9yIGluIG90aGVyIHdvcmRzIHNlZ21lbnRzIGxlZnQgd291bGQgb25seSBkaWZmZXIg YXQgaW5ncmVzcyB0byBpcHY2U1JIU2VnbWVudExpc3QuIENvcnJlY3Q/IElmIHllcywgdGhhbiBJ IHRoaW5rIEkgZ290IHlvdXIgcG9pbnQuIFdvdWxkIHlvdSBwbGVhc2UgZGVzY3JpYmUgbWUgd2hh dCBraW5kIG9mIHVzZSBjYXNlIHlvdSBoYXZlIGluIG1pbmQuDQo+IFtZYW9dIEkgbWVhbiB0aGF0 IElQRklYIElFIGZvciBTUkggVExWIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBkcmFmdCB3aGlsZSBv dGhlciBtYWluIGVsZW1lbnRzIG9mIFNSSChTUkhGbGFncyxTUkhUYWcsaXB2NlNSSFNlZ21lbnRM aXN0Li4uKSBhcmUgZGVmaW5lZC4gV2hhdCBpZiB0aGUgdXNlciB3YW50IHRvIGV4cG9ydCB0aGUg U1JIIFRMViBpbmZvIG9mIHRoZSBwYWNrZXRzPw0KWW91IG1lYW4gdGhlIGVudGlyZSBTUkggaGVh ZGVyIHdpdGhvdXQgZGlzYXNzZW1ibGUgdGhlIGRpbWVuc2lvbnMgaW50byBJUEZJWCBlbnRpdGll cy4gTGlrZSBJRSAzMTYgbXBsc0xhYmVsU3RhY2tTZWN0aW9uLiBDb3JyZWN0PyBJIHRoaW5rIHRo aXMgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UgYW5kIEkgY29uc2lkZXIgdGhpcyB0byB0aGUgLTAxIHZl cnNpb24gb2YgdGhlIGRvY3VtZW50Lg0KTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgY2xhcmlmaWNh dGlvbnMuDQpCZXN0IHdpc2hlcw0KVGhvbWFzDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogbGl1LnlhbzcxQHp0ZS5jb20uY248bWFpbHRvOmxpdS55YW83MUB6dGUuY29tLmNuPiA8 bGl1LnlhbzcxQHp0ZS5jb20uY248bWFpbHRvOmxpdS55YW83MUB6dGUuY29tLmNuPj4NClNlbnQ6 IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMjIgMTA6MjcgQU0NClRvOiBHcmFmIFRob21hcywgSU5J LU5FVC1UQ1otWkgxIDxUaG9tYXMuR3JhZkBzd2lzc2NvbS5jb208bWFpbHRvOlRob21hcy5HcmFm QHN3aXNzY29tLmNvbT4+DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTpbc3ByaW5nXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQNCkhpIFRob21hcywNClBsZWFz ZSBzZWUgaW5saW5lIFtZYW9dLg0KQmVzdCBSZWdhcmRzLA0KWWFvDQotLS0tLS0tLS0tLS0tLS0t LS3ljp/lp4vpgq7ku7YtLS0tLS0tLS0tLS0tLS0tLS0NCuWPkeS7tuS6uu+8mlRob21hcy5HcmFm QHN3aXNzY29tLmNvbTxtYWlsdG86VGhvbWFzLkdyYWZAc3dpc3Njb20uY29tPg0K5pS25Lu25Lq6 77ya5YiY5bCnMDAxNjUyODY7DQrmioTpgIHkurrvvJpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz47DQrml6Ug5pyfIO+8mjIwMjLlubQwMeaciDIz5pelIDAxOjE2DQrkuLsg 6aKYIO+8mlJlOiBbc3ByaW5nXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRn cmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQNCkhpIFlhbywNCk1hbnkgdGhhbmtzIGZv ciB0aGUgcmV2aWV3IGFuZCBmZWVkYmFjay4NCj4gMSkgQnV0IHRoaXMgZHJhZnQgZGVzY3JpYmVz IHRoZSByb3V0aW5nIHByb3RvY29sIHdoZXJlIHRoZSBsYXN0IFNSdjYgc2VnbWVudCBoYXMgYmVl biBsZWFybmVkIGZyb20sIGluc3RlYWQgb2YgdGhlIFNSdjYgc2VnbWVudCB0byBiZSBwcm9jZXNz ZWQgYnkgdGhlIGN1cnJlbnQgaG9wLg0KSSBhbSBnb2luZyB0byByZXBocmFzZSB0aGUgc2VudGVu Y2VzIHRvIHJlZmVyIHRvIHRoZSBhY3RpdmUgc2VnbWVudC4gV2hpY2ggc2hvdWxkIG1ha2UgaXQg bGVzcyBhbWJpZ3VvdXMuDQo+IDIpIGJ1dCBpbiBTUnY2LCBzZWdtZW50IGxpc3QgYW5kIHNlZ21l bnRzIGxlZnQoY3VycmVudGx5IG5vdCBkZWZpbmVkIGluIHRoZSBkcmFmdCkgYXJlIGJvdGggbmVl ZGVkIHRvIHByb3ZpZGUgdGhlIHNpbWlsYXIgaW5mb3JtYXRpb24uDQpDb3VsZCB5b3UgZWxhYm9y YXRlIHRoZSB1c2UgY2FzZSBmb3Igc2VnbWVudHMgbGVmdCBpbiB0aGlzIGNvbnRleHQuIFRoaXMg ZG9jdW1lbnQgY292ZXJzIGFsbCBkaW1lbnNpb25zIGJlaW5nIHByZXNlbnQgaW4gdGhlIFNSdjYg c2VnbWVudCByb3V0aW5nIGhlYWRlciBkZXNjcmliZWQgaW4gc2VjdGlvbiBvZiBSRkM4NzU0ICho dHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4NzU0JTIzc2Vj dGlvbi0yJmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzAw OTM4OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUxZTQzJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVk MTliNTU3YTElN0MwJTdDMCU3QzYzNzc5ODIzNzMzOTUyMjA3NyU3Q1Vua25vd24lN0NUV0ZwYkda c2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dp TENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1uNlkweFgzRFQxQm11c09MYnVVWERaSGIy Q1ElMkJpSmxZJTJGU09QeEljVHI3YyUzRCZhbXA7cmVzZXJ2ZWQ9MDxodHRwczovL2V1cjAzLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4NzU0JTIzc2VjdGlvbi0yJmRhdGE9MDQl N0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMzg3NGQ1MGI0NzAyNGU1ODdhOWUw OGQ5ZWYzNDVmZWUlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdD NjM3ODAzODMwNDg4MjA4OTM4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMw MDAmc2RhdGE9SjRrUDJXMTBVM2xlVVBIT1JFUUQ5VDM4Y1JGTE4yaHBrJTJCNEpTUDdMM0tnJTNE JnJlc2VydmVkPTA+KSB3aXRoIHRoZSBleGNlcHRpb24gb2YgIkxhc3QgRW50cnkiLg0KW1lhb10g U2VnbWVudHMgbGVmdCBpcyBvbmUgb2YgdGhlIGVsZW1lbnRzIHRvIGlkZW50aWZ5IGFuIFNSSC4g Rm9yIGV4YW1wbGUsIChTQSxEQT1TSURCKSAoU0lEQixTSURDLFNJREIsU0lEQTsgU0w9MikgYW5k IChTQSxEQT1TSURCKSAoU0lEQixTSURDLFNJREIsU0lEQTsgU0w9MCkgYXJlIGRpZmZlcmVudC4g U28gSSB0aGluayBzZWdtZW50cyBsZWZ0IGlzIGFsc28gdXNlZnVsIHdoZW4gZXhwb3J0aW5nIFNS djYgaW5mb3JtYXRpb24uDQo+IDMpIEVsZW1lbnQgZm9yIFNSSCBUTFYgaXMgbm90IGRlZmluZWQg aW4gdGhlIGRyYWZ0LCB3aGF0J3MgdGhlIGNvbnNpZGVyYXRpb24gYWJvdXQgdGhhdD8NCkNvdWxk IHlvdSBlbGFib3JhdGUgZnVydGhlciBwbGVhc2UuIFRoZSBkb2N1bWVudCByZWZlcnMgdG8gUkZD IDg3NTQgd2hlcmUgdGhlIFNSSCBUTFYgaXMgYmVpbmcgZGVzY3JpYmVkLg0KW1lhb10gSSBtZWFu IHRoYXQgSVBGSVggSUUgZm9yIFNSSCBUTFYgaXMgbm90IGRlZmluZWQgaW4gdGhlIGRyYWZ0IHdo aWxlIG90aGVyIG1haW4gZWxlbWVudHMgb2YgU1JIKFNSSEZsYWdzLFNSSFRhZyxpcHY2U1JIU2Vn bWVudExpc3QuLi4pIGFyZSBkZWZpbmVkLiBXaGF0IGlmIHRoZSB1c2VyIHdhbnQgdG8gZXhwb3J0 IHRoZSBTUkggVExWIGluZm8gb2YgdGhlIHBhY2tldHM/DQpCZXN0IHdpc2hlcw0KVGhvbWFzDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbGl1LnlhbzcxQHp0ZS5jb20uY248bWFp bHRvOmxpdS55YW83MUB6dGUuY29tLmNuPiA8bGl1LnlhbzcxQHp0ZS5jb20uY248bWFpbHRvOmxp dS55YW83MUB6dGUuY29tLmNuPj4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIwLCAyMDIyIDEw OjIzIEFNDQpUbzogR3JhZiBUaG9tYXMsIElOSS1ORVQtVENaLVpIMSA8VGhvbWFzLkdyYWZAc3dp c3Njb20uY29tPG1haWx0bzpUaG9tYXMuR3JhZkBzd2lzc2NvbS5jb20+Pg0KQ2M6IHNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6W3NwcmluZ10gTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1z cmgtMDAudHh0DQpIaSBUaG9tYXMsDQpJJ3ZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBoYXZlIHNvbWUg cXVlc3Rpb25zLg0KMSkgUkZDIDkxNjAgaW50cm9kdWNlcyBuZXcgcHJvdG9jb2wgdHlwZXMgZm9y IFNSLU1QTFMgdG9wIGxhYmVsLiBDb25zaWRlcmluZyB0aGF0IHRoZSBNUExTIHRvcCBsYWJlbCBp cyBhbHdheXMgdGhlIGxhYmVsIHRvIGJlIHByb2Nlc3NlZCwgdGhlIHVzZXIgY2FuIGtub3cgd2hp Y2ggcHJvdG9jb2wgdGhlIFNSLU1QTFMgU0lEIHRvIGJlIHByb2Nlc3NlZCBpcyBsZWFybmVkIGZy b20uDQpCdXQgdGhpcyBkcmFmdCBkZXNjcmliZXMgdGhlIHJvdXRpbmcgcHJvdG9jb2wgd2hlcmUg dGhlIGxhc3QgU1J2NiBzZWdtZW50IGhhcyBiZWVuIGxlYXJuZWQgZnJvbSwgaW5zdGVhZCBvZiB0 aGUgU1J2NiBzZWdtZW50IHRvIGJlIHByb2Nlc3NlZCBieSB0aGUgY3VycmVudCBob3AuDQpBcyBm b3IgbXkgdW5kZXJzdGFuZGluZywgdGhlIGN1cnJlbnQgZHJhZnQgaXMgaW5jb25zaXN0ZW50IHdp dGggUkZDIDkxNjAgaW4gdGhpcyBhc3BlY3QuDQoyKSBSZWxhdGVkIHRvIHBvaW50IDHvvIxpbiBT Ui1NUExTLCBleHBvcnRpbmcgdGhlIHRvcCBsYWJlbCBjYW4gcHJvdmlkZSB0aGUgaW5mb3JtYXRp b24gb2YgdGhlIHNlZ21lbnQgdG8gYmUgcHJvY2Vzc2VkLCBidXQgaW4gU1J2Niwgc2VnbWVudCBs aXN0IGFuZCBzZWdtZW50cyBsZWZ0KGN1cnJlbnRseSBub3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQp IGFyZSBib3RoIG5lZWRlZCB0byBwcm92aWRlIHRoZSBzaW1pbGFyIGluZm9ybWF0aW9uLg0KMikg RWxlbWVudCBmb3IgU1JIIFRMViBpcyBub3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQsIHdoYXQncyB0 aGUgY29uc2lkZXJhdGlvbiBhYm91dCB0aGF0Pw0KQmVzdCBSZWdhcmRzLA0KWWFvDQotLS0tLS0t LS0tLS0tLS0tLS3ljp/lp4vpgq7ku7YtLS0tLS0tLS0tLS0tLS0tLS0NCuWPkeS7tuS6uu+8mlRo b21hcy5HcmFmQHN3aXNzY29tLmNvbTxtYWlsdG86VGhvbWFzLkdyYWZAc3dpc3Njb20uY29tPg0K 5pS25Lu25Lq677yac3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Ow0K5pel IOacnyDvvJoyMDIy5bm0MDHmnIgxNeaXpSAxNzoyNw0K5Li7IOmimCDvvJpbc3ByaW5nXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNy aC0wMC50eHQNCkRlYXIgU1BSSU5HIHdvcmtpbmcgZ3JvdXAsDQpGb2xsb3dpbmcgdXAgb24ganVz dCByZWxlYXNlZCBSRkMgOTE2MCAoaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2Ml MkZodG1sJTJGcmZjOTE2MCZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2Nv bS5jb20lN0MwMDkzODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2NGU1Yjg3YzFjNzQy MGQ5YmVlYzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIwNzclN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRp STZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9WlJZelNrRlhDRFNTVVlw ckxYamdIQWRmUUhQTEZuVGw2c0E4eE1XMlVyNCUzRCZhbXA7cmVzZXJ2ZWQ9MDxodHRwczovL2V1 cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZk YXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM5MTYwJmRhdGE9MDQlN0MwMSU3 Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMzg3NGQ1MGI0NzAyNGU1ODdhOWUwOGQ5ZWYz NDVmZWUlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3ODAz ODMwNDg4MjA4OTM4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFp TENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2Rh dGE9STBHbmZveklldVNZRmNoVmRCOVNkcTVwSktKQSUyQk1qZ2Y4S1QlMkI0djQ4TjglM0QmcmVz ZXJ2ZWQ9MD4pLCBJUEZJWCBjb2RlIHBvaW50cyBmb3IgTVBMUyBTZWdtZW50IFJvdXRpbmcsDQpo dHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC10Z3JhZi1v cHNhd2ctaXBmaXgtc3J2Ni1zcmgmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dp c3Njb20uY29tJTdDMDA5Mzg5YTNjN2FmNGU1M2RhODIwOGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2Mx Yzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5r bm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxD SkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPU9XZ1FBQTdiQzk4 UUtDZ21kbXpqVUklMkJzVVJ4MGNsQnZ1NEdWYkh3MFR1RSUzRCZhbXA7cmVzZXJ2ZWQ9MDxodHRw czovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC10Z3JhZi1vcHNh d2ctaXBmaXgtc3J2Ni1zcmgmZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5j b20lN0MzODc0ZDUwYjQ3MDI0ZTU4N2E5ZTA4ZDllZjM0NWZlZSU3QzM2NGU1Yjg3YzFjNzQyMGQ5 YmVlYzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc4MDM4MzA0ODgyMDg5MzglN0NVbmtub3duJTdD VFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJ azFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT1jOGloeCUyQnM5R3JmZzN5VGkyVG9I NEVZYjZhdGRmSVRnaFBON0h0UXl4MkElM0QmcmVzZXJ2ZWQ9MD4gaGFzIGJlZW4gc3VibWl0dGVk IGZvciB0aGUgU1JWNiBkYXRhLXBsYW5lLg0KVGhlIGRvY3VtZW50IGFpbXMgdG8gYmUgb24gcGFy IHdpdGggTVBMUy1TUi4gRGVzY3JpYmUgdGhlIHJvdXRpbmcgcHJvdG9jb2wgb3IgUENFUCBleHRl bnNpb24gd2hlcmUgdGhlIGxhc3QgU1J2NiBzZWdtZW50IGhhcyBiZWVuIGxlYXJuZWQgZnJvbSwg dGhlIFNSdjYgc2VnbWVudCBsaXN0IGFuZCBhbGwgb3RoZXIgcHJvcGVydGllcyBmcm9tIHRoZSBT ZWdtZW50IFJvdXRpbmcgaGVhZGVyLg0KSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIgZG9jdW1lbnQg cmV2aWV3IGFuZCBmZWVkYmFjay4NCkkgYWltIHRvIHByZXNlbnQgYXQgSUVURiAxMTMgYXQgT1BT QVdHIGFuZCBTUFJJTkcgYW5kIHJlcXVlc3QgYWRvcHRpb24gYXQgT1BTQVdHLg0KQmVzdCB3aXNo ZXMNClRob21hcw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiA8aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KU2VudDog U2F0dXJkYXksIEphbnVhcnkgMTUsIDIwMjIgMTA6MTIgQU0NClRvOiBHcmFmIFRob21hcywgSU5J LU5FVC1UQ1otWkgxIDxUaG9tYXMuR3JhZkBzd2lzc2NvbS5jb208bWFpbHRvOlRob21hcy5HcmFm QHN3aXNzY29tLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDAudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRob21hcyBHcmFmIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCk5hbWU6ICAgICAgICBkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2 Ni1zcmgNClJldmlzaW9uOiAgICAwMA0KVGl0bGU6ICAgICAgICBFeHBvcnQgb2YgU2VnbWVudCBS b3V0aW5nIElQdjYgSW5mb3JtYXRpb24gaW4gSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQ RklYKQ0KRG9jdW1lbnQgZGF0ZTogICAgMjAyMi0wMS0xNQ0KR3JvdXA6ICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgOQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v ZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRmFyY2hpdmUlMkZpZCUyRmRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1z cnY2LXNyaC0wMC50eHQmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20u Y29tJTdDMDA5Mzg5YTNjN2FmNGU1M2RhODIwOGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2MxYzc0MjBk OWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPVhTcDd6blZqSWtRcVBaTHBD VXgwNHREMWVhSDlSb09IVDZ4SmxYMWNNcTAlM0QmYW1wO3Jlc2VydmVkPTA8aHR0cHM6Ly9ldXIw My5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 LmlldGYub3JnJTJGYXJjaGl2ZSUyRmlkJTJGZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYt c3JoLTAwLnR4dCZkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM4 NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVk MTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODM2NTE1MyU3Q1Vua25vd24lN0NUV0ZwYkda c2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dp TENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPTdneVJxZnlTYlVtU0ZNTmRaUTYlMkZTOVVYZ3NG ZzBYZDU3WVYyaGZPV2QlMkZJJTNEJnJlc2VydmVkPTA+DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgt c3J2Ni1zcmglMkYmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29t JTdDMDA5Mzg5YTNjN2FmNGU1M2RhODIwOGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2MxYzc0MjBkOWJl ZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5rbm93biU3Q1RX RnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsx aGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPWU4MGtkN0tyazdWNHlpdzZqdGp5 aDdPMTQ0SFB3d0FsSmtVTU5ZY096WGMlM0QmYW1wO3Jlc2VydmVkPTA8aHR0cHM6Ly9ldXIwMy5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgl MkYmZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20lN0MzODc0ZDUwYjQ3 MDI0ZTU4N2E5ZTA4ZDllZjM0NWZlZSU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1N2Ex JTdDMCU3QzAlN0M2Mzc4MDM4MzA0ODgzNjUxNTMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlK V0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2 TW4wJTNEJTdDMzAwMCZzZGF0YT1KVVclMkJ0dnZBaERkOTY0JTJCZVNwRGRRZWFkajFmaWxnZFNv SmlYd2FWVzR4RSUzRCZyZXNlcnZlZD0wPg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZXVyMDMu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1z cnY2LXNyaCZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20lN0Mw MDkzODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1 ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIwNzclN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9T1dnUUFBN2JDOThRS0NnbWRtempVSSUy QnNVUngwY2xCdnU0R1ZiSHcwVHVFJTNEJmFtcDtyZXNlcnZlZD0wPGh0dHBzOi8vZXVyMDMuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFj a2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2 LXNyaCZkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBi NDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3 YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODM2NTE1MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhl eUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZD STZNbjAlM0QlN0MzMDAwJnNkYXRhPU9QZzU1JTJGS0RJOGVlVUluWlZ1dk5aeVhTRUdJa0N1SU9a RFBCMUlKS3BhWSUzRCZyZXNlcnZlZD0wPg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGludHJv ZHVjZXMgbmV3IElQIEZsb3cgSW5mb3JtYXRpb24gRXhwb3J0IChJUEZJWCkgY29kZSBwb2ludHMg dG8gaWRlbnRpZnkgd2hpY2ggdHJhZmZpYyBpcyBiZWluZyBmb3J3YXJkZWQgd2l0aCB3aGljaCBT ZWdlbW50IFJvdXRpbmcgSGVhZGVyIGRpbWVuc2lvbnMgYmFzZWQgb24gd2hpY2ggU1J2NiBjb250 cm9sIHBsYW5lIHByb3RvY29sLg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vZXVyMDMuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhv bWFzLkdyYWYlNDBzd2lzc2NvbS5jb20lN0MwMDkzODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0 MyU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzcz Mzk1MjIwNzclN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pR SWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2Rh dGE9Mm1GU3VyeEVTaEdESkdJeHZxT2l3TzhwdnB2RkU3YklvVzlNJTJCWTVsVGNnJTNEJmFtcDty ZXNlcnZlZD0wPGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNw cmluZyZkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBi NDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3 YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODM2NTE1MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhl eUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZD STZNbjAlM0QlN0MzMDAwJnNkYXRhPTB3R2hDbHFQcnBwdHI0a3k5bUlOWWdkb3RmJTJCalM5TnF4 RGU3ZEJKMGJUNCUzRCZyZXNlcnZlZD0wPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUy Rmxpc3RpbmZvJTJGc3ByaW5nJmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNz Y29tLmNvbSU3QzAwOTM4OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUxZTQzJTdDMzY0ZTViODdjMWM3 NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzc5ODIzNzMzOTUyMjA3NyU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT0ybUZTdXJ4RVNoR0RK R0l4dnFPaXdPOHB2cHZGRTdiSW9XOU0lMkJZNWxUY2clM0QmYW1wO3Jlc2VydmVkPTA8aHR0cHM6 Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nJmRhdGE9MDQlN0Mw MSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMzg3NGQ1MGI0NzAyNGU1ODdhOWUwOGQ5 ZWYzNDVmZWUlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3 ODAzODMwNDg4MzY1MTUzJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAm c2RhdGE9MHdHaENscVBycHB0cjRreTltSU5ZZ2RvdGYlMkJqUzlOcXhEZTdkQkowYlQ0JTNEJnJl c2VydmVkPTA+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+DQpodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJp bmcmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMDA5Mzg5 YTNjN2FmNGU1M2RhODIwOGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1 NTdhMSU3QzAlN0MwJTdDNjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNk OGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pY VkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPTJtRlN1cnhFU2hHREpHSXh2cU9pd084cHZwdkZF N2JJb1c5TSUyQlk1bFRjZyUzRCZhbXA7cmVzZXJ2ZWQ9MDxodHRwczovL2V1cjAzLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcmZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYl NDBzd2lzc2NvbS5jb20lN0MzODc0ZDUwYjQ3MDI0ZTU4N2E5ZTA4ZDllZjM0NWZlZSU3QzM2NGU1 Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc4MDM4MzA0ODgzNjUxNTMl N0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVN eklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT0wd0doQ2xxUHJw cHRyNGt5OW1JTllnZG90ZiUyQmpTOU5xeERlN2RCSjBiVDQlM0QmcmVzZXJ2ZWQ9MD4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGlu ZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPGh0dHBzOi8vZXVyMDMuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmluZyZkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3Jh ZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0 ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODM2NTE1 MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJs dU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPTB3R2hDbHFQ cnBwdHI0a3k5bUlOWWdkb3RmJTJCalM5TnF4RGU3ZEJKMGJUNCUzRCZyZXNlcnZlZD0wPg0K --_000_ZRAP278MB017621DBE533D68302AF9D1089379ZRAP278MB0176CHEP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNo ZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiVHJlYnVjaGV0IE1TIixzYW5zLXNlcmlmOw0KCWNvbG9yOiM0NDU0NkE7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 REUtQ0g7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjo3MC44NXB0IDcwLjg1cHQgNTYuN3B0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERS1DSCIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBHcmVn LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM0NDU0NkE7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5UaGFua3MgZm9yIGJyaW5naW5nIHRoYXQgcXVlc3Rpb24gdXAuIEkgYWxyZWFkeSBj b25zaWRlcmVkIHRoaXMgYXNwZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZB O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QTttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+QXMgZGVzY3JpYmVkIGluIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDAu aHRtbCNzZWN0aW9uLTIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDAuaHRtbCNzZWN0aW9uLTI8L2E+ LCB0aGUgY29tcHJlc3NlZC1TSUQgY29udGFpbmVyIChDLVNJRCBjb250YWluZXIpIGlzIDEyOC1i aXQgbG9uZyBhbmQgY29udGFpbnMgYSBzZXF1ZW5jZSBvZiBDLVNJRHMuIFRoZXJlZm9yZSB0aGUg aXB2NlNSSFNlZ21lbnRMaXN0IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM0NDU0NkE7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmNvbnRh aW5zIGVpdGhlciBhIGxpc3Qgb2YgSVB2NiBTSUQncywgYSBsaXN0IG9mIGNvbXByZXNzZWQtU0lE IGNvbnRhaW5lcnMgb3IgYm90aC4gVGhleSBhcmUgbm90IG11dHVhbGx5IGV4Y2x1c2l2ZS48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZB O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5JdCBwcm9iYWJseSBtYWtlcyBzZW5zZSB0byBhZGQgYW4gb3BlcmF0aW9uYWwg Y29uc2lkZXJhdGlvbiBzZWN0aW9uIGluIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNy aCB0byBkZXNjcmliZSB0aGUgdXNlIG9mIEMtU0lEIGNvbnRhaW5lcnMgYW5kIGl0cyBjb250ZXh0 IHRvIGlwdjZTUkhTZWdtZW50VHlwZS4gRnJvbSB3aGF0IEkgdW5kZXJzdG9vZCwgYW5kIGhlcmUg SSB3b3VsZCBsaWtlIHRvIGhhdmUgZmVlZGJhY2sgZnJvbSB0aGUgbWFpbGluZyBsaXN0LCBpdCBk b2VzIG5vdCBicmluZyBtdWNoIGFkZGVkIHZhbHVlIHRvIGRlY29tcG9zZSB0aGUgQy1TSUQgY29u dGFpbmVyIGludG8gQ29tcHJlc3NlZC1TSUQgKEMtU0lEKSBpbiBJUEZJWC48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5CZXN0IHdpc2hlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM0NDU0NkE7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRob21hczwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IEdyZWcgTWlyc2t5ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5T ZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSAxMywgMjAyMiAxMDowNCBQTTxicj4NCjxiPlRvOjwv Yj4gR3JhZiBUaG9tYXMsIElOSS1ORVQtVENaLVpIMSAmbHQ7VGhvbWFzLkdyYWZAc3dpc3Njb20u Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbGl1LnlhbzcxQHp0ZS5jb20uY247IHNwcmluZyAmbHQ7 c3ByaW5nQGlldGYub3JnJmd0Ozsgb3BzYXdnICZsdDtvcHNhd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgVGhvbWFzLCBldCBhbC4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+d2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhlIG5ldyBTUFJJTkcgV0cgZHJhZnQgdGhhdCBp bnRyb2R1Y2VzIHR3byBtZXRob2RzIG9mIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMy5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNr ZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1zcmgtY29t cHJlc3Npb24tMDAmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29t JTdDMzg3NGQ1MGI0NzAyNGU1ODdhOWUwOGQ5ZWYzNDVmZWUlN0MzNjRlNWI4N2MxYzc0MjBkOWJl ZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3ODAzODMwNDg4MjA4OTM4JTdDVW5rbm93biU3Q1RX RnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsx aGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPWtIc0VWU3RPZ2VpNnRtME9nUTAw VWVha0glMkYyWmZuR2czcW41NUdtYSUyQjg0JTNEJmFtcDtyZXNlcnZlZD0wIj4NCmNvbXByZXNz ZWQgU1J2NiBTSUQgbGlzdCBlbmNvZGluZyBpbiB0aGUgU1JIPC9hPj88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBGZWIg MTIsIDIwMjIgYXQgMTI6MTAgQU0gJmx0OzxhIGhyZWY9Im1haWx0bzpUaG9tYXMuR3JhZkBzd2lz c2NvbS5jb20iPlRob21hcy5HcmFmQHN3aXNzY29tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBZ YW8sPGJyPg0KPGJyPg0KVGhhbmtzIGEgbG90IGZvciB0aGUgZGV0YWlsZWQgZGVzY3JpcHRpb24u IEJvdGggdW5kZXJzdG9vZCwmbmJzcDsgYWNrbm93bGVkZ2VkIGFuZCBiZWluZyBtZXJnZWQgdG8g dGhlIC0wMSB2ZXJzaW9uLiBGZWVkYmFjayB3ZWxjb21lLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRnJmY2RpZmYlM0Z1cmwxJTNEaHR0cHMlM0ElMkYlMkZyYXcu Z2l0aHVidXNlcmNvbnRlbnQuY29tJTJGZ3JhZjNuZXQlMkZkcmFmdC10Z3JhZi1vcHNhd2ctaXBm aXgtc3J2Ni1zcmglMkZtYWluJTJGZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAw LnR4dCUyNnVybDIlM0RodHRwcyUzQSUyRiUyRnJhdy5naXRodWJ1c2VyY29udGVudC5jb20lMkZn cmFmM25ldCUyRmRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaCUyRm1haW4lMkZkcmFm dC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDEudHh0JmFtcDtkYXRhPTA0JTdDMDElN0NU aG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1 ZmVlJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgz MDQ4ODIwODkzOCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxD SlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtz ZGF0YT1URHhtVlM3VkFhQzVtSWxrVWs1M0kzZW5NcHQlMkY4JTJCTHBWOXFya3BDQVdLZyUzRCZh bXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMT1odHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vZ3JhZjNuZXQvZHJhZnQt dGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoL21haW4vZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4 LXNydjYtc3JoLTAwLnR4dCZhbXA7dXJsMj1odHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5j b20vZ3JhZjNuZXQvZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoL21haW4vZHJhZnQt dGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAxLnR4dDwvYT48YnI+DQo8YnI+DQpJIHdpbGwg cHVibGlzaCAtMDEgaW4gdGhlIHVwY29taW5nIHdlZWtzIGJlZm9yZSBJRVRGIDExMy48YnI+DQo8 YnI+DQpCZXN0IHdpc2hlczxicj4NClRob21hczxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmxpdS55YW83MUB6dGUuY29tLmNu IiB0YXJnZXQ9Il9ibGFuayI+bGl1LnlhbzcxQHp0ZS5jb20uY248L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86bGl1LnlhbzcxQHp0ZS5jb20uY24iIHRhcmdldD0iX2JsYW5rIj5saXUueWFvNzFAenRl LmNvbS5jbjwvYT4mZ3Q7DQo8YnI+DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDcsIDIwMjIgMTA6 NDIgQU08YnI+DQpUbzogR3JhZiBUaG9tYXMsIElOSS1ORVQtVENaLVpIMSAmbHQ7PGEgaHJlZj0i bWFpbHRvOlRob21hcy5HcmFmQHN3aXNzY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlRob21hcy5H cmFmQHN3aXNzY29tLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVj dDogUmU6W3NwcmluZ10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10Z3JhZi1v cHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDAudHh0PGJyPg0KPGJyPg0KSGkgVGhvbWFzLDxicj4NCjxi cj4NClNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4gUGxlYXNlIHNlZSBpbmxpbmUgW1lhbzJdLjxi cj4NCiZndDsgW1lhb10gU2VnbWVudHMgbGVmdCBpcyBvbmUgb2YgdGhlIGVsZW1lbnRzIHRvIGlk ZW50aWZ5IGFuIFNSSC4gRm9yIGV4YW1wbGUsIChTQSxEQT1TSURCKSAoU0lEQixTSURDLFNJREIs U0lEQTsgU0w9MikgYW5kIChTQSxEQT1TSURCKSAoU0lEQixTSURDLFNJREIsU0lEQTsgU0w9MCkg YXJlIGRpZmZlcmVudC4gU28gSSB0aGluayBzZWdtZW50cyBsZWZ0IGlzIGFsc28gdXNlZnVsIHdo ZW4gZXhwb3J0aW5nIFNSdjYgaW5mb3JtYXRpb24uPGJyPg0KV291bGQgeW91IGFncmVlIHRoYXQg aXB2NlNSSFNlZ21lbnRMaXN0IGF0IG5vZGUgZWdyZXNzIHdvdWxkIGJlIGVxdWFsIHRvIFNlZ21l bnRzIGxlZnQ/IE9yIGluIG90aGVyIHdvcmRzIHNlZ21lbnRzIGxlZnQgd291bGQgb25seSBkaWZm ZXIgYXQgaW5ncmVzcyB0byBpcHY2U1JIU2VnbWVudExpc3QuIENvcnJlY3Q/IElmIHllcywgdGhh biBJIHRoaW5rIEkgZ290IHlvdXIgcG9pbnQuIFdvdWxkIHlvdSBwbGVhc2UgZGVzY3JpYmUgbWUg d2hhdCBraW5kDQogb2YgdXNlIGNhc2UgeW91IGhhdmUgaW4gbWluZC48YnI+DQpbWWFvMl0gSSBt ZWFuIHdpdGhvdXQgc2VnbWVudCBsZWZ0LCBpdCdzIGRpZmZpY3VsdCB0byBkaXN0aW5ndWlzaCBi ZXR3ZWVuIHBhY2tldHMgb2YgdGhlIHNhbWUgc2VnbWVudCBsaXN0IGluIHNvbWUgY2FzZXMuPGJy Pg0KQmVsb3cgaXMgb25lIHNjZW5hcmlvIEkgY2FuIHRoaW5rIG9mLiBUaGUgY29ycmVzcG9uZGlu ZyBzZWdtZW50IGxpc3Qgb2YgcGF0aCAxLS1BLS0yLS0zLS0xLS1BLS00IGlzICZsdDtTSUQtMSxT SUQtQSxTSUQtMixTSUQtMyxTSUQtMSxTSUQtQSxTSUQtNCZndDsuDQo8YnI+DQombmJzcDsgJm5i c3A7IDM8YnI+DQombmJzcDsgLyZuYnNwOyAmbmJzcDtcPGJyPg0KJm5ic3A7LyZuYnNwOyAmbmJz cDsgJm5ic3A7XDxicj4NCjEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyPGJyPg0KJm5ic3A7 XCZuYnNwOyAmbmJzcDsgJm5ic3A7Lzxicj4NCiZuYnNwOyBcJm5ic3A7ICZuYnNwOy88YnI+DQom bmJzcDsgJm5ic3A7IEEtLS0tLTQ8YnI+DQpUaGUgZmxvdyBwYXNzZXMgbm9kZSBBIHR3aWNlLjxi cj4NClRoZSBmaXJzdCB0aW1lLCB0aGUgcGFja2V0IGlzIChTQSxEQT1TSUQtQSkmbHQ7U0lELTEs U0lELUEsU0lELTIsU0lELTMsU0lELTEsU0lELUEsU0lELTQ7IHNlZ21lbnQgbGVmdD01Jmd0Oy48 YnI+DQpUaGUgc2Vjb25kIHRpbWUsIHRoZSBwYWNrZXQgaXMgKFNBLERBPVNJRC1BKSZsdDtTSUQt MSxTSUQtQSxTSUQtMixTSUQtMyxTSUQtMSxTSUQtQSxTSUQtNDsgc2VnbWVudCBsZWZ0PTEmZ3Q7 Ljxicj4NCklmIG9uZSB3YW50cyB0byBjb2xsZWN0IHRoZSBpbmZvIG9mIHRoZXNlIHR3byB0cmFm ZmljIHNlcGFyYXRlbHksIHRoZSBzZWdtZW50IGxlZnQgZWxlbWVudCBpcyBuZWVkZWQuPGJyPg0K QnV0IHRvIGJlIGhvbmVzdCwgSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyByZXF1aXJlbWVudCBp cyBzdHJvbmcuJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KPGJyPg0KJmd0OyBbWWFvXSBJIG1l YW4gdGhhdCBJUEZJWCBJRSBmb3IgU1JIIFRMViBpcyBub3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQg d2hpbGUgb3RoZXIgbWFpbiBlbGVtZW50cyBvZiBTUkgoU1JIRmxhZ3MsU1JIVGFnLGlwdjZTUkhT ZWdtZW50TGlzdC4uLikgYXJlIGRlZmluZWQuIFdoYXQgaWYgdGhlIHVzZXIgd2FudCB0byBleHBv cnQgdGhlIFNSSCBUTFYgaW5mbyBvZiB0aGUgcGFja2V0cz88YnI+DQpZb3UgbWVhbiB0aGUgZW50 aXJlIFNSSCBoZWFkZXIgd2l0aG91dCBkaXNhc3NlbWJsZSB0aGUgZGltZW5zaW9ucyBpbnRvIElQ RklYIGVudGl0aWVzLiBMaWtlIElFIDMxNiBtcGxzTGFiZWxTdGFja1NlY3Rpb24uIENvcnJlY3Q/ IEkgdGhpbmsgdGhpcyBtYWtlcyBhIGxvdCBvZiBzZW5zZSBhbmQgSSBjb25zaWRlciB0aGlzIHRv IHRoZSAtMDEgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuDQo8YnI+DQpbWWFvMl0gWWVzLCB0aGF0 J3Mgd2hhdCBJIG1lYW4uPGJyPg0KPGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NCllhbzxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLTxzcGFuIGxhbmc9 IlpILUNOIj7ljp/lp4vpgq7ku7Y8L3NwYW4+LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPHNwYW4g bGFuZz0iWkgtQ04iPuWPkeS7tuS6uu+8mjwvc3Bhbj48YSBocmVmPSJtYWlsdG86VGhvbWFzLkdy YWZAc3dpc3Njb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+VGhvbWFzLkdyYWZAc3dpc3Njb20uY29t PC9hPjxicj4NCjxzcGFuIGxhbmc9IlpILUNOIj7mlLbku7bkurrvvJrliJjlsKc8L3NwYW4+MDAx NjUyODY7PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iPuaKhOmAgeS6uu+8mjwvc3Bhbj48YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3Jn PC9hPjs8YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiI+5pelIOacnyDvvJo8L3NwYW4+MjAyMjxzcGFu IGxhbmc9IlpILUNOIj7lubQ8L3NwYW4+MDE8c3BhbiBsYW5nPSJaSC1DTiI+5pyIPC9zcGFuPjMw PHNwYW4gbGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj4gMTQ6MTc8YnI+DQo8c3BhbiBsYW5nPSJaSC1D TiI+5Li7IOmimCDvvJo8L3NwYW4+UmU6IFtzcHJpbmddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAwLnR4dDxicj4NCkhpIFlh bzxicj4NClRoYW5rcyBhIGxvdCBmb3IgeW91ciBpbnB1dC48YnI+DQomZ3Q7IFtZYW9dIFNlZ21l bnRzIGxlZnQgaXMgb25lIG9mIHRoZSBlbGVtZW50cyB0byBpZGVudGlmeSBhbiBTUkguIEZvciBl eGFtcGxlLCAoU0EsREE9U0lEQikgKFNJREIsU0lEQyxTSURCLFNJREE7IFNMPTIpIGFuZCAoU0Es REE9U0lEQikgKFNJREIsU0lEQyxTSURCLFNJREE7IFNMPTApIGFyZSBkaWZmZXJlbnQuIFNvIEkg dGhpbmsgc2VnbWVudHMgbGVmdCBpcyBhbHNvIHVzZWZ1bCB3aGVuIGV4cG9ydGluZyBTUnY2IGlu Zm9ybWF0aW9uLjxicj4NCldvdWxkIHlvdSBhZ3JlZSB0aGF0IGlwdjZTUkhTZWdtZW50TGlzdCBh dCBub2RlIGVncmVzcyB3b3VsZCBiZSBlcXVhbCB0byBTZWdtZW50cyBsZWZ0PyBPciBpbiBvdGhl ciB3b3JkcyBzZWdtZW50cyBsZWZ0IHdvdWxkIG9ubHkgZGlmZmVyIGF0IGluZ3Jlc3MgdG8gaXB2 NlNSSFNlZ21lbnRMaXN0LiBDb3JyZWN0PyBJZiB5ZXMsIHRoYW4gSSB0aGluayBJIGdvdCB5b3Vy IHBvaW50LiBXb3VsZCB5b3UgcGxlYXNlIGRlc2NyaWJlIG1lIHdoYXQga2luZA0KIG9mIHVzZSBj YXNlIHlvdSBoYXZlIGluIG1pbmQuPGJyPg0KJmd0OyBbWWFvXSBJIG1lYW4gdGhhdCBJUEZJWCBJ RSBmb3IgU1JIIFRMViBpcyBub3QgZGVmaW5lZCBpbiB0aGUgZHJhZnQgd2hpbGUgb3RoZXIgbWFp biBlbGVtZW50cyBvZiBTUkgoU1JIRmxhZ3MsU1JIVGFnLGlwdjZTUkhTZWdtZW50TGlzdC4uLikg YXJlIGRlZmluZWQuIFdoYXQgaWYgdGhlIHVzZXIgd2FudCB0byBleHBvcnQgdGhlIFNSSCBUTFYg aW5mbyBvZiB0aGUgcGFja2V0cz88YnI+DQpZb3UgbWVhbiB0aGUgZW50aXJlIFNSSCBoZWFkZXIg d2l0aG91dCBkaXNhc3NlbWJsZSB0aGUgZGltZW5zaW9ucyBpbnRvIElQRklYIGVudGl0aWVzLiBM aWtlIElFIDMxNiBtcGxzTGFiZWxTdGFja1NlY3Rpb24uIENvcnJlY3Q/IEkgdGhpbmsgdGhpcyBt YWtlcyBhIGxvdCBvZiBzZW5zZSBhbmQgSSBjb25zaWRlciB0aGlzIHRvIHRoZSAtMDEgdmVyc2lv biBvZiB0aGUgZG9jdW1lbnQuPGJyPg0KTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgY2xhcmlmaWNh dGlvbnMuPGJyPg0KQmVzdCB3aXNoZXM8YnI+DQpUaG9tYXM8YnI+DQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzpsaXUueWFvNzFAenRlLmNvbS5j biIgdGFyZ2V0PSJfYmxhbmsiPmxpdS55YW83MUB6dGUuY29tLmNuPC9hPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmxpdS55YW83MUB6dGUuY29tLmNuIiB0YXJnZXQ9Il9ibGFuayI+bGl1LnlhbzcxQHp0 ZS5jb20uY248L2E+Jmd0Ozxicj4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMjIgMTA6 MjcgQU08YnI+DQpUbzogR3JhZiBUaG9tYXMsIElOSS1ORVQtVENaLVpIMSAmbHQ7PGEgaHJlZj0i bWFpbHRvOlRob21hcy5HcmFmQHN3aXNzY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlRob21hcy5H cmFmQHN3aXNzY29tLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVj dDogUmU6W3NwcmluZ10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10Z3JhZi1v cHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDAudHh0PGJyPg0KSGkgVGhvbWFzLDxicj4NClBsZWFzZSBz ZWUgaW5saW5lIFtZYW9dLjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQpZYW88YnI+DQotLS0tLS0t LS0tLS0tLS0tLS08c3BhbiBsYW5nPSJaSC1DTiI+5Y6f5aeL6YKu5Lu2PC9zcGFuPi0tLS0tLS0t LS0tLS0tLS0tLTxicj4NCjxzcGFuIGxhbmc9IlpILUNOIj7lj5Hku7bkurrvvJo8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOlRob21hcy5HcmFmQHN3aXNzY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlRo b21hcy5HcmFmQHN3aXNzY29tLmNvbTwvYT48YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiI+5pS25Lu2 5Lq677ya5YiY5bCnPC9zcGFuPjAwMTY1Mjg2Ozxicj4NCjxzcGFuIGxhbmc9IlpILUNOIj7mioTp gIHkurrvvJo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iPuaXpSDm nJ8g77yaPC9zcGFuPjIwMjI8c3BhbiBsYW5nPSJaSC1DTiI+5bm0PC9zcGFuPjAxPHNwYW4gbGFu Zz0iWkgtQ04iPuaciDwvc3Bhbj4yMzxzcGFuIGxhbmc9IlpILUNOIj7ml6U8L3NwYW4+IDAxOjE2 PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iPuS4uyDpopgg77yaPC9zcGFuPlJlOiBbc3ByaW5nXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2 LXNyaC0wMC50eHQ8YnI+DQpIaSBZYW8sPGJyPg0KTWFueSB0aGFua3MgZm9yIHRoZSByZXZpZXcg YW5kIGZlZWRiYWNrLjxicj4NCiZndDsgMSkgQnV0IHRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBy b3V0aW5nIHByb3RvY29sIHdoZXJlIHRoZSBsYXN0IFNSdjYgc2VnbWVudCBoYXMgYmVlbiBsZWFy bmVkIGZyb20sIGluc3RlYWQgb2YgdGhlIFNSdjYgc2VnbWVudCB0byBiZSBwcm9jZXNzZWQgYnkg dGhlIGN1cnJlbnQgaG9wLjxicj4NCkkgYW0gZ29pbmcgdG8gcmVwaHJhc2UgdGhlIHNlbnRlbmNl cyB0byByZWZlciB0byB0aGUgYWN0aXZlIHNlZ21lbnQuIFdoaWNoIHNob3VsZCBtYWtlIGl0IGxl c3MgYW1iaWd1b3VzLjxicj4NCiZndDsgMikgYnV0IGluIFNSdjYsIHNlZ21lbnQgbGlzdCBhbmQg c2VnbWVudHMgbGVmdChjdXJyZW50bHkgbm90IGRlZmluZWQgaW4gdGhlIGRyYWZ0KSBhcmUgYm90 aCBuZWVkZWQgdG8gcHJvdmlkZSB0aGUgc2ltaWxhciBpbmZvcm1hdGlvbi48YnI+DQpDb3VsZCB5 b3UgZWxhYm9yYXRlIHRoZSB1c2UgY2FzZSBmb3Igc2VnbWVudHMgbGVmdCBpbiB0aGlzIGNvbnRl eHQuIFRoaXMgZG9jdW1lbnQgY292ZXJzIGFsbCBkaW1lbnNpb25zIGJlaW5nIHByZXNlbnQgaW4g dGhlIFNSdjYgc2VnbWVudCByb3V0aW5nIGhlYWRlciBkZXNjcmliZWQgaW4gc2VjdGlvbiBvZiBS RkM4NzU0ICg8YSBocmVmPSJodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0 bWwlMkZyZmM4NzU0JTIzc2VjdGlvbi0yJmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0 MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTVi ODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODIwODkzOCU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1KNGtQMlcx MFUzbGVVUEhPUkVRRDlUMzhjUkZMTjJocGslMkI0SlNQN0wzS2clM0QmYW1wO3Jlc2VydmVkPTAi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0 bWwlMkZyZmM4NzU0JTIzc2VjdGlvbi0yJmFtcDthbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdy YWYlNDBzd2lzc2NvbS5jb20lN0MwMDkzODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2 NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIw NzclN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYy bHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7YW1wO3NkYXRh PW42WTB4WDNEVDFCbXVzT0xidVVYRFpIYjJDUSUyQmlKbFklMkZTT1B4SWNUcjdjJTNEJmFtcDth bXA7cmVzZXJ2ZWQ9MDwvYT4pDQogd2l0aCB0aGUgZXhjZXB0aW9uIG9mICZxdW90O0xhc3QgRW50 cnkmcXVvdDsuPGJyPg0KW1lhb10gU2VnbWVudHMgbGVmdCBpcyBvbmUgb2YgdGhlIGVsZW1lbnRz IHRvIGlkZW50aWZ5IGFuIFNSSC4gRm9yIGV4YW1wbGUsIChTQSxEQT1TSURCKSAoU0lEQixTSURD LFNJREIsU0lEQTsgU0w9MikgYW5kIChTQSxEQT1TSURCKSAoU0lEQixTSURDLFNJREIsU0lEQTsg U0w9MCkgYXJlIGRpZmZlcmVudC4gU28gSSB0aGluayBzZWdtZW50cyBsZWZ0IGlzIGFsc28gdXNl ZnVsIHdoZW4gZXhwb3J0aW5nIFNSdjYgaW5mb3JtYXRpb24uPGJyPg0KJmd0OyAzKSBFbGVtZW50 IGZvciBTUkggVExWIGlzIG5vdCBkZWZpbmVkIGluIHRoZSBkcmFmdCwgd2hhdCdzIHRoZSBjb25z aWRlcmF0aW9uIGFib3V0IHRoYXQ/PGJyPg0KQ291bGQgeW91IGVsYWJvcmF0ZSBmdXJ0aGVyIHBs ZWFzZS4gVGhlIGRvY3VtZW50IHJlZmVycyB0byBSRkMgODc1NCB3aGVyZSB0aGUgU1JIIFRMViBp cyBiZWluZyBkZXNjcmliZWQuPGJyPg0KW1lhb10gSSBtZWFuIHRoYXQgSVBGSVggSUUgZm9yIFNS SCBUTFYgaXMgbm90IGRlZmluZWQgaW4gdGhlIGRyYWZ0IHdoaWxlIG90aGVyIG1haW4gZWxlbWVu dHMgb2YgU1JIKFNSSEZsYWdzLFNSSFRhZyxpcHY2U1JIU2VnbWVudExpc3QuLi4pIGFyZSBkZWZp bmVkLiBXaGF0IGlmIHRoZSB1c2VyIHdhbnQgdG8gZXhwb3J0IHRoZSBTUkggVExWIGluZm8gb2Yg dGhlIHBhY2tldHM/PGJyPg0KQmVzdCB3aXNoZXM8YnI+DQpUaG9tYXM8YnI+DQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzpsaXUueWFvNzFAenRl LmNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPmxpdS55YW83MUB6dGUuY29tLmNuPC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmxpdS55YW83MUB6dGUuY29tLmNuIiB0YXJnZXQ9Il9ibGFuayI+bGl1Lnlh bzcxQHp0ZS5jb20uY248L2E+Jmd0Ozxicj4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIwLCAy MDIyIDEwOjIzIEFNPGJyPg0KVG86IEdyYWYgVGhvbWFzLCBJTkktTkVULVRDWi1aSDEgJmx0Ozxh IGhyZWY9Im1haWx0bzpUaG9tYXMuR3JhZkBzd2lzc2NvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5U aG9tYXMuR3JhZkBzd2lzc2NvbS5jb208L2E+Jmd0Ozxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4N ClN1YmplY3Q6IFJlOltzcHJpbmddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt dGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAwLnR4dDxicj4NCkhpIFRob21hcyw8YnI+DQpJ J3ZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBoYXZlIHNvbWUgcXVlc3Rpb25zLjxicj4NCjEpIFJGQyA5 MTYwIGludHJvZHVjZXMgbmV3IHByb3RvY29sIHR5cGVzIGZvciBTUi1NUExTIHRvcCBsYWJlbC4g Q29uc2lkZXJpbmcgdGhhdCB0aGUgTVBMUyB0b3AgbGFiZWwgaXMgYWx3YXlzIHRoZSBsYWJlbCB0 byBiZSBwcm9jZXNzZWQsIHRoZSB1c2VyIGNhbiBrbm93IHdoaWNoIHByb3RvY29sIHRoZSBTUi1N UExTIFNJRCB0byBiZSBwcm9jZXNzZWQgaXMgbGVhcm5lZCBmcm9tLjxicj4NCkJ1dCB0aGlzIGRy YWZ0IGRlc2NyaWJlcyB0aGUgcm91dGluZyBwcm90b2NvbCB3aGVyZSB0aGUgbGFzdCBTUnY2IHNl Z21lbnQgaGFzIGJlZW4gbGVhcm5lZCBmcm9tLCBpbnN0ZWFkIG9mIHRoZSBTUnY2IHNlZ21lbnQg dG8gYmUgcHJvY2Vzc2VkIGJ5IHRoZSBjdXJyZW50IGhvcC48YnI+DQpBcyBmb3IgbXkgdW5kZXJz dGFuZGluZywgdGhlIGN1cnJlbnQgZHJhZnQgaXMgaW5jb25zaXN0ZW50IHdpdGggUkZDIDkxNjAg aW4gdGhpcyBhc3BlY3QuPGJyPg0KMikgUmVsYXRlZCB0byBwb2ludCAxPHNwYW4gbGFuZz0iWkgt Q04iPu+8jDwvc3Bhbj5pbiBTUi1NUExTLCBleHBvcnRpbmcgdGhlIHRvcCBsYWJlbCBjYW4gcHJv dmlkZSB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIHNlZ21lbnQgdG8gYmUgcHJvY2Vzc2VkLCBidXQg aW4gU1J2Niwgc2VnbWVudCBsaXN0IGFuZCBzZWdtZW50cyBsZWZ0KGN1cnJlbnRseSBub3QgZGVm aW5lZCBpbiB0aGUgZHJhZnQpIGFyZSBib3RoIG5lZWRlZCB0byBwcm92aWRlIHRoZSBzaW1pbGFy DQogaW5mb3JtYXRpb24uPGJyPg0KMikgRWxlbWVudCBmb3IgU1JIIFRMViBpcyBub3QgZGVmaW5l ZCBpbiB0aGUgZHJhZnQsIHdoYXQncyB0aGUgY29uc2lkZXJhdGlvbiBhYm91dCB0aGF0Pzxicj4N CkJlc3QgUmVnYXJkcyw8YnI+DQpZYW88YnI+DQotLS0tLS0tLS0tLS0tLS0tLS08c3BhbiBsYW5n PSJaSC1DTiI+5Y6f5aeL6YKu5Lu2PC9zcGFuPi0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxzcGFu IGxhbmc9IlpILUNOIj7lj5Hku7bkurrvvJo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlRob21hcy5H cmFmQHN3aXNzY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlRob21hcy5HcmFmQHN3aXNzY29tLmNv bTwvYT48YnI+DQo8c3BhbiBsYW5nPSJaSC1DTiI+5pS25Lu25Lq677yaPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8 L2E+Ozxicj4NCjxzcGFuIGxhbmc9IlpILUNOIj7ml6Ug5pyfIO+8mjwvc3Bhbj4yMDIyPHNwYW4g bGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj4wMTxzcGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+MTU8 c3BhbiBsYW5nPSJaSC1DTiI+5pelPC9zcGFuPiAxNzoyNzxicj4NCjxzcGFuIGxhbmc9IlpILUNO Ij7kuLsg6aKYIO+8mjwvc3Bhbj5bc3ByaW5nXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQ8YnI+DQpEZWFyIFNQUklO RyB3b3JraW5nIGdyb3VwLDxicj4NCkZvbGxvd2luZyB1cCBvbiBqdXN0IHJlbGVhc2VkIFJGQyA5 MTYwICg8YSBocmVmPSJodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwl MkZyZmM5MTYwJmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3 QzM4NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTViODdjMWM3NDIwZDliZWVj MzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODIwODkzOCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1JMEduZm96SWV1U1lGY2hWZEI5U2Rx NXBKS0pBJTJCTWpnZjhLVCUyQjR2NDhOOCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRnJmYzkxNjAm YW1wO2FtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzAwOTM4 OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUxZTQzJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTli NTU3YTElN0MwJTdDMCU3QzYzNzc5ODIzNzMzOTUyMjA3NyU3Q1Vua25vd24lN0NUV0ZwYkdac2Iz ZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENK WFZDSTZNbjAlM0QlN0MzMDAwJmFtcDthbXA7c2RhdGE9WlJZelNrRlhDRFNTVVlwckxYamdIQWRm UUhQTEZuVGw2c0E4eE1XMlVyNCUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+KSwNCiBJUEZJWCBj b2RlIHBvaW50cyBmb3IgTVBMUyBTZWdtZW50IFJvdXRpbmcsPGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtdGdyYWYtb3BzYXdn LWlwZml4LXNydjYtc3JoJmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29t LmNvbSU3QzM4NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTViODdjMWM3NDIw ZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODIwODkzOCU3Q1Vua25vd24l N0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJ NklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1jOGloeCUyQnM5R3JmZzN5 VGkyVG9INEVZYjZhdGRmSVRnaFBON0h0UXl4MkElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFm dC10Z3JhZi1vcHNhd2ctaXBmaXgtc3J2Ni1zcmgmYW1wO2FtcDtkYXRhPTA0JTdDMDElN0NUaG9t YXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzAwOTM4OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUxZTQz JTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzc5ODIzNzMz OTUyMjA3NyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDthbXA7 c2RhdGE9T1dnUUFBN2JDOThRS0NnbWRtempVSSUyQnNVUngwY2xCdnU0R1ZiSHcwVHVFJTNEJmFt cDthbXA7cmVzZXJ2ZWQ9MDwvYT4NCiBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIHRoZSBTUlY2IGRh dGEtcGxhbmUuPGJyPg0KVGhlIGRvY3VtZW50IGFpbXMgdG8gYmUgb24gcGFyIHdpdGggTVBMUy1T Ui4gRGVzY3JpYmUgdGhlIHJvdXRpbmcgcHJvdG9jb2wgb3IgUENFUCBleHRlbnNpb24gd2hlcmUg dGhlIGxhc3QgU1J2NiBzZWdtZW50IGhhcyBiZWVuIGxlYXJuZWQgZnJvbSwgdGhlIFNSdjYgc2Vn bWVudCBsaXN0IGFuZCBhbGwgb3RoZXIgcHJvcGVydGllcyBmcm9tIHRoZSBTZWdtZW50IFJvdXRp bmcgaGVhZGVyLjxicj4NCkkgd291bGQgYXBwcmVjaWF0ZSB5b3VyIGRvY3VtZW50IHJldmlldyBh bmQgZmVlZGJhY2suPGJyPg0KSSBhaW0gdG8gcHJlc2VudCBhdCBJRVRGIDExMyBhdCBPUFNBV0cg YW5kIFNQUklORyBhbmQgcmVxdWVzdCBhZG9wdGlvbiBhdCBPUFNBV0cuPGJyPg0KQmVzdCB3aXNo ZXM8YnI+DQpUaG9tYXM8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPC9hPiZndDs8YnI+DQpTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxNSwgMjAyMiAxMDoxMiBB TTxicj4NClRvOiBHcmFmIFRob21hcywgSU5JLU5FVC1UQ1otWkgxICZsdDs8YSBocmVmPSJtYWls dG86VGhvbWFzLkdyYWZAc3dpc3Njb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+VGhvbWFzLkdyYWZA c3dpc3Njb20uY29tPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaC0wMC50eHQ8YnI+DQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAwLnR4 dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGhvbWFzIEdyYWYgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZpeC1zcnY2LXNyaDxicj4NClJldmlz aW9uOiZuYnNwOyAmbmJzcDsgMDA8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgRXhwb3J0IG9mIFNlZ21lbnQgUm91dGluZyBJUHY2IEluZm9ybWF0aW9uIGluIElQIEZsb3cg SW5mb3JtYXRpb24gRXhwb3J0IChJUEZJWCk8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAmbmJz cDsgMjAyMi0wMS0xNTxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg OTxicj4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBo cmVmPSJodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZhcmNoaXZlJTJGaWQlMkZkcmFmdC10Z3JhZi1v cHNhd2ctaXBmaXgtc3J2Ni1zcmgtMDAudHh0JmFtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3Jh ZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0 ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4ODM2NTE1 MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJs dU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT03Z3lS cWZ5U2JVbVNGTU5kWlE2JTJGUzlVWGdzRmcwWGQ1N1lWMmhmT1dkJTJGSSUzRCZhbXA7cmVzZXJ2 ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGYXJjaGl2ZSUy RmlkJTJGZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoLTAwLnR4dCZhbXA7YW1wO2Rh dGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMDA5Mzg5YTNjN2FmNGU1 M2RhODIwOGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAl N0MwJTdDNjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9p TUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUz RCU3QzMwMDAmYW1wO2FtcDtzZGF0YT1YU3A3em5WaklrUXFQWkxwQ1V4MDR0RDFlYUg5Um9PSFQ2 eEpsWDFjTXEwJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZXVyMDMuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGZG9jJTJGZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYtc3JoJTJGJmFtcDtk YXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBiNDcwMjRl NTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0Mw JTdDMCU3QzYzNzgwMzgzMDQ4ODM2NTE1MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MzMDAwJmFtcDtzZGF0YT1KVVclMkJ0dnZBaERkOTY0JTJCZVNwRGRRZWFkajFmaWxnZFNv SmlYd2FWVzR4RSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZXVy MDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRh dGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtdGdyYWYtb3BzYXdnLWlwZml4LXNydjYt c3JoJTJGJmFtcDthbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20l N0MwMDkzODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVl YzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIwNzclN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7YW1wO3NkYXRhPWU4MGtkN0tyazdWNHlpdzZq dGp5aDdPMTQ0SFB3d0FsSmtVTU5ZY096WGMlM0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9hPjxicj4N Ckh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZXVy MDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRh dGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LXRncmFmLW9wc2F3Zy1pcGZp eC1zcnY2LXNyaCZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20l N0MzODc0ZDUwYjQ3MDI0ZTU4N2E5ZTA4ZDllZjM0NWZlZSU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVl YzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc4MDM4MzA0ODgzNjUxNTMlN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9T1BnNTUlMkZLREk4ZWVVSW5aVnV2 Tlp5WFNFR0lrQ3VJT1pEUEIxSUpLcGFZJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtdGdy YWYtb3BzYXdnLWlwZml4LXNydjYtc3JoJmFtcDthbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdy YWYlNDBzd2lzc2NvbS5jb20lN0MwMDkzODlhM2M3YWY0ZTUzZGE4MjA4ZDllYTFlMWU0MyU3QzM2 NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1N2ExJTdDMCU3QzAlN0M2Mzc3OTgyMzczMzk1MjIw NzclN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYy bHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7YW1wO3NkYXRh PU9XZ1FBQTdiQzk4UUtDZ21kbXpqVUklMkJzVVJ4MGNsQnZ1NEdWYkh3MFR1RSUzRCZhbXA7YW1w O3Jlc2VydmVkPTA8L2E+PGJyPg0KQWJzdHJhY3Q6PGJyPg0KVGhpcyBkb2N1bWVudCBpbnRyb2R1 Y2VzIG5ldyBJUCBGbG93IEluZm9ybWF0aW9uIEV4cG9ydCAoSVBGSVgpIGNvZGUgcG9pbnRzIHRv IGlkZW50aWZ5IHdoaWNoIHRyYWZmaWMgaXMgYmVpbmcgZm9yd2FyZGVkIHdpdGggd2hpY2ggU2Vn ZW1udCBSb3V0aW5nIEhlYWRlciBkaW1lbnNpb25zIGJhc2VkIG9uIHdoaWNoIFNSdjYgY29udHJv bCBwbGFuZSBwcm90b2NvbC48YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMy5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nJmFtcDtkYXRhPTA0JTdDMDElN0NUaG9t YXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBiNDcwMjRlNTg3YTllMDhkOWVmMzQ1ZmVl JTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzgwMzgzMDQ4 ODM2NTE1MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0 YT0wd0doQ2xxUHJwcHRyNGt5OW1JTllnZG90ZiUyQmpTOU5xeERlN2RCSjBiVDQlM0QmYW1wO3Jl c2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZzcHJpbmcmYW1wO2FtcDtkYXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0 MHN3aXNzY29tLmNvbSU3QzAwOTM4OWEzYzdhZjRlNTNkYTgyMDhkOWVhMWUxZTQzJTdDMzY0ZTVi ODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzc5ODIzNzMzOTUyMjA3NyU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDthbXA7c2RhdGE9Mm1G U3VyeEVTaEdESkdJeHZxT2l3TzhwdnB2RkU3YklvVzlNJTJCWTVsVGNnJTNEJmFtcDthbXA7cmVz ZXJ2ZWQ9MDwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3By aW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmlu ZyZhbXA7ZGF0YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20lN0MzODc0ZDUw YjQ3MDI0ZTU4N2E5ZTA4ZDllZjM0NWZlZSU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1 N2ExJTdDMCU3QzAlN0M2Mzc4MDM4MzA0ODgzNjUxNTMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW Q0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9MHdHaENscVBycHB0cjRreTltSU5ZZ2RvdGYlMkJq UzlOcXhEZTdkQkowYlQ0JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nJmFtcDthbXA7ZGF0 YT0wNCU3QzAxJTdDVGhvbWFzLkdyYWYlNDBzd2lzc2NvbS5jb20lN0MwMDkzODlhM2M3YWY0ZTUz ZGE4MjA4ZDllYTFlMWU0MyU3QzM2NGU1Yjg3YzFjNzQyMGQ5YmVlYzM1ZDE5YjU1N2ExJTdDMCU3 QzAlN0M2Mzc3OTgyMzczMzk1MjIwNzclN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lN QzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNE JTdDMzAwMCZhbXA7YW1wO3NkYXRhPTJtRlN1cnhFU2hHREpHSXh2cU9pd084cHZwdkZFN2JJb1c5 TSUyQlk1bFRjZyUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2V1cjAzLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcmYW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFm JTQwc3dpc3Njb20uY29tJTdDMzg3NGQ1MGI0NzAyNGU1ODdhOWUwOGQ5ZWYzNDVmZWUlN0MzNjRl NWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3ODAzODMwNDg4MzY1MTUz JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1 TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPTB3R2hD bHFQcnBwdHI0a3k5bUlOWWdkb3RmJTJCalM5TnF4RGU3ZEJKMGJUNCUzRCZhbXA7cmVzZXJ2ZWQ9 MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnNwcmluZyZhbXA7YW1wO2RhdGE9MDQlN0MwMSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Nj b20uY29tJTdDMDA5Mzg5YTNjN2FmNGU1M2RhODIwOGQ5ZWExZTFlNDMlN0MzNjRlNWI4N2MxYzc0 MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3Nzk4MjM3MzM5NTIyMDc3JTdDVW5rbm93 biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJU aUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO2FtcDtzZGF0YT0ybUZTdXJ4RVNo R0RKR0l4dnFPaXdPOHB2cHZGRTdiSW9XOU0lMkJZNWxUY2clM0QmYW1wO2FtcDtyZXNlcnZlZD0w PC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3ByaW5nJmFtcDtk YXRhPTA0JTdDMDElN0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM4NzRkNTBiNDcwMjRl NTg3YTllMDhkOWVmMzQ1ZmVlJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0Mw JTdDMCU3QzYzNzgwMzgzMDQ4ODM2NTE1MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MzMDAwJmFtcDtzZGF0YT0wd0doQ2xxUHJwcHRyNGt5OW1JTllnZG90ZiUyQmpTOU5xeERl N2RCSjBiVDQlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_ZRAP278MB017621DBE533D68302AF9D1089379ZRAP278MB0176CHEP_-- ------=_Part_1812520_661749683.1645168502914 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 HuzkCrsqTOsJYDnOymLYLm4AADGCA7swggO3AgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAh4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMjE4MDcxNTAyWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCBWuGuL l5VfFGn2SDG4sgTTL28H5aGyXyC+j5NXxFmK/TB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQBOsDD/PuK25Enev7gnLqD5yKWf ccNhJbM5x1tTyzvXLPnr/xfwXkExdFkVE3RKG+LxoYvR6SZ1NV4i5jAofm24A9Wh8RfSoBbwLZE7 yjPSTEy0f6IGxNCRkk19in3EQDlJveB5zQOdkPyC6/ot7BxykAgQkXAZmdQzOEjgCdyXX15DrEw9 b4wbRCQFsTpCVdFWL0GvOxSEhjw0nbU8Lspf2LYfiB6LvwHkSJyHmwVL5QE/8E/C3+uQv09b6xUw rC0PWVARRGwKaM33nh3uguJSrCdJ5KBZbxhaO7RTunq+2vdHTqEwjQrE23lgyllblAlsU/9m0E+q nHLfCwDeLAyDAAAAAAAA ------=_Part_1812520_661749683.1645168502914-- From nobody Fri Feb 18 06:00:14 2022 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 812503A10E9; Fri, 18 Feb 2022 06:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQdP0IeKQtMM; Fri, 18 Feb 2022 06:00:03 -0800 (PST) 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 6A9C93A0DE4; Fri, 18 Feb 2022 05:59:58 -0800 (PST) Received: by mail.swisscom.com; Fri, 18 Feb 2022 14:59:56 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_4757176_1928960553.1645192795789" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q8oOrWI6uSV1gGXt0yCGlw/O06QHOQgnbWBIku/3hx+3N87M8IC6Y2zsY/3goUUWh2WPc6EdYJmk3jCllySjla9F6ixmd4S2a/R0P/129KQtvehkfEoizvp3Nr8i1qCEc6G502orWMdoANwQZM64b8VIUZvNb6m9jiB+Jku+E1qMpzTrrs3ES8Gn/4Xw++NrwByf1olhgtTY3SsyMBr9fid+hS2RBZyIYGl3VPUA089ao5uSj+b8fmk3/kKVETOVVpxEiQYBGXoSVGvOeRkaqfiVXv3Wjo3OHY8Kf3U4GrzwV7mtk8U8gk6AmrBFTP57sqSX+rJbe+q6uixJOTB+bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pC04bV7iPkzh7kAtKl3E2Qfc8ow66M47To8daHO7uaE=; b=bKeoe3Q7lP5rvoLzcZsMH2N9eKI2YD5sTiti7fkii7/FQyZMT+A1TDkrEYqgUO0y4yZc4WLYU2OsNgew7BBTZYTrTFwKmYl+qx/sBasNJvlVXS55ZZ9QNaXRR4GbrqPLDWRTNo6+OJoUejMnz9c6vOWXmtUPfF1AoVF+abe4m4LG50rQbXgdVHLa4JtsljIewbcaww9AB7Tg9z+gSCVuIEp3DSrt6zF4wANtXcZ1zus+etq48lzWFHzI7Dw/07wfc+Jw9Ot/bA12Zw+DVp4y9b71irAC4miuYHlEGmLvwbKsMyXo4gjBHS8YFuOnpSSK0iisRem2V3qOv/iCbFL2ig== 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: , Thread-Topic: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-01.txt Thread-Index: AQHYJM4z02TMVY9jv06GHAsxP2qBTKyZUv9A Date: Fri, 18 Feb 2022 13:59:52 +0000 Message-ID: References: <164519210038.10020.7253475367910712592@ietfa.amsl.com> In-Reply-To: <164519210038.10020.7253475367910712592@ietfa.amsl.com> 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_SetDate=2022-02-18T13:59:51Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=f00290a0-9b00-4bbf-b3d1-4c95b8d44739; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bd29cc1c-0750-4bb6-0e25-08d9f2e6efd3 x-ms-traffictypediagnostic: GVAP278MB0151:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IztN/kP+tlebMFFJnx7Q1tLelwpwfCuV2hP2l1hWMaDuQfHn3VV43ZEssUhZBO48FPuNiPbRJpFBNxUQgFN6mHgGcO++mf48c313tAsdw4biqWgfWVTpbq9+DqtMzpsW8EfNkCe2OfJ8z6aRS+u3o/40HyE9kqWZr/DOmoGIQjTzeWN9NzVpfn1vTeIj1hvxunwzBScyKIY/Mu2HVerHHugRq+w9KeP152rfyIkWTDXb5Yru6E7axDYyvyqOgB/u8i0bD+ejnUdfe4c2cEu4CM7gMGIk3F48YTDK9hfJKq9V3KdKb++c3P0pG63P6GNCXNP0I70767rcxhS30W3ZilkBRFJDh4RK7ZxPSuJzqByxumUloRXPDC5llqE9d4IDGvtFXoWtqTPAwia7oYeS/qDgQTNGq0nZ0RSJq9mciVOENjf0Yklg9KjzPsQGicyT2jWmtENm2wM7XyPiYYwACjLTYC03Jf0mahvh/UwIh5sAPEnQrTqpcffNEocGZWiZRh9jKsJDLmwpYYRwHr31r/aF6MsiZyKNj086gQ1tVv9IaKVtj9hbJbVi/AfMl1W5ibQE/4y2P3/sB3egkLlo5vL5EMihcS5GbVT+FS54Il7AMuUz7vhcABpZvSKgwg9YZKd3U6SDDtgqThQaBupxDSCEQXvdxsyNfBpFLZ2K32iMqQ4xFvM6K6udQQvHDS458ox6ly6BnLhxiO11ETVpmf/xY4BWBxdpSVjDBg22pYqUHgzvJOc1SUcaaz2S0J+A7YpWvMBY4NAMwtUJjP2Yn2GTZbHTu5OPeO5xaTth+XA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(33656002)(186003)(26005)(19627235002)(6506007)(66574015)(966005)(508600001)(10290500003)(53546011)(55016003)(9686003)(7696005)(82960400001)(122000001)(38100700002)(86362001)(38070700005)(71200400001)(83380400001)(64756008)(8676002)(66446008)(66946007)(66556008)(76116006)(15650500001)(316002)(66476007)(110136005)(8936002)(10300500001)(52536014)(2906002)(450100002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?eAX9jrSdI94tzThn+wY0JN8aHqHvrfn36L2UKy0tN1PJ67ddbab26IllSwFp?= =?us-ascii?Q?+DK8JHQ1i1r6O/NeOY8fn+xscGFpciP2GJHQnck9DyWaub24V7oXH1gkvg1u?= =?us-ascii?Q?GNDv8F8t7SzGDHR+yZsmOCRlf2O25bRmosZ76pVn8O0N8xZtMNRzxtTkd0WN?= =?us-ascii?Q?LIcnT/OAlemLUpVoykXHsc0f4AU3oapz+rq3jgvlnf6KfUSYC7vEZ8OT7Ib3?= =?us-ascii?Q?w4TZrWx9PNlez45RebURhQ87AB1X2tcd/WlCTsa1cjYBRbdnfIDfAzvldHkT?= =?us-ascii?Q?+Z2WHo6MfVhtEOyAIMqzmXVJ+sB0QqaPKhjZs9t1TDZIzNG1QHjSRGnxv8z6?= =?us-ascii?Q?SWwNqkXwL9p33xMr69HF6UchMKsJkMtVuYXCFOLxXxNlrDZ2HV50KTdDLvFL?= =?us-ascii?Q?8uSw0RQjeFz4BQYW5rcVlY2hF0qKIIHCyQlpioZktChfMr4/549xslPPxari?= =?us-ascii?Q?VRpQEFzx0LTYyicWG/yRSMRWEkfGQA7l8/8L8PMv9CLwGKIpcz0A7A0G6YrX?= =?us-ascii?Q?FW0/tCHH7Cg0wL7SCu/1X5ith5FaiMla6jtwYa5vYXsaQAWx7CrirbclNBVN?= =?us-ascii?Q?YLQA3JZ2j3eIfc8DA6OMXKA9teRk9jj4Mt0mYgK0KbexWJ/aPg2CqrPkymv5?= =?us-ascii?Q?GSqQ7vwvm8wnuwMH/K02RUOXBx0vcDF9D0m4SGJV15Hb95x7n+fkivhFm4ug?= =?us-ascii?Q?zwK7+hmWVFI0xHbdv7Mk3lr6Bi8m8uWYfRsH7oiz8lILHRK3nC/iv8ruspRq?= =?us-ascii?Q?Gn8elir5xxrgsVikGjJHUmc4BWIU2FKCLH5eXl2gmt7WOmoOrBu/neeeL8YE?= =?us-ascii?Q?jkuAN9rMW4K9XCYXzPMB23oGGdw/7DCs9uCeyukIymDwh0Yhs41LKYVeR+4Z?= =?us-ascii?Q?obUdBidthlcdjkYdQ4UNuIPfQfzJr/55c1cBfwU46xW/4xFETQhjmvhLqz78?= =?us-ascii?Q?6fbpbZ2APMp1eSV/BiruZzWvwUe2XwhzbMXpRysAb1PvZMaXOQlzGeemrttu?= =?us-ascii?Q?MetNOovajCYDxYG7Xjqza3HPKQtcS8dZ2OmJDTXHMZMxK24abDlPLKAH12IW?= =?us-ascii?Q?NJ0kavSqB7hUe5lVicyvCpAgARN4qxEVIQgzBiqNf1e1cE4K9PFj8YcoXWuo?= =?us-ascii?Q?eBn7hBDiMgG7JAfDogyLIAqeaBO1W9rRJbQd69PHZJ6F5kJpe42ZF+x6aQIP?= =?us-ascii?Q?mHA3YTvzKYhxZqj/Fd2LirBtfGodTBJoBph9nyFKt+i60+W3pEifHOEB2Ll+?= =?us-ascii?Q?DTNhTabbP6s9qyhxx/0wQQNro8JLzzUAE0nJZdgF/TRGSoV8OQGLvPWVxKBw?= =?us-ascii?Q?/QzN9JNtS+nDmMEeU1nL62UFCtGGJD3IL6TY0+izgYnMD1+6IcxTvTWDiBBg?= =?us-ascii?Q?nx43JHm/Ins03kCKebSIDEZ01f2cDopdAvI5mkVGouRW9Qnbt9Vr8SxIQYNR?= =?us-ascii?Q?wQj92QxYUeQQtBpfFrH9q2mt+YT47ZJ8cwzQIz3jXuNigPTssnrjnjYjeGK3?= =?us-ascii?Q?7yWzQoiKp0FPUpjqOhEVssl0/CjhGppvGLzDHVghoAKWNA2NZDtA8pJCWXJ4?= =?us-ascii?Q?R+ABN+tHcpgw+JjtaxFHArfuW6D8NcBKSFy5KS5ptAmgto8m0TKGbw575ZeU?= =?us-ascii?Q?nm6MPNeq/GRoWKHz0D8DZUP8oVGCNHSwnL5Pp/daZ3WCsgyq1/IMK6NaOBWF?= =?us-ascii?Q?l/Lf0g=3D=3D?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: bd29cc1c-0750-4bb6-0e25-08d9f2e6efd3 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2022 13:59:52.9153 (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: 7w3YL+t6OKofCm6Qp86UyVdOUJy4KXwKFeQd8XY9kxcjvqICMf2SgDDNWsrYuYTiPGpU0c5PEPY7zM+dIHtndSTV8Tqr1G4wTO8zPD9ULxk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVAP278MB0151 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Mailer: Totemo_TrustMail_(Notification) X-Trustmail: processed Archived-At: Subject: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-01.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: Fri, 18 Feb 2022 14:00:08 -0000 ------=_Part_4757176_1928960553.1645192795789 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear OPSAWG and SPRING working group, Based on the feedbacks I received on and off list, I updated the document.= =20 Apart from the small editorial changes, the following points have been addr= essed - added ipv6SRHSection to expose the SRH and it's TLV's in one IE - added ipv6SRHSegmentsLeft to expose how many SID's are left to be conside= red for forwarding Looking forward for further reviews and comments. Based wishes Thomas -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Friday, February 18, 2022 2:48 PM To: Graf Thomas, INI-NET-TCZ-ZH1 Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-01.= txt A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-01.txt has been successfully submitted by Thomas Graf and posted to the IETF repos= itory. Name:=09=09draft-tgraf-opsawg-ipfix-srv6-srh Revision:=0901 Title:=09=09Export of Segment Routing IPv6 Information in IP Flow Informati= on Export (IPFIX) Document date:=092022-02-18 Group:=09=09Individual Submission Pages:=09=099 URL: =09https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix= -srv6-srh-01.txt Status: =09https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfi= x-srv6-srh/ Htmlized: =09https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg= -ipfix-srv6-srh Diff: =09https://www.ietf.org/rfcdiff?url2=3Ddraft-tgraf-opsawg-i= pfix-srv6-srh-01 Abstract: This document introduces new IP Flow Information Export (IPFIX) information elements to identify the SRv6 Segment Routing Header dimensions and SRv6 Control Plane Protocol that traffic is being forwarded with. = =20 The IETF Secretariat ------=_Part_4757176_1928960553.1645192795789 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 HuzkCrsqTOsJYDnOymLYLm4AADGCA7swggO3AgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAh4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMjE4MTM1OTU1WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCB48M7B 1/NDW0zizo5XJSFoOhYw+7FcXFhekx7T5GyTlTB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQA/zJM3EkP/k2EzcEXAFYDAo4Q+ rY+KRDadhyDQJN/IFlkdtr/+tjd+X/osMIVbHQ9WjOT3adgd4yye4NZgK08OePlnh+9SGC7JuKWz c0yPmWtBm0lWnJpkwCm2B/QVgKa7hoyG4OpTqBqLYLrCczAq7LIvDFYGDauvfVZneg3Vr4vrpeJE T6LjhrZaA07orDGkh3OS6EJ8LhNeqGQvwnu+n8PhqH633J5KMOUF5HFtHp+tf674JlLSR6qIdZwT xmgGGulfp5Mfs0cHe3VySMtVV+jURme2ooocCHLcTKSEaKXe4Gi6lTU2l93FCxZFgtoA1EXr2vGI IU51UqLIILCEAAAAAAAA ------=_Part_4757176_1928960553.1645192795789-- From nobody Fri Feb 18 09:12:57 2022 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 C73553A1200; Fri, 18 Feb 2022 09:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxDqSCOtSfPp; Fri, 18 Feb 2022 09:12:51 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 279573A10A8; Fri, 18 Feb 2022 09:12:51 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4K0dYX1DlNzyt0; Fri, 18 Feb 2022 18:12:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645204368; bh=yrgIU+ClkM+ZzdMbyCEFBMOmA3OCPvweyqS5iX9EUQc=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=m8ZGjHdMmSdp587K8O83mrVUWY/24WYz1n96caeCYUy4AZJmYaepcd1xYypHRB0o0 SY0nDTuaYbkHP+Is79yMNjKXntecDBHu+ZFqqyPMCb0v/swqEhVjBlCI82R0M7tUdG pNd9DesJEjWE+FuJRvhI5Wr2qEtfehDu9K2qUVb+M2xeB2hlccfcwfhDunV0+apalC VXjVMs1IEjmQfrUwJLnWnUNYShlLbBQHGlESDv661v+hLM6RKCLMLm+LNkFBy1RAix UsqxMtTnCwI+pgz7YGKhQ7121os+2EklFzkGJlCxQ9Qg0NCQrdP57C2oa4EbRo0mc+ z6PvxLdevS7eA== From: To: "draft-hu-spring-segment-routing-proxy-forwarding@ietf.org" CC: SPRING WG Thread-Topic: IPR poll - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZrGtJ4kNOcThSViQ7BuFbn/8Lgcg088w Date: Fri, 18 Feb 2022 17:12:47 +0000 Message-ID: <8753_1645204368_620FD390_8753_143_1_979641027016468abe7acadc59e3e881@orange.com> References: <3104_1642069058_61DFFC42_3104_319_10_8549b268004442668017df2d9b036441@orange.com> In-Reply-To: <3104_1642069058_61DFFC42_3104_319_10_8549b268004442668017df2d9b036441@orange.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-18T17:12:45Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-18T17:12:45Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: fc33b2e5-0bce-42fa-a4f7-f77e085d8d4e msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.27.53] Content-Type: multipart/alternative; boundary="_000_979641027016468abe7acadc59e3e881orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] IPR poll - draft-hu-spring-segment-routing-proxy-forwarding 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, 18 Feb 2022 17:12:56 -0000 --_000_979641027016468abe7acadc59e3e881orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors, If I'm not mistaken, we received a reply from: * Re: [spring] IPR poll - draft-hu-spring-segment-r... Huaimo Chen * Re: [spring] IPR poll - draft-hu-spring-segment-r... Huzhibo * Re: [spring] IPR poll - draft-hu-spring-segment-r... yaojunda So we are missing replies from the following co-authors: C. Bowers Y. Zhu Y. Liu Thank you, --Bruno Orange Restricted From: spring On Behalf Of bruno.decraene@orange.c= om Sent: Thursday, January 13, 2022 11:18 AM To: SPRING WG ; draft-hu-spring-segment-routing-proxy-forw= arding@ietf.org Subject: [spring] IPR poll - draft-hu-spring-segment-routing-proxy-forwardi= ng Hi authors, contributors, WG In preparation of the WG adoption call on draft-hu-spring-segment-routing-p= roxy-forwarding [1], this email starts a poll for IPR. If you are an author or contributor to the subject document, please respond= to this email. * In your response, please indicate if all relevant IPR has been disclo= sed. * If you know of relevant IPR that has not been disclosed, please state= that and describe how this gap is being addressed. Even if you are not a contributor or author, if you know of relevant IPR, p= lease ensure that it has been dislosed as discussed in BCP 79. If you know of someone else IPR that you believe is relevant and not disclo= sed, please file a third party IPR disclosure. Thanks, Regards, Bruno, Jim, Joel [1] https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-p= roxy-forwarding/ ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_979641027016468abe7acadc59e3e881orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors,

 

If I’m n= ot mistaken, we received a reply from:

 

So we are miss= ing replies from the following co-authors:

C. Bowers

Y. Zhu

Y. Liu

 

Thank you,

--Bruno

 

 

 

Orange Restricted

Fro= m: spring <spring-bounces@ietf.org> On Behalf Of bruno.decraene@= orange.com
Sent: Thursday, January 13, 2022 11:18 AM
To: SPRING WG <spring@ietf.org>; draft-hu-spring-segment-routi= ng-proxy-forwarding@ietf.org
Subject: [spring] IPR poll - draft-hu-spring-segment-routing-proxy-f= orwarding

 

Hi authors, co= ntributors, WG

 

In preparation= of the WG adoption call on draft-hu-spring-segment-routing-proxy-forwardin= g [1], this email starts a poll for IPR.

 

If you are an = author or contributor to the subject document, please respond to this email= .

  • In your response, please indica= te if all relevant IPR has been disclosed.&= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     
  • I= f you know of relevant IPR that has not been disclosed, please state that a= nd describe how this gap is being addressed.

 

Even if you ar= e not a contributor or author, if you know of relevant IPR, please ensure t= hat it has been dislosed as discussed in BCP 79.

 

If you know of= someone else IPR that you believe is relevant and not disclosed, please fi= le a third party IPR disclosure.

 

Thanks,

Regards,<= /o:p>

Bruno, Jim, Jo= el

[1]      https://datatracker.ietf.org/doc/draft-hu-spring= -segment-routing-proxy-forwarding/ = ;            &n= bsp;            = ;            &n= bsp;             =     

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_979641027016468abe7acadc59e3e881orangecom_-- From nobody Fri Feb 18 11:48:29 2022 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 61F203A13BD; Fri, 18 Feb 2022 11:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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.714, 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 n99ItKymUjeX; Fri, 18 Feb 2022 11:48:16 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF803A13BA; Fri, 18 Feb 2022 11:48:16 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id d16so8725990pgd.9; Fri, 18 Feb 2022 11:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CinmUZ0mRo47FGqBWUNOmQDEbGos/kqk7FJMwL/+K6M=; b=OKnhiiPCJivt4OiJqIwesEQSNIYx0a+ZwzckleuDOouxF1qymRGJExVpBQZz6hEizg IXsP1knrQX9qFv5LvywqSnSOaaGdv5b99uiar7ypBoZKtgdUs/qcw8pGyKy7B4DBbphS khc6OXeLG4OLzDEj6kI4/IA8E0xNtZqW5qG7C0SO+vlOtr7+yz8NvNm115RL8RV9B2ow 4Q61F1tKHPN2HPhdhwnQJsx4feVGFHYU7JMR7ytZEnsbrhFGmPfas32iREOlOIfdytSp /TSTfMmV4e4VdhQhgJlv88EQPOUnRSmJUiG7AU12Oq8+T4uOClIDe0naaXaIklZgNSI7 /ogg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=CinmUZ0mRo47FGqBWUNOmQDEbGos/kqk7FJMwL/+K6M=; b=Rb7Nd/vT1Blg6l0GzJiSJZ+lA2lGZ4QNHGvbo+9DSJbjryk+srsvBicuek8nkvHUYR 4EZE2sWQeit+IuwtkT+u2ANT/m34NELebuugzF9h5yoRPSgWi2EOjuvj/Xg6Wxu6uIHl PH6OYzBGMkUGffdhLeR3oOf9vVf3Sm+prnFubeOpY3a/13kGgbp7XrwxOJdAu48rvWn3 N0gZspEc+CyGKkiR8K0FsatwC/QppowaZvLNJFPz7jg5/MR2veeiso/XfMWzhRsE+yCW uzkFZzk10OZzTlrRQEvmBlr50oZfxenKVU8BHVeBHzqlLzDdyUUZ22RCWntHO2metPb+ wnOw== X-Gm-Message-State: AOAM532Zg4Ei4SvcV1q9z8ohvmB+O3kpxUru6RcJBDdzg7vDD8eun3Rl tXervoE3jn9be4onw3KQ235B7ypfIHwL0Q== X-Google-Smtp-Source: ABdhPJxXjnnB96wFVKCjhTI0YNRt9vuicFoZrWi0c2ogTU4l6wUtDYPknUOJUhueU8YN0Jj9K0cMMw== X-Received: by 2002:a63:8543:0:b0:35e:3bd9:3798 with SMTP id u64-20020a638543000000b0035e3bd93798mr7620544pgd.73.1645213695931; Fri, 18 Feb 2022 11:48:15 -0800 (PST) Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id p27sm4244137pfh.98.2022.02.18.11.48.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Feb 2022 11:48:15 -0800 (PST) To: Suresh Krishnan , IPv6 List Cc: spring@ietf.org References: <164455296624.22420.8697444414967128483@ietfa.amsl.com> <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> From: Brian E Carpenter Message-ID: <8028d270-121d-8751-b897-8f0839c65566@gmail.com> Date: Sat, 19 Feb 2022 08:48:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0EFAE014-F23F-49DE-B65F-3BE0E65D3CC7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Requesting comments on draft-krishnan-6man-sids-00.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: Fri, 18 Feb 2022 19:48:19 -0000 I find this draft useful and its suggestion of a dedicated prefix would clear up some ambiguity. I think it would need to be standards track to make that prefix assignment. I think section 4.1 "Open Issues to be Addre= ssed with C-SIDs" needs to be actioned by SPRING so that it can be removed fro= m this draft. Similarly, I don't think section 4.2 would really belong in the final version. Regards Brian Carpenter On 11-Feb-22 17:35, Suresh Krishnan wrote: > Hi all, > =C2=A0 As discussed during the IETF112 6man working group meeting I ha= ve written a short draft that describes the characteristics of SRv6 SIDs = and attempts to clarify the relationship of SRv6 SIDs to the IPv6 Address= ing Architecture [RFC4291]. Comments are welcome and greatly appreciated.= >=20 > Text: https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt <= https://www.ietf.org/archive/id/draft-krishnan-6man-sids-00.txt> > Html: https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids >=20 > Thanks > Suresh >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Fri Feb 18 13:15:44 2022 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 B44253A14B6; Fri, 18 Feb 2022 13:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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_FREEMAIL_DOC_PDF=0.01] 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 uV22V3IS8yCC; Fri, 18 Feb 2022 13:14:58 -0800 (PST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 377CA3A14B0; Fri, 18 Feb 2022 13:14:55 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id vz16so17893412ejb.0; Fri, 18 Feb 2022 13:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=ErzcCyRW9XIXtXxfrWPAgqXOFXk4/XIkYrcmh515WxQ=; b=ZeT13fU9+CDXTw8h5trsqeeJtmFFpq51cr/ARCgzyHTbIIBvfsjtCcFgcEuTkvMD8n NL/VmN9VsHVvBWDboOGJBYAQvXY4f8XwQsAbxxs0VxQY8AKmd0lxL/DIhT2BIjmBOc5u hBnwPRJpv3x0705beLgjs8xFyQVIZXqRwHUV0GM7dvUl19TYY2OVSM+p/VbjsFHAKgNc qysrYhWu+/ZAkPrt9UG0UI13m8WpAi5riGfnBz+qfyhYhG6nRWSMCcVKoF2nWz+YRWsM PDyCvCPl3IDyCOQy6MsXSPz/7cN2Wo2I0rZf7fGb/20TalAmnKVIHzwmyGKzJg+H40Ut u9nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ErzcCyRW9XIXtXxfrWPAgqXOFXk4/XIkYrcmh515WxQ=; b=u8owvDsr7IzuPDzqJNxHqgO2YiP+LjuX8W6ODWUfyowOEIgL057ct//d5sWOI70stM 9ze7b1LJZyFVgt+mUiVPSp6IWBc+3rUD04FcRURKPUCIVXMUIIyK7sA9AOP0SsxX6TZw 1t7z6k7Y3Uu3gPMBJ+LoZ4xZ+Tox1Vx9Kxe9zF14nxo5z+aJHYI+O0whJeT/YP0CgdK7 pzWQyYec2LYc22Baiks4CCnair2mfxKoMhI1CQEXl2Pm4X5lXftqbOyESswS7aYsGK/u NSRB6veQ6qJDLX+BzxYVY2pCHzVE/Qu1B3wuuHis617YnmjXj3kfecOWVFrIa6EADxGA tBFg== X-Gm-Message-State: AOAM532zmsQSxeT1zP1TRTz+p3ck0lzuyfeQdKCJ2qTOAqPs2cADrSUU KeLkc0YtcsX2bN3TFk0tpVOMygQs4xrC+VXBWG5e2jK+ X-Google-Smtp-Source: ABdhPJwCQg2iUtlO4niGmFT+7HENZJUNAi1XC3lxK29dKeKQ6V7pzuUB9Ky4riVFdIL9mqNl0tDUGSNWEbp1amhuarg= X-Received: by 2002:a17:906:729d:b0:6ce:538d:1268 with SMTP id b29-20020a170906729d00b006ce538d1268mr7980326ejl.172.1645218892294; Fri, 18 Feb 2022 13:14:52 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Fri, 18 Feb 2022 13:14:40 -0800 Message-ID: To: draft-saad-mpls-miad-usecases@ietf.org, mpls , pals@ietf.org, DetNet WG , spring Content-Type: multipart/mixed; boundary="000000000000a766ad05d8515f47" Archived-At: Subject: [spring] Comments on draft-saad-mpls-miad-usecases 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, 18 Feb 2022 21:15:02 -0000 --000000000000a766ad05d8515f47 Content-Type: multipart/alternative; boundary="000000000000a766a905d8515f45" --000000000000a766a905d8515f45 Content-Type: text/plain; charset="UTF-8" Dear Authors, thank you for your work putting this document together. It helps to analyze essential use cases in the scope of the work at the Open DT. Attached, please find a copy of the draft with my notes and some editorial suggestions. I hope you'll find some of them helpful. I am looking forward to your feedback and questions. Regards, Greg --000000000000a766a905d8515f45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,
thank you for your work putting this doc= ument together. It helps to analyze essential use cases in the scope of the= work at the Open DT. Attached, please find a copy of the draft with my not= es and some editorial=C2=A0suggestions. I hope you'll find some of them= helpful.
I am looking forward to your feedback and questions.

Regards,
Greg
--000000000000a766a905d8515f45-- --000000000000a766ad05d8515f47 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-saad-mpls-miad-usecases-00+GregM.docx" Content-Disposition: attachment; filename="draft-saad-mpls-miad-usecases-00+GregM.docx" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzswt2me0 UEsDBBQABgAIAAAAIQCNsxTWiAEAANUHAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lctOwzAQRfdI/EPkLUrcskAINe2Ch8QGKlE+wNiT1sIv2e7r75m8KoTaplCyieTM3HuPR048mmy0 Slbgg7QmJ8NsQBIw3App5jl5nz2ltyQJkRnBlDWQky0EMhlfXoxmWwchQbUJOVnE6O4oDXwBmoXM OjBYKazXLOLSz6lj/JPNgV4PBjeUWxPBxDSWHmQ8eoCCLVVMHjf4uibxoAJJ7uvGMisnzDklOYtY pysjfqSkTUKGyqonLKQLV9hA6N6EsnI4oNG94mi8FJBMmY8vTGMXXVsvqLB8qVGZHbfZw2mLQnLY 6Us35y2HEHDmWmW7imbStPwHOULcKgj/T1H7dsdDjCjoA6Bx7kRYw8dbbxTfzDtBuNWlSQ8UrfPJ CNUxFyD6Q2kTTkZ6Fj0OBs1/N5sgPxT0PJ0qoxOrwPgZ64VmZ90J4cC6Pghq3874iNcG1M/h2RCV zbFI7Jx66wKeCP+HPbf3TKlOcbcOfJTHf5W7RLQ+e3/QfHl7sml1KY+/AAAA//8DAFBLAwQUAAYA CAAAACEAHpEat+8AAABOAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySwWrDMAxA74P9g9G9UdrB GKNOL2PQ2xjZBwhbSUwT29hq1/79PNjYAl3pYUfL0tOT0HpznEZ14JRd8BqWVQ2KvQnW+V7DW/u8 eACVhbylMXjWcOIMm+b2Zv3KI0kpyoOLWRWKzxoGkfiImM3AE+UqRPblpwtpIinP1GMks6OecVXX 95h+M6CZMdXWakhbeweqPUW+hh26zhl+CmY/sZczLZCPwt6yXcRU6pO4Mo1qKfUsGmwwLyWckWKs ChrwvNHqeqO/p8WJhSwJoQmJL/t8ZlwSWv7niuYZPzbvIVm0X+FvG5xdQfMBAAD//wMAUEsDBBQA BgAIAAAAIQAIFlXw40YAAKylAwARAAAAd29yZC9kb2N1bWVudC54bWzsfVlz28iW5vtE9H/I0Ivt DlPGvqi71IH1Wj22y226ZqLnRj2AYFJEGwR4AVAy69fPOQmAO+WkqsSku9P3RokCyRQSX559+9d/ +z7LyQOt6qwsfrlSr5UrQou0HGfF/S9Xv32NB84VqZukGCd5WdBfrpa0vvq323/6X//6eDMu08WM Fg2BJYr65nGe/nI1bZr5zbt3dTqls6S+nmVpVdblpLlOy9m7cjLJUvrusazG7zRFVdireVWmtK7h 7wVJ8ZDUV91y6Xe+1cZV8ghfxgWNd+k0qRr6fb2GevIi5jv3nbO/kPaMhWCHmrq/lH7yUtY7vKu9 hYxnLQR3tbeS+byVDmzOet5K2v5K9vNW0vdXcp630t5xmu0f8HJOC3hzUlazpIFfq/t3s6T6tpgP YOF50mSjLM+aJaypWP0ySVZ8e8YdwbdWK8z08ckr2O9m5Zjm+rhfpfzlalEVN933B6vv463ftN/v fvTfqHj2334l7JgD2/m7iubwLMqinmbzFYXPnrsavDntF3l4ahMPs7z/3ONc5SSXY+wpbB/lekGe 2++e/yxv7/zpFVWFAxFcYvUNnlvY/pv9nczgFK7/8LMezcbDVTkZSL+AtreAlVJOht+v4XRrvEvX FIrrZJyk0a/TooLrZOsHq3Lysd2b2VigHjfj6UmraP1zfYffTZpkmtSrg44r0tNuylwtt5xtPKP5 /Z8jhL9V5WK+Xi37c6vdrdnaIyoYJ6zVEdQmkdd/7maG02QO3G6W3tzdF2WVjHK4IyAPAiecMATw v3BQ8Ad7Sb+z64g1QR5zdQua0agcL/HnHN4zbuZJldzBobRdVw98Nb5iV0GuNOxq9w+u3oAWNv7y y5Wi2I7quO7q0ueKXVT0yDVXF0M6SRZ5s//xzxsfZnfxuWI/hs0yh/u/eUjyX64+58AAvsI9XL3D N6v2M1VcFk0Nn0nqNANgg3JRZbQin+gjrj71inr/alpvX4IF33Urvuv+Ov7cfyC6GRmWpSt//QOJ PDVwLvmBwK8H9/KCf/rxprn9+PnDkPzfsvoGZ50wOian/ft6TYZJMsZFm3bpY+Cqlq6qjorwSHDP Au5d0dCqoM0A9IpJ82Ms+3//viiyOVuyAW74reYA1zZs0wkcR4J7TnCLMR2jMd4s6htyV7RKHmjV Sf40wP/7mnxMvk2z/0qKjANcM3BDXTMjCe65wI2+z7OKAqiqCtSYLwnogtrTmG7/ew9suSzuediy 6WlaFGoS3DOBi6rpTT1PUtAk5wAyrR7o1e2PId39Fy+aRUUfaUa+0nRalHl5n1EeXq24kRcFnkT8 Z0O8/2eTf0+KRVK1bIGHxg3H8H1N6tWXg/hvNU2TmtYEhDZhWvhdMc7SpCmrmiTFmHhFmuU5ghyC 4c8BsqErvh1GCIYE+bLIeoz696AGO2kwm+fox4NXi+4EDBSFA13NizxdDaX1dDYdzBvVTZWkDQc4 YPtYtqMjDBIcoaT3dZrVZBWHZG/h305IsZiNYKlyQoDuSMt6m2nSkGnyQOH9tJzNyoIUlPL4MgzN j4IgMiTgogFH8dnHp1s5OlkUKRrBJNsWqMlKoKInHd6FLVD2FR72GwS25oWBBFw04HDpG23qa6R1 ukHMY1qnVTaiAHRFSVE2ADih36fJom4yIPGaNm/JaMHDzq04MBRFl9QtHOwqaabwDfgPKYueYyO+ IJcB1BxoOavTRV0j7A373Ba+8IeBr4MI+JIU93TYJFUDN4MBQaV7nAJ2u+V05xE2oeH4uiGPo/Dj yAIkTxywCMTM4eOF9644pmNaW/e+9WiDbiU6oRWINNotsbU/4HkzuKtZVpTVe9zaao/772xtqr/N fvHN++y3IoQYrjkowHZVTdVcqV+fDZUhCyqgusw06o90VvJwKtNSVNX0JU4XYQftxP/gSr0YzbKm AWmZFaAo5znYPW3YiLGErJmiDOVAWlUdyw9sqQ+L14er8iHDZF1GrX7wmdgOQXuHvXS52KsTu06k SfYqHMxtiq2ZqosheDRue68Gwxk13f7DJCrus4LSik+dVJ0gNk1T+onFM+mk/kbisgLW+/ou+hq/ AaP2U9nQ1swpmelzjypnTWbJkiR5XaK904CZu2h4uLRlKm4U29JyEA71PhEnu/K5d2nkgDCSeLqo KnRirj7Fo4C5uqEqoScBFw14x8BB50Ifc9PM65t379DxiDGFb7S6zmgz6TPC4ZPvOrjf8QhsK7Rt S3VfIHFUwvznBTYDdIPS4SllY+aoToCPf89mixnSd519JzO40ylPzoZqR05s6TK/TjjiqFqjNB5R spgDQdPxW1LReQ6fhFcAcjmqy5yijTVadkJ8g+ujW3rJAbgZ656t+xJw4YA32YyCaL5jBnRWJHOw uOZVlqCeVrIAxB4TqOFEdH42Hm6u2JbRgiWhFgr1DEAFZHMkY8A2zZguTmcdGYNaXiC4V6jNoQcF TsI9fL++vuKAWTd91dFloqV4mA85xx6zPCeUpd2SstjKu+XRyEAd80JdkTR8LnBvg3K+rLL7aYMm c8bFaO1IjawokGqzcApcg/c6fdMmt6MDhHytFjVqSGPm4JrTqka/ZjYG3SmbZBjkxRgwF9aKE0ax Kh3UwrFeZWMli2ZaVujm8IDXMvhRUWKfHPMwWVVRfcW0VInpuZgslva9JRSwy6+3U1q7CpUfFKj8 /XNyT4n6Ow/B2p6nmK4sMjoTuCP8m81yjuQKIPVvHoPHVDzLMVUJz5ngyZO6+YIFfhUdIxH5FU2+ sd3+qK7z450XrssLdv+dWjkSG2GgOFKvFS5GtzOb21j+f9G0QUN1I+rLAoMrVepVTT7Q+yTnQFox wtjSpAUjHunP64j+F9Ymp7hHkBmqfd+bmrzugwoNAk3pOqDAA7YTKKqnICgSbKFg52C6FjUdZMWk fIM+JTqZIFWXBSNldDBjsGC+GOWYzI557Sz8v8EMeFRnI/B1W42k6SueunMKghnsnoeMPiLG8Ms6 PpAmFcW8rOXbztRdrhLbyRL+WGc28UhuX7O8UAsl4qIRR7EMvzdVxupS6jbPDq7MO/G9Tc3oHRlT +M9sXhZ4KDjA1s0gMh0GigRbKNiwbSwapGMyqcrZNrRkht6trEjzBQD8BTgA1i34w5B8aKUAQeSA 8HkYuqPZpufJ+KBwxNeFRyC9h7StPTOumdhGEd76NJkavqnasZK0iseVqTlBGJiSuMVDzXJtsecO cvBy0ZDHpKqSolmisN46Bwj8AQLnUdVsV43DKNQl3GeC+/YrtvVDcg1KbKrEJXFNyzf0SCbAiydK FZMziqYqx4uW95LrE/9HCI8rzPSDSNFMaUIJRxwxR9S/0grL3fLyfnky4joH4oqrh5EWShPqIhDX MHCYVmWxnHUdckYjtKLbPtI/ono+xDVLN8LIkogLRxzR/g0sooBFMfioehdxg4erm4YZKLJx5SXQ uMa4+l0xqLNmQX71Pr4I4lYc2/B/2QztIhBHOu/6zJJhnqUY7PirEVcdJbY8U2ZeXgDiLeZI53/L y1GSk7s+uatCIxqPACVDmtO0KauDiJs8clyzIjuSHWsvB3Gk87isHpOKdWr6kIxojoAnu5AfQNzi QFzRY82zIon4RXB1Ha2zbIawwsqs/1LH5Hn4OyfiUez5liuLWy+ExnXG1YdNkn4bjBJ0fH6kzbQc ty1OPyQNLdIlc7FVZf4sxA1d91XTlh6Yi0EcuTpDnEQA6xI5/CxpeDxwhNg8iAe+YTuBDH1cBFc3 UFcfvic+o+4hvIeSO+77LQZTeD7H+Tsn4prjuYacEnIZiJsb1tlnLHZLZjN+C40PcdM1Y99QpAfm IhC3ADZvPl8lm3mPWNK+oby99j5/enOMwxPi8NC47Xh2FEnEhSOOenpQDuj3rEb1jAVB16njfDTO g7hm67rlyOKOS6DxVk+/Q/cqS0Q71fvGh7jtGaqhazI+fhGIo56+RvxUy5wPcd3wvTCUGWniEUc9 /c775KGxDfdEqy5E+iPK3kTc5aHxOLR0w5b1mMIRRz19SFP4XsNcLKejzoe4aXtWGCvS5yYccaan p9+K8jGn43vK0ov5kD4Ncd0OLEeNZUtf4YjbTFcv2u6PONTiRLy5ady0TdPxpa4uHHEHIFs1bH8G 3ryIq2rombovfW4XoKs7zDr71E5yfcAk8tPw59XcAk/RfKm5XQTizDrrp/eejDkf4ooeWkYgY2fi EffaNjiviDcew3VuT9sG4qrKgbgRG6qpRlJzOxfit7uVCDyi144VO3Rkw2bhZLndX6Mv5qpJNpuX VZPAtY2hgRX9xwI7BaZJVS352u4rihKEii2VLOFIJ+NxhuSZ5GRnJiB6R7viPTaja97OmmO1+I80 ZwlrfO3nFMszA8+QRXzC0Z7RpKixyr4bB0l3QQeyZ1/ga6ShqUaoKnIO7yUwbPhlYwAkG+Q6orQg G/0iR8s1NfdBDjZSAzl8ds8jojXD8Z1IlZqzcMQbmsxWKJYFQDhpE45OmPvKo5M5oR37hjSOhQOO iaMr8mXMep4nBXZjPzb7lUnvDUWOA25dCSLP8GWkWjjcrAc3zlXA9EKQ2Eld4yycbMXRUdXude9u ngIQeFbXC1TMS/guj2qmuZobKFI1E4532gUqsVkOUPpk0Swq7IxVl/mCcfJOem8Jbh4lzQhtO4zl QLuzQfwXNQrWeBoFK57vBIon6zfPBO6JjYKtINAczZQerTPBcyGNgu1QiX0v2IHddGLVtXW0nSTs Z5Kq/0zIXXjTTiEb3IOCNM0Gs3leD7ISzKe1Y3ML1MebDBsTspngaPjctM36f7n6W0XvSzgGH7Oq /rbEd7AlKVjFcCwGijZQra+acmOoN4ry/9odb0GtmXoQC3kSqDjsnlvYoyi4bpM2qX6U5ZijVU7a fExQWtG44SAwM7bDSHF31FbDNmzHjRlkksDOQ2Dw7yjtYI+BU2lHP0w7wDptWxGySWZqXxLxtGY/ jxjy1dC0/R3NXzPCWDXYWFRJJecTQ1/igDiuY20IHeTKRVdwwKandQVlYPIfpSlkeafSlHFxNHVR 9IQqH7O5h18eeCqvtdj3Vc2ytskKZ4J4noFXJVmdT/jsubE3iQVTs39+AfRzCh/d8kNPj3aEj2FH dhQ66K+QVHJm4WO6Jo/Fw575Ty9hLkplO3yLK88uyp4dONJyhj79L0lxT4dNUjUdOFZ3gEWQPtpm XTOTybp5EROclHU/4JGdhmF6kSW7j12C7NxrVvHEIYyK8ZEjiFtxA8v0t7ey9aSDbqU+l7dbYmu7 X6d0BjeJTWyr97jT1Zb339naY3+b/eKb9/nkWVR09NLJWOfZOMhep2IOjgEaQxj5sgJHPMfANINJ meflIxvCtdFvOqvbMHWXLtjnG9xwwKuEtgtWk8wvEQ4vG6m22f+AcuEXeXpo6LJJ9CUI9IQl5g5Y KhiQY4pTk+qsHZqWkJo2+IIW43mZFZjJi8SalkWBc1oesoaHHeuRqkaOKhNGLgHvreyfEZAuJnzW ixEgXXcTd2q6CThLAazrMs3AihtzwG0qihI7lqybuTS4/4URLwph8qr3IdfItF/tpf3B90Azxpww LsANW1F82dTgEgB/xWTyDrxsulLL4LOCA1EjirUwlo1JLgLRv98NQjacdtDQpB6wVx2+A4Zv/fs1 D5Vathb6yk4IQmJ6fkz3tea+q28OC73+NAzecKnRseFa6q4ZpLu+qiqscEoCej4i3cJr0zXOKOtE 17gpXeNP3eJtuqYWVk3a+xKaEvSWJM/+wBq1lsy2BCEPUYWa6xiBLFb6byT5lCB0PEU23RKPaS/0 vtAavgxy73NSNayWmEfgWaEd24olE9cvgTZbP1COQ0cwHFROWN0JgtqV+GPb454r14s5NgFAhxIn HzZCxYo1TfLhS8A6ub8HxQU0FR5uq0aOGSp7GYRKEKmhgSEZidy5gi/Z7HhSILaZ5ddL7a+qdqPa h/VS3zENx3/hXd4Ods9ep4GOad5tiR2NP7+lQ8cwpPm5dgr7wQP7RF5X94mNRwFXRJ2+20N9kDmj QIZv7o4fUqPIUH1N5uOfl8N30HWiu6mSomYCu3mKhagsJe9E29Y6zEMUT4sdVTwPUZ9TvHNgT08w kXNs9WdjIvWKicDZm0yylEfTMOPQ8tX4f2al5LFsP1XrbuCSOAymgXyjSyxEH9fk6uNvw69Xb9uf 5NOv7PWX6D9+u/sShfh6+N778GH1ov0Ex3kwPNtyfQVxkzaDULwBuF9/+9Bhia/WKAe/fvwYfQpb oOEq2bn00fvPKxZ05gFc1yxXc+XEBPGA//r5692vn7wPV/uhZHQEsN4i8FZDK/heQzGlYKvrDAfa uhtqnmohXhJtoWj7wWeiGuTvX+JAU1X3d/bKUW3jd/I4pUWbM1IW+bL7tZkC70/mc5pUeDySPOeA 21Icy1ICmSUmHO40mWdNkrdtHOtp+ViQKa12nEHbGsk69XtPH8H9HIhkCc/9bm/0qROpRnrgaoEs RDibWaCy1t5eWpXFctY2q/JGo4o+ZO1sFg42ohqhFSm+ZCPC2QhpO6bctN3o2gHm7ezbu3XDQSwN 8lYNB0POhoOa7diOKRX/S8D4bggQ3xWDmkHL2TJS17zQjWKZnHQJCH5GBD+XdXMahobrAzRy1vRl cFrgscBp4QFm86psyrTMe5b7mDXplK/num65vq87Mgp7No3nr+kDqHP1AYwMQzdY6yMJ7hnAPbUP oOvFvuvJMoozwXMhfQBV09ZCW5fFUmdjuWhiAnokQPg4ELJV37JjF7GQCJ0JoXYy0KDOmgX51fvI I91Uw/VccydZUHP9SFMsmYZ0Rm10hdu8H6n7lnjjWVZkddNeaB3GHxOMDxQJuuReY3PHN7wdTlS9 fa4bYfzT2ji1uUDOSWF817Mj13vZh9oH6SuaYuQU3zkat9/Iy2C3+uc3f65dNrezZEnaPT6B+IZP ucP7R3cq3qfMbnSFFMs2OcauYlXVbelbFs6ueHmOwLZKh++97Pkrm8s1Jg3N4cw2QPp8RHWoSY8X 6bq2nasknqg2uvSIef63WT9stCw2Z57N2bgz8jjN4AnxzTlTHUf3DKaQSLoXSvcdeKCSPNAKDbkE LlVNli7ypIKXzZTFrlcVZeNyBk/rmgNjJTTsINpt7S4xvlzebovj7beYK8d6NFxlreJ8tW7GwLjM JEmbLk8XfmNd0Fm/6UlG83GN6TY8fMcKjdAKZE2c8DOZjMdtkRRrg8VmdLVTMwlI8yllJa4FGVFs oIVDFrcETlVyjWyyIz2O1FhqlxciZWpSz2maTbI0yfMlgQPAJmuyY4D0XFbkM62YjoF6z0ea1Iu2 iQsP2HoQKLYqwRYO9uvPH99sKwhHle9diYM3rymmawVbNy9e+WY3+uTxM3VH13dbncvjd/7jx1SD FIRHtcChngT0VjIrx6DawsEbNOUAz9/rSIveELQX35fzwWg5gB/k9fvR+zfM5crBbxSM+puuDBIL BxygZAC/bZNvUUMA0k3mNZgwDeoPCPOYbl4p2HlggyNBmUhpzRMB0V1LUx0VsZWIiyfxDe2f0SwB 6u3OAccR4KFw3dCiSN2ps1BDK9Y9hxUSS7zPg3dLrknNmnbiT1ZSMQP9EQezP6FqbJm3TvvoNiIG DILTIgbakS5Fmm0qwbbWcq4HhNQwgKOdjPKLml12+G5bLJ/AbEM97BDbetCOYnuutXXr4tVDdqP9 ZkQ869tOjO2zRi7B5huBG8tkceGMDr1gh1xbG30sN9pDZfP5jI1nHODHf+etH7Rs3/QDS+baCIcb rZR+cDmWADwkVVYuWFu3QZtWVU6YZwTVl88feWjZ0BRX8aWHUzy4jE53B6kO6ur3jphrMi0fn+vI thXV1PRYVoUKh3nVNQRoeFGzeQ/AxFmxT+vWxjFgm9YIywTKijRf4FQgHqwtVcWJuBJr0VgP6T2r 7f5SLphV+Xr45Q0LTOzhDe8M8NqOI/QwwKpl+qEaI5QbABuWq0aWnD4qxrGwBdtmjp12WvsfZjTq B0YlHoKuy7EzTQMDGS/6DJ5slYMaJ36WI+uu7Vn15x/HufbdZt3thA8P38flHMxdHiJ0IDkL3CaT hmKMlpJR2TTlrJuhQXJWbMUK6K7X5gwHDzR9V/NNYzdbRAtDR9ckDzwjD9xURjsDBcDdoZcNBvCc 2eVHWioqhgGIC9n4ZbX6nmTfgchK7BuSthHwBKiKdfg+caaFZhmq78qZFuLp6qjf5vqIrYiGYjeD lgNoQ7P1yNstWtWDWA0NC117EugzAX2cVT5nJP0RVmlhcqUjZIso5y+IWR7h5/N5nqXJKMuzZokC jKn2TfkEOs+ZgX6kfiS2dEsxJDo37Szkp2fPa6cV7jz54AWSxeXTBHNNXHPnA2siR2ij6bAdwmcH CaOHHMLQ1mMPpJ6MaAkXhgWlY5bD/a0oH0nWWonbyTgrYJm50Qcy+yxvDrQt3Q4dlUXzN9A2Pd+J TBs7CUi0z2k7juikrChmeCO6WbNrqGzxfkaMJ/J+V6DQvd2fDXlxfH6jKuv6CV6/TrTY4/S4gQPe OOGJFu2NPskLlCCyg1BOyzmbpNZYt8LNwX58YS0rcG3NcPY9E04QRWsEJFJn9EwcHTjWV26wMUdd OgqbYMUGZh9n78+Yt3KMvRvA3NWXngN4uy2qeu5++ATboaVYoRpsn2DFctVA9/GqPMHCXS7sIf5E B/BIiicOdTyid6xDk/ozQpOmelpo0tIMXeQUj74OGT/PEZ7UnxGePPRIzrX35vbTzlk+dAsXQ3ob YDx9Mk8LEv2UJ5NJSu5zeZor+ALO5fBnOpcrKJ4+lc9ol3RIODxxKs8hM548lZhWuqjpZvn0Spgc Pacbj+g03+xPSbiYXMtLtljf+TOR7eEdX5O75hh5bGzWfsZmNZE8arKosHfAj3f2DLPkBzAePOgi sL2o4M84q9NFjYnsyHjuaUGrhGcKim0blu/H0osj3LKaVMmMMiUPJUlF/7Gg9aqisuu9Bb8xmbLp A6I1K8PM9ojxkCco9owgMmSCs3C00ylAkja0ygDkFEffYEc1IN2CYlAGG/rWy7qhM5KWs3lZULwz /AwryJzAglwFZ5riuIHpywlmwgFvW+XnCHBLu62/r0/8q2iSZ39gKhqojuWcOfsIFjnAN2o4K5Sr 3kyxtdhwZCMw4Wh3IPOQqG6qgWEosp+JcNDuClJWY/hOU5LygVbAeYH40gQeD7DrPKfFPQrbAxKY HEh1P4y26liebbuRRFs02sn9PZgjrCsWyNSS3FflYg4yNsU2way6rAQGPMuwO+OOtG4T7jnQNmzb 94AjS7RFo936DFeYt5G4EWjYo6Rqg3FFPWgj+b+TDJtzpmVRN9Wi64XII31jRdEVR6ZCiVeuQWUG Um2rulGp7oZ+k0lePrKLoFBj0v8M02cO8fNywgG4bZq6rbKUbwm4WOo+wqd5BHKo65ZvS4F8LhD/ ohFUBs8IKtPxYtdk7lUJ7hnAPXUElRYHpqHIFhpngudCRlAppq6ouoLASdiFyk2PgNHT1hcnDfM5 M/47KavHpDWCmB+q1YvbD41oXhb3LNE8abVqDsQ1xbRMT7YMFo/42gJCl8U0eaCI5Jim2Zgy3yM2 gF/DD8oUph5i9/DkGyUjIH8eR6TmB56mGrJlq3C8Abya5jRFN0cBz2AwLeev6zfreMMG2A2Ig4a1 XXlNr++v3/KwcsMKXH23c6ceGL7lu7IW9pwmUDql40W+asFalXMyL4E/L988WYyps2d8YoT+SFsR 1TIURUze5uiyajEpDvDZEY2bT914TgKpyKd+u8f2L68Yh0mnXogldV2m2LV2TOa0GnDwMtMwdc+y pVoqnJeBjAI9E5STrKyuedQNRzO9IJRpDcKRw2Li1qTA1tFdQkPrWWXWQ6dtrByyGGYjILS+Yd4S vM/Xk9FwLD20ZVbDBWgdLDWBjJZk1uc37ERaalaYjCoIWBhFk03auQG8lqPumrbjqnJKuXCo15Zj 6w5gBL6Kl3cKz67oXVsXHFhbka77eoCYSKzFYt2a/cxG7I1CHkFsKo6pGbvD5a1IjYPIXyMjEXx5 z17RxjW3ss2O99o0Tq3eUuwb9bTqg1hVHe+FW879oKCN/qD8QASCtx+9/yT1Yo6NjTuHTJ6Xj2jH f6NLMgHqW8AWbjioT40CzwlD6XUTTn3qNfrWWS4BGTL3W8mTnm36vmq7royHCQcQGy14pE8K+UJr WAKw/IwDe1vRuNZxWFvqLhay1pJ4xKWhuZoS6jKBRDjeOsP7Mw5hbt3liHFaZZhKst104TCSAI/m +4akXOFIGoDk/wHUcPZpG7tCv8IcFmkJdPjh13bQSzvxdkYbls2Z9Tm8ZFwWPIaponq2Zho7eUNW qPhBsIGkRPzFEcd/oyWzWR4oALqaZVuT11kxoVVFx28w2w8+xOZGbKG7pQWfVjzvPKMGNwDryBZZ pnxIA3482pnQ0LsTdVlbY5PYfriRddutvW1s3O8PNyG8F1d79ytmtFcrzcTOX3BszwXisZM5XY6q bLxJwciep+W4fktYQPpgm0KRYT4eJU8xjCiIpbNavKAwUckbj5kCj3PRWd0saAKY7l+QsjguF9jj P9E7cqA+/wnmGXmm5b1wS8WeWbJg6GU5Qe5LVMa6InbW7KzoZjwNAT6+UIEZObrjKUhSktCEa2Tx omBWFChhw7juhjdt175uKt5d7iEBbk4r/B4H4LZt6mqsSvP5IgDHTNGCfBq+5xGKhheGnqHIqgvh 0FlAhTGWQmH8djAuZ/AsSJ3SAidkYl+CrezfpkoeaIU54H28lwNsXY98x2TzqyTYwum0hbjlumBk YDfwcTZhFkfTx+hh2bpvZEWTdNp9iYeyrdCMFUsGIc6nO2FbYAw4/C0vR0lO7lYQ4gijk2MQtura jiNjEOKJ1TuMaLKDKXn9t7vh8E3fSKQlaTa/uuGqUTeBYB2VOUIk4EIBZ+MZOmm7NX2srVb/Vs7m NM+Tdm7VrJ7nxiT5nSdLX9dj01EMBFNCLBRiBmTejR6jxTQpUjoePMyLwUNTDLIx/2j5wLCiyJJ5 cZcB6ZimVUIL2gIL5u140DFi+NlU5Xw5YAM7EWJm9tKOufNIZEc3bT+QDYKEQ70hiHdkcCd8F1iA gJWRfXbAxoAQVjLJJ5J1K/RMAF0iLhrxnaQOHCc/pnMsoQZjqWsuwsT2RhldO5mXmcsZzzxJW/ED xXJ2hhtItM+P9qhcYMYrI1McCdpkBcshAI79YfilZu2dn0B8b17RQWZuGkocSPNYONhj2tBqBhr2 bhnsXplsD/ueOcaBt+FHseXIDiTi8d6R2Gzudl+j1Ls4S8ISRtoKlXYOT3paDYPu2WFsqrIFp3C8 19XsTBSvxiOCmsZG1q5LRVv0rznQVUJd8Rx9R1RrtmvrUbSGUqL74ugyC+puONx1e3VOa7jIhHQr mbeQ3cqcOW3KQJs5YxzOnIl8xdZeuL7hyPOoGzjBBDgbO+6751hkgkynBQNKVYUUx+2VVCNfC3xW MyT5qFBKa7njq3qToNiBw2yaPF9bt+vuQL0KXSfYQJez0tMI9NAzDERGIi4U8XWlJ9YmIel2NbsI J2O6ndp04ETc8Rq9emiA0JR2kHi087ok87Kus1HOmkGxplCrcm7E+xVGi+fPomrdsRXXDyVVXw5V 9/7nA9rTnuaE5i8mCoDGTBOuEjZdtb04kHJbON6YxkMfcAwQUjdLel315Nhj3DzyOfKjKGQISGTP ojz/NY1yTZ5GuUro+bYbylTKM4F7YqNcxbKiwPRkUs6Z4LmQRrmW5gFh2rKv1dlYLubSYe13vA4H fGgVof3EKx6ZGcM9R3Lai3ht6O9f4kBXdPV3VHiwKxVoQsOuzlu7Vpn34oa8GuLIn76BWVIk+fIP SngKwA0rjAPNlEgLR3rlr+qLTfJkCStMaYKtqooSiworCkoTmLPptCy74N7G177zTHtRVV2xPAm4 eMCn5fwtGS1QTa7Ltpt1H9ntixcAVvxOSsesZheLwa9SEPKcg14U1wr1WA5JFY81vgIZfPXqmgM2 PdY9N4qlxSocNuYVXjsZsVsDvLwvWLdqsiiyfyyOZ9WwChQuERyrjuVIjiyeSneGrb2Oo4B1IR/j XKbifpHV063MyA71NnmSM0fSC/TQ2u08r0Z+EEY6ngGJ9rnQxnjARrbcE10GGRWeWEdvXWod/eEH gooIfvay6ut3grPrgr/dbr0Ywit4VCIzdrUokK4J4eTXYAk9upvetkmqGNLpMxZxkvQhidpmuY3K hrFhHtmqO7qv+TKtTTjc+8N5npzk0ia8ZcVD+W2V8MaBtxZZgakFiKzE+wLcGciXvdWYy2Q+r0os y86wSrBOq2zEgrc8fDvwFdCaZDci4cCyurGMNpNBPa+AaAdV12V0kAAZ00FN71kTu9+RwDmQtUzX M3xXloldBrIjenC29DUPkr6peba3My3PiDzgyQFWfEokz4Gkdo1dYbfwejzeKNHpno+A27/9ms2e GDXF8P7zRld7fl7euur6kx3IYF4bkuap47N+QkPyAq3IIS0wkeiBkq4z9n4z1SP9N3epgz1hW3EU d+uetziPkFab7EafYs5mEJux5shmRsLFLCYxbsyaSlYBP7SA57QCe2hG4ErndUwbMln1pOPqL2dp lqnKJmUXADWgV87QsO2sobekSGYYw92weV8/smaeG+V89bRc5GO0f2sg9TcciJueHxu+KvOshCOO To2NkaYI7lap5g62mNMMShBZSSgOsG3bV3Qllj4t4WCvtQny+uvw0xuGfthF8ZF5p5sfmVflA06r 7rKbOZDWQ1OPPGenWY7hRLarRugKkUifCekZTacJQDpjMb9NCl9gtiWj8KSuF7P5enbDKh0LuftT lo75nCFW9mFLx7dVTd9WTs9m6RyRTbbp+kEk24QIP8T1skinVVlkf9BxV0wzK+uG0MkEMwrZEIqt Yw42W7IkyMtm2R8sRsrBtDTHV51Yl0lHF6B9PpQ5oIpzpCd5+Uh6Ty1J8rxsx8xc84ihKIjiQDYo F4/osPWtky8gWpjWMfzyho0B2DQoELZxdj9rpRBC/Vi3lXJ8rUA007Pt2ERYJNxC4d4AFQRsUy06 L8B29xfmQ2hbKYCmgC/xg4uK8rTY1Mwg1I1I0rZwsKsEMEVNkpW2dgbDfZXMZixG2hUxd0plJ76H X7YOBgfeRmDrxh7eeqyans76w0i8z+UpALMghT+XsGa5ff+XDaLuciNmbELB8V4w5mnDv1rrwRFp PcS753Q/ToL5WX/Bnp6Ik5xjq30UhOXqX1ZIBB5lM9jJvNg6VafN5rqAU7Un7QT2D3oiMnb4abPT +d+Mhk/rUSVp+Hk0DPrALhSHfMahZuueK9U84WK/U9SztEmYCbeTATmmaYaDxLDCi9SLNKV1jZ6Z Xu/jwNoy4thzHRkfEI51b64jeGxobzupd9F12+6qOFHnw/nNi8kkSzP4fL7EMFHVJcFyIA7qu6M4 shOzeMTTZJ5gpRgQbxvuQdi3kEU/HC3G2x70LbnJADtRbronyU1Hs0JNfdln9LPlCDXlAGAhOTzd Il2yutxxSXlMaqC9wIskvxVPfVgknxWTfMEyo1Cy/mNBF8yXAgSZFeMMKHKBjaW6+r1+TFgrXUmC dUY8/NZ1Fc/VZLqFcMSZixvEJwdoduibXrybI6Orhu4F7mqctgTt5UH7OvyEQYtudOqYhRq7HLga JzUW9Ry0H6YcPxk2ZxkQf15Q4gNR0D6KXlrGcCQIs2P0osL/HFv92YR/vUoQhuOHyhrXdLJI8ZxA zje6ECmQ1W+3ezqjg33FY9p6QjhjAHL3O+gHGc5TKPhysczAtlRN2ljC0d4s2ceOHOQeMC2YrLjm ATKIbNdkHfQlkGfhrliQhINeh+j6GowSdH98pCDixm2a0YfO5gpKHDnHQ4yqb1o2GLESQ9HE+GtB MX+sdW/s5B8wcEHFoa0yhylHOVBvMs6zgnWy426aYmLNjRfKrg3C8W7b0dVt0tEVc2ZfvV0VeDNA QfQyDyfrVLidr8Q1akyNHM9zGFwSbMHeTByhcCQLqUtBKRazEaxaTlaUTeDBLdpOlZxNOhxbA6tk p25YAn5+wLuBPP9YJDkq0Zvo9tnsG4lnq9FUYDSBVl1jvw4eZu5ZkafrcoSGcLgZwq3jpZ0YyJyh 23RM0rKC78zLosU6WQ2Y44DaUm3XtTRZiSgc6pZ8O579tZwPysmA6ePk9ddy+GYXZRaVxvyC7ouv uAIhiqMbnmw3eja0/6JJCxbPpAXVDiPPUmX9+JnAPXHSgqm7piu76JwNnguZtKCFduS7cviceAG7 0poep1neBp/9smnK2Yak9VHSVti6YyVk8Ry9Yl3Sch7Hl626Vhx7sg2acLz3vVkMz9aCwtADZpJU 2LGdmVM93umiYv1L9yKbh/E2nNDzQ1dmGgjH+/UClGMkbrCQkjxfV3ffV5R2A9cR1JqkeQlf6wEH 7RqPAwfWiufZbiydnOKxTvLHZFmDNVzl+M0tGj4AMbD1aw58Td9jldESX9H4og2cFUC4dd2nfrVh ita9tRLlLTNf1d61bi8erh1GThyp0hAWjnQXrvgXUpSkZPWVHd4r3+WIEta3FH2crMCyzRhgLUy7 azx6WWTZrqvvyGnLDQzbY3mCEvFz+TSfShmzntF/UVMOp4wFseJY3gtvkyNlzHpG95hDezp0ELuU sXNs9edNGcPWGmjBvWdZx8l4ljUs2ImN/R7Zu6Qs8mXPWXg8qZZthcBQZAhUODtZzMfrOq2swHrs LvMoqVcyY1uX4NEFLV/z/VC2MxcPMJvexAZQsMwF+n3eT9b7Ws4R4M0oSTuIAvt0spltwIvnNOXR CBVH1WLDk3468fpB26mtTDOQi2Ny1Sv7VyzbIWvzVjaC3K9pxvTGrJsvz2wCDsRNz1Bcz5LWnnDE wXxPJqjzo/uVhznbvhW7vsxHOZ8yhRmiOL645bVR0YAGGzNRy8NbdTc2XUWGvoRTmreZDbYa1YUW GWtkk8B9YP9ypg33KYJd/glfazJV16wwlHm/4qFO5vM8a1sI4sDpMVOKNmrbWb+5Vo/aiZTwcGDT VFxTs3c4sOUHSuRqa/wkzi+OM3Dh3RYV9WI0oMiit4DccrM8oyXVMTeLFxhRpL20APoJmgc9Yioe 9g5PxuW8IXn2Dfu/DXqltBgDPBykZaleEOqRZKHCSUvXBqOsaa0KZljW2C4e44tdWziSEE1hn2nt TmSzoMMSuNIGHDng1iPDV63dZFtL80M1chiZSrjPA3czXdRIsFj93OVZAxPNMJrYjwSwDESb5RLU 2R9PuLGf0R5PUyV/fRIh0EznVVYzzy0fH1X1KN6pBzWjyI8dQ6ooIvkoY5TMzwNaC4vkgZYKammx 0798i6RO63fofFW1G/NIMwFLNRT7hdvrHI8MicDmtldAOjA46EdRY0/zFFkFIl4wYUpLk8zm1xyw 2aYW6LomUxuEw+blmGWcYAgyX6I6uK9cLNeqhWuh2shUi5wW982UA2vd9zU9iCTWwrHe1E2OyLsu TNFFJHt+jKM+OrWSB/A4tPRQZhdfEE/mcpepruLosYwmn0/f0a6Na0I+Dd8Tn7WzGAJyWUpJ3E1q JMEUngKfU9sKbE81PMTpfx56x+YSW2Z3A5dElZg32g10WyH+nmUYktdwFt70TnA6G9HxuI1vwJXo e4OVQjzuGk2zbd1VpXdOONY9rhHA2pSkXsyxKR0Trp+xXe9dyMRuUizJjDYJ63zCMkg2Mks5ADe1 0ApDW7aVEq9jdekfTJn6jnPQ7imqzs0j/f/sXV1vozgU/StonjpSmwUDBuZhJGPMqi+jUUfztNoH kjgJozREQNLpv19f85GEIbNONIVU8mPVpCk5vh+2zz2Hg5JJJ8HH1YUIzwvj7lscF0rMAsuLw9AM 9KZ3dLRJNYdXCcVW9H6o5t9iCleYBgxngsbNnC+kPYtI5P88xdR3A/zvKdCnJexgHf5LAYNn7jkZ OoFkDOvw6h/9bVGKQtuLiF61A7aXLrSXdavxtfaBUmsn3YAF2A01d3j0HPMIRzLyZKYhCG+AE1GU HKpGa/VUrvJst1zB6zIoKCLdrNOiFFt5BbRxwGLqubphHB3tY22se1FA1muglxaVAlrxQcQzA3Wd bNPQxqVe0kXmbYhREwV2xw9agz082DmXP8LnJcai6QmrcbIaelCgbbWSJAlKvkZZFc2iMfGp9OTT YI8Kdk1RnEDX2GItmkNJbFu/tk2iNP7mVZJ/WYlEbqQgS6xSsxFDAcNMYz021vwnn+1gMAC2geDX k0Nbbyzy7BlULrcC7udsDwfxNSOuFX6opS6hdKsgTphDid73j484aNpt4KZMgMt/wu4vf2giespX yT7NlEa6LGz7UUx1JzY6oj37JoB3KnVaei20m6wO53YqUDPGMMUAqoZ6VKhFR53yPXioHeYIjGz6 g88qNwc4kF1mAvYpf80go0NVrvddtSubSmzbIbU8rC3RBwP8DykbeirKhqbHsGnqSb2hwL1Q2dCK SBB4npbAGgieG1E2NBlyzMjXZx2j19jHsjEunfMizaW/5WHCKzG2WQrL4gTTE4GSK4ygEbpIoMR1 rHAgT6vPcj9/U1okZ5ATGLWnFbCbTUs1N0vk2xHq9LYojhlGPmxudNwNFHfnA0qmvwsDyr4ooBzH IzYeJqCaRSoJ7bcl8pPky12lBPaSlquKzSN5l83VTWNWWAuNTeTApEKUuSRk1A87Gwonsjw/duEY UEfZYAd+CRz83DcCH52oO5oQucJusi/qhgqvdzPUKmLqaFo8/v6FfvpEnv5uY66SSQaes6r2CnaQ 59C4s2WwTBzFmGqr1wGjq9VeARDPh5b8Ri8MLWfM0ArPhNahSHvXSA32PNONFOnpzRXn/jUnJdfh gv3sYvOu0UscdbGd1qTexXaN4MLtLrbb22J9ljNVHR4w6DmKFA+3CWLBtYVLoUC5iIpaYmlG3egF CkwKn/bYSIDrWczydHrE9gz8LtuzH05EGSEWIqdwupjYhMgeX8P5h8MRTTDQMQ4iROfT/TVaCWfS PXYc2/be+tn+X/JXHoa/bbof4lHfm+QvkTrh9e2yvDsmX798VMgPjmm7xHY02WP0dH+UMR4q2fcu nGDukb0UxwJn1SsVcMYOxdjXRPlbKOsHpea7dMIn94YA10jKUlT4Xck/ilfM1jupZwa/SOegErKo ATfuHiOVuEaEEObSjiee4wTYDl2Ido33QHgnm/lfWS6hBHCeufTmueOTDr3jpDOQ3/yFVdTt7wyC wCP4zQvQOzjQq2k4xpbnMgJhzujYUkMOUypNRnqBTWPL1ff+owcX38ySbbEDQzNJa28w5vMl3AnD XGSjAdoqaFcXJCoXjjYybURMTb8ZHefaxluqjGxkLp1nz+L7ADzlZJK8Uk5m6TotxVow4J0wE7vN s31aiLop3vlLiupDnOE4MMPOdlkjPjzidZY2gO38sMyTjQjyPC1fYSksYGxFzqpVC2Lexr34C+Kj Zr9P4v8BAAD//+ydbXPbOJLHvwrKL/ZmqiQZ4DO9N6nh48SJnfgs78ztbM0LmIQkjClCB5JWPJ/+ AJB2bMfJQbeJxFTBVSlLFC2F+vHf6G40Ghyflj8duSGCMIf+Edgi56QlH1p51B9+xNET3tDy8qcj CP0ABWH4cOiCq4PQzkL34WBKFrirWvlKFqEkeDj94tHJr/5ze7K54OrXvL2riDjnFlc/HV1UmNZX 4v9wdCxf5P05PGd124hzcFNQ+tNRwjpOCQfvyFa++yqqm0+PFs3TQ+INj4d3PH74dP7itXzDj96e tODDujppNrggPx1tOGkIvyVHrwAAuPyza9o1qdsZAFcMNN1mw3gLoot3gNbg/OJsDmrSbhm/aSZg TYoVrmmzbgDmRLxASlLKz2n7T+svU33FiuwG8553gFIvRJnhfWjeLQMrVpWgXRHFGLctp9ddS2Ya GP3Y9fwYpQbjnjC+soUqEzYlH2jTkroggC3APxpS4IY0GsDsPE5zlCYG2KF1d7VlgHGwZlwxlPLD C/FEWl7KalKCriFAcQXn0T9BMUCXRlie3OA10VGokzuua8UG+KGBi0M3RA6qc7YmgHzA600l2Ar2 TVesJO0ethxHS9IUwgqLm+CaVGyrY4rdxHcchKABvT9TjATN0/fROdjSdiVOUV4RmFe0oPVSR5xW DvMQ5YbZocWpKK7xHdhwdktLAm7IHVh0dSFtcdPzHbxe0PR8ledEqg0gddNxHVtsodBCtm0b3Ad3 ele4BcLCtrTA1ROwBMzP3vdG+JpIymvSgus7NeQO5+kIO859xw0DQ/rgo26vZ641hAa2m+SR5POI mpX5WRSG0oMy1PZljuveKcLKAZ705pkKWV6LL+gJye0Jlfb5hEp9efIjcdeumLiGXzhZMn4Hzilv bu7kKyVuxQdZ0LKm0Joi/wr6J5Z7AuHv/XU+BhyGfuQd5vrFuPL8ZhXXeChGrwpWVaRo1Yi4IVzE KGssA881wXLck/GKzthne4kV2MY9HUEcwkXo2BKuYo+nY1/L8WJBC7AQQcczmZWkupeZwrWjzPxP ZfYS2JRU8iCCnp943/YbEhckb4FXKm1y/+TjPSyOjAwdbgBtJaJbwU4EisIl0RAe9J0shLb8ho3w Dut0clw3Kpc+iE7HJ/HiPIcocQy+Q+O7WgkHRIaInPxPR7nwSmgNcFlSGSLKYLDAnN/JkAGDZkMK Kg3pE/OqgduGuR25yKTrDo67IdLrYRz8QGbL2QT8cjqf/zhRceDjObBh4OyTe/39sRIGWtwPOrY5 QyiOIzN9cnDauGoGAfexhvBwaVVh8VR4M1jHULuhG4ZZYEL+g7N8x1rSZ3ikWF/A+Vil4FpEMqwU xpqUE3Ge1uR1ZtlxFFoG9aFRdxsZbJRADMANW5NjXFXgbH7ZPHjJ5bPc3WCulQUfbLaOuIWVDl07 lWQeEYd+5vi2I823If7VJ1esJ5MrV/TZdOeTxI+0ujtGpM5nEj9OZMMAfevLmz6/6YYMz6MoW90U //41fSHK3selDoH1ZxQsTxxV6P1qTsQftVSMDcN0nt5MnpWnlh96Zkg4+JCgTAbbEI5VXCaHeuXc XatZdcpVCpkNhWz3bns/H6Tcv1YYmk/U+VKkFgS+n7mmgu3gxJsHyXJSKXdA+ewAzOmaCqevupNh 29PgXfkE6l36GioN4A6CfuSlkQF+aOBr8b3Rjfgynrn1P2xXRHDl4LSeNq2QtiywumBNOzx7OF2D tpuGQerFJu92cNoS7Y9DpNYr9kkN3GNDPtORceyjKFbTuQbsflwqjEVoTVoxDguj/Pgn+7ARtrgB CIE3XXUHpDf79Az5868LvCQg+EMDrmelyAoUHgN3D3Cv5We2dxupWQHp/sXP4YEpzOIkliAMnj3g qXDTXpK6JJyUUkQxJ/hGXW376rRuCa9JO005XrTPNXd+GqUPdeWfKPINrjs56kq9aqgShl7kIwsZ 7PsyuY7MnUTvIpAw8dflEAzpLBBw7cCKs8TUaRzc71HzjSUrOllhA1a4ATXroeK+KlXH23HDNInj 2Ehvb9JzZeBJCvF6e7e7/KCDQjf1DK+RyY/WLWdlVxClwppsQXPPuHjCWEuUiQURssy0795E6QlR RsVNzbYVKZe6NYuua+dp7BpOIxAjAf1USAOWQmlk0VUiXsQfkap8AK03XXu/mm5N1tekL3LUrJRL k9xLUxM8Hhy3Sum835AapKShyxpcEbzWsaxeGAvN2mYaZm+W1Vfrket+zbiQpxYkx3NRYGZORmFW F6yq2FaWLdK6pLe07HDVSKdmaANQytSrmj65d4ZONBg7YWxHEJl15gdnLH7eUo5rcI5vVvRPXFOd oTBGFsoSE4aMAV/etR0nW0LFMFisalaxJdVq9uAi2/L95+vZDMWDUMzWmFYn4EZqcf3z4p7prGBr DZQosFwUh3KBm0F5aJSvMbvrwJxpVQZ5VpjnsVnA8X2bUisLoiBMjf5GZEpXUoazRshwd3Nqp17k uqZYfww4zxgGkZykbARLHS0mIcpC00ZjFPBizuq/CEg5XrJazXfI4iy97jdOlFi+Y5I1I7KpFcM/ b+is7jT4wdiLUYDk92z47YPfq2AGwCVZEC6rVrXcFi8I7MgyKe09IpJNwd7JJhmqJHknXK5txZ4X G7fk4BbxX5d5YiEU/iFHOFzWhE/AfDYBR2/JHdgyXjZgwbhq0UhrIE5uZJr0tC5pgVudySbHRjC0 PWM8xzD43f9c9osD1Iz/GbklVXM0AXFyAZAzkZCBvCUmGnS9NLdzKzT50zHRTd+fAgRnyHcC/3jQ 9wScY16sAApDXwesY0WpCD2MzzomsH+r2r+v2nbTnBwfb7fbGV8UU1LSlvEZ48tjWi/YsTgmef9t 2f59psEZ+bkTJ9BwHsVIHAjNipH4jNBrLAyyHIej9TVddrL+SjbA3mwIl6XK4LYBZ2w7POlHZg3a lpWmHrRNdm9MqpZyBdLd+k26W88GYnlHTD6x6OqoDm+UiOAVGudrTLzPsVxQgPyJrj2XtHXtuR8i x/YC45Dti7gIhFUDh1r1i9w9FEa+H+dZYgbgww/Ap9N0dk2a9hrzaUtwM62bab/eUmdJHoyyEEGz oGRUtrZfknklHKmYEI7XE/DrDFyIp7+RunewElIUmJOqomKYFc9f40r4WLXW6BrZjhtCs1B+TMTf CIYXpF72aaxkJTlfikdntJuA/5aHxH+Li3uhEcdm4FwcuWQ3HdUBbrtOECS+yTKPCbiEi+tSwnyD K1qJmOmSiAd/yVLPx1tVkEYGSqcXx7LqWod27CDLMXPn+3Olvs4C+lBntHZSlCAnMNVKe4K74wJ6 J3TiLM+M9vaEZywL6JGd+0kuARvsYxlghzFUZqZ+k2OpGEQvOFuKs4UL9fTmmIBS/tJpK+bHURjl vtkSakyoX45+p9CbADHepqRQSw2lmpGWv+zHWRjnJhk1JsbPk46UtAuVbpTzg/SWHNPyuFfx87tB g7jl+ch2zLaboyL+oOJZ+6HVTSR7ELph5Jji04OTVHnJkhQck5pM15uqmTYVLaekLlhJ5O+Ws83d tMLXpJrSUif8cVEep1FuJobGpNN0YNwnJnNaNQvxbwISmZZUzjktbj4IL0w8f0hsasB2PJh4idlr Y1Swn+Wjn2Ww/tHI7FXWKxucSWXLOjwdu+2GieXmmYE9vhCqT0OC01Jufb2QFZSyczMdejQPnfub 2cdAS4O3bXmR5/tmEmJMvP+v+PiF0VwHtY9gYKdG2mNC/TkvbAqtCfBA1C27ptWOmGEe5nFumvaO CrF+xPz/07WfBZ6bhCYV9p3oepcwGtrCHUtMGH14tiqMXgo/e0V7eVKG1zqxMgrdKI48Y5PHJM9f FMi+tCOStTu/yxofzoqbmnDhd+WPa3yeBNYaxJ0gylw/NKVcYyIuI2QRLL9lf+EbESGrkCmVu2GI L6gmIlYu8Kbpqj6mkmvW5OYYtNVZ4OvZngUzZGabx8Rbbm8k+e4w7ThYdx2F24kdeY4JpcZE/GFU nkI0ASGYk02724SjwJqnjiMBGqzfX/j03DvTUTLyYR5ksQmexoQcol1iJCfK7DzLTC3ewRG+GCNN G64TJll+7LkoN07zmIT4Ypj0dGbxM0GTjukNfMvyHUN8TMS/ZZiUuUEQB8a7GhPvbxomuW6WRomZ jhgV8ccDsyrNRAHIyTW/L7TWipRQBO0osUyh3pjIfuNIKcxhZptW9aNCriS8U7AUOq4fp6am+uAU VbAkJTqlm826l6Hcw1drsXgYxVlgmfzjmLT4LBKKV8LIYk77lcTSr76agXP6F8cyojpSTnVOSVVq Nai0ci+LY1OmNSbgj8If6Ud/5QVObpzB3DaGekzEXzDXU9mJB9m7r25CvhvGrpH0d+pCP7sVNIB7 fpi6sdkbYVTABwnv4kKjKA2Ro0gYjiNxoZsNp/VyKl4U71KQKd5iTqYNWcoetY1WmZaT+16UmU1M x6TOlMlOPLInT8zvcN32vvQ5vcMNvsF9Z6bfV90E/FM8+C9a9573mVY3Ht9K0tTJTHJyTMDl/JIM lfIZSCq5RO3odNhRWi5ouhzkDSIp71o42LKb+PxSg7abepmdmcUPo6I9H+zzDpGTsvY6zlboZYll em2NiveXR+kptEUkZT10aNKKotzQ8rLUNVHUmDjvGEUNt4UGbcf1Eh86koqhPRban5fzTg0jEpR4 sdmC5/BoP0ZVqnOLejQsLpZr0gqiF0+Fju/5rpHqmKSaY85JNQGRcLN/4fhuAjK5voXjG9KHWX0v U1Xv9Zqt11gFXDrqtV0ntD1TyzUm2g87mU/A2xc718pI680MXInIuuk41urJlUVe4plmIHsD/e92 Nf2XamqKoJbNzmGUhomBuye4O3Y19TPXgplrchh7wjOSrqZWkme2bZslKmMaW49yjtdEdeVRZQDZ VQ6edgt/KamlQzuHMM4CU2Y3JtpfyEV+LkaaQncCLFeDuBOFUZybSGlUxN8XLXuo5tg1oaUj8zSK I9d0KB8V9C9oeZdUlpXCwIeuWZB4cLYqlXXD1htSVbgvd183m8pZaFXZ2n4S5jkyBTtj0ujbgWaf 03jWBvPjfk0ytXE6A+eEVvRGayIpduIkswzsUXnZ5+I7pNNNxzesIWC+IQXFFbgYnj80NgU541vM S1ovNVBDz4Z+nJqAakyoo0IuKf3Ku0TAFCZpbGaHR0X6xfFY9WzZdfLfQY4vbLZxoseEVz9Wenoj aPD2oziJrcTIeUy8Pwp4lxjJdiw7TQKTyz44ShUjVcNiYFKvcF2Qcnq7qae3ba27H0SWIghNpDQq YZ6pfi1gmOTtS6mPEsz5nayl/ZXythO+9BXHdbNhvAVD+loDN7Ly1PYdM084Jtz32wKIN7jfEuBC 7dzzZZdaB7dvZ1memSmJMeF+Egp9wXz3jrUDog2nlQZszwm8zIrMhvJjgr3rLMT9/aDB23Jj5EFo eI+J98s63mkOAsZJFoYG6+H968s8saGN/gDgkjWyPZ6sufyVNltc41Zw7ssxpZt2OQMJripWy85r MvO54axlBdOx2zByQyfxjAs+KhdcJajnW9oKAy2c7kga6pYUbceJcMvEnQHkraHVLiBLnSiDJvcx Kifs/SlAcIZ8J/CPB51PHtV3QS20HrRcz82NdMeE9rmzxRfFlJS0ZVy5XLResGNxTBLXbhzgJq6X mfbi4xiTAzf0/pBF8hVt+iH48Rrz17jaiAC5XxUhx+bfZo830dSg7VqW40HfbN0zJlX3DW0/5rw+ 7WfbrgiYiz+VOy3mXa1mJXVoB6ELYWTaNY2JdrIS34P0u36Y58mP4KE+d8D7mmChZ/DDu/nrHwdv TBoFrSHbF9pOoSkhGLM3pmCCN11NhCuGQq0NFF0vT0OzAf336IpJ3NrpkRy6geub6cdxuGJhIF2x pxsLZKVcs4jXmNOqYhNV36eOnZGyvOsds1/ZHeFaukZpjszuEiOz17KXE26brlnRYakxkK727zM1 d3k0tIcBl6xr5SjObsVHnV7cejoDtBvnSRyYmHpMwH+YX956H/0wNRuJ12vB9t79EoZAS85hlsex Z2KrUbtfEubuWws4Se4IaCaS+h5dMIFc1wVzwyjLQ7OaeW+cX0Vdu2K8+Q8QlaWsAiFanceDCPmh 6ctzeDleYU5u1BIXHXW5MXIS08rh8NjedDXdqD9RXo+O5mCaxplrtlo5PLxsjWl1AtpGqO7nP3uS s5q0On6MnyPLNjWxh4f4lnJcf+yGpCPAII3TKDDxxcHZ5Z2sldgSCq5IsapZxZZUy2/xXTcKTIZ+ j+7l12lUhbQ2i00zy80CEyPuCe6Ojao86EI7DY329oRnJI2qIHKD3MuMxzMWt/VGOj7rnxf3Y+is YGsNjk4KnSDOjHU9OMfXmN11YM602ho4lu9DJzIVot+v0+pFeZTkvrGgY7GgKynAWSMEuLMVta3c TZPIbCi0L5ZfKQCxtDrlpiiP/FDH1j6l9f3Dvf9ChNPYXjxw1rzSufij55e0nP8lXt3KZcWWIys0 TlayVjoQj9X1bJbnWH5OyzZym67+FE6Xq1aeplaunVyztmXrjy9XZNG/Kp2Yk5Uq9BN8LPXigrH2 0dNl16qnw8cVrJLf2mAU5DnqcMmKXzgt5XvTmlzIFR1C45569fj+21APr1l5px6IP+lkAcOr/wUA AP//AwBQSwMEFAAGAAgAAAAhAMA622BSAQAAuQUAABwACAF3b3JkL19yZWxzL2RvY3VtZW50Lnht bC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJTBUsIwEIbvzvgOndxt WlQEh8JFneGq+AAh2ZaObZLJrgpvbwTRIJCRscfdbf7/6+4mo8mybZI3cFgbXbA8zVgCWhpV66pg z7OHiwFLkIRWojEaCrYCZJPx+dnoERpB/hAuaouJV9FYsAWRveUc5QJagamxoH2lNK4V5ENXcSvk i6iA97Ksz12owcY7mslUFcxNlfefrSz8RduUZS3hzsjXFjQdsOCl0TQT8wa8qHAVUMG+U6lXY/ww xGWXEO8wfwIi32H8wQiSMZCbIyBtLZ1BU1IqTfvF4L3zAc8Gv+z9B59keL8k0FjvNGO/FoPpddkV 3GvJNhNDyDtFoFUDIcA6jtn3TxxHn2fDI+OYqsA5SMbsr0+0z2OroEAdWQRfic4g63II5M8GG7kO N8k8BnHVJcP27/f7EUMY/nMaFowNL+Mm3jrynQd3/AEAAP//AwBQSwMEFAAGAAgAAAAhAN/qGs+0 CAAAtyEAABEAAAB3b3JkL2NvbW1lbnRzLnhtbMxZ227jOBJ9X2D/gfDTLhDbkmxdbHTS8DUdYDLd 6GTQwL7REm0RkUQtKcXx2/7G/t5+yVaRsi3Hnh7J/RKgYbtF8ajEc+pUkfn0+S1NyCuTiovstmP3 rA5hWSginm1uO388L7tBh6iCZhFNRMZuOzumOp/v/v63T9txKNKUZYUiAJGp8TYPbztxUeTjfl+F MUup6qU8lEKJddGDm/tiveYh62+FjPqOZVv6Vy5FyJSC581o9kpVp4IL35qhRZJuYTICDvthTGXB 3o4YdmsQtz/qB+dAzhVA8IaOfQ41aA3l9TGqM6DhVUAQ1RmSex3ShZfzrkNyzpH865AG50jBdUhn ckrPBS5ylsHgWsiUFvBfuemnVL6UeReAc1rwFU94sQNMy9vDUJ69XBERzDogpIOoNYLfT0XEkkG0 RxG3nVJm42p+9zAfQx+b+dXXfoZs8v5mylyEJbqDfvO+ZAmshchUzPNDhqfXosFgvAd5/dlLvKbJ /r5tbjdMlz+zp7lZyiNgk/Cr9U8TE/nPEW2rASMIcZjRJITTZ+4jSUGFxwdftTS1xbUbGsgewDkD 8ELW0PD3GEGF0Q+PGYo4vGFq7HEMK4jDjwtrN/Sx98HUAFRURHErFGe/rn2cSwsaU3UQOiKydkG5 B7hdWlujfPNriXAvRZkf0fivoT0cbW2LDUYLrCqh6kmufi2Yp5jm4HZpOH7YZELSVQIRQXoQUDjR DOAnCAW/9E/2pq8j1wQ9pnN37IzIdoxihJZqO6ZlEQvwz3vJNkLuyCOX6mWHI0A0PATYd7qW07X9 Z9sZW6OxZf0LR3nGC04TeK/7R42dw/OG45xK+gDYduAHI89ZdPRVqFUFXh0EQ8BzpwgAnV30HYKw rMANXO9wac7WtEyK2ohG/yb111OxS+Bdx680ue3MzOs8A3qnf/epf7jNfFS/L035ztZMQj/JqnnV vTTLRKELAtxQjRzwiruJIkXMyFfwMjJ/JpAFZMXgtynHkkVktSOKQddKE/LjXt0QFYsyiXAWl4SG L5nYJizaMM2CWGs4qEHslUIseCHhqgAcnumhqCovJKSKKQLLLeCJMGOdsBDu+4wRFvs48f31Z0Xz OeN6ldsxbg8aMu64I9sPFsNTxr2lNZ0PB/MTxkczz526lxivRj4K45i+Y5XTEJYll0wx+co6d9+X M+KORi6JmAolXwEzidjwEEiXTN+WGUgk9PenL8gmzcjjt9+eyAlh8FFfFnviWBOTqH/y5ISuWILb nvClpwUCDgFWkKKGKOqmEASjC1yIrohpQVK6Q8XQKAIQZRRaoqOQx4fJnHB1eAktugbh7S99k+9j voOmAnqCJO2meaK6ah12odOMu5APHNxNL0lLwdpOK8V6z441HroNFTscDdyhN1+eKnY48JeTeTA7 UWywtH1f++V7xVYjH8ujgFb495CZdgtuBWlqcm60alAijm2PyErwhMkctQO+xVJFyixjWHOo3PV+ JobF1PKd+c+0Sr6GYSn1C6i91WUmnldGyjxnEl2NYIwX/C5D2YKxZhsjaxxOxJZJ7YWnsTXQ0eAK 5wsa6sifLxbzyRwfUdeRC0ryZpNT55v4i9HxUt35zMiH0dF3FkIHgkbx8HXySLDrA5aACEoKyTcb IAIYf2EFKk3kRmQ98lRVv5TBUkcKaiSQrYtkxNY8Y9ENYb1N78agzrmEOkYWb7mQBXhkRL7sVhK6 mOet6EIhzG9IKBKsdXqwkDRT+tYCaiY8AjjkR5GDhJESGNuRtRSpkRQGbiJVrVVzRb0EA2roPoOF Yw2WaHA11fi+vZxNF8GJaiaLwcCxL6mmGvkwqnmOYdL//vNfBalOwoRRSSLoaHgWaoJWrNiiFmA3 KPe+pIk90Il09cC5yJqG6FYnA9j4MKnQDmh2Sj3oiIGvRIZ4vDMVaGo7UFHaI89xCd0YB7FmYVJG 6Ei1EOpAZn5m9JmJqL3V+FeIxmkoGtceLr3Z6F3Jsn3HmzjusT6hNBzLHXnHKlYTTTXygURj6pXC /N6wumJ6hoeqHEAXAwwDSVoABEdMZu9N5el58vjtBodZFuuWukYtEA2xlrrNBhNjqgDDUHi+DE8h qgRPg0sRKK5A29NVFFs5fJ/WItAJ3FIEXuO9lWPP57P39cYZDkcj3X/X+hbLn4wu7q2qkQ8jggdd SKATLXQjrZvXeuXRZq47X1SCqQRU4orrmoSZaiZFgqH7ALnQY2CtEPJ4DaYAPs+x4eFVkle77LYU O1cUh8GwIcWe5zr2aPqOYi+YTgaDWg+ORLru0Ddt8nuKq5EPlOdAz1ZviFe67yMLZ2HaOfIDx0AA kv275LiTxuEvqy+fySRJDN3g3sgybIMlboGr+4D9PdHIZtsd8bBdYxggi8OmhyDWdOkEwWL0zq0h d+eBdaznyNVsOBhc3mBUIx8nUTFnsOfLtJOyNwq7PdPix6Z5SxlVpTRnHFUfiA4Lhpq9mBIutcGK CxMU7FiLMAY86B0SDl2mnoBR6kQP9e7h0hPaEt/OoTXxrt80fRfuZGDr3r9++mU702UwPC3TCx+s GBVyRnw18pEc2uwRaQ6WmUuOJkrViymWjMxZ8TtsB37c65yMMUs58PnK2VbXbKynJWz4rtm/efq0 qA1beGzVtJ7OJ5Y7c96xZQfTKZTU0zT17KHlX+zEq5GPwtblPfkDoWlVG2VVLpE5k0KnJ0HVMZK3 d1qlW+6qrdLMVHt6faxFZRjzAvZpgNsjX021FvAhYQeYRebY4Wk56+LdNxef5OJNEFB1lAZ7OJaW eDKh9BmaObQSGVzXT6wdhRG9SQDvuKmOuzLYahbHLaAoC1CTdqv68e1WyJcemTQ8ATPHXTWW2x93 HTLp5rR7JWmpsLYVWBZzqo/pTIf7tCT/0IvCzcnzisF+mkNlhEBhUf4JdZOjrepB9qb75s05I+R+ 8hv20NUjSnxAvaPCSfg32Mu8/FWuHn+ru/8DAAD//wMAUEsDBBQABgAIAAAAIQC29GeY0gYAAMkg AAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlLixtHEL4H8h+Guct6zehhrDXSSPJr1zbetYOP vVJrpq2eadHd2rUwhmCfcgkEnJBDDLnlEEIMMcTkkh9jsEmcH5HqHkkzLfXEj12DCbuCVT++qv66 qrq6NHPh4v2YOkeYC8KSjls9V3EdnIzYmCRhx719MCy1XEdIlIwRZQnuuAss3Is7n392AZ2XEY6x A/KJOI86biTl7Hy5LEYwjMQ5NsMJzE0Yj5GELg/LY46OQW9My7VKpVGOEUlcJ0ExqL0xmZARdg6U SndnpXxA4V8ihRoYUb6vVGNDQmPH06r6EgsRUO4cIdpxYZ0xOz7A96XrUCQkTHTciv5zyzsXymsh Kgtkc3JD/beUWwqMpzUtx8PDtaDn+V6ju9avAVRu4wbNQWPQWOvTADQawU5TLqbOZi3wltgcKG1a dPeb/XrVwOf017fwXV99DLwGpU1vCz8cBpkNc6C06W/h/V671zf1a1DabGzhm5Vu32saeA2KKEmm W+iK36gHq92uIRNGL1vhbd8bNmtLeIYq56IrlU9kUazF6B7jQwBo5yJJEkcuZniCRoALECWHnDi7 JIwg8GYoYQKGK7XKsFKH/+rj6Zb2KDqPUU46HRqJrSHFxxEjTmay414FrW4O8urFi5ePnr989PvL x49fPvp1ufa23GWUhHm5Nz9988/TL52/f/vxzZNv7XiRx7/+5avXf/z5X+qlQeu7Z6+fP3v1/dd/ /fzEAu9ydJiHH5AYC+c6PnZusRg2aFkAH/L3kziIEMlLdJNQoAQpGQt6ICMDfX2BKLLgeti04x0O 6cIGvDS/ZxDej/hcEgvwWhQbwD3GaI9x656uqbXyVpgnoX1xPs/jbiF0ZFs72PDyYD6DuCc2lUGE DZo3KbgchTjB0lFzbIqxRewuIYZd98iIM8Em0rlLnB4iVpMckEMjmjKhyyQGvyxsBMHfhm327jg9 Rm3q+/jIRMLZQNSmElPDjJfQXKLYyhjFNI/cRTKykdxf8JFhcCHB0yGmzBmMsRA2mRt8YdC9BmnG 7vY9uohNJJdkakPuIsbyyD6bBhGKZ1bOJIny2CtiCiGKnJtMWkkw84SoPvgBJYXuvkOw4e63n+3b kIbsAaJm5tx2JDAzz+OCThC2Ke/y2EixXU6s0dGbh0Zo72JM0TEaY+zcvmLDs5lh84z01QiyymVs s81VZMaq6idYQK2kihuLY4kwQnYfh6yAz95iI/EsUBIjXqT5+tQMmQFcdbE1XuloaqRSwtWhtZO4 IWJjf4Vab0bICCvVF/Z4XXDDf+9yxkDm3gfI4PeWgcT+zrY5QNRYIAuYAwRVhi3dgojh/kxEHSct NrfKTcxDm7mhvFH0xCR5awW0Ufv4H6/2gQrj1Q9PLdjTqXfswJNUOkXJZLO+KcJtVjUB42Py6Rc1 fTRPbmK4RyzQs5rmrKb539c0Ref5rJI5q2TOKhm7yEeoZLLiRT8CWj3o0Vriwqc+E0LpvlxQvCt0 2SPg7I+HMKg7Wmj9kGkWQXO5nIELOdJthzP5BZHRfoRmsExVrxCKpepQODMmoHDSw1bdaoLO4z02 Tker1dVzTRBAMhuHwms1DmWaTEcbzewB3lq97oX6QeuKgJJ9HxK5xUwSdQuJ5mrwLST0zk6FRdvC oqXUF7LQX0uvwOXkIPVI3PdSRhBuENJj5adUfuXdU/d0kTHNbdcs22srrqfjaYNELtxMErkwjODy 2Bw+ZV+3M5ca9JQptmk0Wx/D1yqJbOQGmpg95xjOXN0HNSM067gT+MkEzXgG+oTKVIiGSccdyaWh PySzzLiQfSSiFKan0v3HRGLuUBJDrOfdQJOMW7XWVHv8RMm1K5+e5fRX3sl4MsEjWTCSdWEuVWKd PSFYddgcSO9H42PnkM75LQSG8ptVZcAxEXJtzTHhueDOrLiRrpZH0Xjfkh1RRGcRWt4o+WSewnV7 TSe3D810c1dmf7mZw1A56cS37tuF1EQuaRZcIOrWtOePj3fJ51hled9glabuzVzXXuW6olvi5BdC jlq2mEFNMbZQy0ZNaqdYEOSWW4dm0R1x2rfBZtSqC2JVV+re1ottdngPIr8P1eqcSqGpwq8WjoLV K8k0E+jRVXa5L505Jx33QcXvekHND0qVlj8oeXWvUmr53Xqp6/v16sCvVvq92kMwioziqp+uPYQf +3SxfG+vx7fe3cerUvvciMVlpuvgshbW7+6rteJ39w4Byzxo1IbtervXKLXr3WHJ6/dapXbQ6JX6 jaDZH/YDv9UePnSdIw32uvXAawxapUY1CEpeo6Lot9qlplerdb1mtzXwug+Xtoadr75X5tW8dv4F AAD//wMAUEsDBBQABgAIAAAAIQDzENG8AwUAAKYPAAARAAAAd29yZC9zZXR0aW5ncy54bWy0V99v 2zYQfh+w/8Hw8xzrJyUbTQpZltcWzTrUKfZMS7RNRBIFkrLjDvvfd6REy0mZImnRl4S67+674/F4 PL95+1CVowPhgrL6euxeOeMRqXNW0Hp3Pf5yt5rE45GQuC5wyWpyPT4RMX578/tvb45zQaQENTEC ilrMq/x6vJeymU+nIt+TCosr1pAawC3jFZbwyXfTCvP7tpnkrGqwpBtaUnmaeo6Dxj0Nux63vJ73 FJOK5pwJtpXKZM62W5qT/p+x4C/x25ksWd5WpJba45STEmJgtdjTRhi26kfZANwbksP3NnGoSqN3 dJ0XbPfIeHG2eEl4yqDhLCdCwAFVpQmQ1oPj4Buis+8r8N1vUVOBuevo1WXk4esIvG8IUE4eXscR 9xxTsLzkocXreNCZhw6JddGPBXNBIApZ7F/F4pm8TpUtlniPxbmKFCN5XVDhme5UDTkS5UuqpoM+ 0g3HvLuTfclU+fz9rmYcb0oIB0pnBKc/0tGpv5BE9U8vyYOWqzyMb6BHfGWsGh3nDeE5XBRoMI4z nipAcpzffyYHqhqP0KKCbHFbyju8WUvWgNUBQ9yR11vkeww2kvB1g3Mo65TVkrPS6BXsLyZTaCsc qr630E1mWK27hgUWNa5gJ4+a0C0roKMc5y2nL0+5MtDe3fDS5VNHDBospwW5Uxlcy1NJVhD8mn4l SV18aIWkwKhb0U9E8L0ASK08f4Izvzs1ZEWwbCFNv8iZPolVSZtbyjnj7+sCjv6XOaPbLeHggGJJ bqF8KGdHned3BBfwrv0iv60g/4AyXDn/TpXygknJqnenZg+5/rmT1PU+vSxfeJ0LYRafGZNnVSdJ IjSLu0gVOiBOEETe0orEYRwiK5J4q7jf9xNk6UV+ZkNcB0Wplc1FgWPu+xMk8ZwksCGeE85QakWi 0EmtCGw08a0RBMgJXGsEQeI79p2Ggbuw7zQMg8j1rAjyAt/KhtzAiexIEPh+ZEeiNLOeaeT42axv NU8QL/TTlRWJ3Xg2syGxEyUza95iDy09a9Txyo0ia0ZnsyhB1thmSZTNEiuSonBhtXm+rpM0yDLr KSSZ79ujXsC5+dYcLOIwiBc2JFXHY91punJiZN1PhsIws965LIJ0WyPIEjeNn0FCZL8l2cJ55m6v XDdO7Ajy4TYoZNpB0FGquZpa/+ZmpZ6lUdVZpLjacIpHt2qunSqNDb9f0NrgGwLDA7lE1u3GgJNJ B4gKl+UKGqQBdEKreUFFsyRbvS5vMd8NvL0Gt0phRvhw5lIjBeF/ctY2HXrkuOmeG6PiBkFvSWv5 kVZGLtrN2ljVMO5cQG1dfDpwnachPTCwQPvWz/ZHrJ8BrUvqyZd1l+y85GvV4sktbprupdjs3Otx SXd76armLuGrgJ8/+mOz83rM05jXYfoD52pnoN0vBplnZBd6vpH5gywwsmCQhUYWDjJkZEjJ9jAb 8JLW9/BomaWSb1lZsiMp3g34N6IuCWKPG7Ls5jgoL9YJ+sFOjA5z8gBDICmohF+VDS0q/KBmQk83 oV67xCfWyke6ClPKzWMGNS/3z/T0kbEu8SexqPkyp1CO61O1GcbGqy7wkgp44huYMCXjBvtDY24w L1j+Hm4SrLqigvdh5vpdt3VDPZlKPQXAuX8m2wUWpOgxYxp2pv/GaIkW4RJNsiDNJkGySCfxMg4n yWI5i1ASeUG2+q+/pOYH9s3/AAAA//8DAFBLAwQUAAYACAAAACEAXig1KbAMAAAXfAAADwAAAHdv cmQvc3R5bGVzLnhtbMydTXPbOBKG71s1/4Gl0+whkeUPOUmNM+U48dq1ceKJnM0ZIiELa5LQklRs 769fACQlUE1QbLDj2ktiUeoHQHe/TYCff/z5lMTBT57lQqZno8nrg1HA01BGIr0/G32/u3z1ZhTk BUsjFsuUn42eeT768/1vf/vj8V1ePMc8DxQgzd8l4dloWRSrd+NxHi55wvLXcsVT9eVCZgkr1Mfs fpyw7GG9ehXKZMUKMRexKJ7HhwcH01GFyfpQ5GIhQv5RhuuEp4WxH2c8VkSZ5kuxymvaYx/ao8yi VSZDnudq0Elc8hIm0g1mcgxAiQgzmctF8VoNpuqRQSnzyYH5K4m3gBMc4BAApiF/wjHeVIyxsrQ5 IsJxphuOiCyOX2csQB4V0RJFOaz9Ota2rGBLli9tIsd16mSDe060j5Lw3fV9KjM2jxVJRT1QgQsM WP+rxq//M3/yJ7NdD2H0XmkhkuFHvmDruMj1x+w2qz5Wn8x/lzIt8uDxHctDIe5UB1UriVANXp2n uRipbzjLi/NcsNYvl/qP1m/CvLA2fxCRGI11i/l/1Zc/WXw2Ojyst1zoHjS2xSy9r7fx9NX3md0T a9Nccc9GLHs1O9eG42pg5f/WcFe7n0zDKxYK0w5bFFzJfDI90NBY6KpyePK2/vBtrZ3P1oWsGjGA 8v8Ndgw8rtSvasGsLEnqW774LMMHHs0K9cXZyLSlNn6/vs2EzFTZORu9NW2qjTOeiCsRRTy1fpgu RcR/LHn6PefRdvtfl6Z0VBtCuU7V30enU5MFcR59egr5Shci9W3KdEy+aINY/3otto0b8//UsEkV iTb7JWe6GgeTXYTpPgpxqC1ya7TtzPXO2M2vUA0dvVRDxy/V0MlLNTR9qYZOX6qhNy/VkMH8yoZE GqnCb34PmwHUfRyHGtEch9jQHIeW0ByHVNAchxLQHEeiozmOPEZzHGmK4BQydGWhlexHjmzv5u7f R/hx9+8S/Lj79wB+3P0F34+7v777cfeXcz/u/urtx91frPHccqoVXCuZpcVglS2kLFJZ8KDgT8Np LFUss0Sl4emdHs9IBkmAKStbtSMeTAuZ+bw/Q4xI/ffnhV7pBXIRLMT9OuP54I7z9CeP5YoHLIoU jxCY8WKdOTzik9MZX/CMpyGnTGw6qF4JBuk6mRPk5ordk7F4GhG7ryaSFIVNQqv181KLRBAkdcLC TA7vmmRk9eGzyIf7SkOCD+s45kSsLzQpZljD1wYGM3xpYDDDVwYGM3xhYMWMykUVjchTFY3IYRWN yG9lflL5raIR+a2iEfmtog33250oYlPi7VnHpP+xu4tY6pMKg/sxE/cpUxOA4bub6phpcMsydp+x 1TLQR6XbsfaYse18kNFzcEexT9uQqOb1JkUu1KhFuh7u0AaNSlwbHpG8NjwigW14wyV2o6bJeoJ2 RbOema3nRatoDamXaGcsXpcT2uFqY8XwDNsK4FJkOZkM2rEEGfxFT2d1OCkq37aXwzu2ZQ2X1W5V Iu1ehSToZSzDB5oyfPW84plalj0MJl3KOJaPPKIjzopMlrlmS/7QhKSX5D8lqyXLhVkrNRD9d/X1 5QjBDVsNHtBtzERKE7dPrxIm4oBuBnF1d/M5uJMrvczUjqEBfpBFIRMyZnUk8PcffP53mg6eq0Vw +kw02nOiw0MGdiEIdjIlSUZEJDXNFKkg2Yca3j/581yyLKKh3Wa8vAKo4ETEGUtW5aSDQFuqLj6q +kMwGzK8f7FM6ONCVKK6I4FZhw3z9fzfPBxe6r7IgOTI0Nd1YY4/mqmusabDDZ8mNHDDpwgmmmr3 oPOXYLAN3PDBNnBUg72IWZ4L5ylUbx7VcGse9XiHL/4qnoxltljHdA6sgWQerIFkLpTxOklzyhEb HuGADY96vIQpY3gEh+QM7x+ZiMiCYWBUkTAwqjAYGFUMDIw0AMOv0LFgwy/TsWDDr9UpYURTAAtG lWeku3+iszwWjCrPDIwqzwyMKs8MjCrPjj4GfLFQk2C6XYyFpMo5C0m3o0kLnqxkxrJnIuSnmN8z ggOkJe02kwt9a4hMy4u4CZD6GHVMONkucVRB/sHnZF3TLMp+ERwRZXEsJdGxte0Ox1g2r13bZ2bu 5BjchduYhXwp44hnjjG5bdV6eVbelrHbfdONXoc9P4v7ZRHMlpuj/TZmerDXsl6wN8z2N9jm82l9 P0ub2Q2PxDqpOwpvppge9Tc2Gd0wPt5vvJ1JNCxPelrCNqf7Lbez5IblaU9L2OabnpZGpw3LLj18 ZNlDayKcduXPZo3nSL7TrizaGLc225VIG8u2FDztyqKGVILzMNRnC2B0+mnGbd9PPG57jIrcFIyc 3JTeunIjugT2jf8Ues+OKZqmvc3VE6Dum0l0r8r511qWx+0bJ5z639R1rSZOac6DVs5R/xNXjSrj 9mPvcuNG9K47bkTvAuRG9KpETnNUSXJTetcmN6J3kXIj0NUK7hFw1Qra46oVtPepVpDiU60GzALc iN7TATcCLVSIQAt1wEzBjUAJFZh7CRVS0EKFCLRQIQItVDgBwwkV2uOECu19hAopPkKFFLRQIQIt VIhACxUi0EKFCLRQPef2TnMvoUIKWqgQgRYqRKCFauaLA4QK7XFChfY+QoUUH6FCClqoEIEWKkSg hQoRaKFCBFqoEIESKjD3EiqkoIUKEWihQgRaqOWthv5ChfY4oUJ7H6FCio9QIQUtVIhACxUi0EKF CLRQIQItVIhACRWYewkVUtBChQi0UCECLVRzsnCAUKE9TqjQ3keokOIjVEhBCxUi0EKFCLRQIQIt VIhACxUiUEIF5l5ChRS0UCECLVSI6MrP6hSl6zL7Cf6op/OK/f6nrqpOfbNv5bZRR/1Rda/crP73 InyQ8iFovfHwyKw3+kHEPBbSHKJ2nFa3ueaSCNSJz68X3Xf42PSBD12q7oUw50wB/LivJTimctyV 8rYlWOQdd2W6bQlmncdd1de2BLvB466ia3RZX5SidkfAuKvMWMYTh3lXtbbMoYu7arRlCD3cVZkt Q+jgrnpsGZ4EujjvWp/09NN0c30pIHSlo0U4dRO60hLGqi7HUBh9g+Ym9I2em9A3jG4CKp5ODD6w bhQ6wm6UX6ihzLCh9heqm4ANNSR4hRpg/EMNUd6hhii/UMPCiA01JGBD7V+c3QSvUAOMf6ghyjvU EOUXargrw4YaErChhgRsqAfukJ0Y/1BDlHeoIcov1HByhw01JGBDDQnYUEOCV6gBxj/UEOUdaojy CzVYJaNDDQnYUEMCNtSQ4BVqgPEPNUR5hxqiukJtjqI0Qo2KsGWOm4RZhrgdsmWIK86WocdqybL2 XC1ZBM/VEoxVHXPcaskOmpvQN3puQt8wugmoeDox+MC6UegIu1F+ocatltpC7S9UNwEbatxqyRlq 3GqpM9S41VJnqHGrJXeocaultlDjVkttofYvzm6CV6hxq6XOUONWS52hxq2W3KHGrZbaQo1bLbWF Grdaagv1wB2yE+MfatxqqTPUuNWSO9S41VJbqHGrpbZQ41ZLbaHGrZacocatljpDjVstdYYat1py hxq3WmoLNW611BZq3GqpLdS41ZIz1LjVUmeocaulzlDjVks3ykQQPAJqlrCsCOieF3fF8mXBhj+c 8Hua8VzGP3kU0A71M2qU48fG668027ybT/2+UD7TT0C3bleKyifAVkDzw+to85oqbax7ElQvBKs2 mw5Xp2vLFo0hbCpcqrbC6tlVjqaqZ9BubqIyT6DdbdjxoFrTkW0C1r+uXLr1V/m7hrc6+13ohO/o sxFEp49Kzbg6+LYqAvt6qPozj8tXpqk/rtNIAR6r14WVPY2eWIlS31/wOL5h5a/lyv3TmC+K8tvJ gXlkwc738/Lpe077zJRpJ2Dc7Ez5sXptm8Pf5fP4q+sHnCmpa1GLu83FLEM97e5bQy6b3pjz8+YW 690OWU9rLL3JVAtftaaBhHT5aphpqwulmX2jaUmULBc6O8zPDg5OD44+va2uEnC9c89+497x5kP7 G/ccry3UlwOlquYxc+WNeSWhtal0/Patg7Us7bcO1iWrfnlgn0ISrnOVn6a87SZJ04vu0ARbL+/E p7UcuaO1L1LusPwfOXTjvguZ6KeWbi9c2vVg6+s9cG4cUg2b3nxzOTmtL5qrvLl1zqSaLdrOKbft d0675CvntIp+930+GOVb3D7aH+IlUAqw8reSr0I2ks9so1Pzrmd2vV59T6JoO7q4CCCScojTOpNy Vj00syMv6+dqtrkIDD7VHnV92eK2qv1fnb+VQ+flGC7yX5Ft9lBcCVf9xp1zrZp2+40642wH+eZf /Vf+/n8AAAD//wMAUEsDBBQABgAIAAAAIQDvCilOTgEAAH4DAAAUAAAAd29yZC93ZWJTZXR0aW5n cy54bWyc019rwjAQAPD3wb5DybumyhQpVmEMx17GYNsHiOnVhiW5kour7tPv2qlz+GL3kv/34y4h 8+XO2eQTAhn0uRgNU5GA11gYv8nF+9tqMBMJReULZdFDLvZAYrm4vZk3WQPrV4iRT1LCiqfM6VxU MdaZlKQrcIqGWIPnzRKDU5GnYSOdCh/beqDR1SqatbEm7uU4TafiwIRrFCxLo+EB9daBj128DGBZ RE+VqemoNddoDYaiDqiBiOtx9sdzyvgTM7q7gJzRAQnLOORiDhl1FIeP0m7k7C8w6QeML4Cphl0/ Y3YwJEeeO6bo50xPjinOnP8lcwZQEYuqlzI+3qtsY1VUlaLqXIR+SU1O3N61d+R09rTxGNTassSv nvDDJR3ctlx/23VD2HXrbQliwR8C62ic+YIVhvuADUGQ7bKyFpuX50eeyD+/ZvENAAD//wMAUEsD BBQABgAIAAAAIQAPJIjqhAIAAJkLAAAZAAAAd29yZC9jb21tZW50c0V4dGVuZGVkLnhtbKSW326b MBTG7yftHRD3qbEJBFCTKg1k6vW6B3CNE1CxjWzyp28/m4SQja3C9CYQ4Pv5O8fnHPnx6cwq50il KgVfuvDBcx3KichLvl+6v163s8h1VIN5jivB6dL9oMp9Wn3/9niCQUIEY5Q3Kjs7GsNVcqrJ0i2a pk4AUKSgDKsHVhIplNg1D/pzIHa7klBwEjIHyINee1dLQahSes0N5kes3CuOnMfRcolPWmyAc0AK LBt67hnQGhKAGERDEJoA0hEiOET51qgQGFcD0HwSSLsakIJppH8EF04joSFpMY3kD0nRNNKgnNiw wEVNuX65E5LhRv+Ve8CwfD/UMw2ucVO+lVXZfGimF3YYXPL3CY606kZgfm5NWAAmclr5eUcRS/cg eXLVz256Yz256K+XTiHHxH+RpIIczHxoIweSVjoXgquirG8dzqbS9Muigxw/C+LIqu67Uw1Htsv/ xlN6SWUPHGP/mn9WXZx/ToTeiB0xiJtijIU/1+ycMF2F/cKTUnOXXDhygHQANACEhI4c+B0jujIA 6TvUcMqRrdFxLrtiOGWfWDhyjv1t5g6g8iYvrCioyyswWtzgAqtboRsitTMV3HAf7C5H9f5rjfBD ikPd08qv0V76sXYyhwwL1rWh7ptcfc3MzwLXetoxkrzsuZD4rdKOdHs4usKddgfMry4Uc2lv6bl9 bvbaMTPGXd2fjjLzNkhqLPGLLksYLaI4RJnbPs3bQ5Xngs8kKIjhIsrmFpJ57AfzMN1aSBZplqXr 1LdZxc+Q52+RhSSA8224iW2MwQjBNN3YGAvDAMH42UbiPW9RFGWxzSpZsPbhZm0TS7r2gg0aSsCd Rp+nV78BAAD//wMAUEsDBBQABgAIAAAAIQDUhn9ZuQIAAIgMAAAUAAAAd29yZC9jb21tZW50c0lk cy54bWyk19tyojAYAOD7ndl3cLhvQ8LZqd1RgR2vd/cB0hCFKSFMgoe+/SYoYsvSjfRGEPi//Dn9 4tOPEytnBypkwauFBR9ta0YrwrOi2i2sP7/Th9CayQZXGS55RRfWG5XWj+fv356O0CdFNiecMVo1 cpPJmaIqOT/WZGHlTVPPAZAkpwzLR1YQwSXfNo/qecC324JQcOQiA8iGdntWC06olKrdNa4OWFoX jpzMtEzgowrWoAtIjkVDT70B70Y8EIFwCKEJkOohgkPKuZvygc5qALmTIJXVQPKmSf/onD9NQkMp mCY5QymcJg2WExsucF7TSt3ccsFwo76KHWBYvO7rBwXXuCleirJo3pRp+x2Di+p1QkYq6iowJ7tb CADjGS2drFP4wtqLan6Jf7jG69Tn5/jLoYsQJv0/h8Sc7HWBaHsOBC3VWPBK5kV93eFsqqZu5h1y +KwTB1Z2zx1raLhdxspTfB7KHjRJ/zL+rDxn/rkIbYMZ0cQ1wiSF9212mTC1CvuGJw3NzeBCwwLS AWgA+IQaFvzOCC8GIP0OPf843eecZ0U7RT+w0LCOfUzmBpBZk+V3KagbV6BjcYNzLK8LXYv0vqS8 K/fGbsao3n1tI/wUfF/3WvE1bdOXtaN+0bjDumyo200uv5bMrxzXqtoxMt/sKi7wS6kyUttjplb4 rJ0B/akWij60p/TUXtdzPdM1xnr+8Ia0aZ/VF2os8EYtThgGYeSjxOpuZPu2JX0PeatwFfm+Bf7v IC+CQZi4o84ysE0cN3I814/TESdI7NTICeIkiZexM5rPKkqN8nESZDspGnXW0DNxPOim/joa65dy ImjiwBDBOF6P9yv2lyaO73sIRqtxJ3VjE8depSgMk2jEWULXXRvlk3hLB66Xo44PjeYLxkvbW6NP nNTRDngP6b8Oz38BAAD//wMAUEsDBBQABgAIAAAAIQAXP2htpgIAAH0NAAAbAAAAd29yZC9jb21t ZW50c0V4dGVuc2libGUueG1spNfNc6IwFADw+87s/8Bwt0n4Epnajq11p+dtL3tLIQpTkjBJ/Oh/ vwmC2LKrkF5Exffj5fES4u39gZbOjghZcDZ30Q10HcJSnhVsM3dfX1aT2HWkwizDJWdk7n4Q6d7f /fxxu0dRSg5JyiklTMmngyJMFm8lcbTIZLKv0rmbK1UlAMg0JxTLG1qkgku+Vjc6DPD1ukgJ2HOR AQ8iWL+rBE+JlPryj5jtsHQbLj0M0zKB9zrYgAFIcywUOXQGGo2EYAbiPuRZQHqEHupT/mgqAiar HhRYQTqrnhTaSf8YXGQneX1paif5fSm2k3rtRPsNzivC9Mk1FxQr/VFsAMXifVtNNFxhVbwVZaE+ tAmjlsEFe7fISEedBOpno4UpoDwjpZ+1Cp+7W8GSJn5yijepJ8f45tBGiCHjP4Ysebo160Q9ciBI qWvBmcyL6jTDqa2mT+Ytsrs0iB0t29/tKzRwuvxveVoeS9mBQ9Jv6k/LY+aXRQQH3BFDnCKGpPD5 mm0mVHdhd2Gr0pwVFw1cQFrA6wHm2TLOiBsDpN0MNU4xcGq0zvGuGKfoCosGrmNfkzkDZKayfJTi tXUFJhYrnGN5anQjknFJhSfug57VqNp8byL8EnxbdVrxPe25W9b2Zr8xwmom1Pkkl99L5neOK73a 0TR53jAusN7dzF09PRzd4U59B8yrbhRzqN+SQ/29udeOWWPcuy8bpbN9UnMi29bws+5TL3yIH2aR fjS057Air0o/Z3Q3eBPoTdD0xYMJnCUQ/nHBeHwxhddw5Nvh0ye4uozDIAlC28wfZqurmce2+CMK r+Gm7Jb4DF3FPVt8GS2u4pEtvgqW13A/sMMXKAgeL+CxwQPLPl+gCF3qlhoPp9b4yr+MIy23OPis n/1RuvsLAAD//wMAUEsDBBQABgAIAAAAIQD/CXwnNwIAAI8IAAASAAAAd29yZC9mb250VGFibGUu eG1s3JRRb9owEIDfJ+0/RH4vcUKggBoqlRVp0rSHqf0BxnGItdiOfIbAv985CSkSoDWV1ofxEJw7 +4vvy8UPjwdVBnthQRqdkmhESSA0N5nU25S8vqzvZiQAx3TGSqNFSo4CyOPy65eHepEb7SDA9RoW iqekcK5ahCHwQigGI1MJjcncWMUc3tptqJj9vavuuFEVc3IjS+mOYUzplHQY+x6KyXPJxTfDd0po 16wPrSiRaDQUsoITrX4PrTY2q6zhAgBrVmXLU0zqHhMlFyAluTVgcjfCYrodNShcHtFmpMo3wGQY IL4ATLk4DGPMOkaIK885MhvGmfYcmZ1xPraZMwBkLisGUeKT19CvZY4VDIpzohi2qUmPOyrvSPHF 9602lm1KJOFbD/DFBQ3YX7F+/9cMxaGJ+xLIsvsUgnqhmcKVK1bKjZVNomLagIgwt2dlSrCGNZ1Q X0tMEzr2VxL6ibxgFoSHtBNpG86ZkuXxFIVaArSJSjpenOJ7ZqXfdZsCucXEDjY0Jc8JpfHzek3a SIS7oxhJ7p+6SOyf1fzmXWTcR6iP8IbT3EYthzecfg4+M2wNXJh4kUpA8FPUwS+jmL5hJKZTNDFB H97MeJAR23AHGfH1Xxi5n00+xcgKjyhTMrih4glVzD/YHMpkwl5zkcuDyK6LoNNzET6wXvWRNxHR 30XMB4vYWSmsb44bLu7RQOvCt0Xyz11ca4pk/ClN0R4YwQ+5LdzNY8P3w396bHQDWP4BAAD//wMA UEsDBBQABgAIAAAAIQC+hexweQIAAA4KAAAPAAAAd29yZC9wZW9wbGUueG1spJbbjpswEIbvK/Ud EPfEQAJJUJJt1airXPRq2wfwGhOs4INs5/T2tTmmpV0BuQFsPJ//Gc+MvHm50cK5YKkIZ1s3mPmu gxniKWHHrfvr53dv5TpKQ5bCgjO8de9YuS+7z5821yBKBOaiwI5BMJVcBdq6udYiAUChHFOoZpQg yRXP9AxxCniWEYTBlcsUhH7gl19CcoSVMvt9g+wClVvj0G0YLZXwaowtcAFQDqXGt44RjIZEYA1W fVA4AWQ8DIM+aj4aFQOrqgdaTAIZVT1SNI30D+fiaaSwT1pOI837pNU0Ui+daD/BucDM/My4pFCb oTwCCuXpLDwDFlCTd1IQfTdMP24wkLDTBEXGqiXQeTqasASUp7iYpw2Fb92zZElt77X2VnpS2dev xkIO8b8y2XN0ppjp0nMgcWFiwZnKiWgrnE6lmZ95A7l85MSFFs26qwgGlsv/2tO+CmUHHCK/jj8t KuUfEwN/wIlYRGsxRMKfezZKqMnCbuNJoXkIbjCwgTSAsAeIER7Y8BvGqmYA1FWo5ZCBpdFwqlOx HNIFNhjYx/4W8wBQqU7zUZSwiSuwtlDDHKo20S0RjxMVtbg7fYiROD5XCK+Sn0VHI8/RDl1bu9oL xghWXVCPRa6eE/OWQ2G6HUXJ4ci4hO+FUWTKwzEZ7pQnYJ8mUeyr/MS3ct6etWN7jLurb0ZScWbN EnjWOTed81XiI5d35weR6nRv1kmszH0LH1jGy9VGy4WkWB5MFn/du+XcWVXjtyQ5VhDjlYV8wZIg ZTayviUJClYQrRH0YIRjb4GzzFvHMPMQWqV+uoziMIxcsNuATmE7sBe53W8AAAD//wMAUEsDBBQA BgAIAAAAIQARdjGXdwEAAPQCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACMklFPwjAQgN9N/A9L30e7IcQsYyRq8EUSEzEa32p7QGVrm7Yw 9u/tNjZc4MG3u953327XpvNjkQcHMFYoOUPRiKAAJFNcyM0Mva8W4T0KrKOS01xJmKEKLJpntzcp 0wlTBl6N0mCcABt4k7QJ0zO0dU4nGFu2hYLakSekL66VKajzqdlgTdmObgDHhExxAY5y6iiuhaHu jeik5KxX6r3JGwFnGHIoQDqLo1GEz6wDU9irDU3lD1kIV2m4inbFnj5a0YNlWY7KcYP6+SP8uXx5 a341FLLeFQOUpZwlTrgcshSfQx/Z/fcPMNce94mPmQHqlMmeDWyUqYKlMHZXNVhXqpe+g6pUhlsv GGQe42CZEdr5q2z1gwNP59S6pb/btQD+UF186ZKomwwcRP06svGkQfo8Pe26HQ944HeUtBvtKh/j x6fVAmUxieOQxGE0XRGSRHcJIV/1hIP+s7A4TfAf4/0qjhIyGRo7Qbuk4TvNfgEAAP//AwBQSwME FAAGAAgAAAAhAEioP/vkAQAA4wMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPBbtswDL0P2D8YujeyvTRtA0XFkGLoYVsDxG3PqkwnwmRJ kNSg2dePshdP2XaqT4+P9NMTSbHbt14XB/BBWbMi1awkBRhpW2V2K/LYfLm4JkWIwrRCWwMrcoRA bvnHD2zjrQMfFYQCJUxYkX2MbklpkHvoRZhh2mCms74XEUO/o7brlIQ7K197MJHWZbmg8BbBtNBe uEmQjIrLQ3yvaGtl8heemqNDPc4a6J0WEfj39KdmdCJYY6PQjeqB1/NqgZkpZhuxg8CrmtERsWfr 28A/LW6wbsRsvRdeyIgd5HVVLq4ZzRj22TmtpIjYXf5NSW+D7WLxMFgukgKjeQnDa2xBvnoVj7xk NA/ZV2WSm6tLRkeI/rzYeeH2gc9vkskpZFspNKyxB7wTOgCjfwh2DyLNdyNUsniIywPIaH0R1E+c cE2KFxEgdW5FDsIrYSIZy8ZgwNqF6HmjokbtKR5gXpZjNefVUIDgvHAIBg+Iz90NJ4SHDu8W/2O2 ys0OHkarmZ3c2emMv1TXtnfCYIvphLDDP8Kja+xdWpLfPTwns9E/q7jfOiFxKPX8qrrMlyDLsS2y 0OJUp6lMBLvHO3idTsB/zQ7aU82/ibRWT+Ob5dViVuI37NGJw1WYHhP/BQAA//8DAFBLAQItABQA BgAIAAAAIQCNsxTWiAEAANUHAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAB6RGrfvAAAATgIAAAsAAAAAAAAAAAAAAAAAwQMAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhAAgWVfDjRgAArKUDABEAAAAAAAAAAAAAAAAA4QYAAHdvcmQvZG9jdW1l bnQueG1sUEsBAi0AFAAGAAgAAAAhAMA622BSAQAAuQUAABwAAAAAAAAAAAAAAAAA800AAHdvcmQv X3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA3+oaz7QIAAC3IQAAEQAAAAAA AAAAAAAAAACHUAAAd29yZC9jb21tZW50cy54bWxQSwECLQAUAAYACAAAACEAtvRnmNIGAADJIAAA FQAAAAAAAAAAAAAAAABqWQAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAPMQ 0bwDBQAApg8AABEAAAAAAAAAAAAAAAAAb2AAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgA AAAhAF4oNSmwDAAAF3wAAA8AAAAAAAAAAAAAAAAAoWUAAHdvcmQvc3R5bGVzLnhtbFBLAQItABQA BgAIAAAAIQDvCilOTgEAAH4DAAAUAAAAAAAAAAAAAAAAAH5yAAB3b3JkL3dlYlNldHRpbmdzLnht bFBLAQItABQABgAIAAAAIQAPJIjqhAIAAJkLAAAZAAAAAAAAAAAAAAAAAP5zAAB3b3JkL2NvbW1l bnRzRXh0ZW5kZWQueG1sUEsBAi0AFAAGAAgAAAAhANSGf1m5AgAAiAwAABQAAAAAAAAAAAAAAAAA uXYAAHdvcmQvY29tbWVudHNJZHMueG1sUEsBAi0AFAAGAAgAAAAhABc/aG2mAgAAfQ0AABsAAAAA AAAAAAAAAAAApHkAAHdvcmQvY29tbWVudHNFeHRlbnNpYmxlLnhtbFBLAQItABQABgAIAAAAIQD/ CXwnNwIAAI8IAAASAAAAAAAAAAAAAAAAAIN8AAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYA CAAAACEAvoXscHkCAAAOCgAADwAAAAAAAAAAAAAAAADqfgAAd29yZC9wZW9wbGUueG1sUEsBAi0A FAAGAAgAAAAhABF2MZd3AQAA9AIAABEAAAAAAAAAAAAAAAAAkIEAAGRvY1Byb3BzL2NvcmUueG1s UEsBAi0AFAAGAAgAAAAhAEioP/vkAQAA4wMAABAAAAAAAAAAAAAAAAAAPoQAAGRvY1Byb3BzL2Fw cC54bWxQSwUGAAAAABAAEAAPBAAAWIcAAAAA --000000000000a766ad05d8515f47-- From nobody Sat Feb 19 01:33:54 2022 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 650CC3A0B90 for ; Sat, 19 Feb 2022 01:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 PZ8fL5t0JMdq for ; Sat, 19 Feb 2022 01:33:46 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4B3A0B21 for ; Sat, 19 Feb 2022 01:33:44 -0800 (PST) HMM_SOURCE_IP: 172.18.0.188:50004.713135537 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-61.144.66.66 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 47EA42800AC; Sat, 19 Feb 2022 17:33:37 +0800 (CST) X-189-SAVE-TO-SEND: 44031110@chinatelecom.cn Received: from ([172.18.0.188]) by app0023 with ESMTP id 42161b5818534ec5b962e645f5d32e93 for bruno.decraene@orange.com; Sat, 19 Feb 2022 17:33:38 CST X-Transaction-ID: 42161b5818534ec5b962e645f5d32e93 X-Real-From: zhuyq8@chinatelecom.cn X-Receive-IP: 172.18.0.188 X-MEDUSA-Status: 0 Sender: zhuyq8@chinatelecom.cn Date: Sat, 19 Feb 2022 17:33:31 +0800 From: "zhuyq8@chinatelecom.cn" To: bruno.decraene , spring References: <3104_1642069058_61DFFC42_3104_319_10_8549b268004442668017df2d9b036441@orange.com>, <8753_1645204368_620FD390_8753_143_1_979641027016468abe7acadc59e3e881@orange.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.22.188[cn] Mime-Version: 1.0 Message-ID: <20220219172847890316101@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart427847105863_=----" Archived-At: Subject: Re: [spring] IPR poll - draft-hu-spring-segment-routing-proxy-forwarding 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, 19 Feb 2022 09:33:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart427847105863_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIG1pc3NpbmcgdGhpcyBJUFIgUG9sbC4NCkknbSBub3QgYXdhcmUgb2YgdW5kaXNj bG9zZWQgSVBSIGFwcGxpY2FibGUgZm9yIHRoaXMgZHJhZnQuIFRoYW5rcy4NCkIuUi4NCllvbmdx aW5nIFpodQ0KDQoNCg0KDQp6aHV5cThAY2hpbmF0ZWxlY29tLmNuDQogDQpGcm9tOiBicnVuby5k ZWNyYWVuZUBvcmFuZ2UuY29tDQpEYXRlOiAyMDIyLTAyLTE5IDAxOjEyDQpUbzogZHJhZnQtaHUt c3ByaW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1mb3J3YXJkaW5nQGlldGYub3JnDQpDQzogU1BS SU5HIFdHDQpTdWJqZWN0OiBSRTogSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1y b3V0aW5nLXByb3h5LWZvcndhcmRpbmcNCkhpIGF1dGhvcnMsDQogDQpJZiBJ4oCZbSBub3QgbWlz dGFrZW4sIHdlIHJlY2VpdmVkIGEgcmVwbHkgZnJvbToNClJlOiBbc3ByaW5nXSBJUFIgcG9sbCAt IGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXLigKYgIEh1YWltbyBDaGVuDQpSZTogW3NwcmluZ10g SVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1y4oCmICBIdXpoaWJvDQpSZTogW3Nw cmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1y4oCmICB5YW9qdW5kYQ0K IA0KU28gd2UgYXJlIG1pc3NpbmcgcmVwbGllcyBmcm9tIHRoZSBmb2xsb3dpbmcgY28tYXV0aG9y czoNCkMuIEJvd2Vycw0KWS4gWmh1DQpZLiBMaXUNCiANClRoYW5rIHlvdSwNCi0tQnJ1bm8NCiAN CiANCiANCk9yYW5nZSBSZXN0cmljdGVkDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbQ0KU2VudDogVGh1 cnNkYXksIEphbnVhcnkgMTMsIDIwMjIgMTE6MTggQU0NClRvOiBTUFJJTkcgV0cgPHNwcmluZ0Bp ZXRmLm9yZz47IGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGlu Z0BpZXRmLm9yZw0KU3ViamVjdDogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmct c2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmcNCiANCkhpIGF1dGhvcnMsIGNvbnRyaWJ1 dG9ycywgV0cNCiANCkluIHByZXBhcmF0aW9uIG9mIHRoZSBXRyBhZG9wdGlvbiBjYWxsIG9uIGRy YWZ0LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZyBbMV0sIHRoaXMg ZW1haWwgc3RhcnRzIGEgcG9sbCBmb3IgSVBSLg0KIA0KSWYgeW91IGFyZSBhbiBhdXRob3Igb3Ig Y29udHJpYnV0b3IgdG8gdGhlIHN1YmplY3QgZG9jdW1lbnQsIHBsZWFzZSByZXNwb25kIHRvIHRo aXMgZW1haWwuDQpJbiB5b3VyIHJlc3BvbnNlLCBwbGVhc2UgaW5kaWNhdGUgaWYgYWxsIHJlbGV2 YW50IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpJZiB5b3Uga25vdyBvZiByZWxldmFudCBJUFIg dGhhdCBoYXMgbm90IGJlZW4gZGlzY2xvc2VkLCBwbGVhc2Ugc3RhdGUgdGhhdCBhbmQgZGVzY3Jp YmUgaG93IHRoaXMgZ2FwIGlzIGJlaW5nIGFkZHJlc3NlZC4NCiANCkV2ZW4gaWYgeW91IGFyZSBu b3QgYSBjb250cmlidXRvciBvciBhdXRob3IsIGlmIHlvdSBrbm93IG9mIHJlbGV2YW50IElQUiwg cGxlYXNlIGVuc3VyZSB0aGF0IGl0IGhhcyBiZWVuIGRpc2xvc2VkIGFzIGRpc2N1c3NlZCBpbiBC Q1AgNzkuDQogDQpJZiB5b3Uga25vdyBvZiBzb21lb25lIGVsc2UgSVBSIHRoYXQgeW91IGJlbGll dmUgaXMgcmVsZXZhbnQgYW5kIG5vdCBkaXNjbG9zZWQsIHBsZWFzZSBmaWxlIGEgdGhpcmQgcGFy dHkgSVBSIGRpc2Nsb3N1cmUuDQogDQpUaGFua3MsDQpSZWdhcmRzLA0KQnJ1bm8sIEppbSwgSm9l bA0KWzFdICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHUtc3By aW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1mb3J3YXJkaW5nLyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIENlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uY3BhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv bixPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuIFRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7dGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLlRoYW5rIHlvdS4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KDQo= ------=_001_NextPart427847105863_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A=0A
Sorry for missing this IPR Poll.
I'm not awa= re of undisclosed IPR applicable for this draft. Thanks.
= B.R.
Yongqing Zhu

=0A

=0A
<= span>
zhuyq8@chinatelecom.cn
=0A
 
D= ate: 2022-02-19 01:12
Subject: RE: IPR poll = - draft-hu-spring-segment-routing-proxy-forwarding
<= div class=3D"FoxDiv20220219172547198506" style=3D"overflow-wrap: break-wor= d;">=0A=0A
=0A

Hi authors,

=0A

&= nbsp;

=0A

If I=E2=80=99m not mistaken, we received a reply from:

=0A=0A

 

= =0A

So we= are missing replies from the following co-authors:

= =0A

=0AC. Bo= wers

=0A

=0AY. Zhu

=0A

=0AY. Liu

= =0A

=  

=0A

Thank you,

=0A

--Bruno

= =0A

=  

=0A

 

=0A

 

=0A

=0AOrange Restricted

=0A
=0A
=0A
=0A

From:= =0A spring <spring-bounc= es@ietf.org> On Behalf Of bruno.decraene@orange.com
=0ASen= t: Thursday, January 13, 2022 11:18 AM
=0ATo: SPRING WG <= spring@ietf.org>; draft-hu-spring-segment-routing-proxy-forwarding@ietf= .org
=0ASubject: [spring] IPR poll - draft-hu-spring-segment-rou= ting-proxy-forwarding

=0A
=0A
=0A

 

=0A

Hi authors, contributors, WG=

=0A

 

=0A

In preparation of the WG adoption call on dra= ft-hu-spring-segment-routing-proxy-forwarding [1], this email starts a pol= l for IPR.

=0A

 

=0A

If you are an author o= r contributor to the subject document, please respond to this email.<= /o:p>

=0A
    =0A
  • In your response, pleas= e indicate if all relevant IPR has been disclosed.           =             &n= bsp;           &nbs= p;            =         =0A
  • If you know of relevant IPR that has not been disclosed, p= lease state that and describe=0A how this gap is being addressed.
=0A

 

=0A

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Arial"= ;,sans-serif;mso-ansi-language:EN-US">Even if you are not a contributor or= author, if you know of relevant IPR, please ensure that it has been dislo= sed as discussed in BCP 79.

=0A

 

= =0A

If yo= u know of someone else IPR that you believe is relevant and not disclosed,= please file a third party IPR disclosure.

=0A

 

=0A

Thanks,

=0A

Regards,

=0A

Bruno, Jim, Joel=

=0A

[1]   &nbs= p; =0Ahttps://datatracker.ietf.org/doc/draft-hu-sprin= g-segment-routing-proxy-forwarding/&nb= sp;            = ;            &= nbsp;           &nb= sp;       =0A         

=0A
__________________________=
__________________________________________________________________________=
_____________________
=0A
 =
=0A
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doiven=
t donc
=0A
pas etre diffuses, exploit=
es ou copies sans autorisation. Si vous avez recu ce message par erreur, v=
euillez le signaler
=0A
a l'expediteu=
r et le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration,
=0A
=
Orange decline toute responsabilite si ce message a ete altere, deforme ou=
 falsifie. Merci.
=0A
 
=0A
This message and its attachments may cont=
ain confidential or privileged information that may be protected by law;
=0A
they should not be distributed, us=
ed or copied without authorisation.
=0A
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
=0A
As emails may be altered, Orange is not liable for messages that h=
ave been modified, changed or falsified.
=0A
Thank you.
=0A
=0A
=0A
______________________________________________________________________=
___________________________________________________=0ACe message et ses pi=
eces jointes peuvent contenir des informations confidentielles ou privileg=
iees et ne doivent donc=0Apas etre diffuses, exploites ou copies sans auto=
risation. Si vous avez recu ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e=
lectroniques etant susceptibles d'alteration,=0AOrange decline toute respo=
nsabilite si ce message a ete altere, deforme ou falsifie. Merci.=0AThis m=
essage and its attachments may contain confidential or privileged informat=
ion that may be protected by law;=0Athey should not be distributed, used o=
r copied without authorisation.=0AIf you have received this email in error=
, please notify the sender and delete this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been=
 modified, changed or falsified.=0AThank you.=0A
=0A
=0A ------=_001_NextPart427847105863_=------ From nobody Sat Feb 19 19:27:43 2022 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 9299F3A09D1; Sat, 19 Feb 2022 19:27:41 -0800 (PST) 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_DNSWL_BLOCKED=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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjLVb1EHdH_E; Sat, 19 Feb 2022 19:27:37 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0704C3A09D0; Sat, 19 Feb 2022 19:27:37 -0800 (PST) Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4K1W340f2Tz67Mll; Sun, 20 Feb 2022 11:22:56 +0800 (CST) Received: from canpemm500005.china.huawei.com (7.192.104.229) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sun, 20 Feb 2022 04:27:33 +0100 Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sun, 20 Feb 2022 11:27:31 +0800 Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2308.021; Sun, 20 Feb 2022 11:27:31 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: IETF 113 Slot Requests Collection Thread-Index: AdgjoxCwfywpFY7xSCStbRd/s3xF5gCZjboQ Date: Sun, 20 Feb 2022 03:27:31 +0000 Message-ID: <13b4ba707b8c4e228d323ec60f871bb2@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.112.41.150] Content-Type: multipart/alternative; boundary="_000_13b4ba707b8c4e228d323ec60f871bb2huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] IETF 113 Slot Requests Collection 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, 20 Feb 2022 03:27:42 -0000 --_000_13b4ba707b8c4e228d323ec60f871bb2huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The IETF 113 preliminary agenda is out. The SPRING session has been schedul= ed in the following slot. Vienna local time, UTC +1 Friday, March 25, 2022 12:30-14:30 Friday Afternoon session I Best Regards, Shuping From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Pen= g Shuping) Sent: Thursday, February 17, 2022 10:09 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] IETF 113 Slot Requests Collection Dear all, For building the IETF 113 SPRING agenda, we will continue to using the Goog= le Form to collect presentation slot requests. Please submit your requests = in the following form up to 2022-03-04 EOD. https://docs.google.com/forms/d/e/1FAIpQLSfxY7TXAl53aMSpclmHjH-90ZTLsWoaZz7= _BvHvlYcewJeaFw/viewform If there is any issue for you to access this Form, please send your request= directly to spring-chairs@ietf.org. Thank you! Best regards, Shuping --_000_13b4ba707b8c4e228d323ec60f871bb2huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear al= l,

&n= bsp;

The IET= F 113 preliminary agenda is out. The SPRING session has been scheduled in t= he following slot.  

&n= bsp;

Vienna = local time, UTC +1

Friday,= March 25, 2022

12:30-1= 4:30

Friday = Afternoon session I

&n= bsp;

Best Re= gards,

Shuping=

&n= bsp;

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, February 17, 2022 10:09 AM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: [spring] IETF 113 Slot Requests Collection

 

Dear all,

 

For building the IETF 113 SP= RING agenda, we will continue to using the Google Form to collect presentat= ion slot requests. Please submit your requests in the following form up to = 2022-03-04 EOD.

 

https://docs.google.com/forms/d/e/1FAIpQLSfxY7TXAl53aMSpclmHjH-90ZTLs= WoaZz7_BvHvlYcewJeaFw/viewform

 

If there is any issue for you t= o access this Form, please send your request directly to spring-chairs@ietf.org.<= /o:p>

 

Thank you!

 

Best regards,=

Shuping

 

--_000_13b4ba707b8c4e228d323ec60f871bb2huaweicom_-- From nobody Sun Feb 20 17:47:17 2022 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 54C153A0ADA; Sun, 20 Feb 2022 17:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HDRS_MISSP=2.499, HTML_MESSAGE=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 vscS0v8PP5ZF; Sun, 20 Feb 2022 17:47:08 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 548BF3A0AD0; Sun, 20 Feb 2022 17:47:06 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee26212ef18fee-b6d70; Mon, 21 Feb 2022 09:47:04 +0800 (CST) X-RM-TRANSID: 2ee26212ef18fee-b6d70 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from CMCC-PC (unknown[223.104.39.65]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee46212ef162fc-04bda; Mon, 21 Feb 2022 09:47:04 +0800 (CST) X-RM-TRANSID: 2ee46212ef162fc-04bda MIME-Version: 1.0 x-PcFlag: 8c235113-ffcb-43e3-bb04-ad1e326eda33_5_53639 X-Mailer: PC_RICHMAIL 2.9.14 Date: 21 Feb 2022 09:47:07 +0800 From: =?utf-8?B?WWlzb25nIExpdQ==?= To: bruno.decraene, draft-hu-spring-segment-routing-proxy-forwarding Cc: =?utf-8?B?U1BSSU5HIFdH?= Message-ID: <202202210947072725575097@chinamobile.com> X-Has-Attach: yes Content-Type: multipart/mixed; boundary="----=_001_NextPart-1569392199_=----" Archived-At: Subject: [spring] =?utf-8?q?Re=EF=BC=9A_Re=3A__IPR_poll_-_draft-hu-spring?= =?utf-8?q?-segment-routing-proxy-forwarding?= 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, 21 Feb 2022 01:47:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart-1569392199_=---- Content-Type: multipart/Alternative; boundary="----=_002_NextPart-1569392199_=----" ------=_002_NextPart-1569392199_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQ1IaSBCcnVubywNDQ0NDUkgaGF2ZSByZXBsaWVkIGFib3V0IGEgbW9udGggYWdvLiBQbGVhc2Ug Y2hlY2sgdGhlIGV4cG9ydGVkIG1haWwgaW4gdGhlIGF0dGFjaGVkIGZpbGVzLg0NDQ0NQmVzdCBS ZWdhcmRzDQ1ZaXNvbmcNDQ0NDQ0NDQ0NIA0NDQ3lj5Hku7bkuro6IGJydW5vLmRlY3JhZW5lDQ3m l7bpl7Q6IDIwMjIvMDIvMTko5pif5pyf5YWtKTAxOjEyDQ3mlLbku7bkuro6IGRyYWZ0LWh1LXNw cmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZzsNDeaKhOmAgeS6ujogU1BSSU5H IFdHOw0N5Li76aKYOiBSZTogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmcgDQ0gDQ1IaSBhdXRob3JzLCANDSAgDQ1JZiBJ 4oCZbSBub3QgbWlzdGFrZW4sIHdlIHJlY2VpdmVkIGEgcmVwbHkgZnJvbTogIFJlOiBbc3ByaW5n XSBJUFIgcG9sbCAtIGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXLigKYgIEh1YWltbyAgQ2hlblJl OiBbc3ByaW5nXSBJUFIgcG9sbCAtIGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXLigKYgIEh1emhp Ym9SZTogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1y4oCmICB5 YW9qdW5kYSANDSAgDQ1TbyB3ZSBhcmUgbWlzc2luZyByZXBsaWVzIGZyb20gdGhlIGZvbGxvd2lu ZyBjby1hdXRob3JzOiANDSBDLiBCb3dlcnMgDQ0gWS4gWmh1IA0NIFkuIExpdSANDSAgDQ1UaGFu ayB5b3UsIA0NLS1CcnVubyANDSAgDQ0gIA0NICANDSBPcmFuZ2UgUmVzdHJpY3RlZCANDSANDSAN DSANDUZyb206ICBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbQ0gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTMsIDIw MjIgMTE6MTggQU0NIFRvOiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz47IGRyYWZ0LWh1LXNw cmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZ0BpZXRmLm9yZw0gU3ViamVjdDog W3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5 LWZvcndhcmRpbmcgICANDSAgDQ1IaSBhdXRob3JzLCBjb250cmlidXRvcnMsIFdHIA0NICANDUlu IHByZXBhcmF0aW9uIG9mIHRoZSBXRyBhZG9wdGlvbiBjYWxsIG9uIGRyYWZ0LWh1LXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZyBbMV0sIHRoaXMgZW1haWwgc3RhcnRzIGEg cG9sbCBmb3IgSVBSLiANDSAgDQ1JZiB5b3UgYXJlIGFuIGF1dGhvciBvciBjb250cmlidXRvciB0 byB0aGUgc3ViamVjdCBkb2N1bWVudCwgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbC4gIElu IHlvdXIgcmVzcG9uc2UsIHBsZWFzZSBpbmRpY2F0ZSBpZiBhbGwgcmVsZXZhbnQgSVBSIGhhcyBi ZWVuIGRpc2Nsb3NlZC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJZiB5b3Uga25vdyBvZiByZWxldmFudCBJUFIgdGhhdCBoYXMgbm90IGJl ZW4gZGlzY2xvc2VkLCBwbGVhc2Ugc3RhdGUgdGhhdCBhbmQgZGVzY3JpYmUgIGhvdyB0aGlzIGdh cCBpcyBiZWluZyBhZGRyZXNzZWQuIA0NICANDUV2ZW4gaWYgeW91IGFyZSBub3QgYSBjb250cmli dXRvciBvciBhdXRob3IsIGlmIHlvdSBrbm93IG9mIHJlbGV2YW50IElQUiwgcGxlYXNlIGVuc3Vy ZSB0aGF0IGl0IGhhcyBiZWVuIGRpc2xvc2VkIGFzIGRpc2N1c3NlZCBpbiBCQ1AgNzkuIA0NICAN DUlmIHlvdSBrbm93IG9mIHNvbWVvbmUgZWxzZSBJUFIgdGhhdCB5b3UgYmVsaWV2ZSBpcyByZWxl dmFudCBhbmQgbm90IGRpc2Nsb3NlZCwgcGxlYXNlIGZpbGUgYSB0aGlyZCBwYXJ0eSBJUFIgZGlz Y2xvc3VyZS4gDQ0gIA0NVGhhbmtzLCANDVJlZ2FyZHMsIA0NQnJ1bm8sIEppbSwgSm9lbCANDVsx XSAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1LXNwcmluZy1z ZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZy8gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANDV9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQ0gIA0NQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIA0NcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIgDQ1hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLCANDU9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4gDQ0gIA0NVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgDQ10 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4gDQ1JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4gDQ1BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuIA0NVGhhbmsgeW91LiAgIA0NX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4gIFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4gQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLiBUaGFuayB5b3Uu ------=_002_NextPart-1569392199_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> DocumentEmail 21 false false false FR X-NONE X-NONE MicrosoftInternetExplorer4 <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 10=5D><=21=5Bendif=5D--><=21--= =5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->
Hi=20Bruno,

I=20have=20replied=20about=20a=20month=20ago.=20Pl= ease=20check=20the=20exported=20mail=20in=20the=20attached=20files.

Best=20Regards
Yisong
<= div=20id=3D=22SIGNNAME53639=22>
 
=E5=8F=91=E4=BB=B6=E4= =BA=BA:=20bruno.decrae= ne
=E6=97=B6=E9=97=B4:=202022/02/19(=E6=98=9F=E6=9C=9F= =E5=85=AD)01:12
=E6=94=B6=E4=BB=B6=E4=BA=BA:=20dr= aft-hu-spring-segment-routing-proxy-forwarding;
=E6=8A= =84=E9=80=81=E4=BA=BA:=20SPRING= =20WG;
=E4=B8=BB=E9=A2=98:=20Re:=20=5Bspring=5D=20IPR= =20poll=20-=20draft-hu-spring-segment-routing-proxy-forwarding
<= /blockquote>=0A=0AHi=20authors,

=0A 

=0A<= p=20class=3D=22MsoNormal=22>If=20I=E2=80=99m=20not=20mistaken,=20we=20received=20a=20reply=20from:<= o:p>

=0A=0ARe:=20=5Bspring=5D=20IPR=20poll=20= -=20draft-hu-spring-segment-r=E2=80=A6  Huaimo=0A=20Che= nRe:=20=5Bspring=5D=20IPR=20p= oll=20-=20draft-hu-spring-segment-r=E2=80=A6  HuzhiboRe:=20=5Bspring=5D=20IPR=20poll= =20-=20draft-hu-spring-segment-r=E2=80=A6  yaojunda=0A 

=0ASo=20we=20are=20= missing=20replies=20from=20the=20following=20co-authors:<= /p>=0A=0AC.=20Bowers

=0A=0A<= span=20lang=3D=22EN-US=22=20style=3D=22font-size:10.0pt;font-family:"C= ourier=20New";mso-fareast-font-family:"Times=20New=20Roman";= mso-ansi-language:EN-US;mso-fareast-language:FR=22>Y.=20Zhu

=0A=0AY.=20Liu

=0A 

=0AThank=20you,

=0A--Bruno

=0A 

=0A 

=0A 

=0A=0AOrange=20Restricted

=0A=0A
=0A=0AFrom:=0A=20spring=20<spring-bounces=40ietf.org>=20On=20Behalf=20Of= =20bruno.decraene=40orange.com
=0ASent:=20Thursday,=20January= =2013,=202022=2011:18=20AM
=0ATo:=20SPRING=20WG=20<spring=40ie= tf.org>;=20draft-hu-spring-segment-routing-proxy-forwarding=40ietf.org=0ASubject:=20=5Bspring=5D=20IPR=20poll=20-=20draft-hu-spring-segm= ent-routing-proxy-forwarding

=0A
=0A
=0A 

=0AHi=20authors,=20cont= ributors,=20WG

=0A 

= =0AIn=20preparation=20of=20the=20WG=20adoption=20call=20on=20draft-hu-s= pring-segment-routing-proxy-forwarding=20=5B1=5D,=20this=20email=20starts= =20a=20poll=20for=20IPR.

=0A 

=0AIf=20you=20are=20an=20author=20or=20contributor=20to=20the= =20subject=20document,=20please=20respond=20to=20this=20email.

=0A=0AIn=20= your=20response,=20please=20indicate=20if=20all=20relevant=20IPR=20has=20be= en=20disclosed.   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  =0AIf=20you=20know=20of=20relevan= t=20IPR=20that=20has=20not=20been=20disclosed,=20please=20state=20that=20an= d=20describe=0A=20how=20this=20gap=20is=20being=20addressed.=0A 

=0AEven=20if=20you=20ar= e=20not=20a=20contributor=20or=20author,=20if=20you=20know=20of=20relevant= =20IPR,=20please=20ensure=20that=20it=20has=20been=20dislosed=20as=20discus= sed=20in=20BCP=2079.

=0A<= span=20lang=3D=22EN-US=22=20style=3D=22font-size:10.0pt;font-family:"A= rial",sans-serif;mso-ansi-language:EN-US=22> =0AIf=20you=20know=20of=20someone=20else=20IPR=20that=20you=20believe= =20is=20relevant=20and=20not=20disclosed,=20please=20file=20a=20third=20par= ty=20IPR=20disclosure.

=0A =

=0AThanks,

=0A<= span=20lang=3D=22EN-US=22=20style=3D=22font-size:10.0pt;font-family:"A= rial",sans-serif;mso-ansi-language:EN-US=22>Regards,=

=0ABruno,=20Jim,=20Joel

=0A=5B1=5D     =0Ahttps://datatracker.ietf.org/doc/draft-hu-spring-se= gment-routing-proxy-forwarding/&n= bsp;            = ;            &n= bsp;            = ;       =0A         =20

=0A_______________________________________________________________________= __________________________________________________=0A =0ACe=20message=20et=20ses=20pieces= =20jointes=20peuvent=20contenir=20des=20informations=20confidentielles=20ou= =20privilegiees=20et=20ne=20doivent=20donc=0Apas=20etre=20diffuses,=20exploites=20ou= =20copies=20sans=20autorisation.=20Si=20vous=20avez=20recu=20ce=20message= =20par=20erreur,=20veuillez=20le=20signaler=0Aa=20l'expediteur=20et=20le=20detruire=20= ainsi=20que=20les=20pieces=20jointes.=20Les=20messages=20electroniques=20et= ant=20susceptibles=20d'alteration,=0AOrange=20decline=20toute=20responsabilite=20si=20= ce=20message=20a=20ete=20altere,=20deforme=20ou=20falsifie.=20Merci.=0A =0AThis=20message= =20and=20its=20attachments=20may=20contain=20confidential=20or=20privileged= =20information=20that=20may=20be=20protected=20by=20law;= =0Athey=20should=20not=20be= =20distributed,=20used=20or=20copied=20without=20authorisation.<= /pre>=0AIf=20you=20have=20re= ceived=20this=20email=20in=20error,=20please=20notify=20the=20sender=20and= =20delete=20this=20message=20and=20its=20attachments.=0AAs=20emails=20may=20be=20alter= ed,=20Orange=20is=20not=20liable=20for=20messages=20that=20have=20been=20mo= dified,=20changed=20or=20falsified.=0AThank=20you.=0A
=0A
= =0A
___________________________________________________________________=
______________________________________________________=0A=0ACe=20message=20=
et=20ses=20pieces=20jointes=20peuvent=20contenir=20des=20informations=20con=
fidentielles=20ou=20privilegiees=20et=20ne=20doivent=20donc=0Apas=20etre=20=
diffuses,=20exploites=20ou=20copies=20sans=20autorisation.=20Si=20vous=20av=
ez=20recu=20ce=20message=20par=20erreur,=20veuillez=20le=20signaler=0Aa=20l=
'expediteur=20et=20le=20detruire=20ainsi=20que=20les=20pieces=20jointes.=20=
Les=20messages=20electroniques=20etant=20susceptibles=20d'alteration,=0AOra=
nge=20decline=20toute=20responsabilite=20si=20ce=20message=20a=20ete=20alte=
re,=20deforme=20ou=20falsifie.=20Merci.=0A=0AThis=20message=20and=20its=20a=
ttachments=20may=20contain=20confidential=20or=20privileged=20information=
=20that=20may=20be=20protected=20by=20law;=0Athey=20should=20not=20be=20dis=
tributed,=20used=20or=20copied=20without=20authorisation.=0AIf=20you=20have=
=20received=20this=20email=20in=20error,=20please=20notify=20the=20sender=
=20and=20delete=20this=20message=20and=20its=20attachments.=0AAs=20emails=
=20may=20be=20altered,=20Orange=20is=20not=20liable=20for=20messages=20that=
=20have=20been=20modified,=20changed=20or=20falsified.=0AThank=20you.=0A=0A=0A

------=_002_NextPart-1569392199_=------



------=_001_NextPart-1569392199_=----
Content-Type: application/octet-stream; name=
 "=?utf-8?B?UmXvvJogSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmcuZW1s?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="=?utf-8?B?UmXvvJogSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmcuZW1s?="

TUlNRS1WZXJzaW9uOjEuMA0KeC1QY0ZsYWc6NDYwYjAxNjItMGQ5MS00NjgxLTgwOTItMDhiZGU3
NTM2NTg3XzVfNTE1MjkNClgtRXh0ZW5kRmxhZzowMDAwMDANClgtTWFpbGVyOlBDX1JJQ0hNQUlM
IDIuOS4xNA0KRGF0ZToxNCBKYW4gMjAyMiAxOToxNDoxNCArMDgwMA0KRnJvbTo9P3V0Zi04P0I/
V1dsemIyNW5JRXhwZFE9PT89PGxpdXlpc29uZ0BjaGluYW1vYmlsZS5jb20+DQpUbzpicnVuby5k
ZWNyYWVuZTxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiwNCgk9P3V0Zi04P0I/VTFCU1NVNUhJ
RmRIPz08c3ByaW5nQGlldGYub3JnPiwNCglkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5n
LXByb3h5LWZvcndhcmRpbmc8ZHJhZnQtaHUtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1m
b3J3YXJkaW5nQGlldGYub3JnPg0KQ2M6DQpCY2M6DQpTdWJqZWN0Oj0/dXRmLTg/Qj9VbVh2dkpv
Z1NWQlNJSEJ2Ykd3Z0xTQmtjbUZtZEMxb2RTMXpjSEpwYm1jdGMyVm5iV1Z1ZEMxeWIzVjBhVzVu
TFhCeWIzaDVMV1p2Y25kaGNtUnBibWM9Pz0NCk1lc3NhZ2UtSUQ6PDIwMjIwMTE0MTkxNDE0MTU5
MTE1NTM4OUBjaGluYW1vYmlsZS5jb20+DQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9BbHRlcm5h
dGl2ZTsNCglib3VuZGFyeT0iLS0tLT1fMDAxX05leHRQYXJ0MTU5MTE1NTM4OV89LS0tLSINCg0K
VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4NCg0KDQotLS0tLS09
XzAwMV9OZXh0UGFydDE1OTExNTUzODlfPS0tLS0NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsN
CgljaGFyc2V0PSJ1dGYtOCINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NA0KDQpE
UTFJYVNCWFIrKzhqQTBORFEwTklDQWdJRWtuYlNCdWIzUWdZWGRoY21VZ2IyWWdZVzU1SUhWdVpH
bHpZMnh2YzJWa0lFbFFVaUJ5DQpaV3hoZEdWa0lIUnZJSFJvYVhNZ1pISmhablF1RFEwTkRRMUNa
WE4wSUZKbFoyRnlaSE1ORFZscGMyOXVadzBORFEwTkRRME5EUTBODQpEUTBnRFEwTkRlV1BrZVM3
dHVTNnVqb2dZbkoxYm04dVpHVmpjbUZsYm1VTkRlYVh0dW1YdERvZ01qQXlNaTh3TVM4eE15am1t
Si9tDQpuSi9sbTVzcE1UZzZNVGNORGVhVXR1Uzd0dVM2dWpvZ1UxQlNTVTVISUZkSE8yUnlZV1ow
TFdoMUxYTndjbWx1WnkxelpXZHRaVzUwDQpMWEp2ZFhScGJtY3RjSEp2ZUhrdFptOXlkMkZ5Wkds
dVp6c05EZVM0dSttaW1Eb2dTVkJTSUhCdmJHd2dMU0JrY21GbWRDMW9kUzF6DQpjSEpwYm1jdGMy
Vm5iV1Z1ZEMxeWIzVjBhVzVuTFhCeWIzaDVMV1p2Y25kaGNtUnBibWNnRFEwZ0RRMUlhU0JoZFhS
b2IzSnpMQ0JqDQpiMjUwY21saWRYUnZjbk1zSUZkSElBME5JQ0FORFVsdUlIQnlaWEJoY21GMGFX
OXVJRzltSUhSb1pTQlhSeUJoWkc5d2RHbHZiaUJqDQpZV3hzSUc5dUlHUnlZV1owTFdoMUxYTndj
bWx1WnkxelpXZHRaVzUwTFhKdmRYUnBibWN0Y0hKdmVIa3RabTl5ZDJGeVpHbHVaeUJiDQpNVjBz
SUhSb2FYTWdaVzFoYVd3Z2MzUmhjblJ6SUdFZ2NHOXNiQ0JtYjNJZ1NWQlNMaUFORFNBZ0RRMUpa
aUI1YjNVZ1lYSmxJR0Z1DQpJR0YxZEdodmNpQnZjaUJqYjI1MGNtbGlkWFJ2Y2lCMGJ5QjBhR1Vn
YzNWaWFtVmpkQ0JrYjJOMWJXVnVkQ3dnY0d4bFlYTmxJSEpsDQpjM0J2Ym1RZ2RHOGdkR2hwY3lC
bGJXRnBiQzRnSUVsdUlIbHZkWElnY21WemNHOXVjMlVzSUhCc1pXRnpaU0JwYm1ScFkyRjBaU0Jw
DQpaaUJoYkd3Z2NtVnNaWFpoYm5RZ1NWQlNJR2hoY3lCaVpXVnVJR1JwYzJOc2IzTmxaQzRnSUNB
Z0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnDQpJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lD
QWdJRWxtSUhsdmRTQnJibTkzSUc5bUlISmxiR1YyWVc1MElFbFFVaUIwDQphR0YwSUdoaGN5QnVi
M1FnWW1WbGJpQmthWE5qYkc5elpXUXNJSEJzWldGelpTQnpkR0YwWlNCMGFHRjBJR0Z1WkNCa1pY
TmpjbWxpDQpaU0FnYUc5M0lIUm9hWE1nWjJGd0lHbHpJR0psYVc1bklHRmtaSEpsYzNObFpDNGdE
UTBnSUEwTlJYWmxiaUJwWmlCNWIzVWdZWEpsDQpJRzV2ZENCaElHTnZiblJ5YVdKMWRHOXlJRzl5
SUdGMWRHaHZjaXdnYVdZZ2VXOTFJR3R1YjNjZ2IyWWdjbVZzWlhaaGJuUWdTVkJTDQpMQ0J3YkdW
aGMyVWdaVzV6ZFhKbElIUm9ZWFFnYVhRZ2FHRnpJR0psWlc0Z1pHbHpiRzl6WldRZ1lYTWdaR2x6
WTNWemMyVmtJR2x1DQpJRUpEVUNBM09TNGdEUTBnSUEwTlNXWWdlVzkxSUd0dWIzY2diMllnYzI5
dFpXOXVaU0JsYkhObElFbFFVaUIwYUdGMElIbHZkU0JpDQpaV3hwWlhabElHbHpJSEpsYkdWMllX
NTBJR0Z1WkNCdWIzUWdaR2x6WTJ4dmMyVmtMQ0J3YkdWaGMyVWdabWxzWlNCaElIUm9hWEprDQpJ
SEJoY25SNUlFbFFVaUJrYVhOamJHOXpkWEpsTGlBTkRTQWdEUTFVYUdGdWEzTXNJQTBOVW1WbllY
SmtjeXdnRFExQ2NuVnVieXdnDQpTbWx0TENCS2IyVnNJQTBOV3pGZElDQWdJQ0FnSUNCb2RIUndj
em92TDJSaGRHRjBjbUZqYTJWeUxtbGxkR1l1YjNKbkwyUnZZeTlrDQpjbUZtZEMxb2RTMXpjSEpw
Ym1jdGMyVm5iV1Z1ZEMxeWIzVjBhVzVuTFhCeWIzaDVMV1p2Y25kaGNtUnBibWN2SUNBZ0lDQWdJ
Q0FnDQpJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0Fn
SUNBZ0lDQWdJQ0FnSUNBZ0RRMWZYMTlmDQpYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5
ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmDQpYMTlmWDE5Zlgx
OWZYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5
ZlgxOWZYMTlmDQpYMTlmSUNCRFpTQnRaWE56WVdkbElHVjBJSE5sY3lCd2FXVmpaWE1nYW05cGJu
UmxjeUJ3WlhWMlpXNTBJR052Ym5SbGJtbHlJR1JsDQpjeUJwYm1admNtMWhkR2x2Ym5NZ1kyOXVa
bWxrWlc1MGFXVnNiR1Z6SUc5MUlIQnlhWFpwYkdWbmFXVmxjeUJsZENCdVpTQmtiMmwyDQpaVzUw
SUdSdmJtTWdjR0Z6SUdWMGNtVWdaR2xtWm5WelpYTXNJR1Y0Y0d4dmFYUmxjeUJ2ZFNCamIzQnBa
WE1nYzJGdWN5QmhkWFJ2DQpjbWx6WVhScGIyNHVJRk5wSUhadmRYTWdZWFpsZWlCeVpXTjFJR05s
SUcxbGMzTmhaMlVnY0dGeUlHVnljbVYxY2l3Z2RtVjFhV3hzDQpaWG9nYkdVZ2MybG5ibUZzWlhJ
Z1lTQnNKMlY0Y0dWa2FYUmxkWElnWlhRZ2JHVWdaR1YwY25WcGNtVWdZV2x1YzJrZ2NYVmxJR3hs
DQpjeUJ3YVdWalpYTWdhbTlwYm5SbGN5NGdUR1Z6SUcxbGMzTmhaMlZ6SUdWc1pXTjBjbTl1YVhG
MVpYTWdaWFJoYm5RZ2MzVnpZMlZ3DQpkR2xpYkdWeklHUW5ZV3gwWlhKaGRHbHZiaXdnVDNKaGJt
ZGxJR1JsWTJ4cGJtVWdkRzkxZEdVZ2NtVnpjRzl1YzJGaWFXeHBkR1VnDQpjMmtnWTJVZ2JXVnpj
MkZuWlNCaElHVjBaU0JoYkhSbGNtVXNJR1JsWm05eWJXVWdiM1VnWm1Gc2MybG1hV1V1SUUxbGNt
TnBMaUFnDQpWR2hwY3lCdFpYTnpZV2RsSUdGdVpDQnBkSE1nWVhSMFlXTm9iV1Z1ZEhNZ2JXRjVJ
R052Ym5SaGFXNGdZMjl1Wm1sa1pXNTBhV0ZzDQpJRzl5SUhCeWFYWnBiR1ZuWldRZ2FXNW1iM0p0
WVhScGIyNGdkR2hoZENCdFlYa2dZbVVnY0hKdmRHVmpkR1ZrSUdKNUlHeGhkenNnDQpkR2hsZVNC
emFHOTFiR1FnYm05MElHSmxJR1JwYzNSeWFXSjFkR1ZrTENCMWMyVmtJRzl5SUdOdmNHbGxaQ0Iz
YVhSb2IzVjBJR0YxDQpkR2h2Y21sellYUnBiMjR1SUVsbUlIbHZkU0JvWVhabElISmxZMlZwZG1W
a0lIUm9hWE1nWlcxaGFXd2dhVzRnWlhKeWIzSXNJSEJzDQpaV0Z6WlNCdWIzUnBabmtnZEdobElI
TmxibVJsY2lCaGJtUWdaR1ZzWlhSbElIUm9hWE1nYldWemMyRm5aU0JoYm1RZ2FYUnpJR0YwDQpk
R0ZqYUcxbGJuUnpMaUJCY3lCbGJXRnBiSE1nYldGNUlHSmxJR0ZzZEdWeVpXUXNJRTl5WVc1blpT
QnBjeUJ1YjNRZ2JHbGhZbXhsDQpJR1p2Y2lCdFpYTnpZV2RsY3lCMGFHRjBJR2hoZG1VZ1ltVmxi
aUJ0YjJScFptbGxaQ3dnWTJoaGJtZGxaQ0J2Y2lCbVlXeHphV1pwDQpaV1F1SUZSb1lXNXJJSGx2
ZFM0PQ0KDQotLS0tLS09XzAwMV9OZXh0UGFydDE1OTExNTUzODlfPS0tLS0NCkNvbnRlbnQtVHlw
ZTogdGV4dC9odG1sOw0KCWNoYXJzZXQ9InV0Zi04Ig0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGlu
ZzogcXVvdGVkLXByaW50YWJsZQ0KDQo8aHRtbCB4bWxuczp2PTNEPTIydXJuOnNjaGVtYXMtbWlj
cm9zb2Z0LWNvbTp2bWw9MjIgeG1sbnM6bz0zRD0yMnVybjpzY2hlbWE9DQpzLW1pY3Jvc29mdC1j
b206b2ZmaWNlOm9mZmljZT0yMiB4bWxuczp3PTNEPTIydXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv
bTpvZmY9DQppY2U6d29yZD0yMiB4bWxuczptPTNEPTIyaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0
LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sPQ0KPTIyIHhtbG5zPTNEPTIyaHR0cDovL3d3dy53My5v
cmcvVFIvUkVDLWh0bWw0MD0yMj48aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9M0Q9MjJDb250ZW50
LVR5cGU9MjIgY29udGVudD0zRD0yMnRleHQvaHRtbDsgY2hhcnNldD0zRHVzLT0NCmFzY2lpPTIy
Pg0KPG1ldGEgbmFtZT0zRD0yMlByb2dJZD0yMiBjb250ZW50PTNEPTIyV29yZC5Eb2N1bWVudD0y
Mj4NCjxtZXRhIG5hbWU9M0Q9MjJHZW5lcmF0b3I9MjIgY29udGVudD0zRD0yMk1pY3Jvc29mdCBX
b3JkIDE1PTIyPg0KPG1ldGEgbmFtZT0zRD0yMk9yaWdpbmF0b3I9MjIgY29udGVudD0zRD0yMk1p
Y3Jvc29mdCBXb3JkIDE1PTIyPg0KPGxpbmsgcmVsPTNEPTIyRmlsZS1MaXN0PTIyIGhyZWY9M0Q9
MjJjaWQ6ZmlsZWxpc3QueG1sPTQwMDFEODA4NkYuMkI2MjE1NzA9DQo9MjI+PD0yMS0tPTVCaWYg
Z3RlIG1zbyA5PTVEPjx4bWw+DQo8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPG86QWxsb3dQ
TkcvPg0KPC9vOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48PTIxPTVCZW5kaWY9NUQt
LT48PTIxLS09NUJpZiBndGUgbXNvIDk9NUQ+PHhtbD4NCjx3OldvcmREb2N1bWVudD4NCjx3OlNw
ZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6
VHJhY2tGb3JtYXR0aW5nLz4NCjx3Okh5cGhlbmF0aW9uWm9uZT4yMTwvdzpIeXBoZW5hdGlvblpv
bmU+DQo8dzpFbnZlbG9wZVZpcy8+DQo8dzpQdW5jdHVhdGlvbktlcm5pbmcvPg0KPHc6VmFsaWRh
dGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhN
TEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250
ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxh
Y2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVPdGhlcj5GUjwv
dzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVBc2lh
bj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2Ny
aXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTbmFw
VG9HcmlkSW5DZWxsLz4NCjx3OldyYXBUZXh0V2l0aFB1bmN0Lz4NCjx3OlVzZUFzaWFuQnJlYWtS
dWxlcy8+DQo8dzpEb250R3Jvd0F1dG9maXQvPg0KPHc6U3BsaXRQZ0JyZWFrQW5kUGFyYU1hcmsv
Pg0KPHc6RW5hYmxlT3BlblR5cGVLZXJuaW5nLz4NCjx3OkRvbnRGbGlwTWlycm9ySW5kZW50cy8+
DQo8dzpPdmVycmlkZVRhYmxlU3R5bGVIcHMvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8bTptYXRo
UHI+DQo8bTptYXRoRm9udCBtOnZhbD0zRD0yMkNhbWJyaWEgTWF0aD0yMi8+DQo8bTpicmtCaW4g
bTp2YWw9M0Q9MjJiZWZvcmU9MjIvPg0KPG06YnJrQmluU3ViIG06dmFsPTNEPTIyJj0yMzQ1Oy09
MjIvPg0KPG06c21hbGxGcmFjIG06dmFsPTNEPTIyb2ZmPTIyLz4NCjxtOmRpc3BEZWYvPg0KPG06
bE1hcmdpbiBtOnZhbD0zRD0yMjA9MjIvPg0KPG06ck1hcmdpbiBtOnZhbD0zRD0yMjA9MjIvPg0K
PG06ZGVmSmMgbTp2YWw9M0Q9MjJjZW50ZXJHcm91cD0yMi8+DQo8bTp3cmFwSW5kZW50IG06dmFs
PTNEPTIyMTQ0MD0yMi8+DQo8bTppbnRMaW0gbTp2YWw9M0Q9MjJzdWJTdXA9MjIvPg0KPG06bmFy
eUxpbSBtOnZhbD0zRD0yMnVuZE92cj0yMi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+
DQo8L3htbD48PTIxPTVCZW5kaWY9NUQtLT48PTIxLS09NUJpZiBndGUgbXNvIDk9NUQ+PHhtbD4N
Cjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0zRD0yMmZhbHNlPTIyIERlZlVuaGlkZVdo
ZW5Vc2VkPTNEPTIyZmFsc2U9DQo9MjIgRGVmU2VtaUhpZGRlbj0zRD0yMmZhbHNlPTIyIERlZlFG
b3JtYXQ9M0Q9MjJmYWxzZT0yMiBEZWZQcmlvcml0eT0zRD0yMjk9DQo5PTIyIExhdGVudFN0eWxl
Q291bnQ9M0Q9MjIzNzY9MjI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
UHJpb3JpdHk9M0Q9MjIwPTIyIFFGb3JtYXQ9M0Q9MjJ0cnVlPQ0KPTIyIE5hbWU9M0Q9MjJOb3Jt
YWw9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNE
PTIyOT0yMiBRRm9ybWF0PTNEPTIydHJ1ZT0NCj0yMiBOYW1lPTNEPTIyaGVhZGluZyAxPTIyLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjk9MjIg
U2VtaUhpZGRlbj0zRD0yMnRydT0NCmU9MjIgVW5oaWRlV2hlblVzZWQ9M0Q9MjJ0cnVlPTIyIFFG
b3JtYXQ9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJoZWFkaW5nIDI9DQo9MjIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyOT0yMiBTZW1pSGlkZGVu
PTNEPTIydHJ1PQ0KZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIgUUZvcm1hdD0zRD0y
MnRydWU9MjIgTmFtZT0zRD0yMmhlYWRpbmcgMz0NCj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI5PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnU9
DQplPTIyIFVuaGlkZVdoZW5Vc2VkPTNEPTIydHJ1ZT0yMiBRRm9ybWF0PTNEPTIydHJ1ZT0yMiBO
YW1lPTNEPTIyaGVhZGluZyA0PQ0KPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBQcmlvcml0eT0zRD0yMjk9MjIgU2VtaUhpZGRlbj0zRD0yMnRydT0NCmU9MjIgVW5o
aWRlV2hlblVzZWQ9M0Q9MjJ0cnVlPTIyIFFGb3JtYXQ9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJo
ZWFkaW5nIDU9DQo9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFBy
aW9yaXR5PTNEPTIyOT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1PQ0KZT0yMiBVbmhpZGVXaGVuVXNl
ZD0zRD0yMnRydWU9MjIgUUZvcm1hdD0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMmhlYWRpbmcgNj0N
Cj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9
MjI5PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnU9DQplPTIyIFVuaGlkZVdoZW5Vc2VkPTNEPTIydHJ1
ZT0yMiBRRm9ybWF0PTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyaGVhZGluZyA3PQ0KPTIyLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjk9MjIgU2Vt
aUhpZGRlbj0zRD0yMnRydT0NCmU9MjIgVW5oaWRlV2hlblVzZWQ9M0Q9MjJ0cnVlPTIyIFFGb3Jt
YXQ9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJoZWFkaW5nIDg9DQo9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyOT0yMiBTZW1pSGlkZGVuPTNE
PTIydHJ1PQ0KZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIgUUZvcm1hdD0zRD0yMnRy
dWU9MjIgTmFtZT0zRD0yMmhlYWRpbmcgOT0NCj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9
M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJpbmRleCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0N
Cj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMmluZGV4IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2Vk
PQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyaW5kZXggMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVz
ZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJpbmRleCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVu
VXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMmluZGV4IDU9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdo
ZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyaW5kZXggNj0yMi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRl
V2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJpbmRleCA3PTIyLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhp
ZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMmluZGV4IDg9MjIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVu
aGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyaW5kZXggOT0yMi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIzOT0yMiBTZW1p
SGlkZGVuPTNEPTIydHI9DQp1ZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIgTmFtZT0z
RD0yMnRvYyAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlv
cml0eT0zRD0yMjM5PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cj0NCnVlPTIyIFVuaGlkZVdoZW5Vc2Vk
PTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIydG9jIDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyMzk9MjIgU2VtaUhpZGRlbj0zRD0yMnRyPQ0K
dWU9MjIgVW5oaWRlV2hlblVzZWQ9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJ0b2MgMz0yMi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIzOT0yMiBT
ZW1pSGlkZGVuPTNEPTIydHI9DQp1ZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIgTmFt
ZT0zRD0yMnRvYyA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQ
cmlvcml0eT0zRD0yMjM5PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cj0NCnVlPTIyIFVuaGlkZVdoZW5V
c2VkPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIydG9jIDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyMzk9MjIgU2VtaUhpZGRlbj0zRD0yMnRy
PQ0KdWU9MjIgVW5oaWRlV2hlblVzZWQ9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJ0b2MgNj0yMi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIzOT0y
MiBTZW1pSGlkZGVuPTNEPTIydHI9DQp1ZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIg
TmFtZT0zRD0yMnRvYyA3PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBQcmlvcml0eT0zRD0yMjM5PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cj0NCnVlPTIyIFVuaGlkZVdo
ZW5Vc2VkPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIydG9jIDg9MjIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyMzk9MjIgU2VtaUhpZGRlbj0zRD0y
MnRyPQ0KdWU9MjIgVW5oaWRlV2hlblVzZWQ9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJ0b2MgOT0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0y
MnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJOb3JtYWwg
SW5kZW50PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlk
ZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0y
MmZvb3Rub3RlIHRleHQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBO
YW1lPTNEPTIyYW5ub3RhdGlvbiB0ZXh0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0y
MnRydWU9MjIgTmFtZT0zRD0yMmhlYWRlcj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNE
PTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9
MjJ0cnVlPTIyIE5hbWU9M0Q9MjJmb290ZXI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0z
RD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNE
PTIydHJ1ZT0yMiBOYW1lPTNEPTIyaW5kZXggaGVhZGluZz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIzNT0yMiBTZW1pSGlkZGVuPTNEPTIy
dHI9DQp1ZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIgUUZvcm1hdD0zRD0yMnRydWU9
MjIgTmFtZT0zRD0yMmNhcHRpb249MjI9DQovPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0y
MmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIy
dHJ1ZT0yMiBOYW1lPTNEPTIydGFibGUgb2YgZmlndXJlcz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVz
ZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJlbnZlbG9wZSBhZGRyZXNzPTIyLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBV
bmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMmVudmVsb3BlIHJldHVybj0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0y
MnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJmb290bm90
ZSByZWZlcmVuY2U9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNl
bWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1l
PTNEPTIyYW5ub3RhdGlvbiByZWZlcmVuY2U9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0z
RD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNE
PTIydHJ1ZT0yMiBOYW1lPTNEPTIybGluZSBudW1iZXI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2Vk
PQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIycGFnZSBudW1iZXI9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdo
ZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyZW5kbm90ZSByZWZlcmVuY2U9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVl
PTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyZW5kbm90ZSB0ZXh0
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNE
PTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMnRhYmxl
IG9mIGF1dGhvcml0aWVzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIg
TmFtZT0zRD0yMm1hY3JvPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIg
TmFtZT0zRD0yMnRvYSBoZWFkaW5nPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRy
dWU9MjIgTmFtZT0zRD0yMkxpc3Q9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZh
bHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1
ZT0yMiBOYW1lPTNEPTIyTGlzdCBCdWxsZXQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0z
RD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNE
PTIydHJ1ZT0yMiBOYW1lPTNEPTIyTGlzdCBOdW1iZXI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2Vk
PQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyTGlzdCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNl
ZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkxpc3QgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVz
ZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJMaXN0IDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5V
c2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyTGlzdCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVu
VXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkxpc3QgQnVsbGV0IDI9MjIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVu
aGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyTGlzdCBCdWxsZXQgMz0yMi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRy
dWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJMaXN0IEJ1bGxl
dCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVu
PTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkxp
c3QgQnVsbGV0IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNl
bWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1l
PTNEPTIyTGlzdCBOdW1iZXIgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFs
c2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVl
PTIyIE5hbWU9M0Q9MjJMaXN0IE51bWJlciAzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0z
RD0yMnRydWU9MjIgTmFtZT0zRD0yMkxpc3QgTnVtYmVyIDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5V
c2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyTGlzdCBOdW1iZXIgNT0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIxMD0yMiBRRm9ybWF0
PTNEPTIydHJ1ZT0NCj0yMiBOYW1lPTNEPTIyVGl0bGU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2Vk
PQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyQ2xvc2luZz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVz
ZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJTaWduYXR1cmU9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyMT0yMiBTZW1pSGlkZGVuPTNE
PTIydHJ1PQ0KZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkRlZmF1
bHQgUGFyYWdyYXBoIEZvbnQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNl
PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0y
MiBOYW1lPTNEPTIyQm9keSBUZXh0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRy
dWU9MjIgTmFtZT0zRD0yMkJvZHkgVGV4dCBJbmRlbnQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2Vk
PQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyTGlzdCBDb250aW51ZT0yMi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRl
V2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJMaXN0IENvbnRpbnVlIDI9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVl
PTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyTGlzdCBDb250aW51
ZSAzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVu
PTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkxp
c3QgQ29udGludWUgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
U2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5h
bWU9M0Q9MjJMaXN0IENvbnRpbnVlIDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0y
MmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIy
dHJ1ZT0yMiBOYW1lPTNEPTIyTWVzc2FnZSBIZWFkZXI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyMTE9MjIgUUZvcm1hdD0zRD0yMnRydWU9
DQo9MjIgTmFtZT0zRD0yMlN1YnRpdGxlPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0y
MnRydWU9MjIgTmFtZT0zRD0yMlNhbHV0YXRpb249MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0K
PTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyRGF0ZT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9
M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJCb2R5IFRleHQgRmlyc3QgSW5kZW50PTIyLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBV
bmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkJvZHkgVGV4dCBGaXJzdCBJ
bmRlbnQgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhp
ZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9
MjJOb3RlIEhlYWRpbmc9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBO
YW1lPTNEPTIyQm9keSBUZXh0IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZh
bHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1
ZT0yMiBOYW1lPTNEPTIyQm9keSBUZXh0IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0z
RD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNE
PTIydHJ1ZT0yMiBOYW1lPTNEPTIyQm9keSBUZXh0IEluZGVudCAyPTIyLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVX
aGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkJvZHkgVGV4dCBJbmRlbnQgMz0yMi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRy
dWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJCbG9jayBUZXh0
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNE
PTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkh5cGVy
bGluaz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRl
bj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJG
b2xsb3dlZEh5cGVybGluaz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9
MjIgUHJpb3JpdHk9M0Q9MjIyMj0yMiBRRm9ybWF0PTNEPTIydHJ1ZT0NCj0yMiBOYW1lPTNEPTIy
U3Ryb25nPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0
eT0zRD0yMjIwPTIyIFFGb3JtYXQ9M0Q9MjJ0cnVlPQ0KPTIyIE5hbWU9M0Q9MjJFbXBoYXNpcz0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0y
MnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJEb2N1bWVu
dCBNYXA9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRk
ZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIy
UGxhaW4gVGV4dD0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2Vt
aUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9
M0Q9MjJFLW1haWwgU2lnbmF0dXJlPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRy
dWU9MjIgTmFtZT0zRD0yMkhUTUwgVG9wIG9mIEZvcm09MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2Vk
PQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIySFRNTCBCb3R0b20gb2YgRm9ybT0yMi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIg
VW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJOb3JtYWwgKFdlYik9MjIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0
cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIySFRNTCBBY3Jv
bnltPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVu
PTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkhU
TUwgQWRkcmVzcz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2Vt
aUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9
M0Q9MjJIVE1MIENpdGU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBO
YW1lPTNEPTIySFRNTCBDb2RlPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxz
ZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9
MjIgTmFtZT0zRD0yMkhUTUwgRGVmaW5pdGlvbj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9
M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJIVE1MIEtleWJvYXJkPTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVu
VXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkhUTUwgUHJlZm9ybWF0dGVkPTIyLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0y
MiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkhUTUwgU2FtcGxlPTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIy
dHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkhUTUwgVHlw
ZXdyaXRlcj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhp
ZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9
MjJIVE1MIFZhcmlhYmxlPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIg
TmFtZT0zRD0yMk5vcm1hbCBUYWJsZT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIy
ZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0
cnVlPTIyIE5hbWU9M0Q9MjJhbm5vdGF0aW9uIHN1YmplY3Q9MjIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5V
c2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyTm8gTGlzdD0yMi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hl
blVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJPdXRsaW5lIExpc3QgMT0yMi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIg
VW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJPdXRsaW5lIExpc3QgMj0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0y
MnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJPdXRsaW5l
IExpc3QgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhp
ZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9
MjJUYWJsZSBTaW1wbGUgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9
MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIy
IE5hbWU9M0Q9MjJUYWJsZSBTaW1wbGUgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNE
PTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9
MjJ0cnVlPTIyIE5hbWU9M0Q9MjJUYWJsZSBTaW1wbGUgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVz
ZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJUYWJsZSBDbGFzc2ljIDE9MjIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVu
aGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgQ2xhc3NpYyAyPTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIy
dHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIENs
YXNzaWMgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhp
ZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9
MjJUYWJsZSBDbGFzc2ljIDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNl
PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0y
MiBOYW1lPTNEPTIyVGFibGUgQ29sb3JmdWwgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9
M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJUYWJsZSBDb2xvcmZ1bCAyPTIyLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVX
aGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIENvbG9yZnVsIDM9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVl
PTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgQ29sdW1u
cyAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVu
PTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRh
YmxlIENvbHVtbnMgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
U2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5h
bWU9M0Q9MjJUYWJsZSBDb2x1bW5zIDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0y
MmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIy
dHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgQ29sdW1ucyA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNl
ZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIENvbHVtbnMgNT0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5o
aWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJUYWJsZSBHcmlkIDE9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVl
PTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgR3JpZCAy
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNE
PTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxl
IEdyaWQgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhp
ZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9
MjJUYWJsZSBHcmlkIDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBO
YW1lPTNEPTIyVGFibGUgR3JpZCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRy
dWU9MjIgTmFtZT0zRD0yMlRhYmxlIEdyaWQgNj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9
M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJUYWJsZSBHcmlkIDc9MjIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5V
c2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgR3JpZCA4PTIyLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhp
ZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIExpc3QgMT0yMi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9
MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJUYWJsZSBMaXN0IDI9
MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9
MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUg
TGlzdCAzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlk
ZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0y
MlRhYmxlIExpc3QgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
U2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5h
bWU9M0Q9MjJUYWJsZSBMaXN0IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZh
bHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1
ZT0yMiBOYW1lPTNEPTIyVGFibGUgTGlzdCA2PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0z
RD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIExpc3QgNz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVz
ZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJUYWJsZSBMaXN0IDg9MjIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlk
ZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgM0QgZWZmZWN0cyAxPTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIy
dHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIDNE
IGVmZmVjdHMgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgU2Vt
aUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9
M0Q9MjJUYWJsZSAzRCBlZmZlY3RzIDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0y
MmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIy
dHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgQ29udGVtcG9yYXJ5PTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVu
VXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIEVsZWdhbnQ9MjIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVu
aGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyVGFibGUgUHJvZmVzc2lvbmFs
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNE
PTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxl
IFN1YnRsZSAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1p
SGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0z
RD0yMlRhYmxlIFN1YnRsZSAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxz
ZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0yMnRydWU9
MjIgTmFtZT0zRD0yMlRhYmxlIFdlYiAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0NCj0zRD0y
MnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIFdlYiAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVuVXNlZD0N
Cj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlRhYmxlIFdlYiAzPTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBVbmhpZGVXaGVu
VXNlZD0NCj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMkJhbGxvb24gVGV4dD0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIzOT0yMiBOYW1lPTNE
PTIyVGFibGUgR3I9DQppZD0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9
MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVlPTIy
IE5hbWU9M0Q9MjJUYWJsZSBUaGVtZT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIy
ZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgTmFtZT0zRD0yMlBsYWM9DQplaG9sZGVy
IFRleHQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5
PTNEPTIyMT0yMiBRRm9ybWF0PTNEPTIydHJ1ZT0NCj0yMiBOYW1lPTNEPTIyTm8gU3BhY2luZz0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2
MD0yMiBOYW1lPTNEPTIyTGlnaHQgU2g9DQphZGluZz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2MT0yMiBOYW1lPTNEPTIyTGlnaHQgTGk9
DQpzdD0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9
M0Q9MjI2Mj0yMiBOYW1lPTNEPTIyTGlnaHQgR3I9DQppZD0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2Mz0yMiBOYW1lPTNEPTIyTWVkaXVt
IFM9DQpoYWRpbmcgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
UHJpb3JpdHk9M0Q9MjI2ND0yMiBOYW1lPTNEPTIyTWVkaXVtIFM9DQpoYWRpbmcgMj0yMi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2NT0yMiBO
YW1lPTNEPTIyTWVkaXVtIEw9DQppc3QgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNE
PTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2Nj0yMiBOYW1lPTNEPTIyTWVkaXVtIEw9DQppc3Qg
Mj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9
MjI2Nz0yMiBOYW1lPTNEPTIyTWVkaXVtIEc9DQpyaWQgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2OD0yMiBOYW1lPTNEPTIyTWVkaXVt
IEc9DQpyaWQgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJp
b3JpdHk9M0Q9MjI2OT0yMiBOYW1lPTNEPTIyTWVkaXVtIEc9DQpyaWQgMz0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3MD0yMiBOYW1lPTNE
PTIyRGFyayBMaXM9DQp0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBQcmlvcml0eT0zRD0yMjcxPTIyIE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBTaGFkaW5nPTIyLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjcyPTIy
IE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBMaXN0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjczPTIyIE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBH
cmlkPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0z
RD0yMjYwPTIyIE5hbWU9M0Q9MjJMaWdodCBTaD0NCmFkaW5nIEFjY2VudCAxPTIyLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjYxPTIyIE5hbWU9
M0Q9MjJMaWdodCBMaT0NCnN0IEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjYyPTIyIE5hbWU9M0Q9MjJMaWdodCBHcj0NCmlk
IEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlv
cml0eT0zRD0yMjYzPTIyIE5hbWU9M0Q9MjJNZWRpdW0gUz0NCmhhZGluZyAxIEFjY2VudCAxPTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY0
PTIyIE5hbWU9M0Q9MjJNZWRpdW0gUz0NCmhhZGluZyAyIEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY1PTIyIE5hbWU9M0Q9
MjJNZWRpdW0gTD0NCmlzdCAxIEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
M0Q9MjJmYWxzZT0yMiBTZW1pSGlkZGVuPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyUmV2aT0NCnNp
b249MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNE
PTIyMzQ9MjIgUUZvcm1hdD0zRD0yMnRydWU9DQo9MjIgTmFtZT0zRD0yMkxpc3QgUGFyYWdyYXBo
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0y
MjI5PTIyIFFGb3JtYXQ9M0Q9MjJ0cnVlPQ0KPTIyIE5hbWU9M0Q9MjJRdW90ZT0yMi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIzMD0yMiBRRm9y
bWF0PTNEPTIydHJ1ZT0NCj0yMiBOYW1lPTNEPTIySW50ZW5zZSBRdW90ZT0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2Nj0yMiBOYW1lPTNE
PTIyTWVkaXVtIEw9DQppc3QgMiBBY2NlbnQgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2Nz0yMiBOYW1lPTNEPTIyTWVkaXVtIEc9DQpy
aWQgMSBBY2NlbnQgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
UHJpb3JpdHk9M0Q9MjI2OD0yMiBOYW1lPTNEPTIyTWVkaXVtIEc9DQpyaWQgMiBBY2NlbnQgMT0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2
OT0yMiBOYW1lPTNEPTIyTWVkaXVtIEc9DQpyaWQgMyBBY2NlbnQgMT0yMi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3MD0yMiBOYW1lPTNEPTIy
RGFyayBMaXM9DQp0IEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBQcmlvcml0eT0zRD0yMjcxPTIyIE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBTaGFkaW5n
IEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlv
cml0eT0zRD0yMjcyPTIyIE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBMaXN0IEFjY2VudCAxPTIyLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjczPTIy
IE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBHcmlkIEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjYwPTIyIE5hbWU9M0Q9MjJMaWdo
dCBTaD0NCmFkaW5nIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBQcmlvcml0eT0zRD0yMjYxPTIyIE5hbWU9M0Q9MjJMaWdodCBMaT0NCnN0IEFjY2Vu
dCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0z
RD0yMjYyPTIyIE5hbWU9M0Q9MjJMaWdodCBHcj0NCmlkIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjYzPTIyIE5hbWU9M0Q9
MjJNZWRpdW0gUz0NCmhhZGluZyAxIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY0PTIyIE5hbWU9M0Q9MjJNZWRpdW0gUz0N
CmhhZGluZyAyIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxz
ZT0yMiBQcmlvcml0eT0zRD0yMjY1PTIyIE5hbWU9M0Q9MjJNZWRpdW0gTD0NCmlzdCAxIEFjY2Vu
dCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0z
RD0yMjY2PTIyIE5hbWU9M0Q9MjJNZWRpdW0gTD0NCmlzdCAyIEFjY2VudCAyPTIyLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY3PTIyIE5hbWU9
M0Q9MjJNZWRpdW0gRz0NCnJpZCAxIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY4PTIyIE5hbWU9M0Q9MjJNZWRpdW0gRz0N
CnJpZCAyIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBQcmlvcml0eT0zRD0yMjY5PTIyIE5hbWU9M0Q9MjJNZWRpdW0gRz0NCnJpZCAzIEFjY2VudCAy
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0y
MjcwPTIyIE5hbWU9M0Q9MjJEYXJrIExpcz0NCnQgQWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNzE9MjIgTmFtZT0zRD0yMkNv
bG9yZnVsPQ0KIFNoYWRpbmcgQWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0z
RD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNzI9MjIgTmFtZT0zRD0yMkNvbG9yZnVsPQ0KIExp
c3QgQWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFBy
aW9yaXR5PTNEPTIyNzM9MjIgTmFtZT0zRD0yMkNvbG9yZnVsPQ0KIEdyaWQgQWNjZW50IDI9MjIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjA9
MjIgTmFtZT0zRD0yMkxpZ2h0IFNoPQ0KYWRpbmcgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjE9MjIgTmFtZT0zRD0yMkxp
Z2h0IExpPQ0Kc3QgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZh
bHNlPTIyIFByaW9yaXR5PTNEPTIyNjI9MjIgTmFtZT0zRD0yMkxpZ2h0IEdyPQ0KaWQgQWNjZW50
IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNE
PTIyNjM9MjIgTmFtZT0zRD0yMk1lZGl1bSBTPQ0KaGFkaW5nIDEgQWNjZW50IDM9MjIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjQ9MjIgTmFt
ZT0zRD0yMk1lZGl1bSBTPQ0KaGFkaW5nIDIgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjU9MjIgTmFtZT0zRD0yMk1lZGl1
bSBMPQ0KaXN0IDEgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZh
bHNlPTIyIFByaW9yaXR5PTNEPTIyNjY9MjIgTmFtZT0zRD0yMk1lZGl1bSBMPQ0KaXN0IDIgQWNj
ZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5
PTNEPTIyNjc9MjIgTmFtZT0zRD0yMk1lZGl1bSBHPQ0KcmlkIDEgQWNjZW50IDM9MjIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjg9MjIgTmFt
ZT0zRD0yMk1lZGl1bSBHPQ0KcmlkIDIgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjk9MjIgTmFtZT0zRD0yMk1lZGl1bSBH
PQ0KcmlkIDMgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNl
PTIyIFByaW9yaXR5PTNEPTIyNzA9MjIgTmFtZT0zRD0yMkRhcmsgTGlzPQ0KdCBBY2NlbnQgMz0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3
MT0yMiBOYW1lPTNEPTIyQ29sb3JmdWw9DQogU2hhZGluZyBBY2NlbnQgMz0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3Mj0yMiBOYW1lPTNE
PTIyQ29sb3JmdWw9DQogTGlzdCBBY2NlbnQgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3Mz0yMiBOYW1lPTNEPTIyQ29sb3JmdWw9DQog
R3JpZCBBY2NlbnQgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
UHJpb3JpdHk9M0Q9MjI2MD0yMiBOYW1lPTNEPTIyTGlnaHQgU2g9DQphZGluZyBBY2NlbnQgND0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2
MT0yMiBOYW1lPTNEPTIyTGlnaHQgTGk9DQpzdCBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2Mj0yMiBOYW1lPTNEPTIyTGln
aHQgR3I9DQppZCBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFs
c2U9MjIgUHJpb3JpdHk9M0Q9MjI2Mz0yMiBOYW1lPTNEPTIyTWVkaXVtIFM9DQpoYWRpbmcgMSBB
Y2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjI2ND0yMiBOYW1lPTNEPTIyTWVkaXVtIFM9DQpoYWRpbmcgMiBBY2NlbnQgND0yMi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2NT0y
MiBOYW1lPTNEPTIyTWVkaXVtIEw9DQppc3QgMSBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2Nj0yMiBOYW1lPTNEPTIyTWVk
aXVtIEw9DQppc3QgMiBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIy
ZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2Nz0yMiBOYW1lPTNEPTIyTWVkaXVtIEc9DQpyaWQgMSBB
Y2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjI2OD0yMiBOYW1lPTNEPTIyTWVkaXVtIEc9DQpyaWQgMiBBY2NlbnQgND0yMi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI2OT0yMiBO
YW1lPTNEPTIyTWVkaXVtIEc9DQpyaWQgMyBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3MD0yMiBOYW1lPTNEPTIyRGFyayBM
aXM9DQp0IEFjY2VudCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBQcmlvcml0eT0zRD0yMjcxPTIyIE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBTaGFkaW5nIEFjY2Vu
dCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0z
RD0yMjcyPTIyIE5hbWU9M0Q9MjJDb2xvcmZ1bD0NCiBMaXN0IEFjY2VudCA0PTIyLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjczPTIyIE5hbWU9
M0Q9MjJDb2xvcmZ1bD0NCiBHcmlkIEFjY2VudCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjYwPTIyIE5hbWU9M0Q9MjJMaWdodCBTaD0N
CmFkaW5nIEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBQcmlvcml0eT0zRD0yMjYxPTIyIE5hbWU9M0Q9MjJMaWdodCBMaT0NCnN0IEFjY2VudCA1PTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjYy
PTIyIE5hbWU9M0Q9MjJMaWdodCBHcj0NCmlkIEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjYzPTIyIE5hbWU9M0Q9MjJNZWRp
dW0gUz0NCmhhZGluZyAxIEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY0PTIyIE5hbWU9M0Q9MjJNZWRpdW0gUz0NCmhhZGlu
ZyAyIEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQ
cmlvcml0eT0zRD0yMjY1PTIyIE5hbWU9M0Q9MjJNZWRpdW0gTD0NCmlzdCAxIEFjY2VudCA1PTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY2
PTIyIE5hbWU9M0Q9MjJNZWRpdW0gTD0NCmlzdCAyIEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY3PTIyIE5hbWU9M0Q9MjJN
ZWRpdW0gRz0NCnJpZCAxIEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjY4PTIyIE5hbWU9M0Q9MjJNZWRpdW0gRz0NCnJpZCAy
IEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlv
cml0eT0zRD0yMjY5PTIyIE5hbWU9M0Q9MjJNZWRpdW0gRz0NCnJpZCAzIEFjY2VudCA1PTIyLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjcwPTIy
IE5hbWU9M0Q9MjJEYXJrIExpcz0NCnQgQWNjZW50IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNzE9MjIgTmFtZT0zRD0yMkNvbG9yZnVs
PQ0KIFNoYWRpbmcgQWNjZW50IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZh
bHNlPTIyIFByaW9yaXR5PTNEPTIyNzI9MjIgTmFtZT0zRD0yMkNvbG9yZnVsPQ0KIExpc3QgQWNj
ZW50IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5
PTNEPTIyNzM9MjIgTmFtZT0zRD0yMkNvbG9yZnVsPQ0KIEdyaWQgQWNjZW50IDU9MjIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjA9MjIgTmFt
ZT0zRD0yMkxpZ2h0IFNoPQ0KYWRpbmcgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjE9MjIgTmFtZT0zRD0yMkxpZ2h0IExp
PQ0Kc3QgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFByaW9yaXR5PTNEPTIyNjI9MjIgTmFtZT0zRD0yMkxpZ2h0IEdyPQ0KaWQgQWNjZW50IDY9MjIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjM9
MjIgTmFtZT0zRD0yMk1lZGl1bSBTPQ0KaGFkaW5nIDEgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjQ9MjIgTmFtZT0zRD0y
Mk1lZGl1bSBTPQ0KaGFkaW5nIDIgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjU9MjIgTmFtZT0zRD0yMk1lZGl1bSBMPQ0K
aXN0IDEgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFByaW9yaXR5PTNEPTIyNjY9MjIgTmFtZT0zRD0yMk1lZGl1bSBMPQ0KaXN0IDIgQWNjZW50IDY9
MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIy
Njc9MjIgTmFtZT0zRD0yMk1lZGl1bSBHPQ0KcmlkIDEgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjg9MjIgTmFtZT0zRD0y
Mk1lZGl1bSBHPQ0KcmlkIDIgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0z
RD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNjk9MjIgTmFtZT0zRD0yMk1lZGl1bSBHPQ0Kcmlk
IDMgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFBy
aW9yaXR5PTNEPTIyNzA9MjIgTmFtZT0zRD0yMkRhcmsgTGlzPQ0KdCBBY2NlbnQgNj0yMi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3MT0yMiBO
YW1lPTNEPTIyQ29sb3JmdWw9DQogU2hhZGluZyBBY2NlbnQgNj0yMi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3Mj0yMiBOYW1lPTNEPTIyQ29s
b3JmdWw9DQogTGlzdCBBY2NlbnQgNj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIy
ZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI3Mz0yMiBOYW1lPTNEPTIyQ29sb3JmdWw9DQogR3JpZCBB
Y2NlbnQgNj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjIxOT0yMiBRRm9ybWF0PTNEPTIydHJ1ZT0NCj0yMiBOYW1lPTNEPTIyU3VidGxlIEVt
cGhhc2lzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0
eT0zRD0yMjIxPTIyIFFGb3JtYXQ9M0Q9MjJ0cnVlPQ0KPTIyIE5hbWU9M0Q9MjJJbnRlbnNlIEVt
cGhhc2lzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0
eT0zRD0yMjMxPTIyIFFGb3JtYXQ9M0Q9MjJ0cnVlPQ0KPTIyIE5hbWU9M0Q9MjJTdWJ0bGUgUmVm
ZXJlbmNlPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0
eT0zRD0yMjMyPTIyIFFGb3JtYXQ9M0Q9MjJ0cnVlPQ0KPTIyIE5hbWU9M0Q9MjJJbnRlbnNlIFJl
ZmVyZW5jZT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjIzMz0yMiBRRm9ybWF0PTNEPTIydHJ1ZT0NCj0yMiBOYW1lPTNEPTIyQm9vayBUaXRs
ZT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9
MjIzNz0yMiBTZW1pSGlkZGVuPTNEPTIydHI9DQp1ZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRy
dWU9MjIgTmFtZT0zRD0yMkJpYmxpb2dyYXBoeT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjIzOT0yMiBTZW1pSGlkZGVuPTNEPTIydHI9DQp1
ZT0yMiBVbmhpZGVXaGVuVXNlZD0zRD0yMnRydWU9MjIgUUZvcm1hdD0zRD0yMnRydWU9MjIgTmFt
ZT0zRD0yMlRPQyBIZWFkaW49DQpnPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBQcmlvcml0eT0zRD0yMjQxPTIyIE5hbWU9M0Q9MjJQbGFpbiBUYT0NCmJsZSAxPTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQy
PTIyIE5hbWU9M0Q9MjJQbGFpbiBUYT0NCmJsZSAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQzPTIyIE5hbWU9M0Q9MjJQbGFpbiBUYT0N
CmJsZSAzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0
eT0zRD0yMjQ0PTIyIE5hbWU9M0Q9MjJQbGFpbiBUYT0NCmJsZSA0PTIyLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ1PTIyIE5hbWU9M0Q9MjJQ
bGFpbiBUYT0NCmJsZSA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBQcmlvcml0eT0zRD0yMjQwPTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIExpZ2h0PTIyLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ2PTIy
IE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDEgTGlnaHQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDc9MjIgTmFtZT0zRD0yMkdyaWQgVGFi
PQ0KbGUgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjI0OD0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSAzPTIyLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ5PTIyIE5hbWU9M0Q9MjJH
cmlkIFRhYj0NCmxlIDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFByaW9yaXR5PTNEPTIyNTA9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgNSBEYXJrPTIyLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUxPTIy
IE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDYgQ29sb3JmdWw9MjIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTI9MjIgTmFtZT0zRD0yMkdyaWQg
VGFiPQ0KbGUgNyBDb2xvcmZ1bD0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFs
c2U9MjIgUHJpb3JpdHk9M0Q9MjI0Nj0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSAxIExpZ2h0
IEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlv
cml0eT0zRD0yMjQ3PTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDIgQWNjZW50IDE9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDg9MjIg
TmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgMyBBY2NlbnQgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0OT0yMiBOYW1lPTNEPTIyR3JpZCBU
YWI9DQpsZSA0IEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxz
ZT0yMiBQcmlvcml0eT0zRD0yMjUwPTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDUgRGFyayBB
Y2NlbnQgMT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjI1MT0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSA2IENvbG9yZnVsIEFjY2VudCAx
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0y
MjUyPTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDcgQ29sb3JmdWwgQWNjZW50IDE9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDY9MjIg
TmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgMSBMaWdodCBBY2NlbnQgMj0yMi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0Nz0yMiBOYW1lPTNEPTIy
R3JpZCBUYWI9DQpsZSAyIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ4PTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDMg
QWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9y
aXR5PTNEPTIyNDk9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgNCBBY2NlbnQgMj0yMi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1MD0yMiBO
YW1lPTNEPTIyR3JpZCBUYWI9DQpsZSA1IERhcmsgQWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTE9MjIgTmFtZT0zRD0yMkdy
aWQgVGFiPQ0KbGUgNiBDb2xvcmZ1bCBBY2NlbnQgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1Mj0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9
DQpsZSA3IENvbG9yZnVsIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ2PTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDEg
TGlnaHQgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFByaW9yaXR5PTNEPTIyNDc9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgMiBBY2NlbnQgMz0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0
OD0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSAzIEFjY2VudCAzPTIyLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ5PTIyIE5hbWU9M0Q9MjJH
cmlkIFRhYj0NCmxlIDQgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0y
MmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTA9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgNSBE
YXJrIEFjY2VudCAzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQ
cmlvcml0eT0zRD0yMjUxPTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDYgQ29sb3JmdWwgQWNj
ZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5
PTNEPTIyNTI9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgNyBDb2xvcmZ1bCBBY2NlbnQgMz0y
Mi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0
Nj0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSAxIExpZ2h0IEFjY2VudCA0PTIyLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ3PTIyIE5hbWU9
M0Q9MjJHcmlkIFRhYj0NCmxlIDIgQWNjZW50IDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDg9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0K
bGUgMyBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIg
UHJpb3JpdHk9M0Q9MjI0OT0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSA0IEFjY2VudCA0PTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUw
PTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDUgRGFyayBBY2NlbnQgND0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1MT0yMiBOYW1lPTNE
PTIyR3JpZCBUYWI9DQpsZSA2IENvbG9yZnVsIEFjY2VudCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUyPTIyIE5hbWU9M0Q9MjJHcmlk
IFRhYj0NCmxlIDcgQ29sb3JmdWwgQWNjZW50IDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDY9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0K
bGUgMSBMaWdodCBBY2NlbnQgNT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFs
c2U9MjIgUHJpb3JpdHk9M0Q9MjI0Nz0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSAyIEFjY2Vu
dCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0z
RD0yMjQ4PTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDMgQWNjZW50IDU9MjIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDk9MjIgTmFtZT0z
RD0yMkdyaWQgVGFiPQ0KbGUgNCBBY2NlbnQgNT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1MD0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQps
ZSA1IERhcmsgQWNjZW50IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNl
PTIyIFByaW9yaXR5PTNEPTIyNTE9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgNiBDb2xvcmZ1
bCBBY2NlbnQgNT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJp
b3JpdHk9M0Q9MjI1Mj0yMiBOYW1lPTNEPTIyR3JpZCBUYWI9DQpsZSA3IENvbG9yZnVsIEFjY2Vu
dCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0z
RD0yMjQ2PTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDEgTGlnaHQgQWNjZW50IDY9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDc9MjIg
TmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgMiBBY2NlbnQgNj0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0OD0yMiBOYW1lPTNEPTIyR3JpZCBU
YWI9DQpsZSAzIEFjY2VudCA2PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxz
ZT0yMiBQcmlvcml0eT0zRD0yMjQ5PTIyIE5hbWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDQgQWNjZW50
IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNE
PTIyNTA9MjIgTmFtZT0zRD0yMkdyaWQgVGFiPQ0KbGUgNSBEYXJrIEFjY2VudCA2PTIyLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUxPTIyIE5h
bWU9M0Q9MjJHcmlkIFRhYj0NCmxlIDYgQ29sb3JmdWwgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTI9MjIgTmFtZT0zRD0y
MkdyaWQgVGFiPQ0KbGUgNyBDb2xvcmZ1bCBBY2NlbnQgNj0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0Nj0yMiBOYW1lPTNEPTIyTGlzdCBU
YWI9DQpsZSAxIExpZ2h0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0y
MiBQcmlvcml0eT0zRD0yMjQ3PTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDI9MjIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDg9MjIgTmFt
ZT0zRD0yMkxpc3QgVGFiPQ0KbGUgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIy
ZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0OT0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSA0PTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUw
PTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDUgRGFyaz0yMi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1MT0yMiBOYW1lPTNEPTIyTGlzdCBU
YWI9DQpsZSA2IENvbG9yZnVsPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxz
ZT0yMiBQcmlvcml0eT0zRD0yMjUyPTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDcgQ29sb3Jm
dWw9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNE
PTIyNDY9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgMSBMaWdodCBBY2NlbnQgMT0yMi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0Nz0yMiBO
YW1lPTNEPTIyTGlzdCBUYWI9DQpsZSAyIEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ4PTIyIE5hbWU9M0Q9MjJMaXN0IFRh
Yj0NCmxlIDMgQWNjZW50IDE9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNl
PTIyIFByaW9yaXR5PTNEPTIyNDk9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgNCBBY2NlbnQg
MT0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9
MjI1MD0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSA1IERhcmsgQWNjZW50IDE9MjIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTE9MjIgTmFt
ZT0zRD0yMkxpc3QgVGFiPQ0KbGUgNiBDb2xvcmZ1bCBBY2NlbnQgMT0yMi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1Mj0yMiBOYW1lPTNEPTIy
TGlzdCBUYWI9DQpsZSA3IENvbG9yZnVsIEFjY2VudCAxPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ2PTIyIE5hbWU9M0Q9MjJMaXN0IFRh
Yj0NCmxlIDEgTGlnaHQgQWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0y
MmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDc9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgMiBB
Y2NlbnQgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjI0OD0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSAzIEFjY2VudCAyPTIyLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ5PTIyIE5h
bWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDQgQWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTA9MjIgTmFtZT0zRD0yMkxpc3QgVGFi
PQ0KbGUgNSBEYXJrIEFjY2VudCAyPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJm
YWxzZT0yMiBQcmlvcml0eT0zRD0yMjUxPTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDYgQ29s
b3JmdWwgQWNjZW50IDI9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIy
IFByaW9yaXR5PTNEPTIyNTI9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgNyBDb2xvcmZ1bCBB
Y2NlbnQgMj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3Jp
dHk9M0Q9MjI0Nj0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSAxIExpZ2h0IEFjY2VudCAzPTIy
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ3
PTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDIgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDg9MjIgTmFtZT0zRD0yMkxp
c3QgVGFiPQ0KbGUgMyBBY2NlbnQgMz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIy
ZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0OT0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSA0IEFj
Y2VudCAzPTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0
eT0zRD0yMjUwPTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDUgRGFyayBBY2NlbnQgMz0yMi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1MT0y
MiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSA2IENvbG9yZnVsIEFjY2VudCAzPTIyLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUyPTIyIE5hbWU9
M0Q9MjJMaXN0IFRhYj0NCmxlIDcgQ29sb3JmdWwgQWNjZW50IDM9MjIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDY9MjIgTmFtZT0zRD0yMkxp
c3QgVGFiPQ0KbGUgMSBMaWdodCBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0Nz0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQps
ZSAyIEFjY2VudCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQ
cmlvcml0eT0zRD0yMjQ4PTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDMgQWNjZW50IDQ9MjIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNDk9
MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgNCBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1MD0yMiBOYW1lPTNEPTIyTGlz
dCBUYWI9DQpsZSA1IERhcmsgQWNjZW50IDQ9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0z
RD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTE9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUg
NiBDb2xvcmZ1bCBBY2NlbnQgND0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFs
c2U9MjIgUHJpb3JpdHk9M0Q9MjI1Mj0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSA3IENvbG9y
ZnVsIEFjY2VudCA0PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQ
cmlvcml0eT0zRD0yMjQ2PTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDEgTGlnaHQgQWNjZW50
IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNE
PTIyNDc9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgMiBBY2NlbnQgNT0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0OD0yMiBOYW1lPTNE
PTIyTGlzdCBUYWI9DQpsZSAzIEFjY2VudCA1PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ5PTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxl
IDQgQWNjZW50IDU9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFBy
aW9yaXR5PTNEPTIyNTA9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgNSBEYXJrIEFjY2VudCA1
PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0y
MjUxPTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDYgQ29sb3JmdWwgQWNjZW50IDU9MjIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFByaW9yaXR5PTNEPTIyNTI9MjIg
TmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgNyBDb2xvcmZ1bCBBY2NlbnQgNT0yMi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI0Nj0yMiBOYW1lPTNE
PTIyTGlzdCBUYWI9DQpsZSAxIExpZ2h0IEFjY2VudCA2PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjQ3PTIyIE5hbWU9M0Q9MjJMaXN0IFRh
Yj0NCmxlIDIgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNl
PTIyIFByaW9yaXR5PTNEPTIyNDg9MjIgTmFtZT0zRD0yMkxpc3QgVGFiPQ0KbGUgMyBBY2NlbnQg
Nj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9
MjI0OT0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9DQpsZSA0IEFjY2VudCA2PTIyLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9M0Q9MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUwPTIyIE5hbWU9M0Q9
MjJMaXN0IFRhYj0NCmxlIDUgRGFyayBBY2NlbnQgNj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPTNEPTIyZmFsc2U9MjIgUHJpb3JpdHk9M0Q9MjI1MT0yMiBOYW1lPTNEPTIyTGlzdCBUYWI9
DQpsZSA2IENvbG9yZnVsIEFjY2VudCA2PTIyLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Q9
MjJmYWxzZT0yMiBQcmlvcml0eT0zRD0yMjUyPTIyIE5hbWU9M0Q9MjJMaXN0IFRhYj0NCmxlIDcg
Q29sb3JmdWwgQWNjZW50IDY9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNl
PTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0y
MiBOYW1lPTNEPTIyTWVudGlvbj0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEPTIyZmFs
c2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9DQo9M0Q9MjJ0cnVl
PTIyIE5hbWU9M0Q9MjJTbWFydCBIeXBlcmxpbms9MjIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVuaGlkZVdoZW5Vc2VkPQ0K
PTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIySGFzaHRhZz0yMi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPTNEPTIyZmFsc2U9MjIgU2VtaUhpZGRlbj0zRD0yMnRydWU9MjIgVW5oaWRlV2hlblVzZWQ9
DQo9M0Q9MjJ0cnVlPTIyIE5hbWU9M0Q9MjJVbnJlc29sdmVkIE1lbnRpb249MjIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0zRD0yMmZhbHNlPTIyIFNlbWlIaWRkZW49M0Q9MjJ0cnVlPTIyIFVu
aGlkZVdoZW5Vc2VkPQ0KPTNEPTIydHJ1ZT0yMiBOYW1lPTNEPTIyU21hcnQgTGluaz0yMi8+DQo8
L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PD0yMT01QmVuZGlmPTVELS0+PD0yMS0tPTVCaWYgZ3Rl
IG1zbyAxMD01RD48PTIxPTVCZW5kaWY9NUQtLT48PTIxLS09DQo9NUJpZiBndGUgbXNvIDk9NUQ+
PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9M0Q9MjJlZGl0PTIyIHNwaWRtYXg9M0Q9MjIx
MDI2PTIyIC8+DQo8L3htbD48PTIxPTVCZW5kaWY9NUQtLT48PTIxLS09NUJpZiBndGUgbXNvIDk9
NUQ+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PTNEPTIyZWRpdD0yMj4NCjxvOmlkbWFwIHY6
ZXh0PTNEPTIyZWRpdD0yMiBkYXRhPTNEPTIyMT0yMiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s
Pjw9MjE9NUJlbmRpZj01RC0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0zRD0yMkZSPTIyIGxpbms9
M0Q9MjI9MjMwNTYzQzE9MjIgdmxpbms9M0Q9MjI9MjM5NTRGNzI9MjIgc3R5bGU9DQo9M0Q9MjJ0
YWItaW50ZXJ2YWw6MzUuNHB0O3dvcmQtd3JhcDpicmVhay13b3JkPTIyPjxkaXYgY2xhc3M9M0Q9
MjJyaWNoX2h0bWw9DQpfY29udGVudD0yMiBzdHlsZT0zRD0yMmNvbG9yOiByZ2IoMCwgMCwgMCk7
IHdvcmQtd3JhcDogYnJlYWstd29yZDs9MjI+PHNwYW49DQogc3R5bGU9M0Q9MjJmb250LXNpemU6
IDExcHQ7PTIyPjxmb250IHN0eWxlPTNEPTIyZm9udC1mYW1pbHk6ID1FNT1CRT1BRT1FOD0NCj1C
RD1BRj1FOT05Qj04NT1FOT1CQj05MTs9MjI+SGk9MjBXRz1FRj1CQz04QzwvZm9udD48L3NwYW4+
PC9kaXY+PGRpdj0yMGNsYT0NCnNzPTNEPTIycmljaF9odG1sX2NvbnRlbnQ9MjI9MjBzdHlsZT0z
RD0yMmNvbG9yOj0yMHJnYigwLD0yMDAsPTIwMCk7PTIwd29yZD0NCi13cmFwOj0yMGJyZWFrLXdv
cmQ7PTIyPjxzcGFuPTIwc3R5bGU9M0Q9MjJmb250LXNpemU6PTIwMTFwdDs9MjI+PGZvbnQ9MjBz
dD0NCnlsZT0zRD0yMmZvbnQtZmFtaWx5Oj0yMD1FNT1CRT1BRT1FOD1CRD1BRj1FOT05Qj04NT1F
OT1CQj05MTs9MjI+PGJyPjwvZm9udD0NCj48L3NwYW4+PC9kaXY+PGRpdj0yMGNsYXNzPTNEPTIy
cmljaF9odG1sX2NvbnRlbnQ9MjI9MjBzdHlsZT0zRD0yMmNvbG9yOj0yMD0NCnJnYigwLD0yMDAs
PTIwMCk7PTIwd29yZC13cmFwOj0yMGJyZWFrLXdvcmQ7PTIyPjxzcGFuPTIwc3R5bGU9M0Q9MjJm
b250LXNpej0NCmU6PTIwMTFwdDs9MjI+PGZvbnQ9MjBzdHlsZT0zRD0yMmZvbnQtZmFtaWx5Oj0y
MD1FNT1CRT1BRT1FOD1CRD1BRj1FOT05Qj04NT0NCj1FOT1CQj05MTs9MjI+Jm5ic3A7PTIwJm5i
c3A7Jm5ic3A7SSdtPTIwbm90PTIwYXdhcmU9MjBvZj0yMGFueT0yMHVuZGlzY2xvcz0NCmVkPTIw
SVBSPTIwcmVsYXRlZD0yMHRvPTIwdGhpcz0yMGRyYWZ0LjwvZm9udD48L3NwYW4+PC9kaXY+PGRp
dj0yMGNsYXNzPTNEPQ0KPTIycmljaF9odG1sX2NvbnRlbnQ9MjI9MjBzdHlsZT0zRD0yMmNvbG9y
Oj0yMHJnYigwLD0yMDAsPTIwMCk7PTIwd29yZC13cmFwPQ0KOj0yMGJyZWFrLXdvcmQ7PTIyPjxz
cGFuPTIwc3R5bGU9M0Q9MjJmb250LXNpemU6PTIwMTFwdDs9MjI+PGZvbnQ9MjBzdHlsZT0NCj0z
RD0yMmZvbnQtZmFtaWx5Oj0yMD1FNT1CRT1BRT1FOD1CRD1BRj1FOT05Qj04NT1FOT1CQj05MTs9
MjI+PGJyPjwvZm9udD48Lz0NCnNwYW4+PC9kaXY+PGRpdj0yMGNsYXNzPTNEPTIycmljaF9odG1s
X2NvbnRlbnQ9MjI9MjBzdHlsZT0zRD0yMmNvbG9yOj0yMHJnYj0NCigwLD0yMDAsPTIwMCk7PTIw
d29yZC13cmFwOj0yMGJyZWFrLXdvcmQ7PTIyPjxzcGFuPTIwc3R5bGU9M0Q9MjJmb250LXNpemU6
PQ0KPTIwMTFwdDs9MjI+PGZvbnQ9MjBzdHlsZT0zRD0yMmZvbnQtZmFtaWx5Oj0yMD1FNT1CRT1B
RT1FOD1CRD1BRj1FOT05Qj04NT0NCj1FOT1CQj05MTs9MjI+QmVzdD0yMFJlZ2FyZHM8L2ZvbnQ+
PC9zcGFuPjwvZGl2PjxkaXY9MjBjbGFzcz0zRD0yMnJpY2hfaHRtbD0NCl9jb250ZW50PTIyPTIw
c3R5bGU9M0Q9MjJjb2xvcjo9MjByZ2IoMCw9MjAwLD0yMDApOz0yMHdvcmQtd3JhcDo9MjBicmVh
ay13bz0NCnJkOz0yMj48c3Bhbj0yMHN0eWxlPTNEPTIyZm9udC1zaXplOj0yMDExcHQ7PTIyPjxm
b250PTIwc3R5bGU9M0Q9MjJmb250LWZhbT0NCmlseTo9MjA9RTU9QkU9QUU9RTg9QkQ9QUY9RTk9
OUI9ODU9RTk9QkI9OTE7PTIyPllpc29uZzwvZm9udD48L3NwYW4+PC9kaXY+PD0NCmRpdj0yMGNs
YXNzPTNEPTIycmljaF9odG1sX2NvbnRlbnQ9MjI9MjBzdHlsZT0zRD0yMmNvbG9yOj0yMzAwMDAw
MDs9MjBmb250LT0NClNpemU6MTJwdDs9MjBmb250LWZhbWlseTo9RTU9QkU9QUU9RTg9QkQ9QUY9
RTk9OUI9ODU9RTk9QkI9OTE7PTIwd29yZC13cmFwOj0NCmJyZWFrLXdvcmQ7eC1vdmVyZmxvdzpo
aWRkZW47PTIyPjxicj48L2Rpdj48ZGl2PTIwaWQ9M0Q9MjJTSUdOTkFNRTUxNTI5PTIyPj0NCjwv
ZGl2PjxkaXY+PHNwYW49MjBpZD0zRD0yMl9USElOS01BSUxOQU1FNTE1Mjk9MjI9MjBmb250LXNp
emU6MTJwdDtmb250LWZhbT0NCmlseTptaWNyb3NvZnQ9M0Q9MjI9MjI9MjB5YWhlaTs9M0Q9MjI9
MjI+PGRpdj0yMGlkPTNEPTIyU0lHTk5BTUU1MTUyOT0yMj48Lz0NCmRpdj48ZGl2PjxzcGFuPTIw
aWQ9M0Q9MjJfVEhJTktNQUlMTkFNRTUxNTI5PTIyPTIwZm9udC1zaXplOjEycHQ7Zm9udC1mYW1p
bD0NCnk6bWljcm9zb2Z0PTNEPTIyPTIyPTIweWFoZWk7PTNEPTIyPTIyPjwvc3Bhbj48L2Rpdj48
L3NwYW4+PC9kaXY+PGJsb2NrcXVvdD0NCmU9MjBzdHlsZT0zRD0yMm1hcmdpbi10b3A6PTIwMHB4
Oz0yMG1hcmdpbi1ib3R0b206PTIwMHB4Oz0yMG1hcmdpbi1sZWZ0Oj0yMD0NCjAuNWVtOz0yMj48
ZGl2PiZuYnNwOzwvZGl2PjxkaXY9MjBzdHlsZT0zRD0yMmJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQ9DQo9MjA9MjNCNUM0REY9MjAxLjBwdDtwYWRkaW5nOjMuMHB0PTIwMGNtPTIwMGNtPTIw
MGNtPTIyPjxtZXRhPTIwY2hhcnNldD0zRD0NCj0yMlVURi04PTIyPjxkaXY9MjBzdHlsZT0zRD0y
MmNvbG9yOj0yMzMzMzMzMzs9MjBmb250LVNpemU6MTJwdDtmb250LWZhbWlseT0NCjpNaWNyb3Nv
ZnQ9MjBZYUhlaTs9MjI+PUU1PThGPTkxPUU0PUJCPUI2PUU0PUJBPUJBOj0yMDxhPTIwaHJlZj0z
RD0yMm1haWx0bz0NCjpicnVuby5kZWNyYWVuZT00MG9yYW5nZS5jb209MjI+YnJ1bm8uZGVjcmFl
bmU8L2E+PC9kaXY+PGRpdj0yMHN0eWxlPTNEPTIyYz0NCm9sb3I6PTIzMzMzMzMzOz0yMGZvbnQt
U2l6ZToxMnB0O2ZvbnQtZmFtaWx5Ok1pY3Jvc29mdD0yMFlhSGVpOz0yMj49RTY9OTc9DQo9QjY9
RTk9OTc9QjQ6PTIwMjAyMi8wMS8xMyg9RTY9OTg9OUY9RTY9OUM9OUY9RTU9OUI9OUIpMTg6MTc8
L2Rpdj48ZGl2PTIwc3Q9DQp5bGU9M0Q9MjJjb2xvcjo9MjMzMzMzMzM7PTIwZm9udC1TaXplOjEy
cHQ7Zm9udC1mYW1pbHk6TWljcm9zb2Z0PTIwWWFIZWk7PQ0KPTIyPj1FNj05ND1CNj1FND1CQj1C
Nj1FND1CQT1CQTo9MjA8YT0yMGhyZWY9M0Q9MjJtYWlsdG86c3ByaW5nPTQwaWV0Zi5vcmc9DQo9
MjI+U1BSSU5HPTIwV0c8L2E+OzxhPTIwaHJlZj0zRD0yMm1haWx0bzpkcmFmdC1odS1zcHJpbmct
c2VnbWVudC1yb3V0aW5nLXA9DQpyb3h5LWZvcndhcmRpbmc9NDBpZXRmLm9yZz0yMj5kcmFmdC1o
dS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmQ9DQppbmc8L2E+OzwvZGl2Pjxk
aXY9MjBzdHlsZT0zRD0yMmNvbG9yOj0yMzMzMzMzMzs9MjBmb250LVNpemU6MTJwdDtmb250LWZh
bWk9DQpseTpNaWNyb3NvZnQ9MjBZYUhlaTs9MjI+PUU0PUI4PUJCPUU5PUEyPTk4Oj0yMElQUj0y
MHBvbGw9MjAtPTIwZHJhZnQtaHUtc3A9DQpyaW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1mb3J3
YXJkaW5nPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPj0wQTxkaXY9MjBjbGE9DQpzcz0zRD0yMldv
cmRTZWN0aW9uMT0yMj0yMHN0eWxlPTNEPTIycGFnZTpXb3JkU2VjdGlvbjE7PTIyPj0wQTxwPTIw
Y2xhc3M9M0Q9DQo9MjJNc29Ob3JtYWw9MjI+PHNwYW49MjBsYW5nPTNEPTIyRU4tVVM9MjI9MjBz
dHlsZT0zRD0yMmZvbnQtc2l6ZToxMC4wcHQ7Zm89DQpudC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUz0yMj5IaT0yMGF1dGg9DQpvcnMs
PTIwY29udHJpYnV0b3JzLD0yMFdHPG86cD48L286cD48L3NwYW4+PC9wPj0wQTxwPTIwY2xhc3M9
M0Q9MjJNc29Ob3JtYWw9DQo9MjI+PHNwYW49MjBsYW5nPTNEPTIyRU4tVVM9MjI9MjBzdHlsZT0z
RD0yMmZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnE9DQp1b3Q7QXJpYWwmcXVvdDssc2Fu
cy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUz0yMj48bzpwPiZuYnNwOzwvbzpwPjwvc3A9
DQphbj48L3A+PTBBPHA9MjBjbGFzcz0zRD0yMk1zb05vcm1hbD0yMj48c3Bhbj0yMGxhbmc9M0Q9
MjJFTi1VUz0yMj0yMHN0eWxlPQ0KPTNEPTIyZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhPQ0Kbmd1YWdlOkVOLVVTPTIy
PkluPTIwcHJlcGFyYXRpb249MjBvZj0yMHRoZT0yMFdHPTIwYWRvcHRpb249MjBjYWxsPTIwb249
MjBkPQ0KcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmc9MjA9
NUIxPTVELD0yMHRoaXM9MjBlbWFpbD0NCj0yMHN0YXJ0cz0yMGE9MjBwb2xsPTIwZm9yPTIwSVBS
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD49MEE8cD0yMGNsYXNzPTNEPTIyTT0NCnNvTm9ybWFsPTIy
PjxzcGFuPTIwbGFuZz0zRD0yMkVOLVVTPTIyPTIwc3R5bGU9M0Q9MjJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZj0NCmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWFuc2ktbGFu
Z3VhZ2U6RU4tVVM9MjI+PG86cD4mbmJzcDs8Lz0NCm86cD48L3NwYW4+PC9wPj0wQTxwPTIwY2xh
c3M9M0Q9MjJNc29Ob3JtYWw9MjI+PHNwYW49MjBsYW5nPTNEPTIyRU4tVVM9MjI9DQo9MjBzdHls
ZT0zRD0yMmZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu
cy1zZXJpZjttc289DQotYW5zaS1sYW5ndWFnZTpFTi1VUz0yMj5JZj0yMHlvdT0yMGFyZT0yMGFu
PTIwYXV0aG9yPTIwb3I9MjBjb250cmlidXRvcj0yMHQ9DQpvPTIwdGhlPTIwc3ViamVjdD0yMGRv
Y3VtZW50LD0yMHBsZWFzZT0yMHJlc3BvbmQ9MjB0bz0yMHRoaXM9MjBlbWFpbC48bzpwPjw9DQov
bzpwPjwvc3Bhbj48L3A+PTBBPHVsPTIwc3R5bGU9M0Q9MjJtYXJnaW4tdG9wOjBjbT0yMj0yMHR5
cGU9M0Q9MjJkaXNjPTIyPj0NCj0wQTxsaT0yMGNsYXNzPTNEPTIyTXNvTGlzdFBhcmFncmFwaD0y
Mj0yMHN0eWxlPTNEPTIybWFyZ2luLWxlZnQ6MGNtO21zby1saT0NCnN0OmwwPTIwbGV2ZWwxPTIw
bGZvMj0yMj48c3Bhbj0yMGxhbmc9M0Q9MjJFTi1VUz0yMj0yMHN0eWxlPTNEPTIyZm9udC1zaXpl
Oj0NCjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1h
bnNpLWxhbmd1YWdlOkVOLVVTPTIyPj0NCkluPTIweW91cj0yMHJlc3BvbnNlLD0yMHBsZWFzZT0y
MGluZGljYXRlPTIwaWY9MjBhbGw9MjByZWxldmFudD0yMElQUj0yMGhhcz0NCj0yMGJlZW49MjBk
aXNjbG9zZWQuPHNwYW49MjBzdHlsZT0zRD0yMm1zby10YWItY291bnQ6NT0yMj4mbmJzcDsmbmJz
cDsmbmJzcD0NCjsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbj0NCmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcD0NCjsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbj0NCmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs9MEE8L3Nw
YW4+PG86cD48L286cD48L3NwYW4+PC9saT48bGk9MjBjbD0NCmFzcz0zRD0yMk1zb0xpc3RQYXJh
Z3JhcGg9MjI9MjBzdHlsZT0zRD0yMm1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMD0yMGxldj0N
CmVsMT0yMGxmbzI9MjI+PHNwYW49MjBsYW5nPTNEPTIyRU4tVVM9MjI9MjBzdHlsZT0zRD0yMmZv
bnQtc2l6ZToxMC4wcHQ7Zm9udD0NCi1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp
Zjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUz0yMj5JZj0yMHlvdT0yMD0NCmtub3c9MjBvZj0yMHJl
bGV2YW50PTIwSVBSPTIwdGhhdD0yMGhhcz0yMG5vdD0yMGJlZW49MjBkaXNjbG9zZWQsPTIwcGxl
YXNlPQ0KPTIwc3RhdGU9MjB0aGF0PTIwYW5kPTIwZGVzY3JpYmU9MEE9MjBob3c9MjB0aGlzPTIw
Z2FwPTIwaXM9MjBiZWluZz0yMGFkZHJlPQ0Kc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwv
dWw+PTBBPHA9MjBjbGFzcz0zRD0yMk1zb05vcm1hbD0yMj48c3Bhbj0yMGxhPQ0Kbmc9M0Q9MjJF
Ti1VUz0yMj0yMHN0eWxlPTNEPTIyZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90PQ0KOyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTPTIyPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD49MEE8cD0NCj0yMGNsYXNzPTNEPTIyTXNvTm9ybWFsPTIy
PjxzcGFuPTIwbGFuZz0zRD0yMkVOLVVTPTIyPTIwc3R5bGU9M0Q9MjJmb250LXNpej0NCmU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWFuc2ktbGFu
Z3VhZ2U6RU4tVVM9DQo9MjI+RXZlbj0yMGlmPTIweW91PTIwYXJlPTIwbm90PTIwYT0yMGNvbnRy
aWJ1dG9yPTIwb3I9MjBhdXRob3IsPTIwaWY9MjB5b3U9DQo9MjBrbm93PTIwb2Y9MjByZWxldmFu
dD0yMElQUiw9MjBwbGVhc2U9MjBlbnN1cmU9MjB0aGF0PTIwaXQ9MjBoYXM9MjBiZWVuPQ0KPTBB
PHNwYW49MjBjbGFzcz0zRD0yMlNwZWxsRT0yMj0yMHN0eWxlPTNEPTIybXNvLXNwbC1lOnllcztt
c28tc3R5bGUtbmFtZTomPQ0KcXVvdDsmcXVvdDs7PTIyPmRpc2xvc2VkPC9zcGFuPj0yMGFzPTIw
ZGlzY3Vzc2VkPTIwaW49MjBCQ1A9MjA3OS48bzpwPjwvbzpwPQ0KPjwvc3Bhbj48L3A+PTBBPHA9
MjBjbGFzcz0zRD0yMk1zb05vcm1hbD0yMj48c3Bhbj0yMGxhbmc9M0Q9MjJFTi1VUz0yMj0yMHN0
PQ0KeWxlPTNEPTIyZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OyxzYW5zLXNlcmlmO21zby1hbnNpPQ0KLWxhbmd1YWdlOkVOLVVTPTIyPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD49MEE8cD0yMGNsYXNzPTNEPTIyTXNvTm9ybWFsPQ0KPTIyPjxzcGFuPTIw
bGFuZz0zRD0yMkVOLVVTPTIyPTIwc3R5bGU9M0Q9MjJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxPQ0KdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t
VVM9MjI+SWY9MjB5b3U9MjBrbm93PTIwb2Y9DQo9MjBzb21lb25lPTIwZWxzZT0yMElQUj0yMHRo
YXQ9MjB5b3U9MjBiZWxpZXZlPTIwaXM9MjByZWxldmFudD0yMGFuZD0yMG5vdD0NCj0yMGRpc2Ns
b3NlZCw9MjBwbGVhc2U9MjBmaWxlPTIwYT0yMHRoaXJkPTIwcGFydHk9MjBJUFI9MjBkaXNjbG9z
dXJlLjxvOnA+PD0NCi9vOnA+PC9zcGFuPjwvcD49MEE8cD0yMGNsYXNzPTNEPTIyTXNvTm9ybWFs
PTIyPjxzcGFuPTIwbGFuZz0zRD0yMkVOLVVTPTIyPQ0KPTIwc3R5bGU9M0Q9MjJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvPQ0KLWFu
c2ktbGFuZ3VhZ2U6RU4tVVM9MjI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPj0wQTxwPTIw
Y2xhc3M9M0Q9MjJNc29OPQ0Kb3JtYWw9MjI+PHNwYW49MjBsYW5nPTNEPTIyRU4tVVM9MjI9MjBz
dHlsZT0zRD0yMmZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pPQ0KbHk6JnF1b3Q7QXJpYWwmcXVv
dDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUz0yMj5UaGFua3MsPG86cD48L286
PQ0KcD48L3NwYW4+PC9wPj0wQTxwPTIwY2xhc3M9M0Q9MjJNc29Ob3JtYWw9MjI+PHNwYW49MjBs
YW5nPTNEPTIyRU4tVVM9MjI9MjBzPQ0KdHlsZT0zRD0yMmZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zPQ0KaS1sYW5ndWFnZTpF
Ti1VUz0yMj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD49MEE8cD0yMGNsYXNzPTNEPTIy
TXNvTm9yPQ0KbWFsPTIyPjxzcGFuPTIwbGFuZz0zRD0yMkVOLVVTPTIyPTIwc3R5bGU9M0Q9MjJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5PQ0KOiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWY7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVM9MjI+QnJ1bm8sPTIwSmltLD0yMEpvPQ0KZWw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+PTBBPHA9MjBjbGFzcz0zRD0yMk1zb05vcm1hbD0yMj48c3Bhbj0y
MGxhbmc9M0Q9MjJFPQ0KTi1VUz0yMj0yMHN0eWxlPTNEPTIyZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlPQ0KcmlmO21zby1hbnNpLWxhbmd1YWdl
OkVOLVVTPTIyPj01QjE9NUQ8c3Bhbj0yMHN0eWxlPTNEPTIybXNvLXRhYi1jb3VudDoxPTIyPQ0K
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOz0wQTwvc3Bhbj5odHRw
czovL2RhdGF0cmFja2VyLmllPQ0KdGYub3JnL2RvYy9kcmFmdC1odS1zcHJpbmctc2VnbWVudC1y
b3V0aW5nLXByb3h5LWZvcndhcmRpbmcvPHNwYW49MjBzdHlsZT0NCj0zRD0yMm1zby10YWItY291
bnQ6ND0yMj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bj0NCmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcD0NCjsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbj0NCmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs9MEE8Lz0NCnNwYW4+PHNwYW49MjBzdHlsZT0zRD0yMm1zby10YWItY291bnQ6MT0yMj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbj0NCmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs9MjA8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPj0wQTwvZGl2Pj0NCj0wQTxw
cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXz0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXz0wQT0wQUNlPTIwbWVzc2FnZT0yMD0NCmV0PTIwc2VzPTIwcGllY2VzPTIw
am9pbnRlcz0yMHBldXZlbnQ9MjBjb250ZW5pcj0yMGRlcz0yMGluZm9ybWF0aW9ucz0yMGNvbj0N
CmZpZGVudGllbGxlcz0yMG91PTIwcHJpdmlsZWdpZWVzPTIwZXQ9MjBuZT0yMGRvaXZlbnQ9MjBk
b25jPTBBcGFzPTIwZXRyZT0yMD0NCmRpZmZ1c2VzLD0yMGV4cGxvaXRlcz0yMG91PTIwY29waWVz
PTIwc2Fucz0yMGF1dG9yaXNhdGlvbi49MjBTaT0yMHZvdXM9MjBhdj0NCmV6PTIwcmVjdT0yMGNl
PTIwbWVzc2FnZT0yMHBhcj0yMGVycmV1ciw9MjB2ZXVpbGxlej0yMGxlPTIwc2lnbmFsZXI9MEFh
PTIwbD0NCidleHBlZGl0ZXVyPTIwZXQ9MjBsZT0yMGRldHJ1aXJlPTIwYWluc2k9MjBxdWU9MjBs
ZXM9MjBwaWVjZXM9MjBqb2ludGVzLj0yMD0NCkxlcz0yMG1lc3NhZ2VzPTIwZWxlY3Ryb25pcXVl
cz0yMGV0YW50PTIwc3VzY2VwdGlibGVzPTIwZCdhbHRlcmF0aW9uLD0wQU9yYT0NCm5nZT0yMGRl
Y2xpbmU9MjB0b3V0ZT0yMHJlc3BvbnNhYmlsaXRlPTIwc2k9MjBjZT0yMG1lc3NhZ2U9MjBhPTIw
ZXRlPTIwYWx0ZT0NCnJlLD0yMGRlZm9ybWU9MjBvdT0yMGZhbHNpZmllLj0yME1lcmNpLj0wQT0w
QVRoaXM9MjBtZXNzYWdlPTIwYW5kPTIwaXRzPTIwYT0NCnR0YWNobWVudHM9MjBtYXk9MjBjb250
YWluPTIwY29uZmlkZW50aWFsPTIwb3I9MjBwcml2aWxlZ2VkPTIwaW5mb3JtYXRpb249DQo9MjB0
aGF0PTIwbWF5PTIwYmU9MjBwcm90ZWN0ZWQ9MjBieT0yMGxhdzs9MEF0aGV5PTIwc2hvdWxkPTIw
bm90PTIwYmU9MjBkaXM9DQp0cmlidXRlZCw9MjB1c2VkPTIwb3I9MjBjb3BpZWQ9MjB3aXRob3V0
PTIwYXV0aG9yaXNhdGlvbi49MEFJZj0yMHlvdT0yMGhhdmU9DQo9MjByZWNlaXZlZD0yMHRoaXM9
MjBlbWFpbD0yMGluPTIwZXJyb3IsPTIwcGxlYXNlPTIwbm90aWZ5PTIwdGhlPTIwc2VuZGVyPQ0K
PTIwYW5kPTIwZGVsZXRlPTIwdGhpcz0yMG1lc3NhZ2U9MjBhbmQ9MjBpdHM9MjBhdHRhY2htZW50
cy49MEFBcz0yMGVtYWlscz0NCj0yMG1heT0yMGJlPTIwYWx0ZXJlZCw9MjBPcmFuZ2U9MjBpcz0y
MG5vdD0yMGxpYWJsZT0yMGZvcj0yMG1lc3NhZ2VzPTIwdGhhdD0NCj0yMGhhdmU9MjBiZWVuPTIw
bW9kaWZpZWQsPTIwY2hhbmdlZD0yMG9yPTIwZmFsc2lmaWVkLj0wQVRoYW5rPTIweW91Lj0wQTwv
cD0NCnJlPj0wQT0wQTwvYm9keT48L2h0bWw+DQoNCi0tLS0tLT1fMDAxX05leHRQYXJ0MTU5MTE1
NTM4OV89LS0tLS0tDQoNCg0KDQoNCg==

------=_001_NextPart-1569392199_=------



From nobody Mon Feb 21 13:45:08 2022
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 C5C7C3A0332; Mon, 21 Feb 2022 13:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level: 
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed4QosoS_EYJ; Mon, 21 Feb 2022 13:44:50 -0800 (PST)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749133A0141; Mon, 21 Feb 2022 13:44:50 -0800 (PST)
Received: by mail-ej1-x630.google.com with SMTP id a8so36627425ejc.8; Mon, 21 Feb 2022 13:44:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=FwMCEMxcCAqkTLfST8yUpE/fY52bxri4987UO+UipGE=; b=BO5yIslN1yRe1x6qt0svgC64oQ43koh1D5FkGnM6akxcXYsCnHmVpcTeXPWpHf3jbw MNB0PrUk7PiIvRqV0U1ynbUhL07FPmW/6Xv5BqW+vgeFXpwwmGesj+EG/FcqbdnBFVS3 lVkLqWoHhvRQU6XOcGdUwQUFtM/jQ/34zWjF4D/uTq18AARx5650PFjv3IH/v9p02Tno 5PtWuiyYTgZFkkt4JnC9lsi+ibJ4EtnL0I1DZbc0F3+1B7Pk+vrXtolW6Ah0mM3pjqWg kE7MTocnE90YIjw3hOmsJsv9wyF6qOSCBjGL+ChzPcKtIuJaW/0u3mJVHwH2GEY4h94P tF8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=FwMCEMxcCAqkTLfST8yUpE/fY52bxri4987UO+UipGE=; b=tlB77R0Kyu/qkazB3Tp3wOj2H87/lL1DOJhaC/gr9/RrM6FpTWWPTAU4JZjvG5lM+H lMKItCBJzbLauU8++CaLk/+ND97RTgZIpVSHbTzQaDSCRAYm0NqyeuoveeCPhqXeQAmP 1G9lYgSCdrawBTNh26xX++wAOc3Vc6sz5fmnfS/n6A5A4JyPNxwQtm4O8y9zlkMQjOF+ 5bR020QhQN6kXUtTXHpkDOWX9xRrpV8HZcQmm7DjnHjZdZDSvtY5or4m1rdKsc8jfNeA AhvJ3mH7s1QX3jKR5kwymXsgom8XjHg76hzsTzPjASDh8i/jYhZ5tBmb7UaC7fn6dofV JmbQ==
X-Gm-Message-State: AOAM531xk5fTlp1GHExjK/IYvJKKnnNlS+Yvi+AxMaLnGs9FELIEGcZx WhG0FivJ1Tn0686nIym6Y51ZIPqCpP/A+E5KimsUWb21
X-Google-Smtp-Source: ABdhPJwjjHXNBzj2CBMJCTbMSDwvsoJNJlqaYabvXdGms3fncRKvHx+V81jBgVQrk2BcHG/+nUUZnhQlXPV3HIwHYDQ=
X-Received: by 2002:a17:906:fcbb:b0:6cd:f8fa:e356 with SMTP id qw27-20020a170906fcbb00b006cdf8fae356mr16945958ejb.436.1645479887591; Mon, 21 Feb 2022 13:44:47 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 21 Feb 2022 13:44:46 -0800
From: Alvaro Retana 
In-Reply-To: 
References: <164504875164.5704.16596621622345086808@ietfa.amsl.com> 
MIME-Version: 1.0
Date: Mon, 21 Feb 2022 13:44:46 -0800
Message-ID: 
To: Ketan Talaulikar 
Cc: james.n.guichard@futurewei.com, spring-chairs@ietf.org,  The IESG , draft-ietf-spring-segment-routing-policy@ietf.org,  SPRING WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)
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, 21 Feb 2022 21:44:53 -0000

On February 17, 2022 at 10:06:39 AM, Ketan Talaulikar wrote:


Ketan:

Hi!

I am looking at -18. =C2=A0Thanks for adding the Updates tag -- you need to
also add text to the Introduction about the update.

Comments inline...


> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
...
> > Besides the general topic of clarifying and updating what an SR Policy =
is,
> > this document also includes other items that were not present in rfc840=
2;
> > the list includes:
> >
> > =C2=A72.1: "SR Policy MUST be identified through the tuple  > endpoint>." =C2=A0 There's not even a mention of "color" in rfc8402.
> >
> > =C2=A72.1: "The headend is specified as an IPv4 or IPv6 address and is =
expected
> > to be unique in the domain." Neither the mechanism to identify a node n=
or
> > the expectation is present in rfc8402.
> >
> > =C2=A72.1: "The endpoint is specified as an IPv4 or IPv6 address and is=
 expected
> > to be unique in the domain." Same as above.
>
> KT> Yes, these are the constructs of SR Policy that are specified by this
> document.
>
> >
> >
> > The SR Database is a new element not in the base architecture. The text=
 in
> > =C2=A73 says that "use of the SR-DB for computation and validation of S=
R
> > Policies is outside the scope of this document", but it is then mention=
ed
> > and used in =C2=A75.1/=C2=A75.2.
>
> KT> The computation algorithm and related discussions about the use of SR=
-DB
> were asked to be moved out of this standards track document during the WG
> process. Those informational sections were moved into
> draft-filsfils-spring-sr-policy-considerations and kept as a reference in
> this document. The reference in 5.1 and 5.2 is about validation of segmen=
ts
> and as a result the segment-list and candidate path. The validation of th=
e
> "objective" and constraints of the SR Policy was deemed to be outside the
> scope of the document. There were several discussions on and off-list at =
the
> IETF meetings in this regard. Perhaps this thread gives a good summary:
> https://mailarchive.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/

It's ok if the SR-DB is out of scope.

=C2=A73 does say that "use of the SR-DB for computation and validation of
SR Policies is outside the scope of this document." =C2=A0But that (using
the DB for validation) is different than leaving validation completely
out of scope. =C2=A0In fact, the text in =C2=A75.1 doesn't leave segment-li=
st
validation (for example) out of scope when it says this:

=C2=A0 =C2=A0The SR Policy headend does not compute the Segment-List. =C2=
=A0The SR Policy
=C2=A0 =C2=A0headend only confirms its validity.

Or when it requires the validation explicitly: "A Segment-List of an
explicit candidate path MUST be declared invalid..."


Leaving the validation out of scope may have been what was intended,
but it is not what the document says. =C2=A0It is also not clear to me
whether the intent was to leave out of scope how to use the DB (as the
text in =C2=A73 says), or to completely leave it out.

The thread was not that easy to follow, with most message being about
support. =C2=A0Can you point me to where the out-of-scope decision was
reached? =C2=A0Alternatively, the Chairs can confirm.



> > Accordingly, the added details require additional Security and Manageab=
ility
> > considerations.
>
> KT> Could you please clarify/explain a bit further what you feel is missi=
ng?

For example, for this construct of the SR Policy specified in this
document: "The headend is specified as an IPv4 or IPv6 address and is
expected to be unique in the domain." (=C2=A72.1)

What new security and/or manageability considerations does it
introduce? =C2=A0Can there be a mixture of IPv4 and IPv6 addresses
identifying headends/endpoints? =C2=A0What happens if there are duplicate
identifiers? =C2=A0How can it be detected? =C2=A0Can a rogue node intercept=
 (or
perhaps attract) the traffic of an SR Policy if it advertises one of
these addresses? =C2=A0...

Some of the answers may be "nothing", or the issues may be carried
over from rfc8402 -- in those cases, please at least point that out.



...
> > (2) =C2=A75.1:
> >
> > Types A or B MUST be used for the SIDs for which the reachability
> > cannot be verified. Note that the first SID MUST always be reachable
> > regardless of its type.
> >
> > These two requirements and the text in the description of these types
> > ("...does not require the headend to perform SID resolution.") results =
in a
> > contradiction: Types A and B are not to be resolved, but if they are th=
e
> > first SID then they MUST. If it's not a contradiction, then Types A and=
 B
> > would not be allowed to be the first SID, which is not correct because =
the
> > most straightforward mechanism to define a path is to list SR-MPLS Labe=
ls
> > or SRv6 SIDs.
>
> KT> I don't see a contradiction here. "Types A or B MUST be used for the =
SIDs
> for which the reachability cannot be verified." is not the same as saying
> "Type A or B are not to be resolved".

True. =C2=A0However, the description of both types say that "This type does
not require the headend to perform SID resolution."

This is one of those cases where a (non) requirement is mentioned
without Normative language that can lead to a potentially wrong
interpretation. :-(



> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
...
> > (1) Is the specification of a headend/endpoint mandatory? IOW, should t=
he
> > text in =C2=A72.1 about the headend/endpoint being identified by a uniq=
ue IPv4
> > or IPv6 address be normative?
>
> KT> It is not normative since we have the case of an unspecified address =
as
> an endpoint. We could use SHOULD though, if that clarifies.

The unspecified address is an IPv4 or IPv6 address.

If you use SHOULD, when would it be ok for the identification to not
be an IPv4 or IPv6 address? =C2=A0Why recommend and not require?




> > (2) =C2=A72.1: "An implementation MAY allow the assignment of a symboli=
c name
> > comprising of printable ASCII [RFC0020] [RFC5234] characters"
> >
> > Why are you normatively limiting the name to be represented in ASCII? P=
lease
> > internationalize it - use UTF-8.
> >
> > =C2=A72.6 also has similar text.
>
> KT> My understanding is that there is no compulsion to use UTF-8 for such
> purposes. This was discussed in the WG. Please check:
> https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/

I wouldn't say that this thread (it only includes the message you sent
to the list) qualifies as a discussion. =C2=A0 But, yes, there is no
requirement to use UTF-8 -- it is just the nice (and maybe correct)
thing to do knowing that non-English-speaking people may also use this
specification.

[See rfc9003 for an an example of an extension what also considered
the Cyrillic alphabet.]



...
> > (4) =C2=A72.1: "An SR Policy MAY have multiple names...in the scenario =
where the
> > headend receives different SR Policy names" Describing multiple names a=
s the
> > case where multiple names are received is not helpful.
>
> KT> When CPs for the same SR Policy are provisioned via different sources=
,
> then such a scenario may occur.

It would be nice if the text included that clarification then: ...via
different sources.

Can multiple names be received from the same source?



...
> > (7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD be se=
t to 0 by
> > default when not available or known."
> >
> > When is it ok for the ASN to not be set to 0 (when not available or kno=
wn)?
> > If that possibility exists, the PCE can use any value (including the re=
al
> > number or a random one). What issues exist with uncoordinated (or rogue=
)
> > PCEs using potentially arbitrary ASNs?
> >
> > Why is this action recommended and not required?
>
> KT> AFAIR PCEP signaling does not carry AS number. So this is a
> recommendation, though a local policy or a future PCEP extension could ch=
ange
> that and we don't want to preclude it.

First of all, the architecture shouldn't be defined as a function of
what the protocols can do today, it should be defined as a function of
what is needed.

If the ASN can be signaled, when is it ok for it to not be set to 0
(when not available or known)? =C2=A0If that possibility exists, the PCE
can use any value (including the real number or a random one). What
issues exist with uncoordinated (or rogue) PCEs using potentially
arbitrary ASNs?



...
> > (9) Given the description, it seems possible for a PCE (for example) to
> > advertise multiple candidate paths with the same Preference, Originator=
, and
> > Discriminator. If that occurs, what is the result of the selection in =
=C2=A72.9?
> > Would this situation result in multiple active candidate paths?
>
> KT> The ability to signal multiple CPs via PCEP is being introduced via
> draft-ietf-pce-segment-routing-policy-cp. The default is for use when not
> using that draft and in that case, there would be only a single CP.


Let me try again: if the PCE can advertise multiple paths
(draft-ietf-pce-segment-routing-policy-cp) with the same Preference,
Originator, and Discriminator, how should the selection in =C2=A72.9 be
evaluated?




> > (10) =C2=A72.11: "Only the active candidate path SHOULD be used for for=
warding
> > traffic that is being steered onto that policy." When is it ok to use
> > non-active paths? Why is this action recommended and not required?
>
> KT> The condition was for path protection as described in section 9.3. Th=
e
> "backup" path is programmed and hence may be used for forwarding while FR=
R is
> active.

By definition, the backup is only used when the main path is being
repaired and not used (because it failed). =C2=A0IOW, in this case only one
path is used at a time.

The text above implies that more than one path can be used at a time.



...
> > (15) =C2=A75.2:
> >
> > When the local computation is not possible (e.g., a policy's tail-end
> > is outside the topology known to the headend) or not desired, the
> > headend MAY send path computation request to a PCE supporting PCEP
> > extension specified in [RFC8664].
> >
> > This action (ask the PCE) is a solution, not an architectural descripti=
on.
> > Are there other external mechanisms that can find a "solution Segment-
> > List"? It seems to me that one such mechanism would be in the form of a
> > configured Segment-List. If that is correct, please generalize the
> > normative statement above -- where using PCEP can be an example.
>
> KT> Agree and will change that to an example.

The updated text says:

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy's t=
ail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, =
the
=C2=A0 =C2=A0headend MAY send path computation request to a centralized
=C2=A0 =C2=A0computation entity (e.g., to a PCE supporting PCEP extensions
=C2=A0 =C2=A0specified in [RFC8664]).

In the case of manual configuration, the request is not sent anywhere
(as in using a protocol)... =C2=A0 How about this:

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy's t=
ail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, =
the
=C2=A0 =C2=A0headend may rely on an external entity. =C2=A0For example, a r=
equest may
=C2=A0 =C2=A0be sent to a PCE supporting PCEP extensions specified in [RFC8=
664].



> > (16) =C2=A77: Which are valid states? Active is one, the text mentions =
an
> > "administrative state", what else? Interoperability is a good reason to
> > specify the states and not assume that implementations might do the rig=
ht
> > thing.
>
> KT> The state here does not mean a single one like up/down. It is referri=
ng
> to the operational state. Those aspects are covered in the
> draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP when
> those protocols are in use. We'll add a reference to
> draft-ietf-spring-sr-policy-yang.

draft-ietf-spring-sr-policy-yang says that it provides a data-model
for the SR Policy framework defined in this document. =C2=A0But this
document points there for the states...circular reference.

Even if nor circular, the reference to
draft-ietf-spring-sr-policy-yang should be Normative because it
specifies the sates for the architecture.

You mentioned above that the "state here does not mean a single one
like up/down. It is referring to the operational state." =C2=A0This is from
draft-ietf-spring-sr-policy-yang:

=C2=A0 typedef policy-oper-state {
=C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 enum UP {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description "SR policy is operationally up";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum DOWN {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description "SR policy is operationally down";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 description "SR policy oper state";
=C2=A0 }

Am I looking in the wrong place?





> > (17) =C2=A77: "The SR Policy state MUST also reflect the reason when a =
policy
> > and/or its candidate path is not active due to validation errors or not
> > being preferred."
> >
> > Given that this is a requirement, please provide a list of reasons. The=
 need
> > for interoperability (by using rfc2119 language) can only be achieved i=
f the
> > reasons are standardized.
>
> KT> The reason is for debugging and troubleshooting. If something is down=
 or
> invalid, then it helps to know why.

Yes, I understand it helps to know the reason, that's why I'm asking. :-)

Again, please make draft-ietf-spring-sr-policy-yang a Normative reference.

I found a couple of identities in draft-ietf-spring-sr-policy-yang
that fit the bill for the requirement:
candidate-path-not-selected-reason and policy-down-reason. =C2=A0However,
what I couldn't find is the specification of the conditions when each
of the reasons is to be used. =C2=A0Most of reasons seem straight forward,
but it would be ideal if the specification was complete.



Thanks!

Alvaro.


From nobody Wed Feb 23 09:13:09 2022
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 355C93A0BD2; Wed, 23 Feb 2022 09:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level: 
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQcX47RgUSEe; Wed, 23 Feb 2022 09:13:02 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 BA2613A0E32; Wed, 23 Feb 2022 09:13:01 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr23.francetelecom.fr (ESMTP service) with ESMTPS id 4K3jKR5Kzlz5vXL;  Wed, 23 Feb 2022 18:12:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645636379; bh=+Z8nGEsUNvMZBF8i/jFD5YXpnMziaiKZB1UOsCRxuBM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=IyNepnFj9qHcOn5ydOp9AL4B/wgEQe80xLZFSc6FYM6xJooOct+Kq4u4fVujEAsFb GeuufGGmtrE1q14Szz/i1Uv/NhG++DqlOWJAXSF3ypTxNSKBNV8bnlrDqUUM01l166 fC1vPDAiK1Fl/HKZuAZ+G0H6XG7H6Bp5dP72b7qk68nfjnFn6MHxakuiEJ66YnUlPF ilRUm0VtYYerUvUeu/ICAymIvc4KI9KteEnum8+w7//FRCmuzgaVaVDjvm7kjFoFz6 abT5qCl/bN7AFBbnZEjgKbtOl+o0haQzS2EklRP4f61rthdVPoZRTkwDTtQxYlkUko 9okjph35HZeeQ==
From: 
To: Yisong Liu 
CC: SPRING WG , draft-hu-spring-segment-routing-proxy-forwarding 
Thread-Topic: =?utf-8?B?UmXvvJogUmU6IFtzcHJpbmddIElQUiBwb2xsIC0gZHJhZnQtaHUtc3ByaW5n?= =?utf-8?Q?-segment-routing-proxy-forwarding?=
Thread-Index: AQHYJsTxnv5lQyIj/USvaSR6V3G1M6yhYLOA
Date: Wed, 23 Feb 2022 17:12:59 +0000
Message-ID: <7386_1645636379_62166B1B_7386_310_1_e770fc25b0dc42eaac54ccbf64db0530@orange.com>
References: <650_1645408030_6212EF1D_650_385_1_202202210947072725575097@chinamobile.com>
In-Reply-To: <650_1645408030_6212EF1D_650_385_1_202202210947072725575097@chinamobile.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-23T17:12:57Z;  MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-23T17:12:57Z
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 30d06a1e-c685-4753-b14d-78dee0dbfbe8
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_e770fc25b0dc42eaac54ccbf64db0530orangecom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [spring]  =?utf-8?q?Re=EF=BC=9A_Re=3A__IPR_poll_-_draft-hu-spring?= =?utf-8?q?-segment-routing-proxy-forwarding?=
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, 23 Feb 2022 17:13:08 -0000

--_000_e770fc25b0dc42eaac54ccbf64db0530orangecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgWWlzb25nLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQoNCkF0IHRoZSB0aW1lLCBJIGNv
dWxkIG5vdCBmaW5kIHlvdXIgZW1haWwgb24gdGhlIGxpc3QgYmFzZWQgb24geW91ciBlbWFpbCBh
ZGRyZXNzIG9yIHRocmVhZDoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv
c3ByaW5nL2xxWTFiR1ltaVJ4VGZhZXplZGRWZmdvbFh0ay8NCmh0dHBzOi8vbWFpbGFyY2hpdmUu
aWV0Zi5vcmcvYXJjaC9icm93c2Uvc3ByaW5nLz9xPWZyb20lM0FsaXV5aXNvbmclNDBjaGluYW1v
YmlsZS5jb20mc289c3ViamVjdA0KDQooRXZlbiBhcyBvZiB0b2RheSwgdGhlIG1haWxhcmNoaXZl
IHNlZW1zIHRvIHJldHVybiBkaWZmZXJlbnQgYW5zd2VycyB0byB0aGUgc2FtZSByZXF1ZXN04oCm
KQ0KDQotLUJydW5vDQoNCg0KDQpPcmFuZ2UgUmVzdHJpY3RlZA0KRnJvbTogWWlzb25nIExpdSA8
bGl1eWlzb25nQGNoaW5hbW9iaWxlLmNvbT4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMjEsIDIw
MjIgMjo0NyBBTQ0KVG86IERFQ1JBRU5FIEJydW5vIElOTk9WL05FVCA8YnJ1bm8uZGVjcmFlbmVA
b3JhbmdlLmNvbT47IGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2Fy
ZGluZyA8ZHJhZnQtaHUtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1mb3J3YXJkaW5nQGll
dGYub3JnPg0KQ2M6IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmXvvJog
UmU6IFtzcHJpbmddIElQUiBwb2xsIC0gZHJhZnQtaHUtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1w
cm94eS1mb3J3YXJkaW5nDQoNCkhpIEJydW5vLA0KDQpJIGhhdmUgcmVwbGllZCBhYm91dCBhIG1v
bnRoIGFnby4gUGxlYXNlIGNoZWNrIHRoZSBleHBvcnRlZCBtYWlsIGluIHRoZSBhdHRhY2hlZCBm
aWxlcy4NCg0KQmVzdCBSZWdhcmRzDQpZaXNvbmcNCg0K5Y+R5Lu25Lq6OiBicnVuby5kZWNyYWVu
ZTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4NCuaXtumXtDogMjAyMi8wMi8xOSjm
mJ/mnJ/lha0pMDE6MTINCuaUtuS7tuS6ujogZHJhZnQtaHUtc3ByaW5nLXNlZ21lbnQtcm91dGlu
Zy1wcm94eS1mb3J3YXJkaW5nPG1haWx0bzpkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5n
LXByb3h5LWZvcndhcmRpbmdAaWV0Zi5vcmc+Ow0K5oqE6YCB5Lq6OiBTUFJJTkcgV0c8bWFpbHRv
OnNwcmluZ0BpZXRmLm9yZz47DQrkuLvpopg6IFJlOiBbc3ByaW5nXSBJUFIgcG9sbCAtIGRyYWZ0
LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZw0KSGkgYXV0aG9ycywN
Cg0KSWYgSeKAmW0gbm90IG1pc3Rha2VuLCB3ZSByZWNlaXZlZCBhIHJlcGx5IGZyb206DQoNCiAg
MS4gIFJlOiBbc3ByaW5nXSBJUFIgcG9sbCAtIGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXLigKY8
aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvQmJjd3Q4ckFXNkN5
eXI4UWZuVVlxd3hmc05NLz4gIEh1YWltbyBDaGVuDQogIDIuICBSZTogW3NwcmluZ10gSVBSIHBv
bGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1y4oCmPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0
Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL0VwZGlhcUc3ZWJnR296YXUteUFQQzkzT2M0TS8+ICBIdXpo
aWJvDQogIDMuICBSZTogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVu
dC1y4oCmPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2ZkT1ZQ
b2JYTG50aTQxdTZSMUNXZW5lNWlpUS8+ICB5YW9qdW5kYQ0KDQpTbyB3ZSBhcmUgbWlzc2luZyBy
ZXBsaWVzIGZyb20gdGhlIGZvbGxvd2luZyBjby1hdXRob3JzOg0KQy4gQm93ZXJzDQpZLiBaaHUN
ClkuIExpdQ0KDQpUaGFuayB5b3UsDQotLUJydW5vDQoNCg0KDQoNCk9yYW5nZSBSZXN0cmljdGVk
DQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91
bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1h
aWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkg
MTMsIDIwMjIgMTE6MTggQU0NClRvOiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86
c3ByaW5nQGlldGYub3JnPj47IGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHkt
Zm9yd2FyZGluZ0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaHUtc3ByaW5nLXNlZ21lbnQtcm91dGlu
Zy1wcm94eS1mb3J3YXJkaW5nQGlldGYub3JnPg0KU3ViamVjdDogW3NwcmluZ10gSVBSIHBvbGwg
LSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmcNCg0KSGkg
YXV0aG9ycywgY29udHJpYnV0b3JzLCBXRw0KDQpJbiBwcmVwYXJhdGlvbiBvZiB0aGUgV0cgYWRv
cHRpb24gY2FsbCBvbiBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndh
cmRpbmcgWzFdLCB0aGlzIGVtYWlsIHN0YXJ0cyBhIHBvbGwgZm9yIElQUi4NCg0KSWYgeW91IGFy
ZSBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IgdG8gdGhlIHN1YmplY3QgZG9jdW1lbnQsIHBsZWFz
ZSByZXNwb25kIHRvIHRoaXMgZW1haWwuDQoNCiAgMS4gIEluIHlvdXIgcmVzcG9uc2UsIHBsZWFz
ZSBpbmRpY2F0ZSBpZiBhbGwgcmVsZXZhbnQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZC4NCiAgMi4g
IElmIHlvdSBrbm93IG9mIHJlbGV2YW50IElQUiB0aGF0IGhhcyBub3QgYmVlbiBkaXNjbG9zZWQs
IHBsZWFzZSBzdGF0ZSB0aGF0IGFuZCBkZXNjcmliZSBob3cgdGhpcyBnYXAgaXMgYmVpbmcgYWRk
cmVzc2VkLg0KDQpFdmVuIGlmIHlvdSBhcmUgbm90IGEgY29udHJpYnV0b3Igb3IgYXV0aG9yLCBp
ZiB5b3Uga25vdyBvZiByZWxldmFudCBJUFIsIHBsZWFzZSBlbnN1cmUgdGhhdCBpdCBoYXMgYmVl
biBkaXNsb3NlZCBhcyBkaXNjdXNzZWQgaW4gQkNQIDc5Lg0KDQpJZiB5b3Uga25vdyBvZiBzb21l
b25lIGVsc2UgSVBSIHRoYXQgeW91IGJlbGlldmUgaXMgcmVsZXZhbnQgYW5kIG5vdCBkaXNjbG9z
ZWQsIHBsZWFzZSBmaWxlIGEgdGhpcmQgcGFydHkgSVBSIGRpc2Nsb3N1cmUuDQoNClRoYW5rcywN
ClJlZ2FyZHMsDQpCcnVubywgSmltLCBKb2VsDQpbMV0gICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2Fy
ZGluZy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg
cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2
aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0
ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz
YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0
IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl
bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk
ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk
ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0
aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk
aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz
ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg
ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg
dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5
b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl
dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls
ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz
IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn
ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBs
ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl
Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVj
bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm
b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh
Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv
biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlz
dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVt
YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo
YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91
Lg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u
dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0
IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz
YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy
LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z
aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu
dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z
YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g
TWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m
aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg
YnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp
dGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl
cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu
ZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v
dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y
IGZhbHNpZmllZC4KVGhhbmsgeW91LgoK

--_000_e770fc25b0dc42eaac54ccbf64db0530orangecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg
Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9
Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p
Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp
c3QueG1sQDAxRDgyOEUwLkZDNTAwRTgwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m
ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT
ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6
V29yZERvY3VtZW50Pg0KPHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9jdW1lbnRL
aW5kPg0KPHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6SHlwaGVuYXRp
b25ab25lPjIxPC93Okh5cGhlbmF0aW9uWm9uZT4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlB1bmN0
dWF0aW9uS2VybmluZy8+DQo8dzpWYWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCjx3OlNhdmVJZlhN
TEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCjx3Oklnbm9yZU1peGVkQ29udGVu
dD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+DQo8dzpBbHdheXNTaG93UGxhY2Vob2xkZXJU
ZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQo8dzpEb05vdFByb21vdGVR
Ri8+DQo8dzpMaWRUaGVtZU90aGVyPkZSPC93OkxpZFRoZW1lT3RoZXI+DQo8dzpMaWRUaGVtZUFz
aWFuPlgtTk9ORTwvdzpMaWRUaGVtZUFzaWFuPg0KPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0Plgt
Tk9ORTwvdzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+DQo8dzpDb21wYXRpYmlsaXR5Pg0KPHc6RG9O
b3RFeHBhbmRTaGlmdFJldHVybi8+DQo8dzpCcmVha1dyYXBwZWRUYWJsZXMvPg0KPHc6U25hcFRv
R3JpZEluQ2VsbC8+DQo8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQo8dzpVc2VBc2lhbkJyZWFrUnVs
ZXMvPg0KPHc6RG9udEdyb3dBdXRvZml0Lz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4N
Cjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8dzpEb250RmxpcE1pcnJvckluZGVudHMvPg0K
PHc6T3ZlcnJpZGVUYWJsZVN0eWxlSHBzLz4NCjwvdzpDb21wYXRpYmlsaXR5Pg0KPHc6QnJvd3Nl
ckxldmVsPk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCjxtOm1h
dGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBtOnZh
bD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxGcmFj
IG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KPG06
ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8bTp3
cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0KPG06
bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0eWxl
cyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVmU2Vt
aUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVu
dFN0eWxlQ291bnQ9IjM3NiI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp
bmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i
aGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijki
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBO
YW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRy
dWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1h
dD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBR
Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRl
eCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRv
YyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzki
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUgdGV4
dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0
YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJlc3Mi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0
aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRu
b3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg
TmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l
PSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1
bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51
bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51
bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBR
Rm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9zaW5n
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO
YW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVl
IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNzYWdl
IEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIg
UUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2Fs
dXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBU
ZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGluZyIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l
PSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDIi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5rIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJv
bmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFGb3Jt
YXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3VtZW50
IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUb3Ag
b2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJI
VE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENv
ZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQcmVm
b3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwg
VmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9
InRydWUiIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJO
byBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9
InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxp
bmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh
YmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMg
NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg
Q29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDQi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDIi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh
YmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl
IExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExp
c3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250ZW1w
b3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9uYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi
bGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi
bGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdo
dCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx
IiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJN
ZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3Jp
ZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1l
PSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNo
YWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBT
aGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNj
ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9
IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBR
Rm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRp
dW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2Vu
dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1l
PSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3Qg
QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMi
IE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExp
c3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1
bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNj
ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5h
bWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlk
IDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3Jm
dWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg
MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0i
TGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2Nl
bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFt
ZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExp
c3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVk
aXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2Vu
dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1l
PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5n
IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYx
IiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGlu
ZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJN
ZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFj
Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBO
YW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRp
bmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0
IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1
bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg
QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYi
IE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBH
cmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3Jm
dWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2Nl
bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFt
ZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2Nl
bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFt
ZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVt
IExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg
NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0i
TWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2Vu
dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1l
PSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBH
cmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9Iklu
dGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5hbWU9
IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxlIDEi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9IlBs
YWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFibGUg
TGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5h
bWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3Jp
ZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlk
IFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFj
Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBO
YW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRh
YmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBU
YWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2Nl
bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFt
ZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJs
ZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFi
bGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50
IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9
IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUg
NiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxl
IDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA0
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJH
cmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYg
Q29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAx
IExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNSIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3Jp
ZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENv
bG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBM
aWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQg
VGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xv
cmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGln
aHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9
Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRh
YmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2Vu
dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1l
PSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFj
Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBO
YW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2Vu
dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1l
PSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQg
MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i
TGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2Nl
bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFt
ZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg
MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0i
TGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxp
c3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50
IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9
Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxp
c3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0
IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJM
aXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0
IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBU
YWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNSIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlz
dCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBU
YWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFi
bGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3Qg
VGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFi
bGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZW50aW9uIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIE5hbWU9IlNtYXJ0IEh5cGVybGluayIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO
YW1lPSJIYXNodGFnIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlVucmVzb2x2ZWQgTWVudGlvbiIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTbWFydCBMaW5rIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0K
PC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkg
NyAyIDUgOCAyIDQ7DQoJbXNvLWZvbnQtYWx0OiLvvK3vvLMg44K044K344OD44KvIjsNCgltc28t
Zm9udC1jaGFyc2V0OjEyODsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rlcm47DQoJbXNv
LWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTc5MTQ5
MTU3OSAxMzQyMTc3NDYgMCAxMzEyMzEgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJD
YW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7DQoJbXNvLWZvbnQt
Y2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1zby1mb250LXBp
dGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODY5MTIxIDExMDczMDU3Mjcg
MzM1NTQ0MzIgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1z
by1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0K
CW1zby1mb250LXNpZ25hdHVyZTotNDY5NzUwMDE3IC0xMDczNzMyNDg1IDkgMCA1MTEgMDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIg
MTEgNSAzIDIgMiA0IDIgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1nZW5lcmlj
LWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250
LXNpZ25hdHVyZTotMjE0NzQ4MzAwMSA3MTgyMjQ0NjQgMjIgMCAyNjIxNzUgMDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMg
MiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rl
cm47DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4Njkx
MjEgNjQ3NjcgMSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9z
b2Z0IFlhSGVpIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDsNCgltc28tZm9udC1j
aGFyc2V0OjEzNDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1w
aXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTIxNDc0ODMwMDEgNzE4MjI0NDY0
IDIyIDAgMjYyMTc1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMi
Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTI4
Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRjaDpmaXhl
ZDsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxNzkxNDkxNTc5IDEzNDIxNzc0NiAw
IDEzMTIzMSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkhlbHZldGljYSA3NSBCb2xk
IjsNCglwYW5vc2UtMToyIDExIDggNCAyIDIgMiAyIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7
DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFi
bGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xNjEwNjEyMDQ5IDEzNDIxODU1NjMgMCAwIDE1OSAw
O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk
aXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6
eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBjbTsNCgltc28tcGFnaW5hdGlv
bjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGlu
aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu
a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11
bmRlcmxpbmU6c2luZ2xlO30NCnByZQ0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7
DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246
d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCnAuTXNvTGlzdFBhcmFn
cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0
eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3Jt
YXQ6eWVzOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdp
bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K
c3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1M
IENhciI7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxl
LWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28t
YXNjaWktZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWJpZGktZm9udC1m
YW1pbHk6Q2FsaWJyaTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt
YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0K
CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndp
ZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KcC5kZXB0aC0x
LCBsaS5kZXB0aC0xLCBkaXYuZGVwdGgtMQ0KCXttc28tc3R5bGUtbmFtZTpkZXB0aC0xOw0KCW1z
by1zdHlsZS11bmhpZGU6bm87DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp
Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207
DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6
Q2FsaWJyaTt9DQpwLm1zaXBmb290ZXJlZDkxZWQ5OCwgbGkubXNpcGZvb3RlcmVkOTFlZDk4LCBk
aXYubXNpcGZvb3RlcmVkOTFlZDk4DQoJe21zby1zdHlsZS1uYW1lOm1zaXBmb290ZXJlZDkxZWQ5
ODsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h
cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl
ZnQ6MGNtOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQt
ZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpu
bzsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZh
bWlseTpBcmlhbDsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9u
dC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6d2luZG93dGV4dDsNCgltc28tdGV4dC1hbmltYXRpb246
bm9uZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1k
ZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246
bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3VnaDpub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LXNp
emU6MTAuMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1z
aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7
DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7DQoJbXNvLWhlYWRlci1t
YXJnaW46MzYuMHB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjM2LjBwdDsNCgltc28tcGFwZXItc291
cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0
IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMjk3NzUxNzA7DQoJbXNv
LWxpc3QtdGVtcGxhdGUtaWRzOi0zMjU5NjMwNDg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s
ZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWIt
c3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDgu
MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu
MHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA
bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6
bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0K
CXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl
dmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWIt
c3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjQxMTY5OTYwODsNCgltc28t
bGlzdC10ZW1wbGF0ZS1pZHM6LTE3MDYxNTc4NDY7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6
NzQ3MTkwNjgzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjEyOTQ2MzQxNDt9DQpAbGlzdCBs
MjpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDIN
Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxl
dmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt
c3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgw
LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4
LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K
QGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwy
OmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDkN
Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6
OTE1NjMzODk3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5MDM2NDQyMzA7fQ0Kb2wNCgl7bWFy
Z2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUu
TXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlYXUgTm9ybWFsIjsNCgltc28t
dHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNv
LXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1w
YXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBh
cmEtbWFyZ2luOjBjbTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQo8L3N0eWxl
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2
OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd
LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG
NzIiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6MzUuNHB0O3dvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl
cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBZaXNvbmcsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s
YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtz
IGZvciB5b3VyIHJlcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1s
YW5ndWFnZTpFTi1VUzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXQgdGhlIHRpbWUsIEkg
Y291bGQgbm90IGZpbmQgeW91ciBlbWFpbCBvbiB0aGUgbGlzdCBiYXNlZCBvbiB5b3VyIGVtYWls
IGFkZHJlc3Mgb3IgdGhyZWFkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVT
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl
LmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9scVkxYkdZbWlSeFRmYWV6ZWRkVmZnb2xYdGsvIj5o
dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9scVkxYkdZbWlSeFRm
YWV6ZWRkVmZnb2xYdGsvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVT
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl
LmlldGYub3JnL2FyY2gvYnJvd3NlL3NwcmluZy8/cT1mcm9tJTNBbGl1eWlzb25nJTQwY2hpbmFt
b2JpbGUuY29tJmFtcDtzbz1zdWJqZWN0Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy
Y2gvYnJvd3NlL3NwcmluZy8/cT1mcm9tJTNBbGl1eWlzb25nJTQwY2hpbmFtb2JpbGUuY29tJmFt
cDtzbz1zdWJqZWN0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1s
YW5ndWFnZTpFTi1VUzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+KEV2ZW4gYXMgb2YgdG9k
YXksIHRoZSBtYWlsYXJjaGl2ZSBzZWVtcyB0byByZXR1cm4gZGlmZmVyZW50IGFuc3dlcnMgdG8g
dGhlIHNhbWUgcmVxdWVzdOKApik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1V
Uzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWFu
c2ktbGFuZ3VhZ2U6RU4tVVM7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tQnJ1bm88bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUzttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im1zaXBmb290
ZXJlZDkxZWQ5OCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbjowY207dGV4dC1hbGlnbjpj
ZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EgNzUgQm9sZCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNFRDdEMzEiPk9yYW5nZSBS
ZXN0cmljdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg
MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQt
ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+IFlpc29uZyBMaXUgJmx0O2xpdXlp
c29uZ0BjaGluYW1vYmlsZS5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJy
dWFyeSAyMSwgMjAyMiAyOjQ3IEFNPGJyPg0KPGI+VG86PC9iPiBERUNSQUVORSBCcnVubyBJTk5P
Vi9ORVQgJmx0O2JydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20mZ3Q7OyBkcmFmdC1odS1zcHJpbmct
c2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmcgJmx0O2RyYWZ0LWh1LXNwcmluZy1zZWdt
ZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+
IFNQUklORyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
ZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O21z
by1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+77yaPC9zcGFuPjxzcGFu
IHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDsiPiBSZTogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0
aW5nLXByb3h5LWZvcndhcmRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhp
IEJydW5vLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQg
WWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBoYXZlIHJlcGxpZWQgYWJvdXQg
YSBtb250aCBhZ28uIFBsZWFzZSBjaGVjayB0aGUgZXhwb3J0ZWQgbWFpbCBpbiB0aGUgYXR0YWNo
ZWQgZmlsZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m
dCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5CZXN0IFJlZ2FyZHM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFI
ZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+WWlzb25nPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6Ni4wcHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3
IFJvbWFuJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW91dGxpbmUtbGV2ZWw6MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMz
MyI+5Y+R5Lu25Lq6Og0KPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20i
PmJydW5vLmRlY3JhZW5lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMz
MzMiPuaXtumXtDogMjAyMi8wMi8xOSjmmJ/mnJ/lha0pMDE6MTI8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMzMzMzMzIj7mlLbku7bkuro6DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQt
aHUtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1mb3J3YXJkaW5nQGlldGYub3JnIj5kcmFm
dC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmc8L2E+OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPuaKhOmAgeS6ujoNCjxhIGhyZWY9Im1h
aWx0bzpzcHJpbmdAaWV0Zi5vcmciPlNQUklORyBXRzwvYT47PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzMzMzMzMyI+5Li76aKYOiBSZTogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFm
dC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmc8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IaSBhdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z
ZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+SWYgSeKAmW0gbm90IG1pc3Rha2VuLCB3ZSBy
ZWNlaXZlZCBhIHJlcGx5IGZyb206PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0YXJ0PSIx
IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iZGVwdGgtMSIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVs
MSBsZm8zO3RhYi1zdG9wczpsaXN0IDM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9t
YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvQmJjd3Q4ckFXNkN5eXI4UWZuVVlx
d3hmc05NLyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1V
UyI+UmU6DQogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1y4oCm
PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1m
b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6
RU4tVVMiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5IdWFpbW8gQ2hlbjxvOnA+PC9vOnA+
PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJkZXB0aC0xIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwx
IGxmbzM7dGFiLXN0b3BzOmxpc3QgMzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL21h
aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9FcGRpYXFHN2ViZ0dvemF1LXlBUEM5
M09jNE0vIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVT
Ij5SZToNCiBbc3ByaW5nXSBJUFIgcG9sbCAtIGRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXLigKY8
L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWZv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF
Ti1VUyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZh
bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkh1emhpYm88bzpwPjwvbzpwPjwvc3Bh
bj48L2xpPjxsaSBjbGFzcz0iZGVwdGgtMSIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8z
O3RhYi1zdG9wczpsaXN0IDM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJj
aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvZmRPVlBvYlhMbnRpNDF1NlIxQ1dlbmU1aWlR
LyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+UmU6
DQogW3NwcmluZ10gSVBSIHBvbGwgLSBkcmFmdC1odS1zcHJpbmctc2VnbWVudC1y4oCmPC9zcGFu
PjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZh
bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMi
PiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij55YW9qdW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwv
bGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWY7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWFu
c2ktbGFuZ3VhZ2U6RU4tVVMiPlNvIHdlIGFyZSBtaXNzaW5nIHJlcGxpZXMgZnJvbSB0aGUgZm9s
bG93aW5nIGNvLWF1dGhvcnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvO3RhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3
NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1
LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNv
LWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1hbnNp
LWxhbmd1YWdlOkVOLVVTIj5DLiBCb3dlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87dGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIy
OS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5
LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7
bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPlkuIFpodTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzt0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y
cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw
dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+WS4gTGl1PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28t
YW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5n
dWFnZTpFTi1VUyI+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWFuc2ktbGFuZ3VhZ2U6
RU4tVVMiPi0tQnJ1bm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Im1zaXBmb290ZXJlZDkxZWQ5OCIgYWxpZ249ImNlbnRlciIgc3R5
bGU9Im1hcmdpbjowY207dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgNzUgQm9sZCZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiNFRDdEMzEiPk9yYW5nZSBSZXN0cmljdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw
YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLW91dGxpbmUtbGV2ZWw6MSI+DQo8Yj48c3Bh
biBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+IHNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRv
OnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7
DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFu
Z2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBU
aHVyc2RheSwgSmFudWFyeSAxMywgMjAyMiAxMToxOCBBTTxicj4NCjxiPlRvOjwvYj4gU1BSSU5H
IFdHICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8
L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmct
cHJveHktZm9yd2FyZGluZ0BpZXRmLm9yZyI+DQpkcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0
aW5nLXByb3h5LWZvcndhcmRpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtz
cHJpbmddIElQUiBwb2xsIC0gZHJhZnQtaHUtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1m
b3J3YXJkaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj5I
aSBhdXRob3JzLCBjb250cmlidXRvcnMsIFdHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5n
dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1V
UyI+SW4gcHJlcGFyYXRpb24gb2YgdGhlIFdHIGFkb3B0aW9uIGNhbGwgb24gZHJhZnQtaHUtc3By
aW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1mb3J3YXJkaW5nDQogWzFdLCB0aGlzIGVtYWlsIHN0
YXJ0cyBhIHBvbGwgZm9yIElQUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj5JZiB5
b3UgYXJlIGFuIGF1dGhvciBvciBjb250cmlidXRvciB0byB0aGUgc3ViamVjdCBkb2N1bWVudCwg
cGxlYXNlIHJlc3BvbmQgdG8NCiB0aGlzIGVtYWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxv
bCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl
PSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvNjt0YWItc3RvcHM6bGlzdCAzNi4wcHQiPg0KPHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg
TmV3IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj5JbiB5b3VyIHJlc3BvbnNl
LCBwbGVhc2UgaW5kaWNhdGUgaWYgYWxsIHJlbGV2YW50IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQu
PHNwYW4gc3R5bGU9Im1zby10YWItY291bnQ6NSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh
c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvNjt0YWIt
c3RvcHM6bGlzdCAzNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh
c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1
YWdlOkVOLVVTIj5JZiB5b3Uga25vdyBvZiByZWxldmFudCBJUFIgdGhhdCBoYXMgbm90IGJlZW4g
ZGlzY2xvc2VkLCBwbGVhc2Ugc3RhdGUgdGhhdCBhbmQgZGVzY3JpYmUgaG93IHRoaXMgZ2FwIGlz
IGJlaW5nIGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdl
OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj5F
dmVuIGlmIHlvdSBhcmUgbm90IGEgY29udHJpYnV0b3Igb3IgYXV0aG9yLCBpZiB5b3Uga25vdyBv
ZiByZWxldmFudCBJUFIsIHBsZWFzZQ0KIGVuc3VyZSB0aGF0IGl0IGhhcyBiZWVuIGRpc2xvc2Vk
IGFzIGRpc2N1c3NlZCBpbiBCQ1AgNzkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+
SWYgeW91IGtub3cgb2Ygc29tZW9uZSBlbHNlIElQUiB0aGF0IHlvdSBiZWxpZXZlIGlzIHJlbGV2
YW50IGFuZCBub3QgZGlzY2xvc2VkLA0KIHBsZWFzZSBmaWxlIGEgdGhpcmQgcGFydHkgSVBSIGRp
c2Nsb3N1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh
bnMtc2VyaWY7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp
Zjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyI+QnJ1bm8sIEppbSwgSm9lbDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWY7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiPlsxXTxzcGFuIHN0eWxlPSJtc28tdGFiLWNvdW50
OjEiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJv
eHktZm9yd2FyZGluZy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1
LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZy88L2E+PHNwYW4gc3R5bGU9
Im1zby10YWItY291bnQ6NCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby10YWItY291bnQ6MSI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEuMHB0Ij5DZSBtZXNzYWdlIGV0IHNlcyBw
aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50
aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxLjBwdCI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4
cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl
IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxLjBwdCI+YSBsJ2V4cGVkaXRldXIgZXQgbGUg
ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0
cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxLjBwdCI+T3JhbmdlIGRlY2xpbmUgdG91dGUg
cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs
c2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxLjBwdCI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u
ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk
IGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxLjBw
dCI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0
IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0
b206MS4wcHQiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEuMHB0
Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz
YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MS4wcHQiPlRoYW5rIHlvdS48
bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNlcyBwaWVj
ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs
bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh
dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs
ZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl
dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv
bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3ByZT4N
CjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh
IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRz
IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y
bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3ByZT4NCjxw
cmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0
IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2
ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl
dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT4NCjxw
cmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz
c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8
L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1
dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl
Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug
Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh
ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1
aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx
dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRl
IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh
bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250
YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy
b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj
b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt
YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu
Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo
YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_e770fc25b0dc42eaac54ccbf64db0530orangecom_--


From nobody Wed Feb 23 09:37:08 2022
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 946333A1187 for ; Wed, 23 Feb 2022 09:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.673
X-Spam-Level: 
X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=RwgC6NzM; dkim=pass (1024-bit key) header.d=juniper.net header.b=QczW6SN9
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DRRaGx_Qkpw for ; Wed, 23 Feb 2022 09:37:01 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF633A0D92 for ; Wed, 23 Feb 2022 09:37:01 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21NGPm7n027076 for ; Wed, 23 Feb 2022 09:37:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=vPlD/qCWuVWTpzogRaKkw6639fTZZtvNic0BDuZLefc=; b=RwgC6NzMpqHF94NzO9wb0fmiL405K/HM0XeARoZ985ohEp2LSTkxeBbHMRQowewBDS1B jsFSVK3MalZ0h43rRZepjyyfTPAZK5dFAUh6z3DzpQjM5dIg6DzyeMqzCek4zW2i06DE /PZM8nmDDqqz2dHx53jnF6sDeg8MHjC/lgNCpb4HjQPBZCWnAaI5wDrPA4+Eq3AkTCMF kX42o66gjVtBKTkOW6mAcXJ/u4eYR43YCO/4HxJqpGa/zXW0O3PgQAsvwWDVn+yjWysk awMTK/rys2VhakAdV4CSHAsyLHMjokSk09sTieqZILGwynutoi5VNtWMKLL8D062DNXb Jg== 
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2175.outbound.protection.outlook.com [104.47.55.175]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3edrej05f6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 Feb 2022 09:37:01 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YPHbMnhUVKiOdddizYYU/kaUIJGxu8L+mi2SyxatBjugG01REh/KFMrWRIdu+tigL2F/XM4KTKz+Dd/+5kY7dQd7V5vt+EajSZ2sGaJLaCJYyEKRXVe5inImGH0VTJGu+SegqxPAs/7gklfnvp0MM+z5zbRb8sbSmR+6D0jY9B/nZMHRsvG94S9NXBxx7pIuxk+sYew46ceDzPYWjwogK7wyifSdWa7CLa9R1Nj/OmJfOHDj0z6RJSFs0Hgpyo43/hYlEjz0xXJya+Gr3VwknsIrbhv1oJEMxEu7MWNdb9WUcL1GLWRZ6YvaCXVkpgSjgRV/W24RtnvsrjvYVrgPOA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vPlD/qCWuVWTpzogRaKkw6639fTZZtvNic0BDuZLefc=; b=l2haAYn0PO2r6hj7pfJDDq/99f7LrrEyQaV8ojDsEfaJAixDFDr1igyhxPiPsgUlU6LHz2s43+wJTvdJH32jwijxBGUkhna3s9WtacNFA9VP3rVbX76EP5efNN3nZLlORh6GNntHrHOnG1wqIvJXv9hmktyvsiHwEmo4gyq2rQ8D0efdFELfeTS0+IXpOSJ2wCZoM1NIIJVH4xFi7UFmz2yp0DJMUch9cyS521qGnpLTTDZo4gnLfnitc5rtkuouX/UyUnHi8aICKXdZYy+YlYEru9mI17U1rxFBpWxhFVv2++vMk1fDPBpREOB96vhwH2+31gZ5EU9bL7MZSd3x2A==
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=vPlD/qCWuVWTpzogRaKkw6639fTZZtvNic0BDuZLefc=; b=QczW6SN9g+QIrJSfdpN3GnWv3XWZ3wRxUi+7I86+DTBZ40fYuizOhNn+qsbl6VYhxyL2iWY57ImiWRpVFJ8wYhBjf4b+leqEgozSnL72jyyjIYzxZUYPOCOzQMraFPhUoaocRPyU86U7UI4P9ffi/XVykX1WKSO4JgGaxr7e/DY=
Received: from CO1PR05MB8314.namprd05.prod.outlook.com (2603:10b6:303:fd::13) by DM6PR05MB6444.namprd05.prod.outlook.com (2603:10b6:5:128::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Wed, 23 Feb 2022 17:36:58 +0000
Received: from CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::857e:c814:a640:6153]) by CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::857e:c814:a640:6153%6]) with mapi id 15.20.5038.009; Wed, 23 Feb 2022 17:36:58 +0000
From: Shraddha Hegde 
To: "spring@ietf.org" 
Thread-Topic: Update on merging draft-hegde-spring-mpls-seamless-sr and draft-dskc-bess-bgp-car-problem-statement 
Thread-Index: Adgo218ShfAHGtYMRH2bvWJolHkmMQ==
Date: Wed, 23 Feb 2022 17:36:58 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.6.400.34
dlp-reaction: no-action
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: caa4a4cc-911e-4eee-db29-08d9f6f317bc
x-ms-traffictypediagnostic: DM6PR05MB6444:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BzbheGPAEbIaTjCynhcFA0Kcx7ytUO8AWpyWOjVFWhEZY9DNaoJ5vT9cAezvQa9amkHM7eoSsxQ6sWDHpA/sU5HSD7OPKYzUnlO3P4uK/YhEkGg+57DrHjXCsdf3/V/pq2DGiiK+gLepjLbxzfgtvAqZl5e4ru4tztaWY3u9ENyI5zSPZjQCUOpkwGA8Gv3D8pt3Bw3/r/Ua8E1ow3cSmjceD0iYBbSH1cIQfGszgwYX78UwtPckmPNH//WL2BPPkjJYkyePhqVplFEiy5r+XYEYVccl2FtnUhVC2iNdWVx3cjQB3BMm1WqGYVqF+UPW8AbLCpgtj5XE8ElUavKdlel+cb41bHjQoFutx2qJOFc/mRW1JBJWy9BGios8gpSm9h5G31CLDpRHcJV+yDo+TFLVroJAo1LKQcDFpbzY+6MTDG+l66W6Sl8TMgpWd2oagVVb/oOYiPZiW3wW0A5eHqdmRBykZaiVX/GUN9t1NBXq3laQZJKj8EgMcQg6gDUw1hogqLxclf6pLqABSaQt8YAtNvVXEbIaP5aJSratrsHJAfvUF37qqGtM+SIwdl83M0gp7ZJEVTXBcwIf+GPl1QvQYMFUyCNxDgs0zl2TICsK/Iksx3Vq0KN5r3Zr0DLGFFQrN6KOlQIlsKJ+sppqHP/tx2WtszaOrEf931ONGAT3THPr8JPTISVlrmQQp0M0YoYoMDZAwcHhW75qd9cBxQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CO1PR05MB8314.namprd05.prod.outlook.com; PTR:; CAT:NONE;  SFS:(13230001)(4636009)(366004)(38100700002)(86362001)(316002)(122000001)(55016003)(38070700005)(6916009)(508600001)(76116006)(8676002)(52536014)(8936002)(15650500001)(5660300002)(64756008)(6506007)(71200400001)(66946007)(66556008)(66476007)(66446008)(83380400001)(7696005)(9686003)(2906002)(26005)(186003)(4743002)(33656002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NECpuB8ZvSetBbgHL6KIhwYuh0SxhmbyuxUWn0/wDgJ+37Oq5Ue13ZZKu86c?= =?us-ascii?Q?+uL3r9GC3YfurtR2j6PBwHfZcJ1U+CrKgsz/sVMo5/Xs6eKlQDRejRgLgn7Y?= =?us-ascii?Q?Ow0y740tkObp6eZRTUslWVi4gTSorA6jU8Vt9esGYNZy700P3PssHrvAZoy5?= =?us-ascii?Q?rBMIQtVwP2Z51jNet96qpzuLcAqMlN9kqKDKMKpVB/TV1HqB+dAfpQfbcqnS?= =?us-ascii?Q?XpOGSuDIjH8n5xu7kmaD9jJP1AaZ4nJ7Z3jeVzOaDGeNII+4dF2OOV8LPn68?= =?us-ascii?Q?yurZzxSZXI/tVfoivaiV7he/gcUaf5vockeuPOD1Cwj0itiJqvDrKj+CwlYW?= =?us-ascii?Q?JyS1sq1prjethCfEq1KImgQvK2vCyftTRRbiepVkaWeuyi9wX0cmcHbiVGjJ?= =?us-ascii?Q?RAoHGD6GmpDRn2mW68XkskL8j2/LcS1GQPDo8WhDdz09oyaCJ932LWT949a3?= =?us-ascii?Q?r8uqxE4ZlfhSFxiBJk9CGmmS4wT89L38yDr+8R7X+VSj5SgCxNPtEfhg4UDF?= =?us-ascii?Q?3B+3WdFhPTGwh73rOEALLc4zMQf3jxZn7xOc5IRZGGaNMsQEYGV5Jyzp43RG?= =?us-ascii?Q?SDz2jczBbfAHjSCytqtpb3J3p45q/ZNEeh/yoolLwd3RGV1swGjUwRYvLWzO?= =?us-ascii?Q?JKR5sdX9XFFzYRHhMjSkSD4Hdk02r0PfpZO5Whg6K/EPPcAfzgGeJwKWTa7g?= =?us-ascii?Q?i2yRbW4LhLQ1BzMQTIK5ppfP/Sa8boZXAPGJafMyHHJWKnT1+7G+JztJRDD0?= =?us-ascii?Q?5CGETJlJr0belntek1NVLOI/uZoSNzqXNrLpGv18ba3JCyTvgY6yJ6cmMx58?= =?us-ascii?Q?KUNOHb7TKge6JA3hBR3qJ94rcaGySrgyMTWDGu4qoxApqNanRddb3BjPEoRy?= =?us-ascii?Q?hwnW7Uk7JSBMPUMgP07gR7yhsfTvo8H2AZCK/Ar2xTxEVztGSuvJqMlFtSE/?= =?us-ascii?Q?3wc33zjRobMCtdKtogXtB0OIwN29BdxzNIK8F57c/Om4qgrkDVApojjREUPp?= =?us-ascii?Q?1vPjPYzbqlCaiRod48Rrv9Muh1Do5ho32PcElrsauTpt0+Kv8s9iVJu+9S/n?= =?us-ascii?Q?vScpAP1zwFA78sgT9FJsRFlNrJB3oEyV+x/4io7T1q0B8D72ks73TMDPlDrb?= =?us-ascii?Q?BketDumfxTXi4SXRguevchULWqAobVHlzWdgxZLLQu8cdYCFncC9iLXy/fWJ?= =?us-ascii?Q?cmqZOXRtZvVBST4bSQhUs5UUllBsDETXgVle6SGdBwaDeAXPwSgcflcjPNmB?= =?us-ascii?Q?rP602daCRR+IG4Cu382+V25DQ5kk1pa4oObIvvgrRV35rgfjN/GPdsUhot3x?= =?us-ascii?Q?i8uhiWZNt4Mz1XFNsrTia6A5rlM4SEMGUM5nlyDXF9swM/ECRJhnAaQnkSs1?= =?us-ascii?Q?pFxVwrV6ojDLckfTjYDYvMekHNYiIBlX6kmh1vatWltQZkEpRBBADwqFmR9I?= =?us-ascii?Q?+QSGKs3YOvsAPNOHeEumXPDf0lCGYb6Ubzs5AVa12AYtUwQhtdz8dD5bbyfg?= =?us-ascii?Q?9XheBUVHT2VbobYeF7aBR+l+G7nJxK7QgmMn3kP8INQJOfQTtzKF5HHw+rMP?= =?us-ascii?Q?Uyxe9WAlzfpkPPSbwBZtdWj/sBCzpNmykunF/eiTASw9IVkcR4sE2Oj8VTVP?= =?us-ascii?Q?e0avHpaojx51gNpdzF8S26g=3D?=
Content-Type: multipart/alternative; boundary="_000_CO1PR05MB83146B1AFD371B0CA3C59BD1D53C9CO1PR05MB8314namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR05MB8314.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: caa4a4cc-911e-4eee-db29-08d9f6f317bc
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2022 17:36:58.4125 (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: /3EmG6qeQqjgvhl/NHF/P7O4bAyFfrAkGdULt5Q+JPnggTBHcDvQPTUBYk0P3pBzKmiMpSUCio2BPFbFAfvXpg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6444
X-Proofpoint-GUID: NZZXILA2RccgqWP20gN98iQrBy24ebz3
X-Proofpoint-ORIG-GUID: NZZXILA2RccgqWP20gN98iQrBy24ebz3
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-02-23_09,2022-02-23_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 adultscore=0 clxscore=1015 phishscore=0 mlxscore=0 mlxlogscore=652 priorityscore=1501 malwarescore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202230100
Archived-At: 
Subject: [spring] Update on merging draft-hegde-spring-mpls-seamless-sr and draft-dskc-bess-bgp-car-problem-statement
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, 23 Feb 2022 17:37:07 -0000

--_000_CO1PR05MB83146B1AFD371B0CA3C59BD1D53C9CO1PR05MB8314namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

WG,

Folks may remember that the draft-hegde-spring-mpls-seamless-sr and
 draft-dskc-bess-bgp-car-problem-statement have been presented in Spring wg
 session in IETF 110. Given the documents have many things in common,
 the Spring wg chairs advised the authors of both documents to collaborate
 and provide a common document
 describing the requirements for inter-domain intent-aware routing solution=
.

Thanks to Jim Uttaro for initiating the collaboration in January 2021
between the authors. Both the authors have been meeting regularly since
June 2021 and thanks to Joel Halpern for joining these meetings.
We have made some progress, agreeing to certain sections of the document.
Few more sections of the document are pending review and both authors agree
to produce the first version of the document ready for WG review.

Here is an update on the progress made
so far and will continue to provide frequent update as we make progress.
We are hopeful to publish the 00 version of the document for IETF 113.

The authors have agreed on the following sections of the common document.
1.           Typical large-scale network deployment scenarios
2.           Use cases for Inter-domain intent-aware routing
3.           Deployment use cases
4.           Transport intent requirements

The authors are in discussion on the following sections of the common docum=
ent.
1.           Name of the document
2.           Table of Contents
3.           Deployment requirements
4.           Architecture requirements
5.           Traffic Steering requirements
6.           Scaling requirements

The authors are yet to discuss on the following sections of the common docu=
ment.
1.           OAM requirements
2.           Network Availability requirements
3.           Service intent requirements


Rgds
Shraddha


--_000_CO1PR05MB83146B1AFD371B0CA3C59BD1D53C9CO1PR05MB8314namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











WG,


 


Folks may remember that the draft-hegde-spring-mpls-=
seamless-sr and



 draft-dskc-bess-bgp-car-problem-statement have=
 been presented in Spring wg



 session in IETF 110. Given the documents have =
many things in common,



 the Spring wg chairs advised the authors of bo=
th documents to collaborate



 and provide a common document 


 describing the requirements for inter-domain i=
ntent-aware routing solution.



 


Thanks to Jim Uttaro for initiating the collaboratio=
n in January 2021



between the authors. Both the authors have been meet=
ing regularly since



June 2021 and thanks to Joel Halpern for joining the=
se meetings.



We have made some progress, agreeing to certain sect=
ions of the document.



Few more sections of the document are pending review=
 and both authors agree



to produce the first version of the document ready f=
or WG review.



 


Here is an update on the progress made 

so far and will continue to provide frequent update =
as we make progress.



We are hopeful to publish the 00 version of the docu=
ment for IETF 113.


 


The authors have agreed on the following sections of=
 the common document.


1.        &n=
bsp;  Typical large-scale network deployment scenarios


2.        &n=
bsp;  Use cases for Inter-domain intent-aware routing


3.        &n=
bsp;  Deployment use cases


4.        &n=
bsp;  Transport intent requirements


 


The authors are in discussion on the following secti=
ons of the common document.


1.        &n=
bsp;  Name of the document


2.        &n=
bsp;  Table of Contents


3.        &n=
bsp;  Deployment requirements


4.        &n=
bsp;  Architecture requirements


5.        &n=
bsp;  Traffic Steering requirements


6.        &n=
bsp;  Scaling requirements


 


The authors are yet to discuss on the following sect=
ions of the common document.


1.        &n=
bsp;  OAM requirements


2.        &n=
bsp;  Network Availability requirements


3.        &n=
bsp;  Service intent requirements


 


 


Rgds


Shraddha


 






--_000_CO1PR05MB83146B1AFD371B0CA3C59BD1D53C9CO1PR05MB8314namp_--


From nobody Wed Feb 23 17:31:58 2022
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 10C0D3A1259; Wed, 23 Feb 2022 17:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level: 
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuuR6lHQZrk9; Wed, 23 Feb 2022 17:31:49 -0800 (PST)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1B3A1273; Wed, 23 Feb 2022 17:31:28 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.83]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee76216dfee92f-e688a; Thu, 24 Feb 2022 09:31:26 +0800 (CST)
X-RM-TRANSID: 2ee76216dfee92f-e688a
X-RM-TagInfo: emlType=0                                       
X-RM-SPAM-FLAG: 00000000
Received: from CMCCPC (unknown[223.104.39.65]) by rmsmtp-syy-appsvrnew02-12027 (RichMail) with SMTP id 2efb6216df0ca60-a116e;  Thu, 24 Feb 2022 09:27:43 +0800 (CST)
X-RM-TRANSID: 2efb6216df0ca60-a116e
From: =?utf-8?B?5YiY5q+F5p2+?= 
To: 
Cc: "'SPRING WG'" , "'draft-hu-spring-segment-routing-proxy-forwarding'" 
Date: Thu, 24 Feb 2022 09:31:25 +0800
Message-ID: <0c6a01d8291e$3e1682d0$ba438870$@chinamobile.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C6B_01D82961.4C3BE5B0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdgpHWeyOhM+XyFKRXW4CxY0qVjuPw==
Content-Language: zh-cn
Archived-At: 
Subject: Re: [spring]  =?utf-8?q?Re=EF=BC=9A_Re=3A__IPR_poll_-_draft-hu-spring?= =?utf-8?q?-segment-routing-proxy-forwarding?=
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, 24 Feb 2022 01:31:55 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0C6B_01D82961.4C3BE5B0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Bruno,

=20

Thank you for reminding me. I have found my e-mail on the list. Please =
help to check if it=E2=80=99s available.

[spring] Re =
 =EF=BC=9A IPR poll - draft-hu-spring-segment-routing-proxy-forwarding =
(ietf.org)

=20

Best Regards

Yisong

=E5=8F=91=E4=BB=B6=E4=BA=BA: bruno.decraene@orange.com =
=20
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022=E5=B9=B42=E6=9C=8824=E6=97=A5 =
01:13
=E6=94=B6=E4=BB=B6=E4=BA=BA: Yisong Liu 
=E6=8A=84=E9=80=81: SPRING WG ; =
draft-hu-spring-segment-routing-proxy-forwarding =

=E4=B8=BB=E9=A2=98: RE: Re=EF=BC=9A Re: [spring] IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding

=20

Hi Yisong,

=20

Thanks for your reply.

=20

At the time, I could not find your email on the list based on your email =
address or thread:

https://mailarchive.ietf.org/arch/msg/spring/lqY1bGYmiRxTfaezeddVfgolXtk/=


https://mailarchive.ietf.org/arch/browse/spring/?q=3Dfrom%3Aliuyisong%40c=
hinamobile.com =
 &so=3Dsubject

=20

(Even as of today, the mailarchive seems to return different answers to =
the same request=E2=80=A6)

=20

--Bruno

=20

=20

Orange Restricted

From: Yisong Liu  >=20
Sent: Monday, February 21, 2022 2:47 AM
To: DECRAENE Bruno INNOV/NET  >; =
draft-hu-spring-segment-routing-proxy-forwarding =
 >
Cc: SPRING WG  >
Subject: Re=EF=BC=9A Re: [spring] IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding

=20

Hi Bruno,

=20

I have replied about a month ago. Please check the exported mail in the =
attached files.

=20

Best Regards

Yisong

=20

=E5=8F=91=E4=BB=B6=E4=BA=BA: bruno.decraene =
=20

=E6=97=B6=E9=97=B4: 2022/02/19(=E6=98=9F=E6=9C=9F=E5=85=AD)01:12

=E6=94=B6=E4=BB=B6=E4=BA=BA: =
draft-hu-spring-segment-routing-proxy-forwarding =
 ;

=E6=8A=84=E9=80=81=E4=BA=BA: SPRING WG  ;

=E4=B8=BB=E9=A2=98: Re: [spring] IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding

Hi authors,

=20

If I=E2=80=99m not mistaken, we received a reply from:

1.	 =
 Re: [spring] IPR poll - draft-hu-spring-segment-r=E2=80=A6  Huaimo =
Chen
2.	 =
 Re: [spring] IPR poll - draft-hu-spring-segment-r=E2=80=A6  Huzhibo
3.	 =
 Re: [spring] IPR poll - draft-hu-spring-segment-r=E2=80=A6  yaojunda

=20

So we are missing replies from the following co-authors:

C. Bowers

Y. Zhu

Y. Liu

=20

Thank you,

--Bruno

=20

=20

=20

Orange Restricted

From: spring  > =
On Behalf Of bruno.decraene@orange.com =
=20
Sent: Thursday, January 13, 2022 11:18 AM
To: SPRING WG  >; =
draft-hu-spring-segment-routing-proxy-forwarding@ietf.org =
=20
Subject: [spring] IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding

=20

Hi authors, contributors, WG

=20

In preparation of the WG adoption call on =
draft-hu-spring-segment-routing-proxy-forwarding [1], this email starts =
a poll for IPR.

=20

If you are an author or contributor to the subject document, please =
respond to this email.

1.	In your response, please indicate if all relevant IPR has been =
disclosed.                                                   =20
2.	If you know of relevant IPR that has not been disclosed, please state =
that and describe how this gap is being addressed.

=20

Even if you are not a contributor or author, if you know of relevant =
IPR, please ensure that it has been dislosed as discussed in BCP 79.

=20

If you know of someone else IPR that you believe is relevant and not =
disclosed, please file a third party IPR disclosure.

=20

Thanks,

Regards,

Bruno, Jim, Joel

[1]    =
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-fo=
rwarding/                                                    =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
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
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.

------=_NextPart_000_0C6B_01D82961.4C3BE5B0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi Bruno,
 
Thank =
you for reminding me. I have found my e-mail on the list. Please help to =
check if it=E2=80=99s available.
[spring] Re=EF=BC=9A IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding =
(ietf.org)
 
Best =
Regards
Yisong
=E5=8F=91=E4=BB=B6=E4=BA=BA: bruno.decraene@orange.com =
<bruno.decraene@orange.com> 
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=
=B4: 2022=E5=B9=B42=E6=9C=8824=E6=97=A5 01:13
=E6=94=B6=E4=BB=B6=E4=BA=BA: Yisong Liu =
<liuyisong@chinamobile.com>
=E6=8A=84=E9=80=81: SPRING WG =
<spring@ietf.org>; =
draft-hu-spring-segment-routing-proxy-forwarding =
<draft-hu-spring-segment-routing-proxy-forwarding@ietf.org>
=E4=B8=BB=E9=A2=98: RE: Re=EF=BC=9A Re: [spring] IPR =
poll - =
draft-hu-spring-segment-routing-proxy-forwarding=

 
Hi Yisong,
 
Thanks for your reply.
 
At the time, I could not find your email on the list based =
on your email address or thread:
https://mailarchive.ietf.org/arch/msg/spring/lqY1bGYmiRxTfaezed=
dVfgolXtk/
https://mailarchive.ietf.org/arc=
h/browse/spring/?q=3Dfrom%3Aliuyisong%40chinamobile.com&so=3Dsubject<=
/a>
 
(Even as of today, the mailarchive seems to return different =
answers to the same request=E2=80=A6)
 
--Bruno
 
 
Orange Restricted
From: Yisong Liu <liuyisong@chinamobile.com&g=
t; 
Sent: Monday, February 21, 2022 2:47 AM
To: =
DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com&g=
t;; draft-hu-spring-segment-routing-proxy-forwarding <draft-hu-spring-segment-routing-proxy-forwarding@ietf.org>
=
Cc: SPRING WG <spring@ietf.org>
Subject: Re=EF=BC=9A Re: [spring] IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding
 
Hi Bruno,
 
I have replied about a month ago. Please check =
the exported mail in the attached =
files.
 
Best =
Regards
Yisong
 
=E5=8F=91=E4=BB=B6=E4=BA=BA: =
bruno.decraene
=E6=97=B6=E9=97=B4: =
2022/02/19(=E6=98=9F=E6=9C=9F=E5=85=AD)01:12
=E6=94=B6=E4=BB=B6=E4=BA=BA: =
draft-hu-spring-segment-routing-proxy-forwarding;<=
/span>
=E6=8A=84=E9=80=81=E4=BA=BA: =
SPRING =
WG;
=E4=B8=BB=E9=A2=98: Re: =
[spring] IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding=

Hi =
authors,
 
If I=E2=80=99m =
not mistaken, we received a reply from:
  1. Re: [spring] IPR poll - =
draft-hu-spring-segment-r=E2=80=A6  Huaimo =
Chen
  2. Re: [spring] IPR poll - =
draft-hu-spring-segment-r=E2=80=A6  Huzhibo
  3. Re: [spring] IPR poll - =
draft-hu-spring-segment-r=E2=80=A6  yaojunda
 
So we are =
missing replies from the following co-authors:
C. =
Bowers
Y. =
Zhu
Y. =
Liu
 
Thank =
you,
--Bruno
 
 
 
Orange Restricted
From: spring <spring-bounces@ietf.org> =
On Behalf Of bruno.decraene@orange.comSent: Thursday, January 13, 2022 11:18 AM
To: SPRING =
WG <spring@ietf.org>; draft-hu-spring-segment-routing-proxy-forwarding@ietf.org
Subj=
ect: [spring] IPR poll - =
draft-hu-spring-segment-routing-proxy-forwarding
 
Hi authors, =
contributors, WG
 
In preparation =
of the WG adoption call on =
draft-hu-spring-segment-routing-proxy-forwarding [1], this email starts =
a poll for IPR.
 
If you are an =
author or contributor to the subject document, please respond to this =
email.
  1. In your =
response, please indicate if all relevant IPR has been =
disclosed.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=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. If you know of =
relevant IPR that has not been disclosed, please state that and describe =
how this gap is being addressed.
 
Even if you =
are not a contributor or author, if you know of relevant IPR, please =
ensure that it has been dislosed as discussed in BCP =
79.
 
If you know of =
someone else IPR that you believe is relevant and not disclosed, please =
file a third party IPR disclosure.
 
Thanks,
Regards,
Bruno, Jim, =
Joel
[1]=C2=A0=C2=A0=
=C2=A0 https://datatracker.ietf.org/doc/draft-hu-spring-segme=
nt-routing-proxy-forwarding/=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
_______________________________________________________________=
__________________________________________________________
 
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.
_______________________________________________________________=
__________________________________________________________
 
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.
_______________________________________________________________=
__________________________________________________________
 
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.

------=_NextPart_000_0C6B_01D82961.4C3BE5B0--





From nobody Thu Feb 24 03:17:30 2022
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 279713A0EA5 for ; Thu, 24 Feb 2022 03:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level: 
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyxOsOvZ2kHE for ; Thu, 24 Feb 2022 03:17:22 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 D50FE3A094B for ; Thu, 24 Feb 2022 03:17:21 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4K49Nc0Nf8zys5 for ; Thu, 24 Feb 2022 12:17:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645701440; bh=KnqQQ/2ISC14/jSqxcn04T4VyaJi7krH/ShaXojMjb8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=oWVSRapjY8OuOrtIkEergrx1LnmQzIEgSuBfDoDpEx5jPxXuK4A9Eam0eUDYREAT9 Pi9i8mW5hHDs1IFt3fjyhGv1USV6dLyMULDfv3jhV/nXCoiEh2zOCzalkJmWWaM7OT 7tzNuxLt2FP28X22Oag+x+1mJuxVuPtjE/90B6spikxHgPrskA6qzQLkRYkzx7PlzB 37V8gHcmrNm2PAZ95djU7cWPCsY1usIodE4kBgTF4sT5eIajPtZxlbmu6gwc1xhG+c IWHiPUt9YI8BKGgrDyxeVWyLe6QJLPzonIbm2XEQey/RjnkYxs+jTg4Yc3VIk4bkOc dGGkWCLQBPUvQ==
From: 
To: SPRING WG 
Thread-Topic: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAhCCJgA
Date: Thu, 24 Feb 2022 11:17:19 +0000
Message-ID: <16252_1645701439_6217693F_16252_172_1_261dad9f8f154ff299920b2359f7d4d9@orange.com>
References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com>
In-Reply-To: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-24T11:17:16Z;  MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-24T11:17:16Z
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: e8585005-f643-4c48-b963-343668e6d7c5
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0
x-originating-ip: [10.115.27.51]
Content-Type: multipart/alternative; boundary="_000_261dad9f8f154ff299920b2359f7d4d9orangecom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding
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, 24 Feb 2022 11:17:27 -0000

--_000_261dad9f8f154ff299920b2359f7d4d9orangecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear WG,

Thank you for all comments received during this WG last call and for the de=
tailed review of the document.

In term of requirement, there is support for the need to protect SR-Policy =
traffic from node failure both:
a) for the protection/FRR duration (from failure detection to the start of =
the IGP convergence)
b) during the subsequent IGP restoration (from the beginning of the IGP con=
vergence in the routing domain to the end of the re-computation and install=
ation of SR-policy on all ingress).

"a" is addressed by [2], with the exception of binding SIDs.

Regarding "b", in term of the solution, two aspects have been discussed:
I) the relation with the solution proposed in [2]
II) the IGP extension for Proxy Forwarding proposed in [1]

[1] https://datatracker.ietf.org/doc/html/draft-hu-spring-segment-routing-p=
roxy-forwarding
[2] https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protect=
ion-sr-te-paths

I) Regarding the relation with the solution proposed in [2]:
- there is a claim that [1] provides better benefits in terms of incrementa=
l deployment. During discussions it appeared to be true in some cases but t=
hat the increased benefit seems relatively limited
- there has been a claim that [2] already solves the problem. During discus=
sions, it appeared that the solution proposed in [2] does not seem to work =
as claimed.
- problem space is twofold: a local fast reroute solution "a" and a global =
IGP rerouting solution "b". In principle, both may be described in a single=
 or two documents.

II) Regarding the IGP extension proposed in [1], the discussion during this=
 adoption call has not clarified the need to define a new IGP extension com=
pared to re-using the existing Mirror SID defined in RFC 8402 (SR Architect=
ure) and RFC 8667 (IS-IS extension).
Authors of [1] are suggested to dig on this point.
In the meantime, the need for a new IGP extension for Proxy Forwarding has =
not been demonstrated.


Coming back to "a", [1] also covers a solution for the FRR protection of bi=
nding SIDs.
The problem seems real for networks using binding SIDs. The document propos=
es to advertise them in IGP. However, during discussions, it appears that:
- main IS-IS PDU (hello, LSP) are not well suited for the requirements (sco=
pe of messages, capability of messages, scaling). During the call, the docu=
ment has been changed to using CS-LSP which may not be well deployed and do=
es not fully address the IGP scalability point.
- it seems debatable to choose to advertise the backup states in the IGP wh=
en the nominal states have not been installed by the IGP but through existi=
ng protocols extensions.

Authors of [1] are suggested to dig on this point and study in depth the ex=
isting configuration/signaling protocols used to install the nominal path a=
nd study how they can be used, including extended if needed, to address the=
 need to install the backup states on the PLR.

In the meantime, the call for adoption of draft-hu-spring-segment-routing-p=
roxy-forwarding is suspended.

Finally, there is the question of whether these different aspects are bette=
r addressed in one document or in two documents.
This will be further evaluated by chairs when we'll have a revised [1] docu=
ment addressing the two requested points. However we note that [1] covers b=
oth a global IGP aspect (restoration) and a local restoration aspect (bindi=
ng SID) hence having two documents based on this dichotomy would not even s=
olve the interactions between the two documents. In addition,  _assuming th=
at [1] does its homework and fully addresses the two above points_, if they=
 wish so, authors of both documents may discuss and may come back with prop=
osals on how to structure the whole solution space.

Yours,
--Bruno, Jim, Joel.



Orange Restricted
From: spring  On Behalf Of bruno.decraene@orange.c=
om
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG 
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-=
forwarding

Dear WG,

This message starts a 2 week WG adoption call, ending 27/01/2022, for draft=
-hu-spring-segment-routing-proxy-forwarding
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw=
arding/

After review of the document please indicate support (or not) for WG adopti=
on of the document to the mailing list.

Please also provide comments/reasons for your support (or lack thereof) as =
this is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on or review the document, please state this exp=
licitly. This gives the chairs an indication of the energy level of people =
in the working group willing to work on the document.

Thanks!
Bruno, Jim, Joel

___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

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

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

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



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

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

Thank you.

___________________________________________________________________________=
______________________________________________

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

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


--_000_261dad9f8f154ff299920b2359f7d4d9orangecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













Dear WG,


 


Thank you for all =
comments received during this WG last call and for the detailed
 review of the document.


 


In term of require=
ment, there is support for the need to protect SR-Policy traffic
 from node failure both:


a) for the protect=
ion/FRR duration (from failure detection to the start of the
 IGP convergence) 


b) during the subs=
equent IGP restoration (from the beginning of the IGP convergence
 in the routing domain to the end of the re-computation and installation of=
 SR-policy on all ingress).


 


"a" is a=
ddressed by [2], with the exception of binding SIDs.<=
/o:p>


 


Regarding "b&=
quot;, in term of the solution, two aspects have been discussed:


I) the relation wi=
th the solution proposed in [2]


II) the IGP extens=
ion for Proxy Forwarding proposed in [1]


 


[1]

https://datatracker.ietf.org/doc/html/draft-hu-spring-segment-routing-proxy=
-forwarding


[2]

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-=
sr-te-paths


 


I) Regarding the r=
elation with the solution proposed in [2]:


- there is a claim=
 that [1] provides better benefits in terms of incremental
 deployment. During discussions it appeared to be true in some cases but th=
at the increased benefit seems relatively limited


- there has been a=
 claim that [2] already solves the problem. During discussions,
 it appeared that the solution proposed in [2] does not seem to work as cla=
imed.


- problem space is=
 twofold: a local fast reroute solution "a" and a global IGP
 rerouting solution "b". In principle, both may be described in a=
 single or two documents.


 


II) Regarding the =
IGP extension proposed in [1], the discussion during this
 adoption call has not clarified the need to define a new IGP extension com=
pared to re-using the existing Mirror SID defined in RFC 8402 (SR Architect=
ure) and RFC 8667 (IS-IS extension).


Authors of [1] are=
 suggested to dig on this point.


In the meantime, t=
he need for a new IGP extension for Proxy Forwarding has not
 been demonstrated.









Coming back to =
220;a”, [1] also covers a solution for the FRR protection of binding
 SIDs.


The problem seems =
real for networks using binding SIDs. The document proposes
 to advertise them in IGP. However, during discussions, it appears that:


- main IS-IS PDU (=
hello, LSP) are not well suited for the requirements (scope
 of messages, capability of messages, scaling). During the call, the docume=
nt has been changed to using CS-LSP which may not be well deployed and does=
 not fully address the IGP scalability point.


- it seems debatab=
le to choose to advertise the backup states in the IGP when
 the nominal states have not been installed by the IGP but through existing=
 protocols extensions.


 


Authors of [1] are=
 suggested to dig on this point and study in depth the existing
 configuration/signaling protocols used to install the nominal path and stu=
dy how they can be used, including extended if needed, to address the need =
to install the backup states on the PLR.


 


In the meantime, t=
he call for adoption of draft-hu-spring-segment-routing-proxy-forwarding
 is suspended.


 


Finally, there is =
the question of whether these different aspects are better
 addressed in one document or in two documents.=



This will be furth=
er evaluated by chairs when we’ll have a revised [1] document
 addressing the two requested points. However we note that [1] covers both =
a global IGP aspect (restoration) and a local restoration aspect (binding S=
ID) hence having two documents based on this dichotomy would not even solve=
 the interactions between the two
 documents. In addition,  _assuming that [1] does its homework and ful=
ly addresses the two above points_, if they wish so, authors of both docume=
nts may discuss and may come back with proposals on how to structure the wh=
ole solution space.




Yours,


--Bruno, Jim, =
Joel.


 


 



Orange Restricted








Fro=
m:
 spring <spring-bounces@ietf.org> On Behalf Of bruno.decraene@=
orange.com

Sent: Thursday, January 13, 2022 11:19 AM

To: SPRING WG <spring@ietf.org>

Subject: [spring] WG adoption call - draft-hu-spring-segment-routing=
-proxy-forwarding






 


Dear WG,<=
/o:p>


 


This message s=
tarts a 2 week WG adoption call, ending 27/01/2022, for draft-hu-spring-seg=
ment-routing-proxy-forwarding


https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-prox=
y-forwarding/


 


After review o=
f the document please indicate support (or not) for WG adoption of the docu=
ment to the mailing list.


 


Please also pr=
ovide comments/reasons for your support (or lack thereof) as this is a stro=
nger way to indicate your (non) support as this
 is not a vote.    &nbs=
p;  


 


If you are wil=
ling to work on or review the document, please state this explicitly. This =
gives the chairs an indication of the energy level
 of people in the working group willing to work on the document.=



 


Thanks!


Bruno, Jim, Joel


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


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


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






______________________________________________________________________=
___________________________________________________

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


From nobody Thu Feb 24 03:21:15 2022
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 3DEA73A11BF; Thu, 24 Feb 2022 03:21:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164570167116.15899.6925021171648652966@ietfa.amsl.com>
Date: Thu, 24 Feb 2022 03:21:11 -0800
Archived-At: 
Subject: [spring] The SPRING WG has placed draft-hu-spring-segment-routing-proxy-forwarding in state "Call For Adoption By WG Issued"
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, 24 Feb 2022 11:21:12 -0000

The SPRING WG has placed draft-hu-spring-segment-routing-proxy-forwarding in
state Call For Adoption By WG Issued (entered by Bruno Decraene)

The document is available at
https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/

Comment:
https://mailarchive.ietf.org/arch/msg/spring/C_6p_1y1JP7BSAe1_8gmkkgci_s/


From nobody Thu Feb 24 03:25:05 2022
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 783643A0F04 for ; Thu, 24 Feb 2022 03:25:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffz_1h33iFvb for ; Thu, 24 Feb 2022 03:24:58 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 5D5D93A1142 for ; Thu, 24 Feb 2022 03:24:58 -0800 (PST)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4K49YN4QDBz101l for ; Thu, 24 Feb 2022 12:24:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645701896; bh=Y7mfOWeq/fqhqHDPd3LijtWmbHVzgifCNnyDdgaUZ1A=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=herFKdA5jHGCmFHndy3GS3BtmKHJEcic2/gK7bu+wExm3VUfTZJhslJ6rt6S5YSpF XJ3hjY1pa9qjr94yeomePNOu5ysvp78r64fa4iup4eCCU+QzgHYScmNFIAdP6KEUI6 8u1+mwf3uhSxnCkxUvQ3+Tv26u4+6mW4jmTAJZN/QYrRplm53Ber/sVsu16f6F1Vkx mem5ZKniYuxwQHUB3EtJAb1IHjjfYkCi3fHIpO6ntsf7z4201t01csaZM5B8kHq4Kh HrmRJxHXTzikGyRg1d0gvPHiWiLffjX/ZPsLcqdI1zEpuMxZOmpOD2Yg37pe6W6doZ YXLRci2qblxiQ==
From: 
To: SPRING WG 
Thread-Topic: Tags changed for draft-hu-spring-segment-routing-proxy-forwarding
Thread-Index: AQHYKXDl9NHGifa900e+mLhUCHGylqyij03A
Date: Thu, 24 Feb 2022 11:24:56 +0000
Message-ID: <22403_1645701896_62176B08_22403_185_1_177f2b6236f5464ca566e3e6022c597a@orange.com>
References: <164570178366.15843.15891014840496976141@ietfa.amsl.com>
In-Reply-To: <164570178366.15843.15891014840496976141@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-24T11:24:54Z;  MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-02-24T11:24:54Z
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: e45d733a-e17c-4f2b-9a17-15cbfebeee6b
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0
x-originating-ip: [10.115.27.51]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [spring] FW: Tags changed for draft-hu-spring-segment-routing-proxy-forwarding
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, 24 Feb 2022 11:25:04 -0000

DQoNCg0KT3JhbmdlIFJlc3RyaWN0ZWQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IElFVEYgU2VjcmV0YXJpYXQgPGlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmc+IA0K
U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI0LCAyMDIyIDEyOjIzIFBNDQpUbzogZHJhZnQtaHUt
c3ByaW5nLXNlZ21lbnQtcm91dGluZy1wcm94eS1mb3J3YXJkaW5nQGlldGYub3JnOyBzcHJpbmct
Y2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBUYWdzIGNoYW5nZWQgZm9yIGRyYWZ0LWh1LXNwcmlu
Zy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZw0KDQoNClRoZSB0YWdzIG9uIGRyYWZ0
LWh1LXNwcmluZy1zZWdtZW50LXJvdXRpbmctcHJveHktZm9yd2FyZGluZyBoYXZlIGJlZW4NCmNo
YW5nZWQgYnkgQnJ1bm8gRGVjcmFlbmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1odS1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXByb3h5LWZvcndhcmRpbmcvDQoNClRh
Z3MgIlBvbGxlZCBmb3IgV0cgYWRvcHRpb24gYnV0IG5vdCBhZG9wdGVkIiwgIlJldmlzZWQgSS1E
IE5lZWRlZCAtIElzc3VlDQpyYWlzZWQgYnkgV0ciIGFkZGVkLg0KDQpDb21tZW50Og0KaHR0cHM6
Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvX2U3Z0NGUVNOY05FLUpyVlBJ
RnVYeHJyYWRVLw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl
dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls
ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91
IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw
YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy
dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p
cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0
ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm
YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u
dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw
cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig
Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl
bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt
ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh
bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj
aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK


From nobody Thu Feb 24 05:53:43 2022
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 985DD3A13E0; Thu, 24 Feb 2022 05:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6eEx8c3b3P0; Thu, 24 Feb 2022 05:52:51 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 057AC3A0CF8; Thu, 24 Feb 2022 05:52:50 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id q8so2750729iod.2; Thu, 24 Feb 2022 05:52:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=oWk4znE/QDPBlWy+xPPC88NCq2AoyycsndHrDU1o1AA=; b=QERGoCUK5mh27Vm7GM8pNtNiXqMKQglTST+WhovF3rySg8d7uQfFhZjNfS+XhTBjcA 3aTMYSHp9sRbXlHwV5tKX9IFc20nrFPeN9MrHPeEO+fQE1HJg1LKjg+490pas4wqfS19 LoUIvnd7yo4g3VOP1ls4I60y5CYiBZ0imdvs6tz0+G5WB4kNWcd2zwEfh0uxovlCz3iV 2SH4KtElV5bsxx967I/OqyGuudWJY038kB2h9gxezN/WSQ0ulDA3bqutBWy3hBDxoWGy 8U+RVidRtDCfS6hNh8rvAAJEIQHri3aa8mBnyv/tpsmXVQyCzHL7ITp3Qftz8/5pj8xN uWqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=oWk4znE/QDPBlWy+xPPC88NCq2AoyycsndHrDU1o1AA=; b=UweBYBLS1b80xSA7s+t1gla1H1AOliuKiPpJqhYEpv5m4zaUhknrtmjAUbPbAHUlue y8xrBrcoNGjMKnm1ma8UCPSc3rk3f/xMYXmdzp2PQSn9GVbAOeGkky4g5hkFUwNaIoeW 17xEvQj0aCLpHF8dgID4bY/cGZMMIXIWeT0gywe4d/jKWZSkir+jcpqMtb+jy19RKlp3 a7rwVawis0O5bUc1jJgmSk6sd4Bn/UOwwLlNtde29lzWYnGt7x+g3LXqfQR4iU49+vUN Z2fmnZzuq4S6+c9o1a+DNpebMxS/7b/cINCTEAnOAbyzsbHpPPFuZ4sNiUEnHqDmUey6 dbcg==
X-Gm-Message-State: AOAM530GNFFcdHKOclOXgZ9H0JhZ8dKSXFdHspY+Lt3ypGiF4OeDdJLG 8gM9T00O26PtnopljsaXHfW2G8ErDMhwRA==
X-Google-Smtp-Source: ABdhPJw3sPra1OXerss5Ojd2jp8LuPSdgA78zhNnFZhzzySPH5ys68ZNsnw+uchvxm8jE1Hs0oR/2g==
X-Received: by 2002:a02:7115:0:b0:2fa:a6d9:9e10 with SMTP id n21-20020a027115000000b002faa6d99e10mr2114420jac.293.1645710769940;  Thu, 24 Feb 2022 05:52:49 -0800 (PST)
Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([40.97.200.53]) by smtp.gmail.com with ESMTPSA id h4sm1753790ilh.71.2022.02.24.05.52.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Feb 2022 05:52:49 -0800 (PST)
From: Tarek Saad 
To: Greg Mirsky 
CC: mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" 
Thread-Topic: [spring] Comments on draft-saad-mpls-miad-usecases
Thread-Index: AVFxTFV5vHqnRHba8IiY5vLVgUYh1o1wb/nd
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 24 Feb 2022 13:52:45 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-CA
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB2150B2E45032A4DF5839AD14FC3D9DM5PR1901MB2150_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 24 Feb 2022 13:52:56 -0000

--_000_DM5PR1901MB2150B2E45032A4DF5839AD14FC3D9DM5PR1901MB2150_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

Thanks for your comments. I=92ve addressed several of your comments. The la=
test diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draf=
t-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/t=
saad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt

Regards,
Tarek (for co-authors)

From: spring  on behalf of Greg Mirsky 
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org , mpls , pals@ietf.org , DetNet WG , spring 
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze=
 essential use cases in the scope of the work at the Open DT. Attached, ple=
ase find a copy of the draft with my notes and some editorial suggestions. =
I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

--_000_DM5PR1901MB2150B2E45032A4DF5839AD14FC3D9DM5PR1901MB2150_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Hi Greg,=



 


Thanks for your com=
ments. I=92ve addressed several of your comments. The latest diffs (revisio=
n to be uploaded soon) can be found at:


https://to=
ols.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpl=
s-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-d=
ev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt


 


Regards,=



Tarek (for co-autho=
rs)


 




From:
spring <spring-b=
ounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com><=
br>
Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls-miad-=
usecases@ietf.org>, mpls <mpls@ietf.org>, pals@ietf.org <pals@i=
etf.org>, DetNet WG <detnet@ietf.org>, spring <spring@ietf.org&=
gt;

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,<=
/o:p>




thank you for your =
work putting this document together. It helps to analyze essential use case=
s in the scope of the work at the Open DT. Attached, please find a copy of =
the draft with my notes and some editorial suggestions.
 I hope you'll find some of them helpful.






I am looking forwar=
d to your feedback and questions.






 






Regards,=







Greg










--_000_DM5PR1901MB2150B2E45032A4DF5839AD14FC3D9DM5PR1901MB2150_--


From nobody Thu Feb 24 17:11:00 2022
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 39D123A0E51; Thu, 24 Feb 2022 17:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRtH4VYM7zi1; Thu, 24 Feb 2022 17:09:30 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450: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 C022E3A07F5; Thu, 24 Feb 2022 17:09:29 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id g20so5286929edw.6; Thu, 24 Feb 2022 17:09:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O2PFSSjUuMyzuZe1Wrh5AYTbM+arjq9SnxJaEwSq3ps=; b=oW9Zu8raORQovcWiqEuvPaFLU/zh2pyyAZ0srDouPlY/C3BpTHj6ADeWA8ZuTtni8t kZZaA0mWk8wyUvhgVa+KLyALTtsYCJ/Pbo+M+M2Ed0K0UsS9eDdUR5SYPrn3YpJ8xiq5 1McBBJJfRyocZa7VzK+4PCUZQBKFtoz0sFx3+JfrDTixZu77ppcjoycEDP6KgNqQgSoc +prpNtAGAFxtN2WTcomMcPUDK5C5RALJ+9OA/UcfvYam82LuiPxRJxk54ExjGjuP44cf Sd+3lQ1VTSoDmWcKgJ3sRLFK3n4sY9oIPentbPkDimG+Y07qJalhKOIT+QsKmGQt0gMQ yh8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O2PFSSjUuMyzuZe1Wrh5AYTbM+arjq9SnxJaEwSq3ps=; b=vQIs4ojyq9+bNMqKDjDf5+y9gBDX6LHYtAGwGxJjBTGBVd4KSyesPOWlWUUvIqd4zR bAm+uL36sBXXI2QghV5qL6hG0W2jzY7CXPBfWspoIhUlv6HKM31DQYT79vJ+CzBHlIL3 W08yhmiDEibrrF2GzbM1qFG7wkQXKIBZPAY+0ouheCsgl9FrVNOZKDjRBg4tOlYFs+zu jivWUo1JY/PYOCaVnVr5sGTXEkUcnxComWebQKCd9VpFB8HolzFCNl3KY0Gx8WO9oQIB s2Kk4Kgm1EPdrkgEwj5vQ18NHhmPldqGgyDczPAa5ZTbu6XRJp5t+jUgMTjgi7Ml4tVk mwOA==
X-Gm-Message-State: AOAM5305XzcwKYLow686Y9oHVF4hs2TwASrHeAGuYuE/+5591bDmKfP2 aKXPp3qGtIm+jwwWFuryZxuaOQi6IEWcH3uHsl0Op6inMF4=
X-Google-Smtp-Source: ABdhPJyTtTKX3rjkYCwLTMDrREdbwYuTTJyeu89c+0SoFI/5I8JbuI0VwZmtMOuyucCPTGIg1Bkp6PKt1KmZFOcH+H0=
X-Received: by 2002:a05:6402:5cd:b0:412:d3fe:843d with SMTP id n13-20020a05640205cd00b00412d3fe843dmr4987615edx.97.1645751367408; Thu, 24 Feb 2022 17:09:27 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Greg Mirsky 
Date: Thu, 24 Feb 2022 17:09:16 -0800
Message-ID: 
To: Tarek Saad 
Cc: mpls , "pals@ietf.org" , DetNet WG , spring ,  "draft-saad-mpls-miad-usecases@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a49e2205d8cd591f"
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 25 Feb 2022 01:09:35 -0000

--000000000000a49e2205d8cd591f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed
the diff and got several follow-up notes:

   - the new text in the Introduction section explains the ISD as being
   encoded as labels:

within the label stack, e.g., encoded as labels, referred to as In

     Stack Data (ISD), and

I think s/as labels/into label stack elements/ makes the text a bit more
accurate. What do you think?


   - in my earlier comments, I've noted that the informational RFC 8596
   appears not posing any requirements for enhancements in the MPLS data
   plane. If I am missing something, please let me know.
   - I might have missed it earlier. The TSN is the term used for a very
   specific technology developed at IEEE to support, for example, URLLC
   services. The DetNet WG defines the methodology in support of these
   services using IETF technologies - MPLS and IP. I think it would be
   appropriate if an IETF document refers to Deterministic Networking, not
   TSN. What is your opinion?

Regards,
Greg


On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad  wrote:

> Hi Greg,
>
>
>
> Thanks for your comments. I=E2=80=99ve addressed several of your comments=
. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/dr=
aft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com=
/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> 
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring  on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *draft-saad-mpls-miad-usecases@ietf.org <
> draft-saad-mpls-miad-usecases@ietf.org>, mpls ,
> pals@ietf.org , DetNet WG , spring <
> spring@ietf.org>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some
> editorial suggestions. I hope you'll find some of them helpful.
>
> I am looking forward to your feedback and questions.
>
>
>
> Regards,
>
> Greg
>

--000000000000a49e2205d8cd591f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Tarek,
thank you for your thoughtf=
ul=C2=A0consideration of my comments. I've reviewed the diff and got se=
veral follow-up notes:
  • the new text in the Introduction s=
ection explains the ISD as being encoded as labels:
within the label stack, e.g., encoded as labels, referred to =
as In	
=C2=A0	=C2=A0=
 =C2=A0Stack Data (ISD), and
I think s/as labels/into=
 label stack elements/ makes the text a bit more accurate. What do you thin=
k?
  • in my earlier comments, I've noted t=
hat the informational RFC 8596 appears not posing any requirements for enha=
ncements in the MPLS data plane. If I am missing=C2=A0something, please let=
 me know.
  • I might have missed it earlier. The TSN is the term used =
for a very specific technology developed at IEEE to support, for example, U=
RLLC services. The DetNet WG defines the methodology in support of these se=
rvices using IETF technologies - MPLS and IP. I think it would be appropria=
te if an IETF document refers to Deterministic Networking, not TSN. What is=
 your opinion?
Regards,
Greg


On Thu, Feb 2=
4, 2022 at 5:52 AM Tarek Saad <ts=
aad.net@gmail.com> wrote:











Hi Greg,


=C2=A0<=
/span>


Thanks for your comme=
nts. I=E2=80=99ve addressed several of your comments. The latest diffs (rev=
ision to be uploaded soon) can be found at:


https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/i=
d/draft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercon=
tent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.=
txt


=C2=A0<=
/span>


Regards,


Tarek (for co-authors=
)


=C2=A0<=
/span>




From:
spring <spring-bounces@ietf.org<=
/a>> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>, pals@ietf.org <pals@ietf.org>, DetNet WG <detnet@ietf.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,<=
u>




thank you for your wo=
rk putting this document together. It helps to analyze essential use cases =
in the scope of the work at the Open DT. Attached, please find a copy of th=
e draft with my notes and some editorial=C2=A0suggestions.
 I hope you'll find some of them helpful.






I am looking forward =
to your feedback and questions.






=C2=A0<=
/span>






Regards,






Greg













--000000000000a49e2205d8cd591f--


From nobody Thu Feb 24 18:03:27 2022
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 BDCB33A1038; Thu, 24 Feb 2022 18:02:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.502
X-Spam-Level: ***
X-Spam-Status: No, score=3.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, KHOP_HELO_FCRDNS=0.399, 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 5I6SQMBYddAu; Thu, 24 Feb 2022 18:02:40 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE75D3A0B89; Thu, 24 Feb 2022 18:02:38 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 21P22RTP020842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Feb 2022 21:02:33 -0500
Date: Thu, 24 Feb 2022 18:02:27 -0800
From: Benjamin Kaduk 
To: Ketan Talaulikar 
Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com
Message-ID: <20220225020227.GM12881@kduck.mit.edu>
References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
Archived-At: 
Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)
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, 25 Feb 2022 02:02:48 -0000

Hi Ketan,

Thanks for the replies here and the updates in the -18.
I think there are still some open topics, though; more inline.

On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote:
> Hi Ben,
> 
> Thanks for your detailed review and your comments/inputs. Please check
> inline for responses.
> 
> 
> On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker <
> noreply@ietf.org> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-spring-segment-routing-policy-17: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > (1) I may just be misunderstanding things, but I'd like to pull on a thread
> > in §8.4 a bit more.  We say that the headend H learns a BGP route that has
> > a
> > VPN label V, but then the following procedures seem to say that we install
> > a
> > route on the appropriate SR Policy P and that when we receive a packet that
> > matches the route in question, push a label stack including the VPN label,
> > and send the resulting packet out.
> 
> 
> KT> Note that we are sending the packet to the selected BGP NH (i.e. egress
> PE) that advertised the route. The SR Policy is enabling the packets to
> traverse a path that is different from (perhaps) the best-effort IGP
> routing.
> 
> 
> > Nowhere do we say to check the VPN
> > status of the incoming packet,
> 
> 
> KT> That is the ingress part of the forwarding entry which maps the
> incoming traffic over a customer interface to their specific VPN context
> and then performs a lookup in their VPN specific table. This all is
> unchanged.
> 
> 
> > so this seems like it would open a hole in
> > the VPN by allowing "arbitrary" incoming traffic (not marked as specific to
> > V) to enter that VPN.  Is the label V filling some other role than
> > identifying a specific VPN of many VPNs that could run along the route R/r?
> > (This is the only instance of the phrase "VPN label" in the document, and
> > no
> > reference is given, so I'm relying heavily on instinct to ascertain the
> > intent here.)
> >
> 
> KT> I hope my responses clarified that the only thing that is changed here
> by the steering over the SR Policy is the path taken through the network to
> get to the egress PE. Rest is as today. And yes, of course, we have the
> ability to indicate the need for such steering via the matching Color
> Extended community to the BGP route.

Yes, these help clarify that the part we're focusing on in this document is
conceptually "after" the determination of the incoming VPN, and so there
isn't any new processing needed for it.  Thanks for the explanation.

> 
> >
> > (2) The security considerations says that this document does not define any
> > new protocol extensions and (accordingly) does not introduce any further
> > security considerations.  The first part of this seems false, not least
> > since we define the meaning of the "CO" bits in the Color Extended
> > Community.  I'm pretty sure that makes the second part also false, and we
> > need to discuss the security considerations relating to imposing SR
> > Policies
> > based only on color and not next-hop.  Alvaro has also noted additional
> > aspects where security considerations are missing.
> >
> 
> KT> Ack. We will add text in the security consideration sections for the CO
> steering modes.

What about the SR-DB concept and other new concepts that Alvaro identified?
Aren't there security and manageability considerations there as well?

> 
> >
> > (3) The Discriminator as defined in §2.5 does not seem wide enough to be
> > able to provide the needed properties.  Some later clarification in §2.6
> > implies that the definition in §2.5 is incomplete and the width is actually
> > appropriate, but in either case §2.5 seems inadequate in its current form.
> > (Details in the COMMENT.)
> >
> 
> KT> 32 bit is wide enough and please see further response below.

I think I'm still failing to understand exactly why; more below.

> >
> > (4) Section 2.11 contains the statement, "A valid SR Policy is instantiated
> > in the forwarding plane."
> >
> > Is this a statement of fact (i.e., a consequence of the definition of
> > "valid") or a mandate for something (e.g., the headend) to take action to
> > make it so?  Given that the point of SR is to be stateless on nodes other
> > than the headend, I suspect the former, but if we are relying on the
> > headend
> > (or some other entity) to take action to ensure this is the case, that
> > needs
> > to be a clearly stated normative requirement.
> >
> 
> KT> The validity of a candidate path and as an extension, the SR Policy is
> discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its
> constructs are instantiated in the forwarding plane.

Would it make sense to say something like "In order to be considered valid,
an SR policy needs to be instantiated in the forwarding plane (Section 5)"?

> 
> >
> > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]."
> > There's nothing in the IANA registry for SAFI
> > (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml)
> > about
> > LISP, and RFC 6830 doesn't talk about SAFI.  What is this referring to?
> >
> 
> KT> Ack - there is no SAFI in LISP and the reference was meant to be for
> routing of both IPv4 and IPv6 packets with LISP. Will fix this.

The new text is still a bit terse/opaque for me to be confident that I
understand properly, but I will drop the discuss point as I think I see how
it works.

> 
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > There's a lot of this document that feels like just some informational
> > discussion of "here are some things that many people do", "here are some
> > possible things you can do with SR", etc..  There are also a small handful
> > of places in the document that look to actually be specifying parts of
> > protocol behavior (I suspect that John has already identified them in his
> > enumeration), and the overall impression ends up being a bit jumbled,
> > like there are a bunch of topics stuck together without an overarching
> > theme.
> > I think the overall content would be more valuable if divided into a tight
> > "protocol specification" portion that could stay at proposed standard, plus
> > an informational "architecture details" document that contains the
> > in-depth exposition that didn't make it into 8402.
> >
> > This draft would benefit greatly from a terminology section.  I note in the
> > section-by-section comments several places where a term is first used
> > without sufficient background/definition, leaving the matter at hand
> > underspecified for the reader.
> >
> > Section 2
> >
> >    An SR Policy is a framework that enables the instantiation of an
> >    ordered list of segments on a node for implementing a source routing
> >
> > Really, an SR policy is a *framework*?  I thought an SR policy was a
> > specific instantiation of a list of segments, or at least that's what I'm
> > getting from RFC 8402.  Perhaps we should say that the general concept of
> > SR
> > Policy provides a framework?
> >
> 
> KT> Ack. Will rephrase.
> 
> 
> >
> > Section 2.1
> >
> >    An SR Policy MUST be identified through the tuple  >    endpoint>.  In the context of a specific headend, an SR policy MUST
> >    be identified by the  tuple.
> >
> > These two MUSTs appear to be in (nominal) conflict.  Maybe start the first
> > one with "absent further context" or "absent the context of a known headend
> > node"?
> >
> 
> KT> It is not "absence of context" but "within the context of a specific
> headend".
> 
> 
> >
> >    The headend is the node where the policy is instantiated/implemented.
> >    The headend is specified as an IPv4 or IPv6 address and is expected
> >    to be unique in the domain.
> >
> > This is the first instance of the word "domain" in this document.  I
> > suggest
> > using the introduction to introduce what is meant by the word, even if just
> > by reference to RFC 8402.
> >
> 
> KT> Ack. It should be SR Domain.
> 
> 
> >
> >    An implementation MAY allow the assignment of a symbolic name
> >    comprising printable ASCII [RFC0020] characters (i.e.  0x20 to 0x7E)
> >    to an SR Policy to serve as a user-friendly attribute for debugging
> >    and troubleshooting purposes.  [...]
> >
> > I agree with the other ADs that limiting to US-ASCII is not actually
> > user-friendly for many users, and that the likelihood of some
> > implementations not properly enforcing such a limitation to be high.
> > (Likewise for the other places where symbolic names are admitted.)
> >
> 
> KT> Please see the response to the other reviews on this point.

I don't find them compelling, but this is just the COMMENT section so
you're not obligated to persuade me.

> 
> >
> > Section 2.2
> >
> >    A dynamic candidate path expresses an optimization objective and a
> >    set of constraints.  [...]
> >
> > Down in §5.2 when we discuss validation procedures for dynamic candidate
> > paths, we say that the optimization problem is solved "for either the
> > SR-MPLS or the SRv6 data-plane as specified".  Does the data plane need to
> > be specified as part of the dynamic candidate path itself?
> >
> 
> KT> Yes.

Should we say that here, e.g., "a dynamic candidate path expresses an
optimization objective and a set of constraints within a specified data
plane"?

> 
> >
> > Section 2.3
> >
> >    in Section 2.9.  The table below specifies the RECOMMENDED default
> >    values of Protocol-Origin:
> >
> > I feel like it would be useful to provide some justification for why the
> > recommended default behavior prefers BGP SR configuration over PCEP, even
> > if
> > that justification is just "we need to have a clear ordering and this one
> > is
> > arbitrary".
> >
> 
> KT> Ack. Will clarify that.
> 
> 
> >
> > Section 2.4
> >
> >    o  Node Address : represented as a 128-bit value.  IPv4 addresses
> >       MUST be encoded in the lowest 32 bits, and the high-order bits
> >       MUST be set to zero.
> >
> >    Its application in the candidate path selection is described in
> >    Section 2.9.
> >
> > The tie-breaker procedure for path selection described in §2.9 seems to
> > always prefer IPv4 originators over IPv6 ones (by virtue of preferring the
> > smaller value).  I guess if we wanted to change that to prefer IPv6 we have
> > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped unicast)
> > from BCP 153, but it's a bit hard to justify either of those as appropriate
> > on technical grounds, and since this is just a tie-breaker and the
> > Preference is explicitly preferred, it seems like this is probably "good
> > enough" as-is.
> >
> 
> KT> Ack. As clarified in a recent text update in v17, preference is the key
> parameter really.
> 
> 
> >
> > Section 2.5
> >
> >    The Discriminator is a 32-bit value associated with a candidate path
> >    that uniquely identifies it within the context of an SR Policy from a
> >    specific Protocol-Origin as specified below:
> >
> > What are the constraints that underlie the 32-bit requirement here?
> > It looks like some of the scenarios are going to involve uncoordinated
> > (random) assignment of these discriminator values (e.g., with the BGP
> > distribution mechanism, when coming from different BGP peers), and the
> > birthday-bound collision probability is not negligible for this few bits.
> > That, in turn, calls into question the "uniquely identifies" property being
> > claimed.  Or is there some other property that means that only
> > discriminators from a single issuer will ever need to be compared with each
> > other (making the allocation "coordinated"), such as being additionally
> > associated with the originator?
> > If my initial analysis was incorrect and these are indeed allocated in a
> > "coordinated" fashion, would it be typical/expected for the allocation to
> > occur by incrementing a local counter on the originator?  In some
> > situations
> > such allocation by counter can have security considerations, which
> > draft-gont-numeric-ids-sec-considerations attempts to cover.
> >
> 
> KT> The discriminator is scoped to a particular originating node for the
> candidate path and as such, there is no requirement for coordination across
> sources/nodes. Therefore, 32-bit is more than sufficient.

When you say "originating node", does that refer to the SR headend, or the
(BGP) originator of the BGP route containing the SR Policy NLRI?

I assume the latter, and agree that *within the context of BGP*, the
discriminator is scoped to the originating BGP node.  But the description
we give in §2.5 of this document does not say anything about making use of
such information.  As far as I know, the BGP originator information is lost
when the BGP distinguisher is converted into the SR Policy candidate path
discriminator data model.  And we don't say anything about how candidate
paths for a given SR Policy can only be originated from a single BGP node,
so I have to account somehow for the possibility that two BGP nodes are
independently announcing candidate paths for the same SR Policy, and thus
might collide in their assignment of distinguisher.  Whereas BGP can
resolve that collision via the BP origination information, I don't see how
that would be done in the SR data model.  Does that help you understand
what part I am missing?


> 
> >
> > Section 2.8
> >
> >    A candidate path is usable when it is valid.  A common path validity
> >    criterion is the validity of any of its constituent Segment-Lists.
> >    The validation rules are specified in Section 5.
> >
> > This document claims to target Proposed Standard status; are we really
> > content to say only that this is "a common" criterion?  Even when we also
> > go
> > on to flat-out state "the validation rules are specified [below]"?
> >
> 
> KT> We will change this to introduce the word RECOMMENDED. There are
> deployments where an operator might need a local policy to declare the
> candidate path invalid when the number of valid SLs drops below a certain
> threshold (for b/w or load-balancing considerations).
> 
> 
> >
> > Section 2.9
> >
> >    The candidate path selection process operates primarily on the
> >    candidate path Preference.  A candidate path is selected when it is
> >    valid and it has the highest preference value among all the candidate
> >    paths of the SR Policy.
> >
> > Should this be "among all the valid candidate paths"?  A path that's
> > invalid
> > is still invalid, even if it has the highest preference value.
> >
> 
> KT> Ack - will clarify this.
> 
> 
> >
> >    2.  If specified by configuration, prefer the existing installed
> >        path.
> >
> > Does "if specified by configuration" refer to the act of applying this rule
> > at all, or that the existing installed path was one specified by
> > configuration?
> >
> 
> KT> The existing installed path. The rationale was that in some deployment
> designs an operator may not want to disturb/churn an active and
> valid/working path that has been installed in the forwarding.
> 
> 
> >
> > Section 2.11
> >
> >    The fraction of the flows associated with a given Segment-List is w/
> >    Sw, where w is the weight of the Segment-List and Sw is the sum of
> >    the weights of the Segment-Lists of the selected path of the SR
> >    Policy.
> >
> > Thank you for stating this clearly!
> >
> > Section 3
> >
> >    o  TE Link Attributes (such as TE metric, Shared Risk Link Groups,
> >       attribute-flag, extended admin group) [RFC5305] [RFC3630].
> >
> > Is RFC 5329 applicable here as well?
> >
> 
> KT> Yes, will add that. Thanks.

(It looks like a second 3630 reference got added in the -18, not 5329; I'll
mention that in my updated ballot remarks as well.)

> 
> >
> > Section 4
> >
> >    Type E: IPv4 Prefix with Local Interface ID:
> >          This type allows identification of Adjacency SID or BGP Peer
> >          Adjacency SID (as defined in [RFC8402]) SR-MPLS label for
> >          point-to-point links including IP unnumbered links.  The
> >          headend is required to resolve the specified IPv4 Prefix
> >          Address to the Node originating it and then use the Local
> >          Interface ID to identify the point-to-point link whose
> >          adjacency is being referred to.  The Local Interface ID link
> >          descriptor follows semantics as specified in [RFC7752].  This
> >
> > The phrase "local interface ID" does not appear in RFC 7752 (and even
> > "local
> > interface" appears just once"; please use terminology actually present in
> > the referred-to document to clarify what is being referenced.
> >
> 
> KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn
> references RFC5307 which in turn RFC4202. We use RFC7752 since it covers
> and explains the use of the various link descriptors that we use for
> various segment types.
> 
> 
> >
> > Section 4.1
> >
> >    When steering unlabeled IPv6 BGP destination traffic using an SR
> >    policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit
> >    Null Label Policy is processed as specified in
> >    [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4.  When an
> >
> > It looks like this is §2.4.5, not 2.4.4, in the referenced document.
> >
> 
> KT> Ack. Will fix.
> 
> 
> >
> > Section 5.1
> >
> >    The computation/logic that leads to the choice of the Segment-List is
> >    external to the SR Policy headend.  The SR Policy headend does not
> >    compute the Segment-List.  The SR Policy headend only confirms its
> >    validity.
> >
> > Does the headend actually have to confirm validity?  Is it okay to just
> > trust the controller and blindly use what is provided?
> >
> 
> KT> At least the first segment needs to be validated from a resolvability
> perspective. The subsequent segments depend on how (i.e., using what
> segment types) the controller has signalled the path to the headend. If it
> is indicated by just referring to a Prefix (e.g. loopback) of a node, then
> the headend will need to resolve and as such validate. While if specified
> as a label, then no resolution is required.

Hmm.  So maybe we could say "the SR Policy headend only confirms the
validity of any segments that it needs to resolve as part of packet
processing"?  Or does that not actually convey the needed information?

> 
> >
> > Section 6.2
> >
> >    When the active candidate path has a specified BSID, the SR Policy
> >    uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is
> >    available (i.e., not associated with any other usage: e.g. to another
> >    MPLS client, to another SRv6 client, to another SID, to another SR
> >    Policy, outside the range of SRv6 Locators).
> >
> > I don't think I understand what is meant by "client" here (for "another
> > client").  This sentence is the only place where the word "client" appears
> > in this document...
> >
> 
> KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be IS-IS
> enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from a
> "label manager" within the router.

I think this explanation actually makes me more concerned about the way
this is written than I previously was.  It seems to imply that we are
trying to describe both that there is an MPLS vs SRv6 data-plane in use and
that the node in question is a client of some unspecified protocol that can
allocate SIDs/MPLS labels, which could be as varied as an IGP or a
dedicated path computation protocol.  Furthermore, not all of these
possible protocols would intrinsically provide for arbitrary headend nodes
to even know if the label/SID in question has already been allocated to
another "client"!

Is the determination of availability to be made by the controller or by the
headend?  I think we should state that clearly, since (given the above
discussion) it seems like it is the controller that is best place to
actually make the determination, but the phrasing "the SR Policy uses"
implies (at least to me) that the determination is made on the headend,
since it is the headend that actually instantiates the policy.

> 
> >
> >    Optionally, instead of only checking that the BSID of the active path
> >    is available, a headend MAY check that it is available within a given
> >    SID range i.e., Segment Routing Local Block (SRLB) as specified in
> >    [RFC8402].
> >
> > Is the only allowed range to check the SRLB?  If not, I think we need to
> > s/i.e./e.g./.
> >
> 
> KT> Yes, SRLB is the one to check/allocate from for such usage.

Okay.  I suspect we want s/a given/the given/ then, but am not 100% sure.
> 
> >
> >    When the specified BSID is not available (optionally is not in the
> >    SRLB), an alert message MUST be generated.
> >
> > This is the first time (of only two) the word "alert" appears in this
> > document, and there is no prior expalanation of what entity might be
> > receiving alerts generated by a headend.  Please clarify.
> >
> 
> KT> Alert mechanism could be one or more of syslog, Netconf notification, a
> telemetry mechanism, etc..

I think the clarification is best placed in the document itself, e.g., in a
glossary/terminology section as I suggested in my high-level comments.

> 
> >
> >    Assuming that at time t the BSID of the SR Policy is B1, if at time
> >    t+dt a different candidate path becomes active and this new active
> >    path does not have a specified BSID or its BSID is specified but is
> >    not available (e.g. it is in use by something else), then the SR
> >    Policy MAY keep the previous BSID B1.
> >
> > Is there a strict bound on or other guidance for what values of dt are
> > allowable for this purpose?
> 
> 
> KT> None
> 
> 
> >   Is the intent that there be an atomic
> > transition from BSID=B1;active-path=P1 to BSID=B1;active-path=P2?
> >
> 
> KT> There is no atomicity requirement. A switch from one active CP to
> another will vary depending on the cause of the switch - e.g. if it is due
> to a failure or because a more preferred path came up.
> 
> 
> >
> >    The association of an SR Policy with a BSID thus MAY change over the
> >    life of the SR Policy (e.g., upon active path change).  Hence, the
> >    BSID SHOULD NOT be used as an identification of an SR Policy.
> >
> > Is there any guidance available on how long to wait with a given BSID value
> > unused before binding it to a new SR Policy?
> >
> 
> KT> None. These depend on the implementation and scenarios like resource
> availability e.g., a BSID might get re-used sooner if the system is running
> short of labels.
> 
> 
> >
> > Section 6.2.3
> >
> >    An implementation MAY support the configuration of the Specified-
> >    BSID-only restrictive behavior on the headend for all SR Policies or
> >    individual SR Policies.  Further, this restrictive behavior MAY also
> >    be signaled on a per SR Policy basis to the headend.
> >
> > Elsewhere in the document we discuss specific potential signaling
> > mechanisms/protocols, but here we say nothing.  Is that vagueness
> > intentional?
> >
> 
> KT> Since this isn't a protocol specification the mechanism is not
> described here. However, you can look at
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.2
> and that document refers back to this specification.

Okay, but if this document isn't a protocol specification and that's
grounds to not describe mechanism in it, then there are quite a few other
places in the document that should also not describe mechanism, if we want
to be applying the rule consistently.

> 
> >
> > Section 6.3
> >
> >    A valid SR Policy installs a BSID-keyed entry in the forwarding plane
> >    with the action of steering the packets matching this entry to the
> >    selected path of the SR Policy.
> >
> > I don't think this is stated properly.  An SR Policy is the list of
> > segments; it isn't the entity that's installing entries in the forwarding
> > plane.  Some other entity is installing an entry in the forwarding plane to
> > realize the SR Policy in question, and we should make our writing reflect
> > that.
> >
> 
> KT> Ack. s/installs/results in the installation of
> 
> 
> >
> > Section 6.4
> >
> >    An implementation MAY choose to associate a Binding SID with any type
> >    of interface (e.g. a layer 3 termination of an Optical Circuit) or a
> >    tunnel (e.g.  IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE
> >    tunnel, etc).  This enables the use of other non-SR enabled
> >
> > Should we have some discussion that contrasts this scenario against the
> > End.X behavior from RFC 8986 (for the "interface" case)?
> >
> 
> KT> What this document says is that a BSID may be also associated to direct
> over these other types of interfaces/tunnels. We can look at them as having
> no other segment being imposed but just redirecting to an interface. In
> that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID in
> SR-MPLS). However, those tend to be associated with protocol adjacencies. I
> am not sure that I've followed your point though and please do let me know
> if I've not.

What you write here indicates to me that you got my point.  My proposal was
for a sentence something like "this behavior is analogous to the End.X
behavior defined in [RFC8986] in that the SID is removed, no new SIDs
applied, and the packet is directed across a particular interface, but it
conceptually fits better as a Binding SID since the SID is bound to a
specific (logical or physical) interface and End.X is typically used with
protocol adjacencies rather than interfaces".  But that's just a
suggestion, and if you think it doesn't make sense or doesn't add much
value, please ignore it.

> 
> >
> > Section 7
> >
> >    The SR Policy State is maintained on the headend to represent the
> >    state of the policy and its candidate paths.  [...]
> >
> > I confess I don't really understand why we need to have the current,
> > minimal, description of SR Policy State in this document.  What would be
> > lost if we deferred its discussion entirely until there is a more
> > comprehensive discussion available?
> >
> 
> KT> We will add an informational pointer to the SR Policy YANG model. What
> this document calls out is the requirement for reporting the operational
> state and provides pointers to other specs where this is being worked out.
> 
> 
> >
> >    The SR Policy state can be reported by the headend node via BGP-LS
> >    [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and
> >    [I-D.ietf-pce-binding-label-sid].
> >
> > The functionality of draft-ietf-pce-binding-label-sid seems much more
> > limited than that of draft-ietf-idr-te-lsp-distribution; in particular, the
> > former does not seem to actually report SR Policy state to the headed at
> > all; rather, it only concerns itself with BSID association to path, with no
> > information about "active", "not preferred", etc.
> >
> 
> KT> The PCEP work might be spread out over different documents but we do
> need to cover these requirements. That is one of the objectives of having
> this document coordinate work across protocol WGs.

It still feels like we're claiming something here that isn't true -- "can
be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]".  It seems
like we are really trying to say "... via extensions to PCEP [some of which
don't exist yet in a form that we're willing to reference]".

> 
> >
> > Section 8.3
> >
> >    If the SR Policy P is invalid, the BSID B is not in the forwarding
> >    plane and hence the packet K is dropped by H.
> >
> > We literally just in the previous section talked about a scenario where the
> > BSDI is kept in the forwarding plane (but with the action to drop, so the
> > overall outcome is not changed from what this text describes).
> > Nonetheless,
> > it's inaccurate to state that "the BSID B is not in the forwarding plane"
> > here.
> >
> 
> KT> There is a difference between the drop being referred to in 8.2 and
> 8.3. What we have in 8.2 is like a route pointing to null where we may
> advertise and get packets but will drop it with normal counters associated
> with that specific entry. While 8.3 is like we are dropping because we have
> no route (ideally we shouldn't have got the packet) and we increment a
> generic lookup failed counter. The use-cases for both are different.

I (think I) understand that the mechanisms are different and both have use
cases.  I just don't think that the specific combination of words used here
makes a true statement.  There are probably a number of ways to make a slight
adjustment and come up with a true statement, such as starting it with a
caveat as in "When Drop-Upon-Invalid behavior is not in use, for an invalid
SR Policy P, its BSID B is not in the forwarding plane and hence the packet
K is dropped by H".

> 
> >
> > Section 8.4.1
> >
> >    When a BGP route has multiple Color Extended communities each with a
> >    valid SR Policy, the BGP process installs the route on the SR Policy
> >    giving preference to the color with the highest numerical value.
> >
> > Do we want to say anything about this being an arbitrary tiebreaker (rather
> > than an intentional preference), or is that thought to be implicitly clear?
> >
> 
> KT> It is an intentional preference.

Peeking forward to §8.8.2, is this also referring to the BGP color rather
than the SR Policy color?  If so, please specifically qualify the word
"color" as being the BGP one.

If not, then I strongly suggest that the introduction of color in §2.1
state that the numerical value of the color is used as a preference
mechanism in addition to indicating intent or objective (with the
implication or explicit statement that assignment of color values must be
performed in a manner that is compatible with the operator's
preference/policy).

> 
> >
> > Section 8.5
> >
> >    In this section, independent of the a-priori existence of any
> >    explicit candidate path of the SR policy (C, N), it is to be noted
> >    that the BGP process at headend node H triggers the instantiation of
> >    a dynamic candidate path for the SR policy (C, N) as soon as:
> >
> > I strongly suggest providing a more explicit framework of what the
> > assumptions and preconditions are for the mechanism described in this
> > section.  My intuition says that it's a fairly optional thing that would
> > need to be specifically configured, but trying to wrap that sentiment into
> > the long bullet point involving "a local policy" seems like a very
> > confusing
> > way to express the desired behavior.
> >
> 
> KT> It is actually a matter of local policy with perhaps some template and
> configuration to drive this. I believe this should get covered in the SR
> Policy YANG model at some point in time.
> 
> 
> >
> > Section 8.6
> >
> >    o  is configured to instantiate an array of paths to N where the
> >       entry 0 is the IGP path to N, color C1 is the first entry and
> >       Color C2 is the second entry.  The index into the array is called
> >       a Forwarding Class (FC).  The index can have values 0 to 7.
> >
> > Why are the only allowed values 0 to 7?  Where does this restriction arise
> > from?  It is because of some protocol element?
> >
> 
> KT> There is text further in the section to indicated that these
> ranges/values are implementation-specific. Historically, the 8 values have
> come from the MPLS EXP bits.

If the ranges/values are implementation-specific, then don't give a
specific range here stated as if it is a universal limitation!  I would
either drop the sentence entirely or say something like "when the index is
conveyed using the MPLS EXP bits, only indices 0 to 7 are usable".

> 
> >
> >    If the local configuration does not specify any explicit forwarding
> >    information for an entry of the array, then this entry is filled with
> >    the same information as entry 0 (i.e. the IGP shortest path).
> >
> >    If the SR Policy mapped to an entry of the array becomes invalid,
> >    then this entry is filled with the same information as entry 0.  When
> >    all the array entries have the same information as entry0, the
> >    forwarding entry for N is updated to bypass the array and point
> >    directly to its outgoing interface and next-hop.
> >
> > I can't tell how much of this is supposed to be protocol specification and
> > how much an illustrative example.  Is A(0) always the IGP shortest path?
> > Are these protocol requirements to fall back to the IGP shortest path when
> > an entry is otherwise unpopulated or the associated SR Policy becomes
> > invalid?
> >
> 
> KT> The specifics are for illustration purposes. Most of these are policy
> knobs/options.

Please add a note at the top of the section that "this section provides an
example of how a headend might apply per-flow steering in practice".

> 
> >
> > Section 8.8.2
> >
> >    The steering preference is first based on the highest color value and
> >    then CO-dependent for the color.  [...]
> >
> > This seems to contradict what I assumed earlier about the "highest color"
> > rule being a tiebreaker, e.g., the word "preference" is used here.  Is it
> > actually intended to be a deliberately configured priority/preference
> > scheme?  If so, that would seem to require some wide-ranging reworking
> > throughout the document.
> >
> 
> KT> There is the color that is in the identification of an SR Policy -
> (color, endpoint). This does not get into any tiebreaker or selection
> logic. All that (sec 2.9) is about the selection of a candidate path within
> an SR Policy. Then there is the color value signaled via the Color Extended
> community on the BGP routes and here, we have the preference for higher
> color when the route is advertised with multiple colors tagged to it.

I think you should clarify that this section refers to the BGP Color, then
-- previously in the document it has been the SR Policy color value and an
unqualified reference to "color value" seems like it refers to the concept
defined in this document, absent other qualifiers.

> 
> >
> > Section 9.3
> >
> >    the most appropriate alternative for the active candidate path.  A
> >    fast re-route mechanism MAY then be used to trigger sub 50msec
> >    switchover from the active to the backup candidate path in the
> >    forwarding plane.  Mechanisms like Bidirectional Forwarding Detection
> >    (BFD) MAY be used for fast detection of such failures.
> >
> > Why is the specific 50msec value important here?  Is there some other
> > requirement that imposes it?
> >
> 
> KT> This comes from "typical" expectations from fast-reroute mechanisms.

I'd consider '''to trigger "fast" (sub 50msec) switchover''', then, but
it's not very important.

> 
> >
> > Section 10
> >
> > I think we also want to mention the security considerations of several more
> > documents, including (but not limited to)
> > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986.
> >
> 
> KT> Ack on the three RFCs, but convinced about the
> draft-ietf-idr-segment-routing-te-policy since that depends on this and not
> the other way around.

I think this relates to John's Discuss point and whether this document
specifies the protocol behavior of the two bits in the context of the
extension defined in draft-ietf-idr-segment-routing-te-policy.  You need to
understand draft-ietf-idr-segment-routing-te-policy in order to understand
the security considerations relating to the protocol behavior controlled by
those two bits, and IMO the protocol behavior specified by those two bits
is solely the responsibility of this document, so this document must
incorporate the security considerations of
draft-ietf-idr-segment-routing-te-policy in order to fully document the
security considerations of the concepts and protocol elements that this
document defines.

Thanks for this, and all the other parts I didn't specifically reply to.

I will attempt to update my ballot position in the datatracker to remove
the parts that are fully addressed (though I will probably inadvertently
leave in something I shouldn't have).

-Ben

> 
> >
> > Section 15.2
> >
> > I agree with John that draft-ietf-idr-segment-routing-te-policy must be
> > classified as a normative reference.
> >
> > It also seems that RFC 7752 should be classified as normative, as we
> > incorporate its definition for the semantics of several of the segment type
> > descriptions.
> >
> 
> KT> Ack
> 
> 
> >
> >
> > NITS
> >
> > Section 1
> >
> >    Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of
> >    segments (i.e. instructions) that represent a source-routed policy.
> >
> > /Segment/A Segment/
> >
> 
> KT> Ack
> 
> 
> >
> >    The headend node is said to steer a flow into a SR Policy.  The
> >    packets steered into an SR Policy carry an ordered list of segments
> >    associated with that SR Policy.  [...]
> >
> > In a certain sense this can be read as saying that the packets that "carry
> > an ordered list of segments" are the ones prior to being steered into an SR
> > policy, which would make this statement not true.  Perhaps we want to say
> > "after being steered into an SR Policy, packets carry an ordered list ..."?
> > (I also went back and forth with myself about whether "packets ... carry"
> > implies in the payload or not.  I settled on "not" but make this note just
> > in case I am missing an aspect of that question.)
> >
> 
> KT> Ack. Will rephrase.
> 
> 
> >
> > Section 2
> >
> >    An SR Policy is a framework that enables the instantiation of an
> >    ordered list of segments on a node for implementing a source routing
> >
> > It's easy to read this as saying that all of the segments in the list
> > instantiated on the single node in question, which I assume is not the
> > intent.  Probably the easiest way to aid readability here is to split the
> > sentence up into multiple smaller sentences that are easier to parse.
> >
> 
> KT> Will rephrase.
> 
> 
> >
> > Section 2.2
> >
> >    A dynamic candidate path expresses an optimization objective and a
> >    set of constraints.  The headend (potentially with the help of a PCE)
> >    computes the solution Segment-List (or set of Segment-Lists) that
> >    solves the optimization problem.
> >
> > I'd suggest computes the solution/computes a solution/ for genericity.
> >
> 
> KT> Ack.
> 
> 
> > A stateful PCE might end up computing a path that is not the optimal one
> > for
> > this specific optimization problem, due to a desire to cooperate with other
> > paths in the network, and the "Min-Metric with margin and maximum number of
> > SIDs" objective in draft-filsfils-spring-sr-policy-considerations doesn't
> > even have a guaranteed unique best solution.
> >
> > Section 2.5
> >
> >    When provisioning is via configuration, this is an implementation's
> >    configuration model-specific unique identifier for a candidate path.
> >    The default value is 0.
> >
> > I'm having a lot of trouble parsing this.  Did we perhaps mean to hyphenate
> > as "configuration-model-specific"?
> >
> 
> KT> Ack
> 
> 
> >
> > Section 2.13
> >
> >    The SR Policy POL1 is identified by the tuple  >    endpoint>.  It has two candidate paths CP1 and CP2.  Each is
> >    identified by a tuple .
> >
> > I suggest (for the last sentence) "identified within the scope of POL1"
> >
> 
> KT> Ack
> 
> 
> >
> >    forwarding instantiation of SR policy POL1.  Traffic steered on POL1
> >    is flow-based hashed on Segment-List  with a ratio
> >    W1/(W1+W2).
> >
> > If I read "ratio" I would instinctively think of the ratio of (traffic on
> > segment list 1)/(traffic on segment list 2), as opposed to the proportion
> > of
> > all traffic, that would be measured as the indicated W1/(W1+W2).
> >
> 
> KT> Ack. s/ratio/proportion
> 
> 
> >
> > Section 3
> >
> >    The attached domain topology may be learned via IGP, BGP-LS or
> >    NETCONF.
> >
> >    A non-attached (remote) domain topology may be learned via BGP-LS or
> >    NETCONF.
> >
> > I think these are both probably not exhaustive lists, so "e.g." or similar
> > may be appropriate.
> >
> 
> KT> Ack.
> 
> 
> >
> > Section 4
> >
> >    Type C: IPv4 Prefix with optional SR Algorithm:
> >          The headend is required to resolve the specified IPv4 Prefix
> >          Address to the SR-MPLS label corresponding to a Prefix SID
> >          segment (as defined in [RFC8402]).  The SR algorithm (refer to
> >          Section 3.1.1 of [RFC8402]) to be used MAY also be provided.
> >
> >    Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:
> >          In this case, the headend is required to resolve the specified
> >          IPv6 Global Prefix Address to the SR-MPLS label corresponding
> >          to its Prefix SID segment (as defined in [RFC8402]).  The SR
> >          Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY
> >
> > These are effectively just the IPv4 and IPv6 incarnations of the same
> > underlying procedure, right?  Can't we minimize the diff between the
> > paragraphs further?
> >
> 
> KT> Ack
> 
> 
> >
> > Section 5.1
> >
> >    Additionally, a Segment-List MAY be declared invalid when:
> >
> > We probably want another word here ("both"?), to specify how the two
> > conditions are combined.
> >
> 
> KT> Ack - will rephrase.
> 
> 
> >
> > Section 5.2
> >
> >    When the local computation is not possible (e.g., a policy's tail-end
> >    is outside the topology known to the headend) or not desired, the
> >    headend MAY send path computation request to a PCE supporting PCEP
> >    extension specified in [RFC8664].
> >
> > missing article ("the PCEP extension").  I forget if it should be
> > "extensions" plural.
> >
> 
> KT> Ack
> 
> 
> >
> > Section 8.7
> >
> >    Finally, headend H MAY be configured with a local routing policy
> >    which overrides any BGP/IGP path and steer a specified packet on an
> >
> > singular/plural mismatch -- s/steer/steers/
> >
> 
> KT> Ack.
> 
> Thanks,
> Ketan



From nobody Fri Feb 25 09:42:34 2022
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 BF82F3A0EB7; Fri, 25 Feb 2022 09:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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_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 gS9c1W4b52T8; Fri, 25 Feb 2022 09:42:09 -0800 (PST)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2128.outbound.protection.outlook.com [40.107.236.128]) (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 48A4F3A0CBC; Fri, 25 Feb 2022 09:42:07 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vm4zYavATtEm0NxvyP/ItQxNqDaHOBiuqtzgnzL5zrp/vl9cjN58tQC3Nzum+lcpRhXwejY/mGrYF89IIaLrHLlQsJnLpTW8qol6F8TpMkjJr6UhuGN8kYjx4Rh0AAsPO+H0seyDf0TNgsVbsAyGXyve3axfLliIqoBsFrx2FkcGSXkF1FS7v7z4xG/r+kJDNSSosUV5SHWinhYe7u/J7iAXLH04Xgb2CVGqilF2dbTk/3UJa92xavZPL5I+NgcNGdGYK9TULCWjq0D1X6kXXxHA1cO0Y+SadkvPVje/AVMeVokzHz+YF19IUQstbWppMUCZxXvfz5BFHlF2SvYzMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nybqO81Qf/4u4sm2xL749DlfphB2sGYFycGOQTkUypE=; b=D/DedACJv8H5ct+nIROAFvDiY36oQ4YOoXu0ItyPi7fkghRhKrbKSJAGzesIq7ipqDK7hhAnh5pOLC4qGsxtSFLC/75MnChQRD9HAY6IhxbpiUxWGFqCCsFeupw+ryeOS8D2LO5UF9P8LDHBZKgAj9/j+liK8d/xI5g6+r25WLXwyXnS34KkN1gkPzpN8JpK7uTaeoax7YY07uvX/rPkXUh5OUqQ7pONckevpat0t0l2M/P11ZRY1PRNk5BClJsgyfNtdKlzVg27W0EIYs9PRZgsF6JdJ5T0xJZBYv6GL2UT0x7DHy6TRF0BNgfa/LGQMUr5yLm0K23WkDSFEd8Srg==
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=nybqO81Qf/4u4sm2xL749DlfphB2sGYFycGOQTkUypE=; b=nGgOipJFIT9WE1I/uF/jItNIzpuVGQ4sEqE+395VvlVp47MQUCdkKxqbyJwVzdeT1kz7f71usDpEr4+EMmS7RdtoiyZREXpjOg8yeE8Ro/58qAzEXpWD/twiLzX9iI+bym1/Dh7lluUrV76pZUizanXRuPmg6AWrqB/58UnqwRg=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by DM5PR13MB1578.namprd13.prod.outlook.com (2603:10b6:3:125::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.9; Fri, 25 Feb 2022 17:42:05 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d%5]) with mapi id 15.20.5038.009; Fri, 25 Feb 2022 17:42:05 +0000
From: Haoyu Song 
To: Greg Mirsky , Tarek Saad 
CC: mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" 
Thread-Topic: [spring] Comments on draft-saad-mpls-miad-usecases
Thread-Index: AQHYJQybUbEkehVNgEePJZTL39BWqqyiwYCAgAC9BACAARPuUA==
Date: Fri, 25 Feb 2022 17:42:04 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 58e46803-3721-4d5d-f97c-08d9f8862352
x-ms-traffictypediagnostic: DM5PR13MB1578:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iGvzSG6kgHVxWpURNyZ8mcFG9+wA7SqOrCJIDOD9qKL6TIjSdFO1jr+Br+9z8JIubwMeM1JwK6+Rta3kzWkIAQ7Zcvbel+hIiL84DOY+eG0HYTFU5R4e0Td6v7r3ZZ7O1Xwigig7yLsL7v4AQoq0m9/iQcqhHqQ6rUVmHK9NAEHAIaBDGgtyiuYTNMHSlNHKlw7QtuJ8C3cOAey77r2whyQ0aYc8Ub3JsAEL46O9ldE+8A8hmaMTRWCtHafNEnywP59of2m5DEOWxQF2paRRWsfLn0jN0WbCWG4hjG/wBODPP0KiwYUrCmSnlj4pL4HjJtdGeZbjTIZkqKT2lrJDGveAlEFrUz9l4rrnUJ/cvhII4pgPWPCTA05gdi0FjzE31M3o+bo0PxPXyscs7tw9XjKEqlsjtCeGzA+MPDP+elf3Rqmw+R04TC46rDC+b8Y6TjKtJJCacRauj5tmjueHPYpUGGJBVdh9nX86U7K7nhc9VL2knxFmIzuVzyVcuqoPyIj3hWRUY8mGLW9Ng0zEapYsjojthMcdtawvPADlxhcLNT2EfVjuiyQLltwyy5oEk9bpg76xGIRO7W5vstIvg8t0NsOMbaFk/57+ybAxGJ+sj/8fICZax4Fn3JKkQAYRra9RaKqR06ofMI7UtJ0m53E28lrbZRO8F6EpEowDjsps5VlZufkNuuevAybbLn6xb1y//pGCvaNGqa1RHqA+n1x96RG3ZmHOT9KiBW5SsyhxYWgQSNfDIareYu/ySXV8VfugSgJnZSFNztA8SeSMHBrJPiRkTSSO8pXJwihObKQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE;  SFS:(13230001)(4636009)(366004)(66476007)(66446008)(6506007)(64756008)(86362001)(66946007)(7696005)(9686003)(76116006)(316002)(54906003)(53546011)(110136005)(508600001)(38070700005)(966005)(122000001)(66556008)(186003)(166002)(71200400001)(38100700002)(83380400001)(8936002)(33656002)(55016003)(4326008)(8676002)(52536014)(44832011)(5660300002)(2906002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?8CZ55LeT/RJUjvyy59Kff7h+ndpMTT8ztL9i/vbcRS8aRSZpMpOARQ6Tv97U?= =?us-ascii?Q?Vvu59Rqfap51isa9uTe8JX27pth+ajd2ZaQbFgP92vZd/niXxGZveTZbfzE8?= =?us-ascii?Q?pP9XTLQIWeSCvuRmWwpXYO85N73nQwh6G7WmRSCyq+m/zcePIX6NWbUlbL6P?= =?us-ascii?Q?yKX9A+48HTUpSJG0wJoDuz8kziIlSGVKFcRafmn4YCS37OvNqLrzBzm+1VkH?= =?us-ascii?Q?eFVU3ycVay28/8WTEsxEd3qxyWFNCiKEOL0s12OImXNe/1LOCsw+jdS0BVeT?= =?us-ascii?Q?FKkYSHb+4j1r6PJEAD6B1znkT746nrVD3TmSCOV2VmpqOZ0Tkd75UDDoTgZv?= =?us-ascii?Q?hrseFQYhNg3Q+KhdJBHDf09WsBKfy6ZJZ3f+CVzZkV08RAj/uvlwENy31TFo?= =?us-ascii?Q?fHPFZnfEmBP2tLSoJ+zj6HXwuJkjggNA6SC7MMT4cJZ75RkJh0tZAIQievtg?= =?us-ascii?Q?GEQTmxf3G5S3RVNpWHAgE4WVjkrBPVf8MCV/OXbP4a9ZXakrejitg8QYuwUM?= =?us-ascii?Q?8WPkpFN7FT7dV52GUmlaWRBUeWNuh3TzITdSnTnSPZrlDBli6JNUKAQTA980?= =?us-ascii?Q?bgXUuzP1SPuqTOjDygLHDyuYvChxNR9EuzPVlbweTeJqpFJeRLYtGEC1iO0w?= =?us-ascii?Q?M7CLHT09jnKXLYfGpoCcaJDXtbY5RY/1BkyZQpaB3M0LPHElC6JCclzv7PnZ?= =?us-ascii?Q?yDEitjLBa0XTHOuoK+W5mqSOxmqru3Cd4ku2i5wwySXEG9nPeL4InnTW4Vgl?= =?us-ascii?Q?aczA8HLu1nUDzyqLnIvZyQiWIXCzJXVgQujk5i9nQ366siPS93c+Vk4+T6Qt?= =?us-ascii?Q?Z6tC2WuM1Ic0RITsTF9q4EyGkQ8Xg1jaklJ3LeMrOFk4vgKxLvw2tI6GaYdX?= =?us-ascii?Q?3fiHt9qx/LIXOvNh8CkHsV8tIAJh2si2nzibcGo62rdMMrNdIEOPpoNfSTF5?= =?us-ascii?Q?o9MURvFlhV4Ob0it7bCNsMQNVJNSOf7OqykEDW0edPsidSSZuIlhq+xHOMPK?= =?us-ascii?Q?9t6vxYWL0qXwqDFsPkd2SjJR9jGID0avXhPs7lU/DQRFkl1M4utPgaZkJDQ7?= =?us-ascii?Q?M8EsBr+xMFntttKUsF4zgl3MCPot4BlX2DSsizjMEPs1sKQUC8ahBdTmvSy8?= =?us-ascii?Q?zyDDRIVQvRp1EfbI7GEIHXaNfh1J6OSdC8CHMqpjaqAA5ZyfNl0yAlBbRFwR?= =?us-ascii?Q?b46x5kPbs6gviC09NikopViNAE7/vIWAjnTLHrboEYo/W43eLMkbJ1SKSq58?= =?us-ascii?Q?N+ImKwC+ShofIcCIgGBBR6TY+CSBm10wqI3rLNo1mAirWY3ITpSnP3GqYDyJ?= =?us-ascii?Q?mpRh1MI+KmmIHKwQGgIk3068SQ7RpyTxz3AKvN9O77pq9JlYM3aMwmAjqONj?= =?us-ascii?Q?ulNYKLK2WL8T1jV0XGxRrs3K2I4kPLQ5SJZkJC+jMhcsUVsSPXadsh6+juOt?= =?us-ascii?Q?Ai3EfRDIfJY5oszEeHWiSAUSvumPIAgA4+7pRkoH466HD4gsoBGTxCBCJA6C?= =?us-ascii?Q?8phHTmvzq43vdSFUAP2n46swgGZa8SgUz96RBLYSR9G12UA6I5Zq1Z4nfF0C?= =?us-ascii?Q?ahoxwDSg98tOSIgWNRVIID52Qmp+fmvsH6SaqUN3xriGBigAPoOOxzNHV+9y?= =?us-ascii?Q?pXsxrY6WQwRx86otE1EMhWwOLrJgiVg1znowEcIotE02GbJcUaOCN2FozKd6?= =?us-ascii?Q?MDujbOmcI/N3weF+RhgoT9tJGBk=3D?=
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787C8798BF17C923278B3009A3E9BY3PR13MB4787namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 58e46803-3721-4d5d-f97c-08d9f8862352
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2022 17:42:04.9863 (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: 2VvE9xqvSHKqfkv6jNhnpxMTkktewyuKh94pABYHK41x2AgXiL8W2KYVT6pY8Xk7bR/MDow2/FK/q171+rvgQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR13MB1578
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 25 Feb 2022 17:42:14 -0000

--_000_BY3PR13MB4787C8798BF17C923278B3009A3E9BY3PR13MB4787namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
Hi Greg,

The RFC is mentioned because it shows that SFC NSH has been considered to b=
e supported in MPLS as well, so it's a legitimate use case like the others =
in the draft. When we need to support multiple such use cases at the same t=
ime, we need a generic mechanism to support them, so the use-case draft ser=
ves as a motivation for our work in the ODT.
Hopefully this answers your question. Thanks,
Haoyu

From: Greg Mirsky 
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad 
Cc: mpls ; pals@ietf.org; DetNet WG ; sprin=
g ; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed t=
he diff and got several follow-up notes:

  *   the new text in the Introduction section explains the ISD as being en=
coded as labels:
within the label stack, e.g., encoded as labels, referred to as In
                 Stack Data (ISD), and
I think s/as labels/into label stack elements/ makes the text a bit more ac=
curate. What do you think?

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
  *   I might have missed it earlier. The TSN is the term used for a very s=
pecific technology developed at IEEE to support, for example, URLLC service=
s. The DetNet WG defines the methodology in support of these services using=
 IETF technologies - MPLS and IP. I think it would be appropriate if an IET=
F document refers to Deterministic Networking, not TSN. What is your opinio=
n?
Regards,
Greg


On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad > wrote:
Hi Greg,

Thanks for your comments. I've addressed several of your comments. The late=
st diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draf=
t-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/t=
saad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt

Regards,
Tarek (for co-authors)

From: spring > on b=
ehalf of Greg Mirsky >
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org >, mpls >, pa=
ls@ietf.org >, De=
tNet WG >, spring >
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze=
 essential use cases in the scope of the work at the Open DT. Attached, ple=
ase find a copy of the draft with my notes and some editorial suggestions. =
I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

--_000_BY3PR13MB4787C8798BF17C923278B3009A3E9BY3PR13MB4787namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.


Hi Greg,


 


The RFC is mentioned because it shows that SFC NSH h=
as been considered to be supported in MPLS as well, so it’s a legitim=
ate use case like the others in the draft. When we need to support multiple=
 such use cases at the same time, we need
 a generic mechanism to support them, so the use-case draft serves as a mot=
ivation for our work in the ODT.


Hopefully this answers your question. Thanks,


Haoyu  


 




From: Greg Mirsky <gregimirsky@gmail.com&g=
t; 

Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@=
ietf.org>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases=
@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 






Hi Tarek,




thank you for your thoughtful consideration of =
my comments. I've reviewed the diff and got several follow-up notes:






    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, ref=
erred to as In     















        &nbs=
p;        Stack Data (ISD), and











I think s/as labels/into label stack elements/ makes=
 the text a bit more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




 




 






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com> wrote:










Hi Greg,


 


Thanks for your co=
mments. I’ve addressed several of your comments. The latest diffs (re=
vision to be uploaded soon) can be found at:


https://tools.ietf.org//=
rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad-usecase=
s-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/drafts/mast=
er/miad-usecases/draft-dt-mpls-miad-usecases.txt


 


Regards,


Tarek (for co-auth=
ors)


 




From:
spri=
ng <spring-=
bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,




thank you for your work putting this document=
 together. It helps to analyze essential use cases in the scope of the work=
 at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial suggestions. I h=
ope you'll find some of them helpful.






I am looking forward to your feedback and que=
stions.






 






Regards,






Greg


















--_000_BY3PR13MB4787C8798BF17C923278B3009A3E9BY3PR13MB4787namp_--


From nobody Fri Feb 25 09:55:13 2022
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 96CE73A0F42; Fri, 25 Feb 2022 09:54:46 -0800 (PST)
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=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 bItqzZyYSl3R; Fri, 25 Feb 2022 09:54:41 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8963A0EB7; Fri, 25 Feb 2022 09:54:41 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id q17so8478718edd.4; Fri, 25 Feb 2022 09:54:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jVZ2gvcuKw9lqZi51XxZIXyuNJ2tQ4C8+ODqucIq6WM=; b=kT4p9kteBkDUtoa7EmsROoDuKI6gRhRf9XKzQhVPmgDRFP7YHLfjtMHztFQBv5ugTl Eh8J+WwTSeVBNoNLWyj5nrI2eMjkdhcAWw41/wdUW4pk85PGcZBVJvuyq2I2sxFL4ErR 5J7ZHYTleAoJRg37MKwHA+F8QNWLClCB/bZnVuMjFof8CeKYHmKXSf7z36AT7FYnm92G FAluwv6sbbqrF+BrjAojpPoGFNQ7C7Wa+t2aHt2DN5UQ+/HKWIPcczXH5eGUp78iaV2b jv/JLlzr4Da3htkbmc56SwyMLQrr74AaNbauqkj8Dmpi3Ua2nW9AjWzGEozuiJL0uZRo JYqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jVZ2gvcuKw9lqZi51XxZIXyuNJ2tQ4C8+ODqucIq6WM=; b=erqrjhbicbQnjkeBu3yu0ClrZiGvYH+LRAtg1VdeHAiwmze2YCL5owpjq+Au4jhiYU SxIjPXgd3UxEiCVaD9EuRGxiXYmmIhV6ssPwMWkAAeb/OBoyCvPJI+0P4TQXMnvk7MRV zGMeC5mLz/R7qsMBGKipa4fNhEpxv2VTfPtQW9oTPZL6u7jrx2iRNhJUZuM3lQXlJ3Ed B159xKtPOm/KZxKXHUtyIpBim0dOOFzbnXl3PM3JOFiOGA1AZmBjlsPaJIiOJKSgsF4l yc2Dxg1W9j+TISqcnMKGgQUaSfq+1seNgbtgpkXRAzAuFxQX/ql9OZK9NS4S/+4xIGe2 mw4w==
X-Gm-Message-State: AOAM532sf78o6uqr5YQF9WgekLytrEpZmFq8txSBJRRsEhM9JwGOA4VS ot4ROCYFU1mmM4HHOr8R9jPFuYgLpn8eIFYrGm4=
X-Google-Smtp-Source: ABdhPJyywpPTx/gVeQK4PY6bePKrJZRi0a6qpw6+3/eFhnT4vM4HfbRnQRKY6JBYRJtFeLD7j5gc+aJX8hOKrbSWjnU=
X-Received: by 2002:a05:6402:51cb:b0:409:e99f:bc1c with SMTP id r11-20020a05640251cb00b00409e99fbc1cmr8321948edd.68.1645811679595; Fri, 25 Feb 2022 09:54:39 -0800 (PST)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Greg Mirsky 
Date: Fri, 25 Feb 2022 09:54:28 -0800
Message-ID: 
To: Haoyu Song 
Cc: Tarek Saad , mpls , "pals@ietf.org" ,  DetNet WG , spring ,  "draft-saad-mpls-miad-usecases@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000878f7205d8db6434"
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 25 Feb 2022 17:54:47 -0000

--000000000000878f7205d8db6434
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Haoyu,
in RFC 8596 I don't find anything that would require any modification to
the existing MPLS architecture. I would agree that SFC NSH using MPLS to
connect SFP components might benefit from the new enhancements to the MPLS,
but so would any other client that uses the MPLS network. Do you think that
the use case document should list them all?

Regards,
Greg

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song  wrote=
:

>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>
> Hi Greg,
>
>
>
> The RFC is mentioned because it shows that SFC NSH has been considered to
> be supported in MPLS as well, so it=E2=80=99s a legitimate use case like =
the others
> in the draft. When we need to support multiple such use cases at the same
> time, we need a generic mechanism to support them, so the use-case draft
> serves as a motivation for our work in the ODT.
>
> Hopefully this answers your question. Thanks,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad 
> *Cc:* mpls ; pals@ietf.org; DetNet WG ;
> spring ; draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Tarek,
>
> thank you for your thoughtful consideration of my comments. I've reviewed
> the diff and got several follow-up notes:
>
>    - the new text in the Introduction section explains the ISD as being
>    encoded as labels:
>
> within the label stack, e.g., encoded as labels, referred to as In
>
>                  Stack Data (ISD), and
>
> I think s/as labels/into label stack elements/ makes the text a bit more
> accurate. What do you think?
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>    - I might have missed it earlier. The TSN is the term used for a very
>    specific technology developed at IEEE to support, for example, URLLC
>    services. The DetNet WG defines the methodology in support of these
>    services using IETF technologies - MPLS and IP. I think it would be
>    appropriate if an IETF document refers to Deterministic Networking, no=
t
>    TSN. What is your opinion?
>
> Regards,
>
> Greg
>
>
>
>
>
> On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad  wrote:
>
> Hi Greg,
>
>
>
> Thanks for your comments. I=E2=80=99ve addressed several of your comments=
. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/dr=
aft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com=
/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> 
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring  on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *draft-saad-mpls-miad-usecases@ietf.org <
> draft-saad-mpls-miad-usecases@ietf.org>, mpls ,
> pals@ietf.org , DetNet WG , spring <
> spring@ietf.org>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some
> editorial suggestions. I hope you'll find some of them helpful.
>
> I am looking forward to your feedback and questions.
>
>
>
> Regards,
>
> Greg
>
>

--000000000000878f7205d8db6434
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0Haoyu,
in RFC 8596 I don't find anything t=
hat would require any modification to the existing MPLS architecture. I wou=
ld=C2=A0agree that SFC NSH using MPLS to connect SFP components might benef=
it from the new enhancements to the MPLS, but so would any other client tha=
t uses the MPLS network. Do you think that the use case document should lis=
t them all?

Regards,
Greg
On Fri, F=
eb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com> wrote:











    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.


Hi Greg,


=C2=A0


The RFC is mentioned because it shows that SFC NSH h=
as been considered to be supported in MPLS as well, so it=E2=80=99s a legit=
imate use case like the others in the draft. When we need to support multip=
le such use cases at the same time, we need
 a generic mechanism to support them, so the use-case draft serves as a mot=
ivation for our work in the ODT.


Hopefully this answers your question. Thanks,=



Haoyu =C2=A0


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.com> 

Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls=
@ietf.org>; pals@=
ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases=
@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0






Hi Tarek,




thank you for your thoughtful=C2=A0consideration of =
my comments. I've reviewed the diff and got several follow-up notes:=







    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, ref=
erred to as 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=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes=
 the text a bit more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




=C2=A0




=C2=A0






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com=
> wrote:










Hi Gre=
g,


=C2=A0=



Thanks=
 for your comments. I=E2=80=99ve addressed several of your comments. The la=
test diffs (revision to be uploaded soon) can be found at:


https://tool=
s.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-=
miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev=
/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt


=C2=A0=



Regard=
s,


Tarek =
(for co-authors)


=C2=A0=





From:
spring=
 <spring-bo=
unces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,




thank you for your work putting=
 this document together. It helps to analyze essential use cases in the sco=
pe of the work at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial=C2=A0suggestions. I h=
ope you'll find some of them helpful.






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






=C2=A0






Regards,





Greg





















--000000000000878f7205d8db6434--


From nobody Fri Feb 25 11:34:41 2022
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 43D0D3A1377; Fri, 25 Feb 2022 11:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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_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 VblcTQgnjMV3; Fri, 25 Feb 2022 11:34:24 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2113.outbound.protection.outlook.com [40.107.244.113]) (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 1D2F33A1374; Fri, 25 Feb 2022 11:34:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BgDzmZq3v0GVuq3bIsPIdYivOQnfxpgslFVrsZpRv3/9X5h1s4vygGhJ4HDWmdtGDYNiG/9Zu3HoQpB0wf7YIRkw2zBJyr3Ky04tiXpVbzmRc6iAca8uhXgApyEtAXV3FhMZ56eWqk2u1JikseiVHuQbEN4c2dyDer0AskXdLHgKQ4Ix0OlYeesAKve0hjHdbudaZx2sJ6eoFAgqCr0tzYMKIY9zZz6U5oDmDpmZzaIEZ4VkW8yLonkEO9R9C9mgvEDXGgyI7M/WZ+8WPB68o0faAS3u5QFbOsxPEzfKgweMrEVnTsuNTTQ53ahKsEACYEBoYDAijAvn8Z2iF5B21A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c6jqLNYfBvYpjM07suUaUHbZAcTMf0S1WEbuhtOZ22A=; b=SViIVZJsuf+K3ifc1+w/54zqv/zNasdQaK1iqkRbUd0UBSpFCEWvx/rCEmwUTfjC5+nkAbQXHBu8BGcezrKJ52YYQZqB+OYREPVfA1M3+HrOuxr8XXUVpzKXtFp75hP9MZmW5yDosHjwOep2P2X6Ff0jvfsyZmvqodn0bNlYgDLWkqx62CbDZFv/azCLRZj5x8rUBKst9V92x9RvOlHrVoDvJNpig3wWwMNGpSEPdvMHU6/9SjSmeO1vNC1s3l0EcuS1d4UWb2dnFweTK9DDCdbkD16sFsw3wpVk+28zXUg/trFaZE4WtTLgj1qjUE7OUloq1Z7sKXVaBif8FRjGiA==
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=c6jqLNYfBvYpjM07suUaUHbZAcTMf0S1WEbuhtOZ22A=; b=ZwtmBEu7SgDdpzxAY1PeTPv6LPAksLlBk0I05awIptroUadcP1qWJBGafmSlpCQHt7ftTxzemRBh3wejuzs0lRjUGrY95XAIqv/3XD4dqE3BVDR8od7U9fSSloZue3NE7K/b5ChqGFI0HXtxNNR7xFm3p4xt+Ii+aGGfaM5SV2Q=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by CY4PR1301MB1909.namprd13.prod.outlook.com (2603:10b6:910:3f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.9; Fri, 25 Feb 2022 19:34:01 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d%5]) with mapi id 15.20.5038.009; Fri, 25 Feb 2022 19:34:01 +0000
From: Haoyu Song 
To: Greg Mirsky 
CC: Tarek Saad , mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" 
Thread-Topic: [spring] Comments on draft-saad-mpls-miad-usecases
Thread-Index: AQHYJQybUbEkehVNgEePJZTL39BWqqyiwYCAgAC9BACAARPuUIAABOwAgAAZz0A=
Date: Fri, 25 Feb 2022 19:34:00 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0ca80ab6-f3fc-4322-c930-08d9f895c649
x-ms-traffictypediagnostic: CY4PR1301MB1909:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OiKSbDNitkrGDnl6MKH9HPkbD3hzliBTezuxIY8uRdAAgjjVYeBSFjZlth7ZwbWPkJAaMfsZZ2PfwyOYJnPt7DMF4yn5tHZWFrJlnjGYhN6R7uPMuvMQilSg5hEWaI9BuiQxW60UqaLKwwxIGO22UTHhaC0B+aYH35W4HigzIj/4h49a3g88dsxdMyDduMgsRxeGxEkU5nL1sLIZwLZCgw4UNlDUiKyLArRL3OEQ6qSUnavhX/PXcBzcVD17+7ZEnFdqfEaCpZirZ2i8ZVb6aIZmdSDWfk42arstJbLuq8KNjNL2qD/ooqVw/VgYWIT/JazcOSVk7uOofRV2YhXqayhhKqyghLAzBNI/6Va+5KbSu+y4YxMNq+HfWovgrPRWTTrA0st7Nfa49bWN6iXdneue6n19jXRNilSWVkT4i0AZa1+XZFQz3zGFYRtGOu4uPZJnNoG84ZT6yjUPtuF4l+TTnROzZObhVx9RNRoekxtJATlhFAIBeMnTN0opquO5azJhkoDKYwrEd/esED7Nfw0otKCaAc1Y/o3s3HCpRgGUH7TGMYwYRKsjpSVRFLBu7nUtI6R51bR6imtEkN8Q50WfNWE6d68t+4cjYzt/QYPJYASd9RlEubqTs8MLnBvIobkzB8AS1iA3djR3Rsk8FmLgQAmzyqrsXG5oqFm+IrqDa8cVkXL/hvdqzqBzsUUqjypkEApd7Gd84xtzuZhlEqSFluxdPlVp7QpfVBMKXaMLChVxW5Mvf9/va16cY+rrMn/O2yol32XBDKIDfEtKCI5hV5JY8KE+gbPBGei9EDw=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE;  SFS:(13230001)(4636009)(366004)(9686003)(66946007)(76116006)(64756008)(4326008)(66476007)(66446008)(166002)(71200400001)(83380400001)(38100700002)(66556008)(53546011)(7696005)(54906003)(316002)(55016003)(6506007)(122000001)(52536014)(33656002)(8936002)(6916009)(9326002)(38070700005)(8676002)(5660300002)(2906002)(44832011)(186003)(508600001)(966005)(86362001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7M6mfYChKmRlafZ7VHLH09cwTldm06hpiJQBPzS1qIUAdZhowU7AOqTQLbUX?= =?us-ascii?Q?rlEgIrCz2x4IKQCo3Us7icGX3220HVJShseoM7QlaBlUDPn3bYWw80upKYRD?= =?us-ascii?Q?l6yVSXeSXoURMo5jEDNyHe0MalmuxbZC8wWZjgkDcOXG1qumVXLkJhxC3FxP?= =?us-ascii?Q?1pNrBRa3MefG6cGvZ8EbCN06kt592GyVpMP5csZlhfbWv5k3S5h4GZ7FlwyH?= =?us-ascii?Q?FZiH1SAozYIZ9fq9t1RNRh84qkhRa5obXm3wwZdlMee7MwHxiuTGVVmugpUg?= =?us-ascii?Q?bpCl10XwL+L/Wypv7dR5Cpv/dmVJGj1S+ml1PQhcn/f1MHcHAy4R6aAxa4an?= =?us-ascii?Q?Qhnq4Csa2xqm3QIsPoCP8WphKuGcfYn257TDA7LAFFVy9oRGRKzKV49MaYSh?= =?us-ascii?Q?+ivMTkRxJYr2fIdz9IjobrRaeSdyz0mJjdUhh3a92oMLhI4aKRcSmzKa4UJb?= =?us-ascii?Q?R5SHvsLT+2MKzpyJI5+XWA4TqHkEuUmm2M3bW7Ms4ZeES67PDLXje3xGxBg7?= =?us-ascii?Q?LAhMFUzz849Dx7yXV5XxoasGHASD7FiOcfniqX2oN398E1d9lHRFv8ltJmYj?= =?us-ascii?Q?NS3IHyrR04rx75NycNGvEtqBroGg8ZC6egGD5h2jMpWPxQPG9ZSabtL6oqhS?= =?us-ascii?Q?F8qmRGV59Gk/M7Omr5k6rF7QcxN2AnvLQ6KVAXN6xpKf05zDq90+iHNdKCQs?= =?us-ascii?Q?w6KvkkdZMTEm3VIpHMXevhnUn/Ltn9J/Gv9S4ra6rmPLrzcZUcbFgBnymS0q?= =?us-ascii?Q?AHP3Om0Yzl3e7TbpPR+qxXHB/44jBkgn/sissrvn/YlbNPsIWlqg1ZRDHAFo?= =?us-ascii?Q?PZvUoy6I4uq5/8WahAXlZgxXkjpN54tXBzDgT70cjE8lTgbTfP6xfPNuR2dM?= =?us-ascii?Q?eivnc7IJVD+rJaiX26pFyeN7cUNQk73U+x2IkSyQH1GyiIiYwSFNOjGVznrk?= =?us-ascii?Q?WLuLsSazt9M8p7wAFjYg/WCiVEkxrfHQKL+hXQCDOTYe+VdfIfwZii6ZHhCy?= =?us-ascii?Q?b+B4Oydd1IXSlRMFZ/h7BWSh7vTFycJ07ZWnk9Zb2jM88Z/72vXWjzw8zATb?= =?us-ascii?Q?ZfNi+/5Q3zV1CgtbJz5aUVkeqpcHzkDvOQ8QWory2MFI+sVTp2XNcClJ80qM?= =?us-ascii?Q?7hUK28VxnLkSj4+OnbpSQnFKzAPPEq8RA2rznd0mqc2aBb3xhVxYeIMM5eaQ?= =?us-ascii?Q?f+VSPx/6zXNGcnbMTspePLJqCHbmDvVdKsEBblNRaRXYIyc6mvjSFuBZOUQl?= =?us-ascii?Q?vzERmZrhedReF7VZW3uabQIvm/Wcm3PXmhGdpcNrTH1iuift1C5QyrvRDD4U?= =?us-ascii?Q?PVS3MshZ/rGc8Gk7E9RoQCwasQoZ9fcd3o6r99typE2eOpfa3YUcANQN3bno?= =?us-ascii?Q?QzYk9+eUXkjB1pqqb8Mc3cuYWn6uYkYfNOlSGO0Om38z1CoLtLSHXSOa8X1r?= =?us-ascii?Q?swlFLCnJHX6nNJGU7uo/aa17+qL6YuX7g+SCoATZVLJjv1JA4s/xj55oEh9o?= =?us-ascii?Q?FCbL3LWkq297vPNO+BoC8Kplb6navaljjYzxDC/LAlWNzxP0qFmVt3ylsCA6?= =?us-ascii?Q?hZgxvK1GNzhdyv0qduymFe5IjwCB8LmbXZYVKinpRh64sR6IprxU3PYFYCXm?= =?us-ascii?Q?7B66x/6JomsatPwp0pY1kPBC3HHj3AjYgZkgLtWbym0kZwhwS9iBGaBfak8K?= =?us-ascii?Q?G/KHQ6Hg1zamVXFRijJzqZndWBM=3D?=
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787E6BEE884F834500A113D9A3E9BY3PR13MB4787namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ca80ab6-f3fc-4322-c930-08d9f895c649
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2022 19:34:00.9238 (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: kyPO9Afjf0RyfnwOaUQpxIsbsFy7VxuE/3+4cPeinqORswt+ScQU+T7UlfCygtp1FueJPbH6D2ofRzZ2dgWgmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1301MB1909
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 25 Feb 2022 19:34:30 -0000

--_000_BY3PR13MB4787E6BEE884F834500A113D9A3E9BY3PR13MB4787namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

There have been some existing standards (e.g., EL and this one) and proposa=
ls (some are listed in the document) with each dealing with a specific use =
case. I think it's beneficial to list them all and then consider to use a g=
eneric mechanism to handle all these otherwise piecemeal solutions. Of cour=
se, finally we would need to pick which shall actually be supported with th=
e generic method, but at this point, we shall not limit ourself.

Regards,
Haoyu

From: Greg Mirsky 
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song 
Cc: Tarek Saad ; mpls ; pals@ietf.org; =
DetNet WG ; spring ; draft-saad-mpls-miad=
-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
in RFC 8596 I don't find anything that would require any modification to th=
e existing MPLS architecture. I would agree that SFC NSH using MPLS to conn=
ect SFP components might benefit from the new enhancements to the MPLS, but=
 so would any other client that uses the MPLS network. Do you think that th=
e use case document should list them all?

Regards,
Greg

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song > wrote:

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
Hi Greg,

The RFC is mentioned because it shows that SFC NSH has been considered to b=
e supported in MPLS as well, so it's a legitimate use case like the others =
in the draft. When we need to support multiple such use cases at the same t=
ime, we need a generic mechanism to support them, so the use-case draft ser=
ves as a motivation for our work in the ODT.
Hopefully this answers your question. Thanks,
Haoyu

From: Greg Mirsky >
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad >
Cc: mpls >; pals@ietf.org; DetNet WG >; spring >; draft-saad-mpls-miad-usecases@ietf.or=
g
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed t=
he diff and got several follow-up notes:

  *   the new text in the Introduction section explains the ISD as being en=
coded as labels:
within the label stack, e.g., encoded as labels, referred to as In
                 Stack Data (ISD), and
I think s/as labels/into label stack elements/ makes the text a bit more ac=
curate. What do you think?

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
  *   I might have missed it earlier. The TSN is the term used for a very s=
pecific technology developed at IEEE to support, for example, URLLC service=
s. The DetNet WG defines the methodology in support of these services using=
 IETF technologies - MPLS and IP. I think it would be appropriate if an IET=
F document refers to Deterministic Networking, not TSN. What is your opinio=
n?
Regards,
Greg


On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad > wrote:
Hi Greg,

Thanks for your comments. I've addressed several of your comments. The late=
st diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draf=
t-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/t=
saad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt

Regards,
Tarek (for co-authors)

From: spring > on b=
ehalf of Greg Mirsky >
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org >, mpls >, pa=
ls@ietf.org >, De=
tNet WG >, spring >
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze=
 essential use cases in the scope of the work at the Open DT. Attached, ple=
ase find a copy of the draft with my notes and some editorial suggestions. =
I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

--_000_BY3PR13MB4787E6BEE884F834500A113D9A3E9BY3PR13MB4787namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Greg,


 


There have been some existing standards (e.g., EL an=
d this one) and proposals (some are listed in the document) with each deali=
ng with a specific use case. I think it’s beneficial to list them all=
 and then consider to use a generic mechanism
 to handle all these otherwise piecemeal solutions. Of course, finally we w=
ould need to pick which shall actually be supported with the generic method=
, but at this point, we shall not limit ourself.



 


Regards,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com&g=
t; 

Sent: Friday, February 25, 2022 9:54 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org&g=
t;; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@iet=
f.org>; draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




in RFC 8596 I don't find anything that would require=
 any modification to the existing MPLS architecture. I would agree tha=
t SFC NSH using MPLS to connect SFP components might benefit from the new e=
nhancements to the MPLS, but so would any
 other client that uses the MPLS network. Do you think that the use case do=
cument should list them all?






 






Regards,






Greg






 






On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com> wro=
te:










    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.


Hi Greg,


 


The RFC is mentioned because it shows that SFC NSH has been consid=
ered to be supported in MPLS as well, so it’s a legitimate use case l=
ike the others in the draft. When we need
 to support multiple such use cases at the same time, we need a generic mec=
hanism to support them, so the use-case draft serves as a motivation for ou=
r work in the ODT.


Hopefully this answers your question. Thanks,


Haoyu  


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls=
@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 






Hi Tarek,




thank you for your thoughtful consideration of my comments. I=
've reviewed the diff and got several follow-up notes:






    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, referred to as In=
     















           =
      Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes the text a bi=
t more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




 




 






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com> wrote:










Hi Greg,


 =



Thanks for your co=
mments. I’ve addressed several of your comments. The latest diffs (re=
vision to be uploaded soon) can be found at:


https://tools.ietf.org//rfcd=
iff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00=
.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/drafts/master/m=
iad-usecases/draft-dt-mpls-miad-usecases.txt


 =



Regards,


Tarek (for co-auth=
ors)


 =





From:
spri=
ng <spring-=
bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,




thank you for your work putting this document=
 together. It helps to analyze essential use cases in the scope of the work=
 at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial suggestions. I h=
ope you'll find some of them helpful.






I am looking forward to your feedback and que=
stions.






 






Regards,






Greg


























--_000_BY3PR13MB4787E6BEE884F834500A113D9A3E9BY3PR13MB4787namp_--


From nobody Fri Feb 25 17:41:22 2022
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 A64323A12B6; Fri, 25 Feb 2022 17:29:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: martin.vigoureux@nokia.com, spring@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164583896066.24617.17529828298917603692@ietfa.amsl.com>
Date: Fri, 25 Feb 2022 17:29:20 -0800
Archived-At: 
Subject: [spring] spring - Requested session has been scheduled for IETF 113
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: Sat, 26 Feb 2022 01:29:32 -0000

Dear Bruno Decraene,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    spring Session 1 (2:00 requested)
    Friday, 25 March 2022, Afternoon Session I 1230-1430
    Room Name: Grand Park Hall 2 size: 200
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/113/sessions/spring.ics

Request Information:


---------------------------------------------------------
Working Group Name: Source Packet Routing in Networking
Area Name: Routing Area
Session Requester: Bruno Decraene


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 100
Conflicts to Avoid: 

       


People who must be present:
  Bruno Decraene
  Jim Guichard
  Joel M. Halpern
  Martin Vigoureux
  Shuping Peng

Resources Requested:

Special Requests:
  
---------------------------------------------------------



From nobody Sat Feb 26 16:36:16 2022
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 6FB7F3A06E7; Sat, 26 Feb 2022 16:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.509
X-Spam-Level: 
X-Spam-Status: No, score=-0.509 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, FROM_FMBLA_NEWDOM=1.498, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 GhxRv1rWwpeF; Sat, 26 Feb 2022 16:35:51 -0800 (PST)
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 A600A3A07D2; Sat, 26 Feb 2022 16:35:43 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id c6so12402163edk.12; Sat, 26 Feb 2022 16:35:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uA54n93eKMhxAntcm1TNmNs+3bZ5Bv5kcncI4WcW12o=; b=jX7/d6+yyXAML9SvjMGJyzbjzJ23sd26K9UdPptCKZT3efZOmQFWP5R4t/OTG63JeZ lTYq7R/nfEFJX+SntvWSrMY0DzSV0fi/c1StPjWXkJApI2YYwIGOu8uGdQfQlZPgnDgM rAKQVaDUQUMlCJITkuy9iI4TpPGiFA/khwaa2sIcYXsSKAN5h1KKIuC9d1n3LdQjSOSM Q+rVBMw+8Hb07Q6Rd9ARGbf6nM3UtfRDTmDJrDYXBIwJb7l0irsq/2w6LRirpN+gO6iH 8m1DadDi6wCbdGLWevMnyAsNKBanN8lY0h9i9ABl4GE13JvjoMWvMONTuKZd2eEdDlDu ss7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uA54n93eKMhxAntcm1TNmNs+3bZ5Bv5kcncI4WcW12o=; b=IMq2WeVWmWMwzHwK7mSU1lTnRr9Wx+X5v/R1o2qBHVE88AtwgvsT2F/yU5mOi5+12u QQk4FgF6Ov0dffw66fQlDVlNYfn0cmOAGLo8TWcx9MoodjDSA3a3kLvOYQK/YIB4Seys wHDxPlwvLSAGGN4CWXPcs5bLjwCt3BXRyXbJf+mGk/AotuZSVDHNq9E7UVqxqJ33+Tvz m0qgM8limgc7XY6MCsAi/07U3MqLg/MggZ7SC3kLhpgAZBzndwfwUg2/pKlw+DORm78Q XVecZhpGPxa2wN5XbAeqRobi3XAt2KEaXfJQy3QabW01Rj2w8ZcUfS0W7kV2W6QVVaxM Nq1g==
X-Gm-Message-State: AOAM531ZGT96ZbNEchgscdCsseJW8h7OvRWoCNnELvtvcCXNIjLQzPQc JI6mVWkkOVkxVP3KytK3gbXFOcouAGgcEkAfGMSOA6l+
X-Google-Smtp-Source: ABdhPJxRwhGQl8bchefONh4ZphfCfEnQ+Zp2rCklztLYtfDhMqB19P+Jd8Q4PGF+Lqlp4cqTqjdp1zQ+c64EvdwE5JM=
X-Received: by 2002:aa7:c3d5:0:b0:40f:b885:8051 with SMTP id l21-20020aa7c3d5000000b0040fb8858051mr13386186edr.395.1645922141685; Sat, 26 Feb 2022 16:35:41 -0800 (PST)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Greg Mirsky 
Date: Sat, 26 Feb 2022 16:35:30 -0800
Message-ID: 
To: Haoyu Song 
Cc: Tarek Saad , mpls , "pals@ietf.org" ,  DetNet WG , spring ,  "draft-saad-mpls-miad-usecases@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000095497505d8f51c97"
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 27 Feb 2022 00:35:56 -0000

--00000000000095497505d8f51c97
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Haoyu,
I am sorry, but after reading your note, I cannot find an answer to my
question How the MIAD work is applicable to the informational RFC 8596? In
other words, What do you see as missing in the solution described in RFC
8596 that MIAD is expected to address?

Regards,
Greg

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song 
wrote:

> Hi Greg,
>
>
>
> There have been some existing standards (e.g., EL and this one) and
> proposals (some are listed in the document) with each dealing with a
> specific use case. I think it=E2=80=99s beneficial to list them all and t=
hen
> consider to use a generic mechanism to handle all these otherwise pieceme=
al
> solutions. Of course, finally we would need to pick which shall actually =
be
> supported with the generic method, but at this point, we shall not limit
> ourself.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Friday, February 25, 2022 9:54 AM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> in RFC 8596 I don't find anything that would require any modification to
> the existing MPLS architecture. I would agree that SFC NSH using MPLS to
> connect SFP components might benefit from the new enhancements to the MPL=
S,
> but so would any other client that uses the MPLS network. Do you think th=
at
> the use case document should list them all?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song 
> wrote:
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>
> Hi Greg,
>
>
>
> The RFC is mentioned because it shows that SFC NSH has been considered to
> be supported in MPLS as well, so it=E2=80=99s a legitimate use case like =
the others
> in the draft. When we need to support multiple such use cases at the same
> time, we need a generic mechanism to support them, so the use-case draft
> serves as a motivation for our work in the ODT.
>
> Hopefully this answers your question. Thanks,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad 
> *Cc:* mpls ; pals@ietf.org; DetNet WG ;
> spring ; draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Tarek,
>
> thank you for your thoughtful consideration of my comments. I've reviewed
> the diff and got several follow-up notes:
>
>    - the new text in the Introduction section explains the ISD as being
>    encoded as labels:
>
> within the label stack, e.g., encoded as labels, referred to as In
>
>                  Stack Data (ISD), and
>
> I think s/as labels/into label stack elements/ makes the text a bit more
> accurate. What do you think?
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>    - I might have missed it earlier. The TSN is the term used for a very
>    specific technology developed at IEEE to support, for example, URLLC
>    services. The DetNet WG defines the methodology in support of these
>    services using IETF technologies - MPLS and IP. I think it would be
>    appropriate if an IETF document refers to Deterministic Networking, no=
t
>    TSN. What is your opinion?
>
> Regards,
>
> Greg
>
>
>
>
>
> On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad  wrote:
>
> Hi Greg,
>
>
>
> Thanks for your comments. I=E2=80=99ve addressed several of your comments=
. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/dr=
aft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com=
/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> 
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring  on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *draft-saad-mpls-miad-usecases@ietf.org <
> draft-saad-mpls-miad-usecases@ietf.org>, mpls ,
> pals@ietf.org , DetNet WG , spring <
> spring@ietf.org>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some
> editorial suggestions. I hope you'll find some of them helpful.
>
> I am looking forward to your feedback and questions.
>
>
>
> Regards,
>
> Greg
>
>

--00000000000095497505d8f51c97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Haoyu,
I am sorry, but after reading your note, I c=
annot find an answer to my question How the MIAD work is applicable to the =
informational RFC 8596? In other words, What do you see as missing in the s=
olution described in RFC 8596 that MIAD is expected to address?
<=
br>
Regards,
Greg

On Fri, Feb 25, 2022 at 11:34 AM=
 Haoyu Song <haoyu.song@futu=
rewei.com> wrote:











Hi Greg,


=C2=A0


There have been some existing standards (e.g., EL an=
d this one) and proposals (some are listed in the document) with each deali=
ng with a specific use case. I think it=E2=80=99s beneficial to list them a=
ll and then consider to use a generic mechanism
 to handle all these otherwise piecemeal solutions. Of course, finally we w=
ould need to pick which shall actually be supported with the generic method=
, but at this point, we shall not limit ourself.



=C2=A0


Regards,


Haoyu


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.com> 

Sent: Friday, February 25, 2022 9:54 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>; dra=
ft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0




Hi=C2=A0Haoyu,




in RFC 8596 I don't find anything that would req=
uire any modification to the existing MPLS architecture. I would=C2=A0agree=
 that SFC NSH using MPLS to connect SFP components might benefit from the n=
ew enhancements to the MPLS, but so would any
 other client that uses the MPLS network. Do you think that the use case do=
cument should list them all?






=C2=A0






Regards,






Greg






=C2=A0






On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurew=
ei.com> wrote:










    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.


Hi Greg,


=C2=A0


The RFC is mentioned because it shows that SFC NSH h=
as been considered to be supported in MPLS as well, so it=E2=80=99s a legit=
imate use case like the others in the draft. When we need
 to support multiple such use cases at the same time, we need a generic mec=
hanism to support them, so the use-case draft serves as a motivation for ou=
r work in the ODT.


Hopefully this answers your question. Thanks,=



Haoyu =C2=A0


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls=
@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0






Hi Tarek,




thank you for your thoughtful=C2=A0consideration of =
my comments. I've reviewed the diff and got several follow-up notes:=







    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, ref=
erred to as 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=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes=
 the text a bit more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




=C2=A0




=C2=A0






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com=
> wrote:










Hi Gre=
g,


=C2=A0=



Thanks=
 for your comments. I=E2=80=99ve addressed several of your comments. The la=
test diffs (revision to be uploaded soon) can be found at:=



https://tools.ie=
tf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad=
-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/dra=
fts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<=
u>


=C2=A0=



Regard=
s,


Tarek =
(for co-authors)


=C2=A0=





From:
spring=
 <spring-bo=
unces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,<=
/u>




thank you for your work putting=
 this document together. It helps to analyze essential use cases in the sco=
pe of the work at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial=C2=A0suggestions. I h=
ope you'll find some of them helpful.






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






=C2=A0






Regards,





Greg





























--00000000000095497505d8f51c97--


From nobody Mon Feb 28 10:05:35 2022
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 3FC4F3A12C8; Mon, 28 Feb 2022 10:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 JO1qj2kFZH_l; Mon, 28 Feb 2022 10:05:05 -0800 (PST)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2119.outbound.protection.outlook.com [40.107.220.119]) (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 DB0183A12B2; Mon, 28 Feb 2022 10:05:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QlTcbQkWolnQNDaDA6OyRlRXGsx8iBUV1PQPZpb/iYyBeDnDobESsUs27mi9o6XH8+LJxzEmexRE6sEJfQublzOgrMEOHMQLo7zpgm9epmlZZQv8KiAu5WCaPtRPK9+/CejLGqyJyWT9LdTNW1elKeFGzoJ+gfBA9CmERQFzIc5iNC1BU4EmHgSeTT3HhXGgZzz/1XEb555+vEBHRRhxAftNt8E48nWOUg2yC8/CVReDh09MexMhM3NTwvIvD6cwK+Rf8xJkNrXo9JOeDTzM+zkiamIe9apFRxE4faWKOpxKoL2UjF0cNrgA0xK4reB4wXjqJPnKWQ2kZd/c9IfFrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jkyjh9grqT0cbWPf2tcUESdL5I+C7ijjx7YNt2v4PRw=; b=gp1XoAMS8f5gxQuSct+Oo8lgr/fyxWvsmc1PGh6hqnK5DEprbQY+fvJFVoR0qFVGY979imX6KRewvhJMrwbYbSOIeA2EJqSu9t6tcHjoMQqAB1h0JSxh6sQ6IyTV4In0DBvyAmyeF/ZjdUgsXrFJuu94wi4Hw+Umo3keUqUNBLh5gun28ZM+B1iWTpKGMsK6pYi3myg+xJIf5lbTqY5c7FDwlS1LjheJ5JmFy5LqK/Q2Z8jU6t/HRWhG1letauGOj4FyBrezn4LpHRhqQY44LsTtobt2WdJTr/ByKBe53SgNF7BysOHRb01RooUqgB1Ty4zU0Cxn1spaQ2eVAfvxRA==
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=jkyjh9grqT0cbWPf2tcUESdL5I+C7ijjx7YNt2v4PRw=; b=bK+yxPsET1SQ8XZYOiV9x+WcZRA6qhzC1ir8DYPlwazCOreXLyZp9Un5JqEpO3YJ/s8/9DJAAjAcK6k3laatYfsqaUc9PdqpVOXhGcGD/V1F45ZlgLTdOmL3x1nZlx6vq7d8rkHFjP0rWvE/Zni26sup4kcXL+jlTMZmyQEDVxA=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BN6PR13MB1171.namprd13.prod.outlook.com (2603:10b6:404:1a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.9; Mon, 28 Feb 2022 18:05:00 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d%5]) with mapi id 15.20.5038.013; Mon, 28 Feb 2022 18:05:00 +0000
From: Haoyu Song 
To: Greg Mirsky 
CC: Tarek Saad , mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" 
Thread-Topic: [spring] Comments on draft-saad-mpls-miad-usecases
Thread-Index: AQHYJQybUbEkehVNgEePJZTL39BWqqyiwYCAgAC9BACAARPuUIAABOwAgAAZz0CAAeiSAIACtr1g
Date: Mon, 28 Feb 2022 18:05:00 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 24e80eee-9719-4de0-55e9-08d9fae4d668
x-ms-traffictypediagnostic: BN6PR13MB1171:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5qW67qkROVDRWA2bTbn5aaxcvMsZEifqOiokixawpf4CT/GH9PywmjjfIfGFxgxKXVUueHA7tOXgIhO7V1lppQ8HakAMnShzoix5Kbr/14Y2ne98xGZ5jxCriq7/KfcC7DPcYi0CwLL/dL3l3DOMa/L0qW1EZemLQkWU+RnMnm/zn9rr/aDuNooU66E8nYdvzdvuzsjM0hMa/zMR7UUv858lBUEtqmcAkQFBWMTn2nuu6S9j0sqrR3miKSfltBYk/A8LB7cjjURQUnT0t1SPEddxVm2i49GaanP10aOQhlbFYj/hTs0qY3Ienf44oUTwxILQ3eDhBLb6HnWvrxHxQrZ+0IQbkoG6sI7oDE/dyfgKqZdUjlmMjDuBf+b5vdhCfbweU60x699oz31Kzuht8L1bmRwEv+V5zTb2DlAZOcn8yk37Ydz4qDz/4pNDDJaAHYGl1XekEl8mflpBxSLLBSu4LIs9708+P8hhr9LSPv+pJ1Lb72+OYTk0M84DbTkq+10Hivbuiu4pSPs97TO19i3a18iLue2Rrqec3RYIXEmTlSm8pDKj69VjO/AkEy3BK1p26ubEF+js5JeZCC02zRUn1tKFHU9vbYXDvNrpR/4Kwu8L97f711qxlAOPcoYX2gHXf09r2S0xEE4av8AHUaI8h7YIndQvzKPAme2VAIZLK4PjgSrqtwyMZgFHZfF+VhW7uCfH5nFyCDW32+lP627MhI7LxAUvM+eJyVJzakT6sGC5wXMlVsGcYTbjH/FNLIPd94PWoeuR7ZbbOt7iWXJ3ig1IPE0hk610DfFEYtg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE;  SFS:(13230001)(4636009)(366004)(9326002)(8936002)(86362001)(7696005)(6506007)(52536014)(5660300002)(53546011)(166002)(508600001)(64756008)(66446008)(55016003)(8676002)(4326008)(83380400001)(66476007)(66556008)(66946007)(966005)(76116006)(186003)(9686003)(38070700005)(33656002)(26005)(71200400001)(38100700002)(54906003)(122000001)(6916009)(2906002)(44832011)(316002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0+06H+mr22XGEmM5MWncesEBXxjynigdcBsKDJe7N1gh0aBQJD3BRoCc9rNG?= =?us-ascii?Q?lkf5ppC0Nhc/o6ZZ45R9KHd2tf9w9PAcmVS6VaHYLrBZmAX15/S8l6TuDuHL?= =?us-ascii?Q?bXyan3XZfyAjkODewgnWXZka9ywRSLZHWk2DoDbRUkhfJMiVcZ40sI2iNMpr?= =?us-ascii?Q?1x1FQxfF/NnERlqBjcyy4KatVEChsZuZ1W0wxbPU4yBdNylkNsWsSedmcuSt?= =?us-ascii?Q?cvWpmrCcNRH5FM1no8/xpBp10morhhYJ3CD7K4191fkTORX0/1W0J2FAqepv?= =?us-ascii?Q?CrK6P6F+HhbuOywuVaXUIOjfLzK3/7DYnCURqLeTsXgigeMO7Sz4XWK166W9?= =?us-ascii?Q?KiDqAadf5kMW5L2caeeJdO/7lFhvwySTIMHBpYwEU8NnYxTKOKQkH1ObxIA8?= =?us-ascii?Q?dDoDbDc8/Q6xSgwpyg/7etO4fiMvJiK3JJ4psmYFuwDo8z5prooKAcCFkKq7?= =?us-ascii?Q?djni+n0zsB3mXbYZMZcwBwxO+adI0HogwNja3Z3T1OyOv4uLvZMCz0GXK5+/?= =?us-ascii?Q?IkHZnF8mAQ0Y4mO4qrtD716k505+XM8NTlyN27p+ohQmO8qPXRb4LcOKYRcQ?= =?us-ascii?Q?fWbuBqcz5HaSGe0NGs6ehWYQJtdQGzz9gI6ucRPzY8G+xJgBcQ2Zl4i5CR9V?= =?us-ascii?Q?2us8VgmYxSD+ZVLl3TLlTS3+rT2CKTS5P6xzcpTtQAVHL1Y7SgjuSPMNW0xT?= =?us-ascii?Q?vk24t6ctWHZuRVmP7tERbobirR3yvFFwYpeguISuPrO+2HvFbpnxZWJTRbip?= =?us-ascii?Q?RcD8WsCyX3xe1y7bP7hlKlX3zm6EXSIU3jtkMDq66rLng7RUFKpt5Q04btAq?= =?us-ascii?Q?XUD7A0NcSSToyHW6+GqS5Zvu1j7eVBaJpGXpplmXRA1kAPR4grOWbql4DOtJ?= =?us-ascii?Q?DuB5wfYKyhrZ5dpI9rfBrJmGqYsWNxyOCdKgVcsljYU85SBfBbBJ7EY8BWUi?= =?us-ascii?Q?coGA1RIpQGK0xC4gjdOMhYhReUjMK7Feam7X34xiJcrD5H7V1J1KmpN8Phye?= =?us-ascii?Q?q7cPIZKNmRCFU/lQLJc72E3gIzzY6TLfaewWToajo+3Q2fDYgGAI4aFLrz5Z?= =?us-ascii?Q?I2Make6V6Xs8ELcFRp3X5nc6wdmYNfYRICrCmpDdYvL3m8uOKsDoEjUWygZX?= =?us-ascii?Q?51AEa543vrFoyelw/5MUEbdgO186eVLEfIoMBs4OfXTOI7VMkX2ok9MYZwEr?= =?us-ascii?Q?X4IjcglHjuKVx0Dy6iz/+Uwxv/k1ozFMtUVw3/WdzAGhlK0IDQdWjIb38HZB?= =?us-ascii?Q?x6JKVVcWoocpcFvBElPS6ASKujBKORNM/WfoweLkRkAIb+yJGVaG61CDWZJy?= =?us-ascii?Q?w+S/1R6AuujXx6ADvNQH/u/B4bnDKc+ApjqhgxvPIAg6YtFE6M52CB7+bfqD?= =?us-ascii?Q?jkFGfNe7RkBL6q9RnU7MhomW6E4IUvfBKwxu89a5gy6nqDr48EbEENJkp7Z6?= =?us-ascii?Q?83A/kJYxupT6x1r6CEiVj72EoDm/HLHil1k8vsrX8MLrWY9X2eTBVPVGrxBT?= =?us-ascii?Q?MD8+ycSzjcvlgJn8ll6JhfovrgR0vUz4HbCfrlnuQvLZZZM/qK/HavFtD4b4?= =?us-ascii?Q?PgKKU6NaJl0zmDSW+5+RgGJFXOySF7RwXX8XA3ewTkFpGNOy1YFcZ3u4qpVD?= =?us-ascii?Q?nQ=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB478792ACD5719D06DCAD2A6F9A019BY3PR13MB4787namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 24e80eee-9719-4de0-55e9-08d9fae4d668
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2022 18:05:00.4879 (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: 49Mf0D+Vzq2XKNzjDiC5IkMRCFYNqFo27GIPZ3C3LQ92cBlR7b8EoHWcMhTIudStM5Mu/JBP32/rpoeGXSaxVg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR13MB1171
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 28 Feb 2022 18:05:11 -0000

--_000_BY3PR13MB478792ACD5719D06DCAD2A6F9A019BY3PR13MB4787namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

What I think is that whatever output is from MIAD, it will provide a new so=
lution to support NSH SFC in MPLS.
RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be cooperat=
ive with the other use cases in the same packet. MIAD tries to solve this p=
roblem.

Best,
Haoyu

From: Greg Mirsky 
Sent: Saturday, February 26, 2022 4:36 PM
To: Haoyu Song 
Cc: Tarek Saad ; mpls ; pals@ietf.org; =
DetNet WG ; spring ; draft-saad-mpls-miad=
-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
I am sorry, but after reading your note, I cannot find an answer to my ques=
tion How the MIAD work is applicable to the informational RFC 8596? In othe=
r words, What do you see as missing in the solution described in RFC 8596 t=
hat MIAD is expected to address?

Regards,
Greg

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song > wrote:
Hi Greg,

There have been some existing standards (e.g., EL and this one) and proposa=
ls (some are listed in the document) with each dealing with a specific use =
case. I think it's beneficial to list them all and then consider to use a g=
eneric mechanism to handle all these otherwise piecemeal solutions. Of cour=
se, finally we would need to pick which shall actually be supported with th=
e generic method, but at this point, we shall not limit ourself.

Regards,
Haoyu

From: Greg Mirsky >
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song >
Cc: Tarek Saad >; mpls >; pals@ietf.org; Det=
Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
in RFC 8596 I don't find anything that would require any modification to th=
e existing MPLS architecture. I would agree that SFC NSH using MPLS to conn=
ect SFP components might benefit from the new enhancements to the MPLS, but=
 so would any other client that uses the MPLS network. Do you think that th=
e use case document should list them all?

Regards,
Greg

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song > wrote:

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
Hi Greg,

The RFC is mentioned because it shows that SFC NSH has been considered to b=
e supported in MPLS as well, so it's a legitimate use case like the others =
in the draft. When we need to support multiple such use cases at the same t=
ime, we need a generic mechanism to support them, so the use-case draft ser=
ves as a motivation for our work in the ODT.
Hopefully this answers your question. Thanks,
Haoyu

From: Greg Mirsky >
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad >
Cc: mpls >; pals@ietf.org; DetNet WG >; spring >; draft-saad-mpls-miad-usecases@ietf.or=
g
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed t=
he diff and got several follow-up notes:

  *   the new text in the Introduction section explains the ISD as being en=
coded as labels:
within the label stack, e.g., encoded as labels, referred to as In
                 Stack Data (ISD), and
I think s/as labels/into label stack elements/ makes the text a bit more ac=
curate. What do you think?

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
  *   I might have missed it earlier. The TSN is the term used for a very s=
pecific technology developed at IEEE to support, for example, URLLC service=
s. The DetNet WG defines the methodology in support of these services using=
 IETF technologies - MPLS and IP. I think it would be appropriate if an IET=
F document refers to Deterministic Networking, not TSN. What is your opinio=
n?
Regards,
Greg


On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad > wrote:
Hi Greg,

Thanks for your comments. I've addressed several of your comments. The late=
st diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draf=
t-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/t=
saad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt

Regards,
Tarek (for co-authors)

From: spring > on b=
ehalf of Greg Mirsky >
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org >, mpls >, pa=
ls@ietf.org >, De=
tNet WG >, spring >
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze=
 essential use cases in the scope of the work at the Open DT. Attached, ple=
ase find a copy of the draft with my notes and some editorial suggestions. =
I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

--_000_BY3PR13MB478792ACD5719D06DCAD2A6F9A019BY3PR13MB4787namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Greg,


 


What I think is that whatever output is from MIAD, i=
t will provide a new solution to support NSH SFC in MPLS.



RFC 8596 shows a way to support NSH SFC in MPLS, but=
 it may not be cooperative with the other use cases in the same packet. MIA=
D tries to solve this problem.



 


Best,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com&g=
t; 

Sent: Saturday, February 26, 2022 4:36 PM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org&g=
t;; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@iet=
f.org>; draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




I am sorry, but after reading your note, I cannot fi=
nd an answer to my question How the MIAD work is applicable to the informat=
ional RFC 8596? In other words, What do you see as missing in the solution =
described in RFC 8596 that MIAD is
 expected to address?






 






Regards,






Greg






 






On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@futurewei.com> wr=
ote:










Hi Greg,


 


There have been some existing standards (e.g., EL and this one) an=
d proposals (some are listed in the document) with each dealing with a spec=
ific use case. I think it’s beneficial
 to list them all and then consider to use a generic mechanism to handle al=
l these otherwise piecemeal solutions. Of course, finally we would need to =
pick which shall actually be supported with the generic method, but at this=
 point, we shall not limit ourself.



 


Regards,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Friday, February 25, 2022 9:54 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




in RFC 8596 I don't find anything that would require any modificat=
ion to the existing MPLS architecture. I would agree that SFC NSH usin=
g MPLS to connect SFP components might benefit
 from the new enhancements to the MPLS, but so would any other client that =
uses the MPLS network. Do you think that the use case document should list =
them all?






 






Regards,






Greg






 






On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com>=
 wrote:










    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.


Hi Greg,


 


The RFC is mentioned because it shows that SFC NSH has been consid=
ered to be supported in MPLS as well, so it’s a legitimate use case l=
ike the others in the draft. When we need
 to support multiple such use cases at the same time, we need a generic mec=
hanism to support them, so the use-case draft serves as a motivation for ou=
r work in the ODT.


Hopefully this answers your question. Thanks,


Haoyu  


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls=
@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 






Hi Tarek,




thank you for your thoughtful consideration of my comments. I=
've reviewed the diff and got several follow-up notes:






    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, referred to as In=
     















           =
      Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes the text a bi=
t more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




 




 






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com> wrote:










Hi Greg,


 =



Thanks for your co=
mments. I’ve addressed several of your comments. The latest diffs (re=
vision to be uploaded soon) can be found at:


https://tools.ietf.org=
//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad-useca=
ses-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/drafts/ma=
ster/miad-usecases/draft-dt-mpls-miad-usecases.txt

 =



Regards,


Tarek (for co-auth=
ors)


 =





From:
spri=
ng <spring-=
bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,




thank you for your work putting this document=
 together. It helps to analyze essential use cases in the scope of the work=
 at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial suggestions. I h=
ope you'll find some of them helpful.






I am looking forward to your feedback and que=
stions.






 






Regards,






Greg


































--_000_BY3PR13MB478792ACD5719D06DCAD2A6F9A019BY3PR13MB4787namp_--


From nobody Mon Feb 28 10:56:59 2022
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 B729A3A13C6; Mon, 28 Feb 2022 10:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 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_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MJgglCASadDC; Mon, 28 Feb 2022 10:56:41 -0800 (PST)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6CA3A13C4; Mon, 28 Feb 2022 10:56:41 -0800 (PST)
Received: by mail-ej1-x634.google.com with SMTP id p14so26712682ejf.11; Mon, 28 Feb 2022 10:56:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UZzsD/QfhQoBWDJl8ZBX47RN0V8W6nzg+XX6vC8qAhs=; b=R15LAnW/KcOGd4noz0ZyYJ98jPW+O/aEQjTc6Rs1WiyKWSlFTZyzFUTtDMXPO4iuhA 6bzJfrPKtqVkyAvIH5qRDQRG0gvnmzEJlBr6GxykHDQ/FP0zHypavwdyGWQbQxnrzqDp qRUCJegBo+p54lY2TBZQqTaWBZi7D8W3zKSdlIJ3JZeYU2GCdJBp0eN/hM9gnQYQCsha d+UF638gThOxET0yWw4NZHQRMh8N5++ysHKAujOaBgWoOIDvcmFVymrLKLGW++JWyE8r YVUJFpoDJs++ZVsiO7K3ImI6+GjLQCynVXLC6TfgDN9bueGYtaKl9dnkecFHafqsk250 noSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UZzsD/QfhQoBWDJl8ZBX47RN0V8W6nzg+XX6vC8qAhs=; b=qZ5Y6o0GuvUxI4s8B+PFrzqylmCeAvMEcnGtbkQBvyVDrUUuXX/c26XUweBq3g06n5 pCNUfOgXT0IxmBrINtRZPkes9hDIPLexuJnUMBsEt/U/KDLkP7l8MYfQhDcTDkGXlyGf JgYWzb/GVQ1XD37UwZpU3Rbjj3Gm2W3UQZhPAlbC5RXO7CvdZTFUAiyw8wca5YdJo4Or xcqlbjAIjWw7Y8sA54LBf41e81TI8aHrofny40SLNRxo1xOmfM3QC8deZ43tImoFs6bj bl3wasb6Wj1+QHMwAsVnvrpwwbkY92JrAdkenAj6BgeJq94wSgH5S9sfQi75BHjqQbLy MxgQ==
X-Gm-Message-State: AOAM5318fTfmMRd+ev/B67SkX6GS16iKK6ByrMknEvMGEmpGOKQu5Bh1 6DA3Y7L4+a1+lfyTQ0kWCEinpA2K3AaIsMAsM0I=
X-Google-Smtp-Source: ABdhPJzF8vT4Fcvz/P9tA9c+FmwVj5R3qrrZtTYxzb3pbflDUlsbD7t9ov7wZHupWTbH3r/Vz5kthIwJZLnsPs+SbIg=
X-Received: by 2002:a17:906:2695:b0:6ce:f9c:b476 with SMTP id t21-20020a170906269500b006ce0f9cb476mr16206361ejc.235.1646074598573; Mon, 28 Feb 2022 10:56:38 -0800 (PST)
MIME-Version: 1.0
References:        
In-Reply-To: 
From: Greg Mirsky 
Date: Mon, 28 Feb 2022 10:56:27 -0800
Message-ID: 
To: Haoyu Song 
Cc: Tarek Saad , mpls , "pals@ietf.org" ,  DetNet WG , spring ,  "draft-saad-mpls-miad-usecases@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b8ca8705d9189bdf"
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 28 Feb 2022 18:56:47 -0000

--000000000000b8ca8705d9189bdf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Haoyu,
can you give an example of "the other use cases in the same packet"? I
don't think that discussing some hypothetical scenarios is a productive way
for the Open DT.

Regards,
Greg

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song 
wrote:

> Hi Greg,
>
>
>
> What I think is that whatever output is from MIAD, it will provide a new
> solution to support NSH SFC in MPLS.
>
> RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be
> cooperative with the other use cases in the same packet. MIAD tries to
> solve this problem.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Saturday, February 26, 2022 4:36 PM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> I am sorry, but after reading your note, I cannot find an answer to my
> question How the MIAD work is applicable to the informational RFC 8596? I=
n
> other words, What do you see as missing in the solution described in RFC
> 8596 that MIAD is expected to address?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song 
> wrote:
>
> Hi Greg,
>
>
>
> There have been some existing standards (e.g., EL and this one) and
> proposals (some are listed in the document) with each dealing with a
> specific use case. I think it=E2=80=99s beneficial to list them all and t=
hen
> consider to use a generic mechanism to handle all these otherwise pieceme=
al
> solutions. Of course, finally we would need to pick which shall actually =
be
> supported with the generic method, but at this point, we shall not limit
> ourself.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Friday, February 25, 2022 9:54 AM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> in RFC 8596 I don't find anything that would require any modification to
> the existing MPLS architecture. I would agree that SFC NSH using MPLS to
> connect SFP components might benefit from the new enhancements to the MPL=
S,
> but so would any other client that uses the MPLS network. Do you think th=
at
> the use case document should list them all?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song 
> wrote:
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>
> Hi Greg,
>
>
>
> The RFC is mentioned because it shows that SFC NSH has been considered to
> be supported in MPLS as well, so it=E2=80=99s a legitimate use case like =
the others
> in the draft. When we need to support multiple such use cases at the same
> time, we need a generic mechanism to support them, so the use-case draft
> serves as a motivation for our work in the ODT.
>
> Hopefully this answers your question. Thanks,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad 
> *Cc:* mpls ; pals@ietf.org; DetNet WG ;
> spring ; draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Tarek,
>
> thank you for your thoughtful consideration of my comments. I've reviewed
> the diff and got several follow-up notes:
>
>    - the new text in the Introduction section explains the ISD as being
>    encoded as labels:
>
> within the label stack, e.g., encoded as labels, referred to as In
>
>                  Stack Data (ISD), and
>
> I think s/as labels/into label stack elements/ makes the text a bit more
> accurate. What do you think?
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>    - I might have missed it earlier. The TSN is the term used for a very
>    specific technology developed at IEEE to support, for example, URLLC
>    services. The DetNet WG defines the methodology in support of these
>    services using IETF technologies - MPLS and IP. I think it would be
>    appropriate if an IETF document refers to Deterministic Networking, no=
t
>    TSN. What is your opinion?
>
> Regards,
>
> Greg
>
>
>
>
>
> On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad  wrote:
>
> Hi Greg,
>
>
>
> Thanks for your comments. I=E2=80=99ve addressed several of your comments=
. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/dr=
aft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com=
/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> 
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring  on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *draft-saad-mpls-miad-usecases@ietf.org <
> draft-saad-mpls-miad-usecases@ietf.org>, mpls ,
> pals@ietf.org , DetNet WG , spring <
> spring@ietf.org>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some
> editorial suggestions. I hope you'll find some of them helpful.
>
> I am looking forward to your feedback and questions.
>
>
>
> Regards,
>
> Greg
>
>

--000000000000b8ca8705d9189bdf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Haoyu,
can you give an example of =
"the other use cases in the same packet"? I don't think that =
discussing some hypothetical scenarios is a productive way for the Open DT.=


Regards,
Greg

On Mon, Feb 28=
, 2022 at 10:05 AM Haoyu Song <haoyu.song@futurewei.com> wrote:











Hi Greg,


=C2=A0


What I think is that whatever output is from MIAD, i=
t will provide a new solution to support NSH SFC in MPLS.



RFC 8596 shows a way to support NSH SFC in MPLS, but=
 it may not be cooperative with the other use cases in the same packet. MIA=
D tries to solve this problem.



=C2=A0


Best,


Haoyu


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.com> 

Sent: Saturday, February 26, 2022 4:36 PM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>; dra=
ft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0




Hi Haoyu,




I am sorry, but after reading your note, I cannot fi=
nd an answer to my question How the MIAD work is applicable to the informat=
ional RFC 8596? In other words, What do you see as missing in the solution =
described in RFC 8596 that MIAD is
 expected to address?






=C2=A0






Regards,






Greg






=C2=A0






On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@future=
wei.com> wrote:










Hi Greg,


=C2=A0


There have been some existing standards (e.g., EL an=
d this one) and proposals (some are listed in the document) with each deali=
ng with a specific use case. I think it=E2=80=99s beneficial
 to list them all and then consider to use a generic mechanism to handle al=
l these otherwise piecemeal solutions. Of course, finally we would need to =
pick which shall actually be supported with the generic method, but at this=
 point, we shall not limit ourself.



=C2=A0


Regards,


Haoyu


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Friday, February 25, 2022 9:54 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0




Hi=C2=A0Haoyu,




in RFC 8596 I don't find anything that would req=
uire any modification to the existing MPLS architecture. I would=C2=A0agree=
 that SFC NSH using MPLS to connect SFP components might benefit
 from the new enhancements to the MPLS, but so would any other client that =
uses the MPLS network. Do you think that the use case document should list =
them all?






=C2=A0






Regards,






Greg






=C2=A0






On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurew=
ei.com> wrote:










    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.


Hi Greg,


=C2=A0


The RFC is mentioned because it shows that SFC NSH h=
as been considered to be supported in MPLS as well, so it=E2=80=99s a legit=
imate use case like the others in the draft. When we need
 to support multiple such use cases at the same time, we need a generic mec=
hanism to support them, so the use-case draft serves as a motivation for ou=
r work in the ODT.


Hopefully this answers your question. Thanks,=



Haoyu =C2=A0


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls=
@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0






Hi Tarek,




thank you for your thoughtful=C2=A0consideration of =
my comments. I've reviewed the diff and got several follow-up notes:=







    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, ref=
erred to as 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=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes=
 the text a bit more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




=C2=A0




=C2=A0






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com=
> wrote:










Hi Gre=
g,


=C2=A0=



Thanks=
 for your comments. I=E2=80=99ve addressed several of your comments. The la=
test diffs (revision to be uploaded soon) can be found at:=



https://to=
ols.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpl=
s-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-d=
ev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt


=C2=A0=



Regard=
s,


Tarek =
(for co-authors)


=C2=A0=





From:
spring=
 <spring-bo=
unces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,<=
/u>




thank you for your work putting=
 this document together. It helps to analyze essential use cases in the sco=
pe of the work at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial=C2=A0suggestions. I h=
ope you'll find some of them helpful.






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






=C2=A0






Regards,





Greg





































--000000000000b8ca8705d9189bdf--


From nobody Mon Feb 28 12:51:13 2022
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 C03483A0C39; Mon, 28 Feb 2022 12:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, T_SCC_BODY_TEXT_LINE=-0.01, 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 yhohQnkMGRRh; Mon, 28 Feb 2022 12:50:47 -0800 (PST)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20712.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e88::712]) (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 55AD03A0C36; Mon, 28 Feb 2022 12:50:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IlKZCHK3AkGvUUo0LihjaC4os+Hw9vIAvEjLcbZZrQwNczwoNM+mCdqAb4abvQdIPy2/5HVGJeS7BN65ewfq5hrLecDSbbPV8kkQcUb6y+xCWhLqXSR0H1SFllZL2emfoDfpCVsM2neFB403aCfK0mu1bT6Vt9FEgL8if4U23DNdkoQaAIOKJwZjl8lGAQw1VALogW47s3hubZFtup0PlPBwrD5e/AO0CyuJG9zkv8xEGn3pMsY/gyOEVrLa5yOM2BtMu4rZBTiLoX7x+VwOScGPnsI1PVafO7W5vTjRqI/OaSmqADmBLu/GIhFBEfx6CfcBqvexg9hjYHmiym3I4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9o4Xq9RCMBtCLaS73JxYzp6CnK3wr+ITgix2naHw21k=; b=fcavQvDNn9X1l8VuHqWvQhVExF7kaW4ytswS9nw6J8QSZpq1l6d+OhuGIc5+yHQ1QRpHkjAZjOzyOYHQTDpfVsf7k95SmiYJTiOEQfxg02lksmRFrM5SH2tLKJWATiTBjY/Pt1d3/C7mJ4g4+ztDGAlCqduA9vNxpZwoGmNWlISSii/DzqGkurjdjR7+9fW0E69KNH44DyBhmxuRBPK+nwO6qFNKZDXCg60Fbaj6LiZC2YV6Uq4uqaALEUIb3XXESppoufK7rMCtnzjxuPZ2G6VO+Cbg3Y5IOd4NOLyeiMimwBFJ13dhATBWelCwYR+2TI/YbJMXikc62UFvS7uXCg==
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=9o4Xq9RCMBtCLaS73JxYzp6CnK3wr+ITgix2naHw21k=; b=hxBikTeAFzfD2dJgcWo+tGkHbIbHhkEZVsI/L0vpk05iodPxE1zJRWY3uFe8zbjrmKc/D8wb9Gzgp0qqrDKEoRsf3iWm2i4cFEpNwcCOiD0MZSM/YFG9XMXNV2HmYe6/D+Swrth7tTuqENrTKFNBVnKYXhHizHtqxu/t0Ew3A88=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by MW4PR13MB5484.namprd13.prod.outlook.com (2603:10b6:303:183::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.11; Mon, 28 Feb 2022 20:50:41 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d%5]) with mapi id 15.20.5038.013; Mon, 28 Feb 2022 20:50:41 +0000
From: Haoyu Song 
To: Greg Mirsky 
CC: Tarek Saad , mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" 
Thread-Topic: [spring] Comments on draft-saad-mpls-miad-usecases
Thread-Index: AQHYJQybUbEkehVNgEePJZTL39BWqqyiwYCAgAC9BACAARPuUIAABOwAgAAZz0CAAeiSAIACtr1ggAAPMYCAAB0MwA==
Date: Mon, 28 Feb 2022 20:50:41 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b8b46298-dd22-448b-71c8-08d9fafbfbd6
x-ms-traffictypediagnostic: MW4PR13MB5484:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: f9aOF7vRKd5tyPw07E4gGR1KTefjsdCAZpILThDYgBU5cSm0q9CPxUaCMAnIq6drHp2Ds+C5MEr8YAXy/o6484uqa6NqVtEiku4qLfP9e1lKs9OGfEFXcOmtw7D05+Bc+gcpi6+W+bYfeaqGZB4+Wd5vtUcSBt6sW3Gx9gwVXqjA2a4ArZ8cLTDMol8P5NtzEIXVjAV0If6HTtYM4FugTwiHvzvq7Y8SdaptP/FKt0TiimaXhHGtO6zvuQm1Vd8lKTkHS16TgsJNFiUs3Tby/fj1in7Hj7+u6vBEMEpHqLTdv+6RKtUO+yQ6TGkyku846/LZdsb3DuteAFS+L6rkMUAk6MUZAK+sXBmppxIqTIkXJlY9XIluciXleDL0lUHPkBLYxtw+WtPqBu0bZvuDffMw6ukwj/GKEow+3AZDLCf7mGBiNXYxyXs5M3uNy6ZbY3kYezZoaSOu22PBxObiuSc4h8IJUxxzezpupjlyFUKPygA7Me87yjuMsMha0Hlx2vH09poa+qS6GXuYaZDf3+CkFgV5jangea48UahnNOBxTH564kJ0OXv3mUhySmpoRyyKrB2D5Z9n6TRuHkEVKbA3zUYccq/35c0GXBVGhInw5yssYqUx+dyq1En6/S89Ak0i+PR8eOavUPQpNYex77esdKTySOlo3EhgZ4W4DP0KL2VJgRihobmcw2q9fjJ7N4ewmfS4jyKgrxl3P7+HOpEihzxfpzZAQ/tmjBEOR30hczF9zF87R5sv/pxAl9a9iYNJYjj2b8ny0UF1Lw0K8O5EnN4SjAmILdAPpwtlMV8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE;  SFS:(13230001)(4636009)(366004)(53546011)(6506007)(7696005)(966005)(166002)(71200400001)(316002)(54906003)(508600001)(6916009)(122000001)(9686003)(55016003)(2906002)(52536014)(38100700002)(33656002)(44832011)(9326002)(38070700005)(5660300002)(8936002)(86362001)(76116006)(66946007)(66556008)(66476007)(8676002)(4326008)(66446008)(64756008)(26005)(186003)(83380400001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FFa0sMAVWK09ygPScyh3osVSohM+wUoSmNgcfIisg10MH6vCV9eTEyqsQAgb?= =?us-ascii?Q?PvbsKa8NF+wadXY97vZbf5hUUICYVun0sB7UMfAZpUrQwJt9ONHiTLToOtd/?= =?us-ascii?Q?6qLtao+a0+BAe0QzpJJaLPBoW/MottAVT79FkNeY+9aFoUvrm8xHGv3ctShj?= =?us-ascii?Q?HKr//+SBeMHsHYh/zIE0jIMjts33e+cJNSdF5CSulAb6EL634MGcq3OiT3vc?= =?us-ascii?Q?Aqi9ys6rkFhnfIz+p1/ZOaLDfL3mmbI3TPu0k1X0EvEHgeWcBwnjbrYl0mqT?= =?us-ascii?Q?L4uJNpY9HJVRqOCVi69NrrluLC9vIus8Td+QolQtn77VnFQmlL2v7XlxHcvV?= =?us-ascii?Q?euHv+7BTE+GR02Sm4QVYyrK0Zd7cABOjP/4jXexxNXuvMDp/wmOyvv46KV1S?= =?us-ascii?Q?EgvqmpOCKlrpOKJxMfauuktTstNdIC5ueUgIaCaLHrfDqxdqsHaIbuGEiueM?= =?us-ascii?Q?Omy17N0WK6bBvZyz8X6qmokoLT/LwWJBq6VoxnwU/mYLN/3RhBgcT2R0W4Um?= =?us-ascii?Q?bJBaDu837TwBssEcwLZBzPUXNa1xb+2u6MSpx1FJF2+9ZdDP/eoTaJn13syY?= =?us-ascii?Q?gD4Xy2ojnofWc3O1Bxw3o6I24vQb9IeCZrxG0CI0pyQoqCIDjE6qbWB2ESkp?= =?us-ascii?Q?TC77vC1lI6ZzHitBtKNTwelj6GSVdvaHTcw7tcjviSEivhM+t/uWnPhwGahG?= =?us-ascii?Q?FIK5gazelxbuOysStfKXEYh9lZiRp3bKTjoqC6yGAo0HsHU2RShXz6pTNpIk?= =?us-ascii?Q?v+SA3QX9Z7fvD612xqrWvQXzOwSbzahajr7WHPdOfnBwhghGZn0xCc8RKp8T?= =?us-ascii?Q?5iXCxLkV+6eRwhqPwA7b8BoBdZ7U6sa3pMwG/vcjQt/WTwz6O8Gy+eXwkAVt?= =?us-ascii?Q?4K5/x15zVbY2dBWN4n92GfvlljkFTO34oJhefQWqi3AtHe2EXXPMOqiCeagW?= =?us-ascii?Q?7BY0t0IYpo4IJso0t5HQsWKRk5JAD+ZvIxbddFjym9+Gp7RX5aq39QUmHkJO?= =?us-ascii?Q?r2w3vuSTEZrJI3hUr2cdJRiPPtr0jcgDe/ndmjU8R7mwtNBiZKC4bI1ZJLin?= =?us-ascii?Q?Tnz3YXcdtGmhlOHAFWhZorqAnzPYTpN4y6apqxRhxPdZT3f3XmdE63PxstcO?= =?us-ascii?Q?EqfJIOLa7SC9D8g77cjN0536hYEk+fRfww7L3p/3tflJnNpVbG467ltq5aZv?= =?us-ascii?Q?M6a+FQB0fYPKIap5+WVzsdifXMpWkR/riY9w/DsRLinkGJVdXoLXOlTOV2Mg?= =?us-ascii?Q?xZuypPIXMZRs6vDGz8Vt6tY8w+TlmKnxYJC9hZ/c3Mf4X38ZB7uJIYOGqiUb?= =?us-ascii?Q?4a0ROP9iAWT+/XqfA21c0K0iEtrfUKk6+12D7xQ5Lxo2rHdCchzzTXIYf5Yh?= =?us-ascii?Q?hg+nXQ08jOtZ83X0yHHKiXm0ojB8kE0pl2dZiWUOIwu0BW7vjzlJXb3nRb32?= =?us-ascii?Q?Dv39oj51ZcNKTvbYXZLc0P1u6rCzML8uLrQSYDNPUEBLMQkEdN4lgBW/sjvF?= =?us-ascii?Q?tgDJ8tx9fkkq1s0XFKsv9vuH71yc838j7sY296DQOVB9SJli/2nWoGJtrmA4?= =?us-ascii?Q?e52ADAaQpElyDoP1byK+0QXZhx2T7XBeR1BzydJNlLi65Pz73POH0GxWTfvM?= =?us-ascii?Q?pA=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB478700BD417E744807B770459A019BY3PR13MB4787namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8b46298-dd22-448b-71c8-08d9fafbfbd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2022 20:50:41.7412 (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: B1xHjRVGtusszTlrBjXgUgSBtP/DfPTRGJ6afUawjKFkmA3bMGJnaiq+6paLmglnOH1nDrbYWlvIOLHSviLdJA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR13MB5484
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 28 Feb 2022 20:50:53 -0000

--_000_BY3PR13MB478700BD417E744807B770459A019BY3PR13MB4787namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

How about IOAM (or other types of OAM) + SFC (i.e., apply OAM simultaneousl=
y) ? Or Slicing + SFC (i.e., apply SFC on a particular slice) ? I think the=
se scenarios are possible. Maybe I misunderstand something. Could you pleas=
e give more explanation on why you don't like this use case particularly? T=
hanks.

Best,
Haoyu

From: Greg Mirsky 
Sent: Monday, February 28, 2022 10:56 AM
To: Haoyu Song 
Cc: Tarek Saad ; mpls ; pals@ietf.org; =
DetNet WG ; spring ; draft-saad-mpls-miad=
-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
can you give an example of "the other use cases in the same packet"? I don'=
t think that discussing some hypothetical scenarios is a productive way for=
 the Open DT.

Regards,
Greg

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song > wrote:
Hi Greg,

What I think is that whatever output is from MIAD, it will provide a new so=
lution to support NSH SFC in MPLS.
RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be cooperat=
ive with the other use cases in the same packet. MIAD tries to solve this p=
roblem.

Best,
Haoyu

From: Greg Mirsky >
Sent: Saturday, February 26, 2022 4:36 PM
To: Haoyu Song >
Cc: Tarek Saad >; mpls >; pals@ietf.org; Det=
Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
I am sorry, but after reading your note, I cannot find an answer to my ques=
tion How the MIAD work is applicable to the informational RFC 8596? In othe=
r words, What do you see as missing in the solution described in RFC 8596 t=
hat MIAD is expected to address?

Regards,
Greg

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song > wrote:
Hi Greg,

There have been some existing standards (e.g., EL and this one) and proposa=
ls (some are listed in the document) with each dealing with a specific use =
case. I think it's beneficial to list them all and then consider to use a g=
eneric mechanism to handle all these otherwise piecemeal solutions. Of cour=
se, finally we would need to pick which shall actually be supported with th=
e generic method, but at this point, we shall not limit ourself.

Regards,
Haoyu

From: Greg Mirsky >
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song >
Cc: Tarek Saad >; mpls >; pals@ietf.org; Det=
Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
in RFC 8596 I don't find anything that would require any modification to th=
e existing MPLS architecture. I would agree that SFC NSH using MPLS to conn=
ect SFP components might benefit from the new enhancements to the MPLS, but=
 so would any other client that uses the MPLS network. Do you think that th=
e use case document should list them all?

Regards,
Greg

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song > wrote:

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
Hi Greg,

The RFC is mentioned because it shows that SFC NSH has been considered to b=
e supported in MPLS as well, so it's a legitimate use case like the others =
in the draft. When we need to support multiple such use cases at the same t=
ime, we need a generic mechanism to support them, so the use-case draft ser=
ves as a motivation for our work in the ODT.
Hopefully this answers your question. Thanks,
Haoyu

From: Greg Mirsky >
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad >
Cc: mpls >; pals@ietf.org; DetNet WG >; spring >; draft-saad-mpls-miad-usecases@ietf.or=
g
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed t=
he diff and got several follow-up notes:

  *   the new text in the Introduction section explains the ISD as being en=
coded as labels:
within the label stack, e.g., encoded as labels, referred to as In
                 Stack Data (ISD), and
I think s/as labels/into label stack elements/ makes the text a bit more ac=
curate. What do you think?

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
  *   I might have missed it earlier. The TSN is the term used for a very s=
pecific technology developed at IEEE to support, for example, URLLC service=
s. The DetNet WG defines the methodology in support of these services using=
 IETF technologies - MPLS and IP. I think it would be appropriate if an IET=
F document refers to Deterministic Networking, not TSN. What is your opinio=
n?
Regards,
Greg


On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad > wrote:
Hi Greg,

Thanks for your comments. I've addressed several of your comments. The late=
st diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draf=
t-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/t=
saad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt

Regards,
Tarek (for co-authors)

From: spring > on b=
ehalf of Greg Mirsky >
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org >, mpls >, pa=
ls@ietf.org >, De=
tNet WG >, spring >
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze=
 essential use cases in the scope of the work at the Open DT. Attached, ple=
ase find a copy of the draft with my notes and some editorial suggestions. =
I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

--_000_BY3PR13MB478700BD417E744807B770459A019BY3PR13MB4787namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Greg,


 


How about IOAM (or other types of OAM) + SFC (i.e., =
apply OAM simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particul=
ar slice) ? I think these scenarios are possible. Maybe I misunderstand som=
ething. Could you please give more
 explanation on why you don’t like this use case particularly? Thanks=
.


 


Best,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com&g=
t; 

Sent: Monday, February 28, 2022 10:56 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org&g=
t;; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@iet=
f.org>; draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 






Hi Haoyu,




can you give an example of "the other use cases=
 in the same packet"? I don't think that discussing some hypothetical =
scenarios is a productive way for the Open DT.






 






Regards,






Greg








 






On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <haoyu.song@futurewei.com> wr=
ote:










Hi Greg,


 


What I think is that whatever output is from MIAD, it will provide=
 a new solution to support NSH SFC in MPLS.



RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be=
 cooperative with the other use cases in the same packet. MIAD tries to sol=
ve this problem.



 


Best,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Saturday, February 26, 2022 4:36 PM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




I am sorry, but after reading your note, I cannot find an answer t=
o my question How the MIAD work is applicable to the informational RFC 8596=
? In other words, What do you see as
 missing in the solution described in RFC 8596 that MIAD is expected to add=
ress?






 






Regards,






Greg






 






On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@futurewei.com>=
; wrote:










Hi Greg,


 


There have been some existing standards (e.g., EL and this one) an=
d proposals (some are listed in the document) with each dealing with a spec=
ific use case. I think it’s beneficial
 to list them all and then consider to use a generic mechanism to handle al=
l these otherwise piecemeal solutions. Of course, finally we would need to =
pick which shall actually be supported with the generic method, but at this=
 point, we shall not limit ourself.



 


Regards,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Friday, February 25, 2022 9:54 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




in RFC 8596 I don't find anything that would require any modificat=
ion to the existing MPLS architecture. I would agree that SFC NSH usin=
g MPLS to connect SFP components might benefit
 from the new enhancements to the MPLS, but so would any other client that =
uses the MPLS network. Do you think that the use case document should list =
them all?






 






Regards,






Greg






 






On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com>=
 wrote:










    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.


Hi Greg,


 


The RFC is mentioned because it shows that SFC NSH has been consid=
ered to be supported in MPLS as well, so it’s a legitimate use case l=
ike the others in the draft. When we need
 to support multiple such use cases at the same time, we need a generic mec=
hanism to support them, so the use-case draft serves as a motivation for ou=
r work in the ODT.


Hopefully this answers your question. Thanks,


Haoyu  


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls=
@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 






Hi Tarek,




thank you for your thoughtful consideration of my comments. I=
've reviewed the diff and got several follow-up notes:






    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, referred to as In=
     















           =
      Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes the text a bi=
t more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




 




 






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com> wrote:










Hi Greg,


 =



Thanks for your co=
mments. I’ve addressed several of your comments. The latest diffs (re=
vision to be uploaded soon) can be found at:


https://tools.ietf.org//rf=
cdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-=
00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/drafts/master=
/miad-usecases/draft-dt-mpls-miad-usecases.txt


 =



Regards,


Tarek (for co-auth=
ors)


 =





From:
spri=
ng <spring-=
bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,




thank you for your work putting this document=
 together. It helps to analyze essential use cases in the scope of the work=
 at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial suggestions. I h=
ope you'll find some of them helpful.






I am looking forward to your feedback and que=
stions.






 






Regards,






Greg










































--_000_BY3PR13MB478700BD417E744807B770459A019BY3PR13MB4787namp_--


From nobody Mon Feb 28 12:58:13 2022
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 1C8AF3A095C; Mon, 28 Feb 2022 12:58:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 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_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yUhow-D22H1u; Mon, 28 Feb 2022 12:57:55 -0800 (PST)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FE03A0105; Mon, 28 Feb 2022 12:57:54 -0800 (PST)
Received: by mail-ej1-x635.google.com with SMTP id bg10so27386265ejb.4; Mon, 28 Feb 2022 12:57:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hRMJJamlsBl+b8rtbb38/tqYZnD18CFOeUrw7X6aqM0=; b=bT0DZv2jPKH5V2sjjJRcHYwV0ojiKC2Vifk7bz/5mthox+hHwU56nWFBk91dzzXHHs OZYnoitO1NFW2isSFlJLstPgu0SYJOmBXlBU1G7jJyumB0vEQ3ABqydCzoI0lk76/8CV +ib/oHxbVPuBF6TwJCe/5eZrWul4grNRIdQDzjP/2ASxBmwiLa2pw6BUgFA5Bg+sRqA1 BhRl1onapDc2gs5lX3dncPbiQa9beV3JoIWn/OKq2hL0a88WLaaqq9EwLKHIoOR+sD0k tV5mPScS+MZd+oSsJnbZpLrEacvIfteffGIxqEXR73p7fRoRsF21p+fQ5sIPVBapd1pq kdpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hRMJJamlsBl+b8rtbb38/tqYZnD18CFOeUrw7X6aqM0=; b=qAyy2JrcLWI/2TD4qEGJR/xEmYTj4jFJUtGdqisvds+hnqElyiwwt2p9oVsUsw7sc4 0N98MdxNsAYB2fH8v02uf5JejMhwrRH5hasVtEY7P2l5SdwxWJ6DpPleVKKCxJ7LXU2C krqfA5vvH+EmS2k9pJPFv4N1f596Aq04FIahrMcA8sWKOefowDvEPfHqOrTEu9U/6LVQ FiSq1GgmhJcC1JPtp7uFDrpCb24Ky6Z9YcdvLa8KvgN71NDry8bRXAWtoe/3JD9bIT5F 717c23g5sffdS9PJXWVa6xTaJQB1I5Lp8Zpv0ZTkZrdF5lOBA1MfYvnkWKRqHbLaE1Kp TAkA==
X-Gm-Message-State: AOAM5322OlPQ1OsWpb2h+2DfiKcmkM83qZjRM+O2tlyTovMYqlwuaBvR T/i7OB43hlPISQOMQmtwnsH+8ES9wH6XEP0xgw0=
X-Google-Smtp-Source: ABdhPJzGN8lUGzXCzsllaYp5PCx0SIyIDajlK/3MGFSCoaR7XlOIbh0M+xckqmdMyB8t/yCKdmHUECcPdFOJZ/h73UA=
X-Received: by 2002:a17:906:2695:b0:6ce:f9c:b476 with SMTP id t21-20020a170906269500b006ce0f9cb476mr16561560ejc.235.1646081872638; Mon, 28 Feb 2022 12:57:52 -0800 (PST)
MIME-Version: 1.0
References:          
In-Reply-To: 
From: Greg Mirsky 
Date: Mon, 28 Feb 2022 12:57:40 -0800
Message-ID: 
To: Haoyu Song 
Cc: Tarek Saad , mpls , pals@ietf.org,  DetNet WG , spring ,  draft-saad-mpls-miad-usecases@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004a36d805d91a4d79"
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 28 Feb 2022 20:58:01 -0000

--0000000000004a36d805d91a4d79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Haoyu,
I wouldn't say that I don't like any use case, I just don't understand how
the RFC 8596 is related to MIAD work. As for your questions, I believe that
all these scenarios should be discussed by the SFC WG. In fact,
draft-ietf-sfc-ioam-nsh defines one them already.

Regards,
Greg

On Mon, Feb 28, 2022, 12:50 Haoyu Song  wrote:

> Hi Greg,
>
>
>
> How about IOAM (or other types of OAM) + SFC (i.e., apply OAM
> simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice=
)
> ? I think these scenarios are possible. Maybe I misunderstand something.
> Could you please give more explanation on why you don=E2=80=99t like this=
 use case
> particularly? Thanks.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Monday, February 28, 2022 10:56 AM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> can you give an example of "the other use cases in the same packet"? I
> don't think that discussing some hypothetical scenarios is a productive w=
ay
> for the Open DT.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song 
> wrote:
>
> Hi Greg,
>
>
>
> What I think is that whatever output is from MIAD, it will provide a new
> solution to support NSH SFC in MPLS.
>
> RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be
> cooperative with the other use cases in the same packet. MIAD tries to
> solve this problem.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Saturday, February 26, 2022 4:36 PM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> I am sorry, but after reading your note, I cannot find an answer to my
> question How the MIAD work is applicable to the informational RFC 8596? I=
n
> other words, What do you see as missing in the solution described in RFC
> 8596 that MIAD is expected to address?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song 
> wrote:
>
> Hi Greg,
>
>
>
> There have been some existing standards (e.g., EL and this one) and
> proposals (some are listed in the document) with each dealing with a
> specific use case. I think it=E2=80=99s beneficial to list them all and t=
hen
> consider to use a generic mechanism to handle all these otherwise pieceme=
al
> solutions. Of course, finally we would need to pick which shall actually =
be
> supported with the generic method, but at this point, we shall not limit
> ourself.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Friday, February 25, 2022 9:54 AM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> in RFC 8596 I don't find anything that would require any modification to
> the existing MPLS architecture. I would agree that SFC NSH using MPLS to
> connect SFP components might benefit from the new enhancements to the MPL=
S,
> but so would any other client that uses the MPLS network. Do you think th=
at
> the use case document should list them all?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song 
> wrote:
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>
> Hi Greg,
>
>
>
> The RFC is mentioned because it shows that SFC NSH has been considered to
> be supported in MPLS as well, so it=E2=80=99s a legitimate use case like =
the others
> in the draft. When we need to support multiple such use cases at the same
> time, we need a generic mechanism to support them, so the use-case draft
> serves as a motivation for our work in the ODT.
>
> Hopefully this answers your question. Thanks,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad 
> *Cc:* mpls ; pals@ietf.org; DetNet WG ;
> spring ; draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Tarek,
>
> thank you for your thoughtful consideration of my comments. I've reviewed
> the diff and got several follow-up notes:
>
>    - the new text in the Introduction section explains the ISD as being
>    encoded as labels:
>
> within the label stack, e.g., encoded as labels, referred to as In
>
>                  Stack Data (ISD), and
>
> I think s/as labels/into label stack elements/ makes the text a bit more
> accurate. What do you think?
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>    - I might have missed it earlier. The TSN is the term used for a very
>    specific technology developed at IEEE to support, for example, URLLC
>    services. The DetNet WG defines the methodology in support of these
>    services using IETF technologies - MPLS and IP. I think it would be
>    appropriate if an IETF document refers to Deterministic Networking, no=
t
>    TSN. What is your opinion?
>
> Regards,
>
> Greg
>
>
>
>
>
> On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad  wrote:
>
> Hi Greg,
>
>
>
> Thanks for your comments. I=E2=80=99ve addressed several of your comments=
. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/dr=
aft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com=
/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> 
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring  on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *draft-saad-mpls-miad-usecases@ietf.org <
> draft-saad-mpls-miad-usecases@ietf.org>, mpls ,
> pals@ietf.org , DetNet WG , spring <
> spring@ietf.org>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some
> editorial suggestions. I hope you'll find some of them helpful.
>
> I am looking forward to your feedback and questions.
>
>
>
> Regards,
>
> Greg
>
>

--0000000000004a36d805d91a4d79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0Haoyu,
I wouldn't say that I=
 don't like any use case, I just don't understand how the RFC 8596 =
is related to MIAD work. As for your questions, I believe that all these sc=
enarios should be discussed by the SFC WG. In fact, draft-ietf-sfc-ioam-nsh=
 defines one them already.

Regards,
Greg

On Mon, Feb 28, 2022, 12:50 Ha=
oyu Song <haoyu.song@futurew=
ei.com> wrote:











Hi Greg,


=C2=A0


How about IOAM (or other types of OAM) + SFC (i.e., =
apply OAM simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particul=
ar slice) ? I think these scenarios are possible. Maybe I misunderstand som=
ething. Could you please give more
 explanation on why you don=E2=80=99t like this use case particularly? Than=
ks.


=C2=A0


Best,


Haoyu


=C2=A0



=C2=A0






Hi Haoyu,




can you give an example of "the other use cases=
 in the same packet"? I don't think that discussing some hypotheti=
cal scenarios is a productive way for the Open DT.






=C2=A0






Regards,






Greg








=C2=A0











Hi Greg,


=C2=A0


What I think is that whatever output is from MIAD, i=
t will provide a new solution to support NSH SFC in MPLS.



RFC 8596 shows a way to support NSH SFC in MPLS, but=
 it may not be cooperative with the other use cases in the same packet. MIA=
D tries to solve this problem.



=C2=A0


Best,


Haoyu


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.co=
m>


Sent: Saturday, February 26, 2022 4:36 PM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@=
ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0




Hi Haoyu,




I am sorry, but after reading your note, I cannot fi=
nd an answer to my question How the MIAD work is applicable to the informat=
ional RFC 8596? In other words, What do you see as
 missing in the solution described in RFC 8596 that MIAD is expected to add=
ress?






=C2=A0






Regards,






Greg






=C2=A0






On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@futurewei.com> wrote:










Hi Greg,


=C2=A0


There have been some existing standards (e.g., EL an=
d this one) and proposals (some are listed in the document) with each deali=
ng with a specific use case. I think it=E2=80=99s beneficial
 to list them all and then consider to use a generic mechanism to handle al=
l these otherwise piecemeal solutions. Of course, finally we would need to =
pick which shall actually be supported with the generic method, but at this=
 point, we shall not limit ourself.



=C2=A0


Regards,


Haoyu


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.co=
m>


Sent: Friday, February 25, 2022 9:54 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@=
ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0




Hi=C2=A0Haoyu,




in RFC 8596 I don't find anything that would req=
uire any modification to the existing MPLS architecture. I would=C2=A0agree=
 that SFC NSH using MPLS to connect SFP components might benefit
 from the new enhancements to the MPLS, but so would any other client that =
uses the MPLS network. Do you think that the use case document should list =
them all?






=C2=A0






Regards,






Greg






=C2=A0






On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com> wrote:










    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.


Hi Greg,


=C2=A0


The RFC is mentioned because it shows that SFC NSH h=
as been considered to be supported in MPLS as well, so it=E2=80=99s a legit=
imate use case like the others in the draft. When we need
 to support multiple such use cases at the same time, we need a generic mec=
hanism to support them, so the use-case draft serves as a motivation for ou=
r work in the ODT.


Hopefully this answers your question. Thanks,=



Haoyu =C2=A0


=C2=A0




From: Greg Mirsky <gregimirsky@gmail.co=
m>


Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls@ietf.org>;
pals@=
ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases




=C2=A0






Hi Tarek,




thank you for your thoughtful=C2=A0consideration of =
my comments. I've reviewed the diff and got several follow-up notes:=







    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, ref=
erred to as 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=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes=
 the text a bit more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appe=
ars not posing any requirements for enhancements in the MPLS data plane. If=
 I am missing=C2=A0something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




=C2=A0




=C2=A0






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaa=
d.net@gmail.com> wrote:










Hi G=
reg,


=C2=
=A0


Than=
ks for your comments. I=E2=80=99ve addressed several of your comments. The =
latest diffs (revision to be uploaded soon) can be found at:<=
u>


https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/=
id/draft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubuserco=
ntent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases=
.txt


=C2=
=A0


Rega=
rds,


Tare=
k (for co-authors)


=C2=
=A0




From:
spri=
ng <spring-bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org &=
lt;draft-saad-mpls-miad-usecases@ietf.org>, mpls=
 <=
mpls@ietf.org>,
pals@=
ietf.org <pals@ietf.org>, DetNet WG <detnet@ietf.org>, spri=
ng <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,<=
/u>




thank you for your work putting=
 this document together. It helps to analyze essential use cases in the sco=
pe of the work at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial=C2=A0suggestions. I h=
ope you'll find some of them helpful.






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






=C2=A0






Regards,





Greg













































--0000000000004a36d805d91a4d79--


From nobody Mon Feb 28 13:20:59 2022
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 F22E43A1527; Mon, 28 Feb 2022 13:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, T_SCC_BODY_TEXT_LINE=-0.01, 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 iNMgVcx9qD8m; Mon, 28 Feb 2022 13:19:51 -0800 (PST)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20702.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eab::702]) (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 3FFB63A1328; Mon, 28 Feb 2022 13:19:50 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HiuqDljuiQEbClsFr6kI5G9oJTt7K1r63nqXo8KHv6kaxjdtKq4UL78l4e5bhjE+WrmXBcG2kXmt4Id9gI6FPGVJH7czg/c6xtQOXRoqe4U5pxhI9BLs/WCZ5eAnYFvTPgdemPOD3jXWKATGdLlIZKn7LxaZXTW3CYTx7LmmPe6tFlScUL2K/avPfFolnVgAayvYmlt/AggZpRQm9d0Sxqvb5tYZ0ubMyLdXyPFxHr7eYhcn7e/ZO1XUpjFmjKEEJ3fg8TGJQNGzg33XKKXKrvvl6Q52bZn7BlwMtXthoziI1iRMwmocCZqulujhRRGbkojxUMAtZczXkv+xY2vuAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Hk4Gyf8+9c2Ill73Z3bQFDW9fdBui7ZPPbWv1aUviCk=; b=TS3lfC7jXKI7OmhFNOyzxo5LgnV1KqlzGKGxm90FhnmKCL5w10M9HJHiPqof3cegL26xCUCP7Xr3PgPwof09JIcMbgOZ56Sb6242n3Fapr/3LDkj5ow5Pub5oPp92EqVUQoZaBC7aFGCLghRFoRcGqWp6pPruaG9ZXuk/iAr6dde51XkxXRfe2Rc9Simm7bO+DY7RyJN/ffOiEnx/oYzgOl7FnVVYSONbzgIz/bi0Ra5e84yUwYfDfj2eKhh4s2D9BmFcMrD96qVF1ZkU3n4f/UpyADGTptC68MxaEoiZblzy7tZw5C2JYYaflkKs+dLL/KZvZjojqoDVP7DlaTWtw==
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=Hk4Gyf8+9c2Ill73Z3bQFDW9fdBui7ZPPbWv1aUviCk=; b=fwlVr3Py28M7QJwgmHbXee+ia/fxAetzi5X33abEdVHtCeVhm+oYTapVMplxcWb4XGHJNZSj0ceuhbkER2iNJD/DFVgED/E7EYqWG9b8TntW6Oj2MU4ero3m+qTvLr00fOkLEZQAx/OmvgFhxZj6lx23vPxfEVtfO4eOWnwPx3k=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by DM6PR13MB4332.namprd13.prod.outlook.com (2603:10b6:5:16a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.11; Mon, 28 Feb 2022 21:19:44 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d%5]) with mapi id 15.20.5038.013; Mon, 28 Feb 2022 21:19:44 +0000
From: Haoyu Song 
To: Greg Mirsky 
CC: Tarek Saad , mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" 
Thread-Topic: [spring] Comments on draft-saad-mpls-miad-usecases
Thread-Index: AQHYJQybUbEkehVNgEePJZTL39BWqqyiwYCAgAC9BACAARPuUIAABOwAgAAZz0CAAeiSAIACtr1ggAAPMYCAAB0MwIAABNMAgAAD1xA=
Date: Mon, 28 Feb 2022 21:19:44 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 276b07b1-896c-456b-1585-08d9fb000a8e
x-ms-traffictypediagnostic: DM6PR13MB4332:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Tmy2RR5IFTeuH3rBrmpfnJnggnoxreE+r3ArzsF4gcaUp4/ceI7DEmqwHatB8+ql9/wlXT0UzHMMxBIdX+hV33Gbja5QvOFVIi8DQc34DBXWT2jIoYBsutEaMkgLIhGJiyVGBnHwgINABh2NdAs8cv/t/0u9kfq1YQ6ITdTgBVNhsQAxhDKLTHE6reh5pwa/LlkxZDJSITpbm2kFgFU+JypSG8wEq9g1H7MUMfLgmqt5r+tCDK6PdBIv1WOkZtd2WuWQhc6HizNLgnjLZFo8o6lf35PWhQy44Y5lo/L9GK3QIG4LWikdTkAV5QQ1LeXVw9JrdNk7A7TU2KDN5/3gKX9WgW7XsphCa/oZUkDhhZGdKp1wgq6KjirdF26I4Vjk3qEougaUOU8K8chbsQhJoQjumi4HFzSsKDdlwrTrhhXa84erebbiuDvlhjXdnnR/X3AAw0lnpuK16KJuMD9Khx6a3sY185dgJB7xtS2UWTjPSm0PqpkYsmL1vtnll+VagCusku0cMqu/fFA+v3m/OzVB3lxG+lVQN/4UXkHue6DWTf4u1iGIWZzd7sujPnVLMhcRxc3Oa9Uzy64bBoNVUnzVc/XTTjc71AqsrKA92ktl+0COJE4RQbiGe5PA+Qziphip8qtRPVFjOu0jGrEeH1dJpk+3btAi6Lc6Vdz7lwpU2DAvnnRj8WGeIvk1KwRimPw0ZvBSbHPOXtmNARZu0i1UAQHq/67LeuYDbfrd1bcFa0JKsMfILZNuCDos32W3lLMw113oarR/LNIqRNjhRyqHXIYDlm1+bnHrA5/b3LU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE;  SFS:(13230001)(4636009)(366004)(64756008)(55016003)(38070700005)(9326002)(8936002)(8676002)(66556008)(4326008)(83380400001)(66476007)(2906002)(76116006)(66946007)(66446008)(26005)(186003)(71200400001)(9686003)(53546011)(508600001)(6506007)(7696005)(33656002)(52536014)(44832011)(122000001)(86362001)(966005)(5660300002)(54906003)(38100700002)(166002)(6916009)(316002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?1cke76GR3nkDpApvFtPW4kFu9KcCS18r3KIM0unK9+zy7hIuZRExmOD20wmI?= =?us-ascii?Q?RZP6AnGZcdZR+B1cU1g5UnzKjr9mODOh1HcLSAwDbOHlWIxxp9/OGUSo5/Ry?= =?us-ascii?Q?x5KrBwJooPy1sw66Eb6RagTQTbbulbgLEujD4NAqAGbh6jYIorarHYMyEV4e?= =?us-ascii?Q?pfmTfO61OJVK0+BbOX4xe6/nauadGgRDAfgj0QYN67yBec7FgOtapPDyWqW2?= =?us-ascii?Q?pM1AiY5OKyv6pnk72U743LZ2WNrcm5WYsECKQKbG87VYYUb/NF5D2lIpJG/5?= =?us-ascii?Q?CbsY60JR+LkfiOdc0ezkxu5DHyRSWtm7GEiKt66QpEvIwIQR73Dl6zrz4qXk?= =?us-ascii?Q?4ifXzBvm7aa65U0chwLkSrLB7wD5eZlUE1Mw5OYmmKr3oXbn1RFLk8r1AeVu?= =?us-ascii?Q?2innF5uumgOTwd7RreU3M0Y7WBmJYWc/TqgvWLOwhgxtJViHrFmE0PsRLN47?= =?us-ascii?Q?q/fJWFrID1J67KHS6l/a/ySbhEm0HJlCo4ZKdBJnACEcsnJmlsnDFLExLaXo?= =?us-ascii?Q?wMbL2NFv99CMX8Q/qqWcOm0dGgQTVfqF0mRSf89siOAwzKSo9ub8hHundKtV?= =?us-ascii?Q?QrHNB3UA1Mq5GQYqM3QscZ1O1zttDKNOPZ352XJc+ccWtkZS8TD2rUlldBWo?= =?us-ascii?Q?V4PoT+v2Bz2W5IJb3seJ1MHwGzEbHdH+AQWRzX0zjkBqMuCDI8m7XmnljYyL?= =?us-ascii?Q?aU81NQtp7UTOFa3Nr1UE34VyV79GzONrRMTNKIJf5AiJlfjf+xS8bnXbjIRw?= =?us-ascii?Q?aDTkLc/mlg1qWJCAblk25WfYgPN1u5LSmZUq1G5TKNxcpi1owlGWGIMCxmYE?= =?us-ascii?Q?oNnHiznxmiN1u9b7VgnYo+fykfCJIA7rmA4EjrqmuyYdN0HIC896oiqQeNuC?= =?us-ascii?Q?GfhpCt8BxnBjeMxkElFZXrhbXv0SuqN6iBHPvq4Z/eMzm7stCseUEzZniKg7?= =?us-ascii?Q?jwpna/MBjWq9mBSMe4dUkHE2OENunuiIAcYL6CLDlndLWAtOBBy0fp0fE7iN?= =?us-ascii?Q?A/tiUAX5UWVG2VLFF5rWf5Du0123xlL9TqS0vK6JsXhGu0mAk236Gjh2a0NE?= =?us-ascii?Q?CtgNwqQ+1gUnaaTIB01r3OAxlFeMumwdKExrIJYN5iuqFfDzxbXOq543wK6L?= =?us-ascii?Q?mYzVY+nXa+Zc29W1U4R8Tlf0MC1CtxQKsWIhrXP9nnt6Lh9Pib5qykR7TNHG?= =?us-ascii?Q?7cG3NU7HrOtJixiJncshZgNWRokWr6zuqFRcbPRT7X4sp0AHIyRBlBeaOExl?= =?us-ascii?Q?9M62GXDE6TwCBqGFUDSdGE73EcpQGcK4VBtrZmyd0WGJ/y5d2byQzQ9CO3b7?= =?us-ascii?Q?k+ZPzHm9ixOKslAmnbLfDYqf+7OejEqGUTADQ3LV7PzBcQ/GT8Li7q4lFgrI?= =?us-ascii?Q?PXbZswYlYwFEzI1oUuDr1ipe82DWCYmFvpHHmN+3BBeXZhqgWpvy2dsFSJob?= =?us-ascii?Q?GvuwX9aWXG8AbmjhlPyuhcDLtTfDlese3QMiM2fVyrmOl6FJOlTNdi3+MYVy?= =?us-ascii?Q?HoSKUF4vdSkvT1tbqntVh2EyMpsMrvU/2KPiheHcdNBxGWOuSPVipZkFCnYY?= =?us-ascii?Q?jnSXMWo1kVwZBRh/yELNljmhkYbNZ5dDlrUeDRT0CWzDdAju6oGidrjBXjHN?= =?us-ascii?Q?6g=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB478781DD7F262BB625CF99F79A019BY3PR13MB4787namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 276b07b1-896c-456b-1585-08d9fb000a8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2022 21:19:44.3572 (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: YQtwqm1TqEcOo7QqFrzyUo/HV79TkhBzEJ/9WjaVb4sHgk1jxUEu2IOrga6puphqkNiHWgIqRLs4jFdZzRVX8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB4332
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 28 Feb 2022 21:19:58 -0000

--_000_BY3PR13MB478781DD7F262BB625CF99F79A019BY3PR13MB4787namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

Here's my logic. I think NSH SFC could be a use case in MPLS and RFC8596, a=
s a reference, shows that this has been considered before, so I take it as =
an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are wor=
king on a generic way to support different use cases in MPLS data plane , s=
o the use cases also include NSH SFC, right? Sure, finally we may end up wi=
th a different solution than RFC8596, but we have good reason for that, as =
I have explained in pervious emails (e.g., to support multiple use cases at=
 the same time). Please note that this is only a use case draft and it does=
n't enforce any solution but to show we have such requirements. When MIAD i=
s developed, whether and where another draft for applying NSH SFC in it nee=
ds to be developed is a totally different issue.

Best,
Haoyu

From: Greg Mirsky 
Sent: Monday, February 28, 2022 12:58 PM
To: Haoyu Song 
Cc: Tarek Saad ; mpls ; pals@ietf.org; =
DetNet WG ; spring ; draft-saad-mpls-miad=
-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
I wouldn't say that I don't like any use case, I just don't understand how =
the RFC 8596 is related to MIAD work. As for your questions, I believe that=
 all these scenarios should be discussed by the SFC WG. In fact, draft-ietf=
-sfc-ioam-nsh defines one them already.

Regards,
Greg

On Mon, Feb 28, 2022, 12:50 Haoyu Song > wrote:
Hi Greg,

How about IOAM (or other types of OAM) + SFC (i.e., apply OAM simultaneousl=
y) ? Or Slicing + SFC (i.e., apply SFC on a particular slice) ? I think the=
se scenarios are possible. Maybe I misunderstand something. Could you pleas=
e give more explanation on why you don't like this use case particularly? T=
hanks.

Best,
Haoyu

From: Greg Mirsky >
Sent: Monday, February 28, 2022 10:56 AM
To: Haoyu Song >
Cc: Tarek Saad >; mpls >; pals@ietf.org; Det=
Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
can you give an example of "the other use cases in the same packet"? I don'=
t think that discussing some hypothetical scenarios is a productive way for=
 the Open DT.

Regards,
Greg

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song > wrote:
Hi Greg,

What I think is that whatever output is from MIAD, it will provide a new so=
lution to support NSH SFC in MPLS.
RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be cooperat=
ive with the other use cases in the same packet. MIAD tries to solve this p=
roblem.

Best,
Haoyu

From: Greg Mirsky >
Sent: Saturday, February 26, 2022 4:36 PM
To: Haoyu Song >
Cc: Tarek Saad >; mpls >; pals@ietf.org; Det=
Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
I am sorry, but after reading your note, I cannot find an answer to my ques=
tion How the MIAD work is applicable to the informational RFC 8596? In othe=
r words, What do you see as missing in the solution described in RFC 8596 t=
hat MIAD is expected to address?

Regards,
Greg

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song > wrote:
Hi Greg,

There have been some existing standards (e.g., EL and this one) and proposa=
ls (some are listed in the document) with each dealing with a specific use =
case. I think it's beneficial to list them all and then consider to use a g=
eneric mechanism to handle all these otherwise piecemeal solutions. Of cour=
se, finally we would need to pick which shall actually be supported with th=
e generic method, but at this point, we shall not limit ourself.

Regards,
Haoyu

From: Greg Mirsky >
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song >
Cc: Tarek Saad >; mpls >; pals@ietf.org; Det=
Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Haoyu,
in RFC 8596 I don't find anything that would require any modification to th=
e existing MPLS architecture. I would agree that SFC NSH using MPLS to conn=
ect SFP components might benefit from the new enhancements to the MPLS, but=
 so would any other client that uses the MPLS network. Do you think that th=
e use case document should list them all?

Regards,
Greg

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song > wrote:

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
Hi Greg,

The RFC is mentioned because it shows that SFC NSH has been considered to b=
e supported in MPLS as well, so it's a legitimate use case like the others =
in the draft. When we need to support multiple such use cases at the same t=
ime, we need a generic mechanism to support them, so the use-case draft ser=
ves as a motivation for our work in the ODT.
Hopefully this answers your question. Thanks,
Haoyu

From: Greg Mirsky >
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad >
Cc: mpls >; pals@ietf.org; DetNet WG >; spring >; draft-saad-mpls-miad-usecases@ietf.or=
g
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

Hi Tarek,
thank you for your thoughtful consideration of my comments. I've reviewed t=
he diff and got several follow-up notes:

  *   the new text in the Introduction section explains the ISD as being en=
coded as labels:
within the label stack, e.g., encoded as labels, referred to as In
                 Stack Data (ISD), and
I think s/as labels/into label stack elements/ makes the text a bit more ac=
curate. What do you think?

  *   in my earlier comments, I've noted that the informational RFC 8596 ap=
pears not posing any requirements for enhancements in the MPLS data plane. =
If I am missing something, please let me know.
  *   I might have missed it earlier. The TSN is the term used for a very s=
pecific technology developed at IEEE to support, for example, URLLC service=
s. The DetNet WG defines the methodology in support of these services using=
 IETF technologies - MPLS and IP. I think it would be appropriate if an IET=
F document refers to Deterministic Networking, not TSN. What is your opinio=
n?
Regards,
Greg


On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad > wrote:
Hi Greg,

Thanks for your comments. I've addressed several of your comments. The late=
st diffs (revision to be uploaded soon) can be found at:
https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draf=
t-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/t=
saad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt

Regards,
Tarek (for co-authors)

From: spring > on b=
ehalf of Greg Mirsky >
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org >, mpls >, pa=
ls@ietf.org >, De=
tNet WG >, spring >
Subject: [spring] Comments on draft-saad-mpls-miad-usecases
Dear Authors,
thank you for your work putting this document together. It helps to analyze=
 essential use cases in the scope of the work at the Open DT. Attached, ple=
ase find a copy of the draft with my notes and some editorial suggestions. =
I hope you'll find some of them helpful.
I am looking forward to your feedback and questions.

Regards,
Greg

--_000_BY3PR13MB478781DD7F262BB625CF99F79A019BY3PR13MB4787namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Greg,


 


Here’s my logic. I think NSH SFC could be a us=
e case in MPLS and RFC8596, as a reference, shows that this has been consid=
ered before, so I take it as an evidence that NSH SFC is indeed a valid use=
 case in MPLS. Now we are working on a generic
 way to support different use cases in MPLS data plane , so the use cases a=
lso include NSH SFC, right? Sure, finally we may end up with a different so=
lution than RFC8596, but we have good reason for that, as I have explained =
in pervious emails (e.g., to support
 multiple use cases at the same time). Please note that this is only a use =
case draft and it doesn’t enforce any solution but to show we have su=
ch requirements. When MIAD is developed, whether and where another draft fo=
r applying NSH SFC in it needs to be developed
 is a totally different issue.


 


Best,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com&g=
t; 

Sent: Monday, February 28, 2022 12:58 PM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org&g=
t;; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@iet=
f.org>; draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




I wouldn't say that I don't like any use case, I jus=
t don't understand how the RFC 8596 is related to MIAD work. As for your qu=
estions, I believe that all these scenarios should be discussed by the SFC =
WG. In fact, draft-ietf-sfc-ioam-nsh
 defines one them already.






 






Regards,






Greg






 






On Mon, Feb 28, 2022, 12:50 Haoyu Song <haoyu.song@futurewei.com> wrote=
:










Hi Greg,


 


How about IOAM (or other types of OAM) + SFC (i.e., apply OAM simu=
ltaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice) ? I =
think these scenarios are possible.
 Maybe I misunderstand something. Could you please give more explanation on=
 why you don’t like this use case particularly? Thanks.

 


Best,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Monday, February 28, 2022 10:56 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 






Hi Haoyu,




can you give an example of "the other use cases in the same p=
acket"? I don't think that discussing some hypothetical scenarios is a=
 productive way for the Open DT.






 






Regards,






Greg








 






On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <haoyu.song@futurewei.com>=
; wrote:










Hi Greg,


 


What I think is that whatever output is from MIAD, it will provide=
 a new solution to support NSH SFC in MPLS.



RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be=
 cooperative with the other use cases in the same packet. MIAD tries to sol=
ve this problem.



 


Best,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Saturday, February 26, 2022 4:36 PM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




I am sorry, but after reading your note, I cannot find an answer t=
o my question How the MIAD work is applicable to the informational RFC 8596=
? In other words, What do you see as
 missing in the solution described in RFC 8596 that MIAD is expected to add=
ress?






 






Regards,






Greg






 






On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@futurewei.com>=
; wrote:










Hi Greg,


 


There have been some existing standards (e.g., EL and this one) an=
d proposals (some are listed in the document) with each dealing with a spec=
ific use case. I think it’s beneficial
 to list them all and then consider to use a generic mechanism to handle al=
l these otherwise piecemeal solutions. Of course, finally we would need to =
pick which shall actually be supported with the generic method, but at this=
 point, we shall not limit ourself.



 


Regards,


Haoyu


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Friday, February 25, 2022 9:54 AM

To: Haoyu Song <haoyu.song@futurewei.com>

Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 




Hi Haoyu,




in RFC 8596 I don't find anything that would require any modificat=
ion to the existing MPLS architecture. I would agree that SFC NSH usin=
g MPLS to connect SFP components might benefit
 from the new enhancements to the MPLS, but so would any other client that =
uses the MPLS network. Do you think that the use case document should list =
them all?






 






Regards,






Greg






 






On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com>=
 wrote:










    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.


Hi Greg,


 


The RFC is mentioned because it shows that SFC NSH has been consid=
ered to be supported in MPLS as well, so it’s a legitimate use case l=
ike the others in the draft. When we need
 to support multiple such use cases at the same time, we need a generic mec=
hanism to support them, so the use-case draft serves as a motivation for ou=
r work in the ODT.


Hopefully this answers your question. Thanks,


Haoyu  


 




From: Greg Mirsky <gregimirsky@gmail.com>


Sent: Thursday, February 24, 2022 5:09 PM

To: Tarek Saad <tsaad.net@gmail.com>

Cc: mpls <mpls=
@ietf.org>;
pals@ietf.org; DetNe=
t WG <detnet@ietf.o=
rg>; spring <spring@ietf.org>;
draft-saad-mpls-miad-usecases@ietf.org

Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=





 






Hi Tarek,




thank you for your thoughtful consideration of my comments. I=
've reviewed the diff and got several follow-up notes:






    

  • 
the new text in the Introduction section explains the ISD as being encoded =
as labels:














within the label stack, e.g., encoded as labels, referred to as In=
     















           =
      Stack Data (ISD), and












I think s/as labels/into label stack elements/ makes the text a bi=
t more accurate. What do you think?








    

  • 
in my earlier comments, I've noted that the informational RFC 8596 appears =
not posing any requirements for enhancements in the MPLS data plane. If I a=
m missing something, please let me know.
  • 
I might have missed it earlier. The TSN is the term used for a very specifi=
c technology developed at IEEE to support, for example, URLLC services. The=
 DetNet WG defines the methodology in support of these services using IETF =
technologies - MPLS and IP. I think
 it would be appropriate if an IETF document refers to Deterministic Networ=
king, not TSN. What is your opinion?




Regards,






Greg




 




 






On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com> wrote:










Hi Greg,


 =



Thanks for your co=
mments. I’ve addressed several of your comments. The latest diffs (re=
vision to be uploaded soon) can be found at:


https://tools.ietf.org//rfcd=
iff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00=
.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/drafts/master/m=
iad-usecases/draft-dt-mpls-miad-usecases.txt


 =



Regards,


Tarek (for co-auth=
ors)


 =





From:
spri=
ng <spring-=
bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>

Date: Friday, February 18, 2022 at 4:15 PM

To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls=
-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
pals@ietf.org <pals@ietf.org>, Det=
Net WG <detnet@ietf=
.org>, spring <spring@ietf.org>

Subject: [spring] Comments on draft-saad-mpls-miad-usecases






Dear Authors,




thank you for your work putting this document=
 together. It helps to analyze essential use cases in the scope of the work=
 at the Open DT. Attached, please find
 a copy of the draft with my notes and some editorial suggestions. I h=
ope you'll find some of them helpful.






I am looking forward to your feedback and que=
stions.






 






Regards,






Greg


















































--_000_BY3PR13MB478781DD7F262BB625CF99F79A019BY3PR13MB4787namp_--


From nobody Mon Feb 28 14:01:16 2022
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 835B43A15C3; Mon, 28 Feb 2022 14:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 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_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 26GvhWnD-TvX; Mon, 28 Feb 2022 14:00:43 -0800 (PST)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89993A133D; Mon, 28 Feb 2022 14:00:42 -0800 (PST)
Received: by mail-ej1-x630.google.com with SMTP id p15so27648808ejc.7; Mon, 28 Feb 2022 14:00:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BcPGhanryNu/fRlTr051E6IeW/h9gLVo0HPrWZTdrLU=; b=clBBTbYxd6RmRoc6p7lDtfbvFOJx4iHmXyZhkTSel7GqeMCTeIJueohQyKs9d//LB0 w6odGH1/RBR52Dpu91xoPKqK95rJB6w+WecTaOVzCTgc+22rF4per1LKsT6aZVkHRCxs vBZD6vez0nbmmJ+8ha82paJCHnWlxFoVVaOyJnrw/E0gUUDWfOd9I06LdPQKm9POa+/F JzSeQ51uKTdbSw7cNlnWR8IB593CCmNlp+z3Q7e1TCZ8+SXyOl1nh4Ag7bCXRp0T8Ndm 3WF0CSMAMUias9J7By+lUME+DsSRypW3oce+34pdL3GcXNo6eO++K26d3bBXH53NWdCZ 18tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BcPGhanryNu/fRlTr051E6IeW/h9gLVo0HPrWZTdrLU=; b=hzJMwANkPPwFcwRS1OJQKxlyYl59aqqLBOEbnWo3LFn7r+GsNC3OOe/5/aUZrpwhiT yC5vAp/HDJizlfDeDs+m3tw8eCXl7gYTte8cHMr0XToc8PWjD1QW97GlLb2M57bKhWo1 pWyRnodDptEJs9IqG2V/KiUhdxQSYRdeus0FTuBsrbbY1FeuecJ2Iv7sXPIR9xld72dn u7PCGfuAMoLYrefE9x2xbtWB15CesL6k4jOOKbdi3UD26EcsmP4Z7HMosSb93GFRB/7s eBr9TNhkec/b2h4lX+tr8poUmff09HhbIb01yuSOvHWU8B0muioFNax24Kj9NU/Pe+qh 4SGw==
X-Gm-Message-State: AOAM531mSDPsSGCoc7yP1lpmTNxAhClgqfOQQ09kuMjinD+7khp15KPJ MrPO1GXFOoqNNsGVcWNrFRGkwVewSeGXFv33BXAqi2FA
X-Google-Smtp-Source: ABdhPJzg4jFO0sXxNkbcHqP/QPO+nn0lCIp+Ed4f0n2fVOsfOL2147PSMUrnejD/efBdszm9TdVC7V2bzF2U0jf2TQA=
X-Received: by 2002:a17:906:a210:b0:6d5:9fa:11ce with SMTP id r16-20020a170906a21000b006d509fa11cemr17134909ejy.172.1646085640773; Mon, 28 Feb 2022 14:00:40 -0800 (PST)
MIME-Version: 1.0
References:            
In-Reply-To: 
From: Greg Mirsky 
Date: Mon, 28 Feb 2022 14:00:29 -0800
Message-ID: 
To: Haoyu Song 
Cc: Tarek Saad , mpls , "pals@ietf.org" ,  DetNet WG , spring ,  "draft-saad-mpls-miad-usecases@ietf.org" ,  Service Function Chaining IETF list 
Content-Type: multipart/alternative; boundary="000000000000e36dde05d91b2d0c"
Archived-At: 
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases
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, 28 Feb 2022 22:00:49 -0000

--000000000000e36dde05d91b2d0c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Haoyu,
adding the SFC WG to our discussion.

I feel that if we continue your way of thinking about the SFC NSH and the
MIAD, then everything we know how to do over MPLS should be revisited.
Would you agree that is a fair conclusion based on your explanation of your
position? I can agree that the extended MPLS architecture enhanced by the
MIAD coupled with the new ways of doing things we already know how to do
might show some level of improvement. But I believe that would not be level
to justify dramatically changing existing mechanisms of delivery services
over an MPLS network. And the same applies to SFC NSH over MPLS. RFC 8596
is informational because it describes how existing and known MPLS
techniques can be used to connect elements of an SFP. I think that is the
best possible solution - re-using the existing technology.
Regarding the reference to RFC 8596 in the use-cases draft. I'd appreciate
it if other participants of the Open DT work and members of WGs share their
opinions. I've stated mine, I believe quite clearly.

Regards,
Greg

On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song  wrote=
:

> Hi Greg,
>
>
>
> Here=E2=80=99s my logic. I think NSH SFC could be a use case in MPLS and =
RFC8596,
> as a reference, shows that this has been considered before, so I take it =
as
> an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are
> working on a generic way to support different use cases in MPLS data plan=
e
> , so the use cases also include NSH SFC, right? Sure, finally we may end =
up
> with a different solution than RFC8596, but we have good reason for that,
> as I have explained in pervious emails (e.g., to support multiple use cas=
es
> at the same time). Please note that this is only a use case draft and it
> doesn=E2=80=99t enforce any solution but to show we have such requirement=
s. When
> MIAD is developed, whether and where another draft for applying NSH SFC i=
n
> it needs to be developed is a totally different issue.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Monday, February 28, 2022 12:58 PM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> I wouldn't say that I don't like any use case, I just don't understand ho=
w
> the RFC 8596 is related to MIAD work. As for your questions, I believe th=
at
> all these scenarios should be discussed by the SFC WG. In fact,
> draft-ietf-sfc-ioam-nsh defines one them already.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 28, 2022, 12:50 Haoyu Song  wrote:
>
> Hi Greg,
>
>
>
> How about IOAM (or other types of OAM) + SFC (i.e., apply OAM
> simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice=
)
> ? I think these scenarios are possible. Maybe I misunderstand something.
> Could you please give more explanation on why you don=E2=80=99t like this=
 use case
> particularly? Thanks.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Monday, February 28, 2022 10:56 AM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> can you give an example of "the other use cases in the same packet"? I
> don't think that discussing some hypothetical scenarios is a productive w=
ay
> for the Open DT.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song 
> wrote:
>
> Hi Greg,
>
>
>
> What I think is that whatever output is from MIAD, it will provide a new
> solution to support NSH SFC in MPLS.
>
> RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be
> cooperative with the other use cases in the same packet. MIAD tries to
> solve this problem.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Saturday, February 26, 2022 4:36 PM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> I am sorry, but after reading your note, I cannot find an answer to my
> question How the MIAD work is applicable to the informational RFC 8596? I=
n
> other words, What do you see as missing in the solution described in RFC
> 8596 that MIAD is expected to address?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song 
> wrote:
>
> Hi Greg,
>
>
>
> There have been some existing standards (e.g., EL and this one) and
> proposals (some are listed in the document) with each dealing with a
> specific use case. I think it=E2=80=99s beneficial to list them all and t=
hen
> consider to use a generic mechanism to handle all these otherwise pieceme=
al
> solutions. Of course, finally we would need to pick which shall actually =
be
> supported with the generic method, but at this point, we shall not limit
> ourself.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Friday, February 25, 2022 9:54 AM
> *To:* Haoyu Song 
> *Cc:* Tarek Saad ; mpls ;
> pals@ietf.org; DetNet WG ; spring ;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> in RFC 8596 I don't find anything that would require any modification to
> the existing MPLS architecture. I would agree that SFC NSH using MPLS to
> connect SFP components might benefit from the new enhancements to the MPL=
S,
> but so would any other client that uses the MPLS network. Do you think th=
at
> the use case document should list them all?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song 
> wrote:
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>
> Hi Greg,
>
>
>
> The RFC is mentioned because it shows that SFC NSH has been considered to
> be supported in MPLS as well, so it=E2=80=99s a legitimate use case like =
the others
> in the draft. When we need to support multiple such use cases at the same
> time, we need a generic mechanism to support them, so the use-case draft
> serves as a motivation for our work in the ODT.
>
> Hopefully this answers your question. Thanks,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad 
> *Cc:* mpls ; pals@ietf.org; DetNet WG ;
> spring ; draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Tarek,
>
> thank you for your thoughtful consideration of my comments. I've reviewed
> the diff and got several follow-up notes:
>
>    - the new text in the Introduction section explains the ISD as being
>    encoded as labels:
>
> within the label stack, e.g., encoded as labels, referred to as In
>
>                  Stack Data (ISD), and
>
> I think s/as labels/into label stack elements/ makes the text a bit more
> accurate. What do you think?
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>    - I might have missed it earlier. The TSN is the term used for a very
>    specific technology developed at IEEE to support, for example, URLLC
>    services. The DetNet WG defines the methodology in support of these
>    services using IETF technologies - MPLS and IP. I think it would be
>    appropriate if an IETF document refers to Deterministic Networking, no=
t
>    TSN. What is your opinion?
>
> Regards,
>
> Greg
>
>
>
>
>
> On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad  wrote:
>
> Hi Greg,
>
>
>
> Thanks for your comments. I=E2=80=99ve addressed several of your comments=
. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/dr=
aft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com=
/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> 
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring  on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *draft-saad-mpls-miad-usecases@ietf.org <
> draft-saad-mpls-miad-usecases@ietf.org>, mpls ,
> pals@ietf.org , DetNet WG , spring <
> spring@ietf.org>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some
> editorial suggestions. I hope you'll find some of them helpful.
>
> I am looking forward to your feedback and questions.
>
>
>
> Regards,
>
> Greg
>
>

--000000000000e36dde05d91b2d0c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Haoyu,
adding the SFC WG to our discussion.

I feel that if we continue your way of thinking about the=
 SFC NSH and the MIAD, then everything we know how to do over MPLS should b=
e revisited. Would you agree that is a fair conclusion based on your explan=
ation of your position? I can agree that the extended MPLS architecture enh=
anced by the MIAD=C2=A0coupled with the new ways of doing things we already=
 know how to do might show some level of improvement. But I believe that wo=
uld not be level to justify dramatically=C2=A0changing existing mechanisms =
of delivery services over an MPLS network. And the same applies to SFC NSH =
over MPLS. RFC 8596 is informational because it describes how existing and =
known MPLS techniques can be used to connect elements=C2=A0of an SFP. I thi=
nk that is the best possible solution=C2=A0- re-using=C2=A0the existing tec=
hnology.
Regarding the reference to RFC 8596 in the use-cases dra=
ft. I'd appreciate it if other participants of the Open DT work and mem=
bers=C2=A0of WGs share their opinions. I've stated mine, I believe quit=
e clearly.

Regards,
Greg

=
On Mon, Fe= b 28, 2022 at 1:19 PM Haoyu Song <haoyu.song@futurewei.com> wrote:

Hi Greg,

=C2=A0

Here=E2=80=99s my logic. I think NSH SFC could be a = use case in MPLS and RFC8596, as a reference, shows that this has been cons= idered before, so I take it as an evidence that NSH SFC is indeed a valid u= se case in MPLS. Now we are working on a generic way to support different use cases in MPLS data plane , so the use cases a= lso include NSH SFC, right? Sure, finally we may end up with a different so= lution than RFC8596, but we have good reason for that, as I have explained = in pervious emails (e.g., to support multiple use cases at the same time). Please note that this is only a use = case draft and it doesn=E2=80=99t enforce any solution but to show we have = such requirements. When MIAD is developed, whether and where another draft = for applying NSH SFC in it needs to be developed is a totally different issue.

=C2=A0

Best,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 28, 2022 12:58 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>; dra= ft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi=C2=A0Haoyu,

I wouldn't say that I don't like any use cas= e, I just don't understand how the RFC 8596 is related to MIAD work. As= for your questions, I believe that all these scenarios should be discussed= by the SFC WG. In fact, draft-ietf-sfc-ioam-nsh defines one them already.

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 28, 2022, 12:50 Haoyu Song <haoyu.song@futurewei= .com> wrote:

Hi Greg,

=C2=A0

How about IOAM (or other types of OAM) + SFC (i.e., = apply OAM simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particul= ar slice) ? I think these scenarios are possible. Maybe I misunderstand something. Could you please give more explanation on= why you don=E2=80=99t like this use case particularly? Thanks.

=C2=A0

Best,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 28, 2022 10:56 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi Haoyu,

can you give an example of "the other use cases= in the same packet"? I don't think that discussing some hypotheti= cal scenarios is a productive way for the Open DT.

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <haoyu.song@future= wei.com> wrote:

Hi Greg,

=C2=A0

What I think is that whatever output is from MIAD, i= t will provide a new solution to support NSH SFC in MPLS.

RFC 8596 shows a way to support NSH SFC in MPLS, but= it may not be cooperative with the other use cases in the same packet. MIA= D tries to solve this problem.

=C2=A0

Best,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Saturday, February 26, 2022 4:36 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi Haoyu,

I am sorry, but after reading your note, I cannot fi= nd an answer to my question How the MIAD work is applicable to the informat= ional RFC 8596? In other words, What do you see as missing in the solution described in RFC 8596 that MIAD is expected to add= ress?

=C2=A0

Regards,

Greg

=C2=A0

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@future= wei.com> wrote:

Hi Greg,

=C2=A0

There have been some existing standards (e.g., EL an= d this one) and proposals (some are listed in the document) with each deali= ng with a specific use case. I think it=E2=80=99s beneficial to list them all and then consider to use a generic mechanism to handle al= l these otherwise piecemeal solutions. Of course, finally we would need to = pick which shall actually be supported with the generic method, but at this= point, we shall not limit ourself.

=C2=A0

Regards,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi=C2=A0Haoyu,

in RFC 8596 I don't find anything that would req= uire any modification to the existing MPLS architecture. I would=C2=A0agree= that SFC NSH using MPLS to connect SFP components might benefit from the new enhancements to the MPLS, but so would any other client that = uses the MPLS network. Do you think that the use case document should list = them all?

=C2=A0

Regards,

Greg

=C2=A0

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

  • in my earlier comments, I've noted that the informational RFC 8596 appe= ars not posing any requirements for enhancements in the MPLS data plane. If= I am missing=C2=A0something, please let me know.

Hi Greg,

=C2=A0

The RFC is mentioned because it shows that SFC NSH h= as been considered to be supported in MPLS as well, so it=E2=80=99s a legit= imate use case like the others in the draft. When we need to support multiple such use cases at the same time, we need a generic mec= hanism to support them, so the use-case draft serves as a motivation for ou= r work in the ODT.

Hopefully this answers your question. Thanks,=

Haoyu =C2=A0

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad <tsaad.net@gmail.com>
Cc: mpls <mpls= @ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi Tarek,

thank you for your thoughtful=C2=A0consideration of = my comments. I've reviewed the diff and got several follow-up notes:=

  • the new text in the Introduction section explains the ISD as being encoded = as labels:

within the label stack, e.g., encoded as labels, ref= erred to as 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=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0Stack Data (ISD), and

I think s/as labels/into label stack elements/ makes= the text a bit more accurate. What do you think?

  • in my earlier comments, I've noted that the informational RFC 8596 appe= ars not posing any requirements for enhancements in the MPLS data plane. If= I am missing=C2=A0something, please let me know.
  • I might have missed it earlier. The TSN is the term used for a very specifi= c technology developed at IEEE to support, for example, URLLC services. The= DetNet WG defines the methodology in support of these services using IETF = technologies - MPLS and IP. I think it would be appropriate if an IETF document refers to Deterministic Networ= king, not TSN. What is your opinion?

Regards,

Greg

=C2=A0

=C2=A0

On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com= > wrote:

Hi Gre= g,

=C2=A0=

Thanks= for your comments. I=E2=80=99ve addressed several of your comments. The la= test diffs (revision to be uploaded soon) can be found at:=

https://tools.ie= tf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad= -usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/dra= fts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<= u>

=C2=A0=

Regard= s,

Tarek = (for co-authors)

=C2=A0=

From: spring= <spring-bo= unces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls= -miad-usecases@ietf.org>, mpls <mpls@ietf.org>, pals@ietf.org <pals@ietf.org>, Det= Net WG <detnet@ietf= .org>, spring <spring@ietf.org>
Subject: [spring] Comments on draft-saad-mpls-miad-usecases

Dear Authors,<= /u>

thank you for your work putting= this document together. It helps to analyze essential use cases in the sco= pe of the work at the Open DT. Attached, please find a copy of the draft with my notes and some editorial=C2=A0suggestions. I h= ope you'll find some of them helpful.

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

=C2=A0

Regards,

Greg

--000000000000e36dde05d91b2d0c-- From nobody Mon Feb 28 14:24:07 2022 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 E8D3C3A1609; Mon, 28 Feb 2022 14:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, T_SCC_BODY_TEXT_LINE=-0.01, 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 UZgaSXeiQovv; Mon, 28 Feb 2022 14:23:12 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2072f.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eaa::72f]) (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 B42923A1361; Mon, 28 Feb 2022 14:23:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SQJAl2g1HV2EN+PlRfqhGs2tcs52mcTvSanBq2TMsxKtkn5ROk4+n0tMuMHlfwLPmKBzzXyba/8tkebpgj6cY/TV/DDbEoZ2kUjEucPtvWSFXNFN6BJ6eWTrhpcSYGoahE6iLYafl+eaKjNVDjVc1m298HZnzumF7xqhh/U8IXSRuMDN2PzWOtw40J64VOjNnLjx1nnVAaMyRGKY1FQDuKwY7xMaAkEbcQOP1TOp/9mbvCXoTaBA1RmG8TDuUwOsQ/SlZVhsFn953fnbbvHS5J2VxlwKahlZlgQOLjuM93I9kxMALY2f4nSHH6bKAiPUvZERr4BL9pehHgfztXE3Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jP7QumnvnVJnINaqahrie+CmSVH+OF2e8WspvpgJUtQ=; b=Ahwt7u6iijvXDTDTF1LpmLtbKK7xfH7eJzCqcxNhUKXyaZwlKvG/qMHT0uf9BvInYVg463ZkocW9f2/xv6syfQ1J98WkZDdD78lh06jBHC2Rin2hg3Nc0giHNTKGxfNexccvm5tx3YbgGmch1sNj+cEcNKQ+WRqCCqjl6Qza9GM05CTpFYeQ2HwqSkRGhQSASnw2FEp81J6Rdz0W8nBKu39eqOZOBfwSDyOyg+LK5JKZD0Z5/1skVGJsvwIzx+fqSwuDRQ6T2biiiADJ46afp9SJRsHj8uhqiIJqEntje06LOYQJ86ReHhPzUW9oAzqKrrXB+3wz9dM+MNvZo3+9AA== 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=jP7QumnvnVJnINaqahrie+CmSVH+OF2e8WspvpgJUtQ=; b=i/nGkHqr1hhHDs1HpPcWaG+YIDcs6rjO4IMLWKB6EqaSjEVLG7fpcQ8c4G8RZFiKuo4XhhxGclYlRfzRKFpzuykmmgOkP20cZAB/wz+qp9yw50Y/oehH8pIYMgTQ6QPn1RP0AtElz5tesB4Hr73ZpzdzEv2JM9Xli00JNI9z2tI= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by MWHPR13MB1213.namprd13.prod.outlook.com (2603:10b6:300:11::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.10; Mon, 28 Feb 2022 22:23:06 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::9435:617d:d2c3:4c3d%5]) with mapi id 15.20.5038.013; Mon, 28 Feb 2022 22:23:06 +0000 From: Haoyu Song To: Greg Mirsky CC: Tarek Saad , mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" , Service Function Chaining IETF list Thread-Topic: [spring] Comments on draft-saad-mpls-miad-usecases Thread-Index: AQHYJQybUbEkehVNgEePJZTL39BWqqyiwYCAgAC9BACAARPuUIAABOwAgAAZz0CAAeiSAIACtr1ggAAPMYCAAB0MwIAABNMAgAAD1xCAAA22gIAAAovg Date: Mon, 28 Feb 2022 22:23:05 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8cb5f7a3-9807-468f-eb9f-08d9fb08e474 x-ms-traffictypediagnostic: MWHPR13MB1213:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +VdrSXEyUZluD5qFWRq1gSmrDkmeePKxp5ZdhNd/efUK5KxCSaVp9VOHr880MZLWCs3Ev6k4BB6MH01AXtAad6H1VqcVnOaxYJ21JP7so/mJ54OdHBJBOM9WFZ4nrq3NO2TNER44/osbQ3hYZB58wB22vaGrW2Yuza1e5BtKcdikxZ4c4/kNDr4RTSzCJJNYmH06NboMYtYebUgOHu8IIGxiJhdAejVR+JDEzn9l/2L58j5w1zZW4AhHZE8UmW6FCcRjmRolKD13Lx8D53KJE/fKKRmyap3x0RKzTrQPTTxZ/Td3iub9NT+Hy84O37AVXMilFZQOUx4mMuzCa9SgymtzDx70sFMiiIGITFnYkZp5GEJpK4GNP4dPzasF1EIRiYxwTclBrB5BsxZq45zhLvY2Ij1OwN4yNu+cMcOoHfIcM7nunwC7i6qH7MUcb6yfL0D5JlUZ+1UnHunT+u/X7odthUDyukAUD4HhkLKqwhWlZbXIhLG2NyQ9/yLiCszJhQbuqBADEiUGd49ySplFWw6nt2KuiCsxLJYI6LPJav34IqduugbfJpYURn32XfE59YIV275ATP+Ir96sUiUkE7kXQRzzEiGSgy4ds2Hb+Y2XmklkrJaJAR6bvMpkERn2ta1Wszy3XU2aKEEECkbX6XwHIWMbcSOjPfaqhNled00DJ6Get0BklG0bdNn8MEDbzEA5nN/Yi5a+uyrhhZXZPb7Ic7rmkIyRehZ9iUYSvzz/zdT29OIJ7OWbHDo/wu9E0m/00mPi4N8DQNj6m7I3b3BdmfO1FrVa05GdEB5oUnk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(26005)(71200400001)(38100700002)(83380400001)(55016003)(38070700005)(6506007)(7696005)(9686003)(508600001)(86362001)(966005)(54906003)(6916009)(33656002)(316002)(76116006)(66946007)(66446008)(66476007)(53546011)(64756008)(66556008)(8676002)(166002)(4326008)(8936002)(9326002)(52536014)(5660300002)(122000001)(44832011)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?xbpvP8LbytDAtqRFuzbEeMjdkWhMyH8Egpm9zPsDRwBSYeTGHPvU2s5oQorK?= =?us-ascii?Q?vHxZThmT9Bq/kj2/fzBkCIQPeRcBi8A8Ag62vCPHBIaocjlktgirXaywxWI+?= =?us-ascii?Q?0zypD9ROCusS3TzgziITn1R2+bRr2vz1yIZD2tI/fmVxhS/5j3yVZfRY9O8J?= =?us-ascii?Q?Hf8vC7AxRrL8eUNJkK+sJ2Qfu/GniQMUkeyt2mj3Gv4XjJsBt+kOevDgqT+T?= =?us-ascii?Q?NT7BonxTO2ZuRVAxkZT5eFgnaK4n6wZbb8Ns5W01oDenjDe8GMjMJ927vEnH?= =?us-ascii?Q?rDDL8f+vI09FBsD5TQAWd7lLodbJq9IyU5EFG/p3DDN8cjHK8Rx32hWgjI5e?= =?us-ascii?Q?mVngP4AB8gMDzcT02tXJWbMnTtJyNqIu/GzWVGNeHgFKsgQTeHAyPMYrvwNH?= =?us-ascii?Q?LJt9Uru7BMnzEU7ABKIAdlO9qEtvgQwtd7LG6Fajhf0K5vipPwmY2h0JKFRX?= =?us-ascii?Q?Q/EdaO92/A65GP7NhsdR84zSav7Y9cZh4egfdttRYlVAzz7xLyI8Xlx0VTrN?= =?us-ascii?Q?8uKMJoTHXD3x1VIVTvVIXVzgHYyw8qG7gLO5Ww25E0KKRQkQYzj6p8wKlKz4?= =?us-ascii?Q?OE3xIXnZAFMg1PgYshIQPXcAdmSN6aZlgPZ69f0cESS/1txNBLSTnphsfYSO?= =?us-ascii?Q?E0zCSJMfjTx3qUJUsijXDAkhFvEpt6+W5YIfxETCzEiyvwWK2YaUT7B/5hdW?= =?us-ascii?Q?/UrTXRV1KQl3EmSU+23Tke+GXzbxzrEUEBmyRkLbnOOmC16Zl7bsMEyE5Un9?= =?us-ascii?Q?WpT85NaOaXVUMMtZoZvEW/K2YfWzZtDNsdeh7Ps6j7GYY7GBUqh15qKKX5yx?= =?us-ascii?Q?B2HdXLhYsvQINZmT0EGi6+LH4i+ZVwppf0Sh8ezJJ9UjKOB8D7YV3l5z+G1l?= =?us-ascii?Q?AXu1HiOsMnGTYsVyaw6tsURMWG4j5mUqdZbTSxWhlI5jk1rtbsJnbzVE8xuT?= =?us-ascii?Q?GCSoeIXUZpQwh4vKMN5cxRqXVV/zHWH/5e4qCGtpw8rsgp5zzDjqDJiOQf5k?= =?us-ascii?Q?nfvQWhddEk6JeViliBznsfAON6+KSiYxl7MDikscuSVtqKRep06CJ1WVMPog?= =?us-ascii?Q?h896RIzdlkiOB90ulM2HiHMaDNkv4M14QD4UBLc+zVSpxsxJjXQZdZTagl/1?= =?us-ascii?Q?73WhBt1v8BEzX9PkjhlUdMVju9++LjZoI7eryntzdH/uQPFhPFiyg6bNINYh?= =?us-ascii?Q?Mr7SeOphElIfKvGAwPQ2W3XF+c9rmjg5aGT1HwDzU0xNO9xt0CQSU9t7G8/9?= =?us-ascii?Q?ErBw4cle9EO0DL0LS/1628OQBhDZF6Y0mmyiHmfrV8q/1un8NWauEwtWuoJd?= =?us-ascii?Q?NCdJ+FRxhQWhgQQ2lAlXI2nTveVzFORpjjskAb+I7Bh6GrX8aP17ZT2f45qh?= =?us-ascii?Q?jaGss9PtxkFfLHrrdcnqsbVDp/icRpwKiIUc2JusQp9MKIbAHoVLmfQuU5cB?= =?us-ascii?Q?7uHFvC1KOSb6lpIQEf0d1FO42HxBfflcH+O9g15x4ezcRzKaaX0s37As7RLF?= =?us-ascii?Q?YKbP+CXCm1ZB0fm2Re9F4vW9T34UUIeE2OLSdz3ZjGmQhXs70ROtbdvy75A3?= =?us-ascii?Q?UoEF8kNOXntKUiCZvHmKBeqqh7ElDeMBBQuZOp97k7foOpNE/gJloO2K4F3p?= =?us-ascii?Q?rHOfjEFWNHL04wWLOXTO0E4=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787B6C6335342D1D3961C4E9A019BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8cb5f7a3-9807-468f-eb9f-08d9fb08e474 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2022 22:23:05.9251 (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: N/nk58o+c5st6drqe+TiJ24fUEL61KuKMCZGFuDsn1zxz1KP1nJU79F8o8O+Ib4fmAJgUZK0udrGw2dRfiUc8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR13MB1213 Archived-At: Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases 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, 28 Feb 2022 22:23:20 -0000 --_000_BY3PR13MB4787B6C6335342D1D3961C4E9A019BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you for the clarification. To further the discussion, could you pleas= e answer the following questions? 1. Could you be specific on exactly what should be revisited on how to = do things over MPLS? This is very important and should be of the interest o= f the open DT. 2. Given that there's no solution consensus yet at this stage, what make= you think it will be dramatical changing existing mechanisms of delivery = services over an MPLS network? 3. Similarly, based on what you think RFC8596 is the "best possible" sol= ution? This seems a very bold claim. Thanks, Haoyu From: Greg Mirsky Sent: Monday, February 28, 2022 2:00 PM To: Haoyu Song Cc: Tarek Saad ; mpls ; pals@ietf.org; = DetNet WG ; spring ; draft-saad-mpls-miad= -usecases@ietf.org; Service Function Chaining IETF list Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases Hi Haoyu, adding the SFC WG to our discussion. I feel that if we continue your way of thinking about the SFC NSH and the M= IAD, then everything we know how to do over MPLS should be revisited. Would= you agree that is a fair conclusion based on your explanation of your posi= tion? I can agree that the extended MPLS architecture enhanced by the MIAD = coupled with the new ways of doing things we already know how to do might s= how some level of improvement. But I believe that would not be level to jus= tify dramatically changing existing mechanisms of delivery services over an= MPLS network. And the same applies to SFC NSH over MPLS. RFC 8596 is infor= mational because it describes how existing and known MPLS techniques can be= used to connect elements of an SFP. I think that is the best possible solu= tion - re-using the existing technology. Regarding the reference to RFC 8596 in the use-cases draft. I'd appreciate = it if other participants of the Open DT work and members of WGs share their= opinions. I've stated mine, I believe quite clearly. Regards, Greg On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song > wrote: Hi Greg, Here's my logic. I think NSH SFC could be a use case in MPLS and RFC8596, a= s a reference, shows that this has been considered before, so I take it as = an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are wor= king on a generic way to support different use cases in MPLS data plane , s= o the use cases also include NSH SFC, right? Sure, finally we may end up wi= th a different solution than RFC8596, but we have good reason for that, as = I have explained in pervious emails (e.g., to support multiple use cases at= the same time). Please note that this is only a use case draft and it does= n't enforce any solution but to show we have such requirements. When MIAD i= s developed, whether and where another draft for applying NSH SFC in it nee= ds to be developed is a totally different issue. Best, Haoyu From: Greg Mirsky > Sent: Monday, February 28, 2022 12:58 PM To: Haoyu Song > Cc: Tarek Saad >; mpls >; pals@ietf.org; Det= Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases Hi Haoyu, I wouldn't say that I don't like any use case, I just don't understand how = the RFC 8596 is related to MIAD work. As for your questions, I believe that= all these scenarios should be discussed by the SFC WG. In fact, draft-ietf= -sfc-ioam-nsh defines one them already. Regards, Greg On Mon, Feb 28, 2022, 12:50 Haoyu Song > wrote: Hi Greg, How about IOAM (or other types of OAM) + SFC (i.e., apply OAM simultaneousl= y) ? Or Slicing + SFC (i.e., apply SFC on a particular slice) ? I think the= se scenarios are possible. Maybe I misunderstand something. Could you pleas= e give more explanation on why you don't like this use case particularly? T= hanks. Best, Haoyu From: Greg Mirsky > Sent: Monday, February 28, 2022 10:56 AM To: Haoyu Song > Cc: Tarek Saad >; mpls >; pals@ietf.org; Det= Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases Hi Haoyu, can you give an example of "the other use cases in the same packet"? I don'= t think that discussing some hypothetical scenarios is a productive way for= the Open DT. Regards, Greg On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song > wrote: Hi Greg, What I think is that whatever output is from MIAD, it will provide a new so= lution to support NSH SFC in MPLS. RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be cooperat= ive with the other use cases in the same packet. MIAD tries to solve this p= roblem. Best, Haoyu From: Greg Mirsky > Sent: Saturday, February 26, 2022 4:36 PM To: Haoyu Song > Cc: Tarek Saad >; mpls >; pals@ietf.org; Det= Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases Hi Haoyu, I am sorry, but after reading your note, I cannot find an answer to my ques= tion How the MIAD work is applicable to the informational RFC 8596? In othe= r words, What do you see as missing in the solution described in RFC 8596 t= hat MIAD is expected to address? Regards, Greg On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song > wrote: Hi Greg, There have been some existing standards (e.g., EL and this one) and proposa= ls (some are listed in the document) with each dealing with a specific use = case. I think it's beneficial to list them all and then consider to use a g= eneric mechanism to handle all these otherwise piecemeal solutions. Of cour= se, finally we would need to pick which shall actually be supported with th= e generic method, but at this point, we shall not limit ourself. Regards, Haoyu From: Greg Mirsky > Sent: Friday, February 25, 2022 9:54 AM To: Haoyu Song > Cc: Tarek Saad >; mpls >; pals@ietf.org; Det= Net WG >; spring >; draft-saad-mpls-miad-usecases@ietf.org Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases Hi Haoyu, in RFC 8596 I don't find anything that would require any modification to th= e existing MPLS architecture. I would agree that SFC NSH using MPLS to conn= ect SFP components might benefit from the new enhancements to the MPLS, but= so would any other client that uses the MPLS network. Do you think that th= e use case document should list them all? Regards, Greg On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song > wrote: * in my earlier comments, I've noted that the informational RFC 8596 ap= pears not posing any requirements for enhancements in the MPLS data plane. = If I am missing something, please let me know. Hi Greg, The RFC is mentioned because it shows that SFC NSH has been considered to b= e supported in MPLS as well, so it's a legitimate use case like the others = in the draft. When we need to support multiple such use cases at the same t= ime, we need a generic mechanism to support them, so the use-case draft ser= ves as a motivation for our work in the ODT. Hopefully this answers your question. Thanks, Haoyu From: Greg Mirsky > Sent: Thursday, February 24, 2022 5:09 PM To: Tarek Saad > Cc: mpls >; pals@ietf.org; DetNet WG >; spring >; draft-saad-mpls-miad-usecases@ietf.or= g Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases Hi Tarek, thank you for your thoughtful consideration of my comments. I've reviewed t= he diff and got several follow-up notes: * the new text in the Introduction section explains the ISD as being en= coded as labels: within the label stack, e.g., encoded as labels, referred to as In Stack Data (ISD), and I think s/as labels/into label stack elements/ makes the text a bit more ac= curate. What do you think? * in my earlier comments, I've noted that the informational RFC 8596 ap= pears not posing any requirements for enhancements in the MPLS data plane. = If I am missing something, please let me know. * I might have missed it earlier. The TSN is the term used for a very s= pecific technology developed at IEEE to support, for example, URLLC service= s. The DetNet WG defines the methodology in support of these services using= IETF technologies - MPLS and IP. I think it would be appropriate if an IET= F document refers to Deterministic Networking, not TSN. What is your opinio= n? Regards, Greg On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad > wrote: Hi Greg, Thanks for your comments. I've addressed several of your comments. The late= st diffs (revision to be uploaded soon) can be found at: https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draf= t-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/t= saad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt Regards, Tarek (for co-authors) From: spring > on b= ehalf of Greg Mirsky > Date: Friday, February 18, 2022 at 4:15 PM To: draft-saad-mpls-miad-usecases@ietf.org >, mpls >, pa= ls@ietf.org >, De= tNet WG >, spring > Subject: [spring] Comments on draft-saad-mpls-miad-usecases Dear Authors, thank you for your work putting this document together. It helps to analyze= essential use cases in the scope of the work at the Open DT. Attached, ple= ase find a copy of the draft with my notes and some editorial suggestions. = I hope you'll find some of them helpful. I am looking forward to your feedback and questions. Regards, Greg --_000_BY3PR13MB4787B6C6335342D1D3961C4E9A019BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thank you for the clarification. To further the disc= ussion, could you please answer the following questions?

 

  1. Could you be specific on exactly what  should be revisited on ho= w to do things over MPLS? This is very important and should be of the inter= est of the open DT.
  2. Given that there’s no soluti= on consensus yet at this stage, what make you think it will be dramatical c= hanging  existing mechanisms of delivery services over an MPLS network= ?
  3. Similarly, based on what you think RFC8596 is the &#= 8220;best possible” solution? This seems a very bold claim.

 

Thanks,

Haoyu

 

From: Greg Mirsky <gregimirsky@gmail.com&g= t;
Sent: Monday, February 28, 2022 2:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org&g= t;; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@iet= f.org>; draft-saad-mpls-miad-usecases@ietf.org; Service Function Chainin= g IETF list <sfc@ietf.org>
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=

 

Hi Haoyu,

adding the SFC WG to our discussion.

 

I feel that if we continue your way of thinking abou= t the SFC NSH and the MIAD, then everything we know how to do over MPLS sho= uld be revisited. Would you agree that is a fair conclusion based on your e= xplanation of your position? I can agree that the extended MPLS architecture enhanced by the MIAD couple= d with the new ways of doing things we already know how to do might show so= me level of improvement. But I believe that would not be level to justify d= ramatically changing existing mechanisms of delivery services over an MPLS network. And the same applies to SFC NSH= over MPLS. RFC 8596 is informational because it describes how existing and= known MPLS techniques can be used to connect elements of an SFP. I th= ink that is the best possible solution - re-using the existing technology.

Regarding the reference to RFC 8596 in the use-cases= draft. I'd appreciate it if other participants of the Open DT work and mem= bers of WGs share their opinions. I've stated mine, I believe quite cl= early.

 

Regards,

Greg

 

On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song <haoyu.song@futurewei.com> wro= te:

Hi Greg,

 

Here’s my logic. I think NSH SFC could be a use case in MPLS= and RFC8596, as a reference, shows that this has been considered before, s= o I take it as an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are working on a generic way to su= pport different use cases in MPLS data plane , so the use cases also includ= e NSH SFC, right? Sure, finally we may end up with a different solution tha= n RFC8596, but we have good reason for that, as I have explained in pervious emails (e.g., to support multipl= e use cases at the same time). Please note that this is only a use case dra= ft and it doesn’t enforce any solution but to show we have such requi= rements. When MIAD is developed, whether and where another draft for applying NSH SFC in it needs to be developed i= s a totally different issue.

 

Best,

Haoyu

 

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 28, 2022 12:58 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=

 

Hi Haoyu,

I wouldn't say that I don't like any use case, I just don't unders= tand how the RFC 8596 is related to MIAD work. As for your questions, I bel= ieve that all these scenarios should be discussed by the SFC WG. In fact, draft-ietf-sfc-ioam-nsh defines one t= hem already.

 

Regards,

Greg

 

On Mon, Feb 28, 2022, 12:50 Haoyu Song <haoyu.song@futurewei.com> wro= te:

Hi Greg,

 

How about IOAM (or other types of OAM) + SFC (i.e., apply OAM simu= ltaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice) ? I = think these scenarios are possible. Maybe I misunderstand something. Could you please give more explanation on= why you don’t like this use case particularly? Thanks.

 

Best,

Haoyu

 

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 28, 2022 10:56 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=

 

Hi Haoyu,

can you give an example of "the other use cases in the same p= acket"? I don't think that discussing some hypothetical scenarios is a= productive way for the Open DT.

 

Regards,

Greg

 

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

Hi Greg,

 

What I think is that whatever output is from MIAD, it will provide= a new solution to support NSH SFC in MPLS.

RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be= cooperative with the other use cases in the same packet. MIAD tries to sol= ve this problem.

 

Best,

Haoyu

 

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Saturday, February 26, 2022 4:36 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=

 

Hi Haoyu,

I am sorry, but after reading your note, I cannot find an answer t= o my question How the MIAD work is applicable to the informational RFC 8596= ? In other words, What do you see as missing in the solution described in RFC 8596 that MIAD is expected to add= ress?

 

Regards,

Greg

 

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

Hi Greg,

 

There have been some existing standards (e.g., EL and this one) an= d proposals (some are listed in the document) with each dealing with a spec= ific use case. I think it’s beneficial to list them all and then consider to use a generic mechanism to handle al= l these otherwise piecemeal solutions. Of course, finally we would need to = pick which shall actually be supported with the generic method, but at this= point, we shall not limit ourself.

 

Regards,

Haoyu

 

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=

 

Hi Haoyu,

in RFC 8596 I don't find anything that would require any modificat= ion to the existing MPLS architecture. I would agree that SFC NSH usin= g MPLS to connect SFP components might benefit from the new enhancements to the MPLS, but so would any other client that = uses the MPLS network. Do you think that the use case document should list = them all?

 

Regards,

Greg

 

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com>= wrote:

  • in my earlier comments, I've noted that the informational RFC 8596 appears = not posing any requirements for enhancements in the MPLS data plane. If I a= m missing something, please let me know.

Hi Greg,

 

The RFC is mentioned because it shows that SFC NSH has been consid= ered to be supported in MPLS as well, so it’s a legitimate use case l= ike the others in the draft. When we need to support multiple such use cases at the same time, we need a generic mec= hanism to support them, so the use-case draft serves as a motivation for ou= r work in the ODT.

Hopefully this answers your question. Thanks,

Haoyu  

 

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad <tsaad.net@gmail.com>
Cc: mpls <mpls= @ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases=

 

Hi Tarek,

thank you for your thoughtful consideration of my comments. I= 've reviewed the diff and got several follow-up notes:

  • the new text in the Introduction section explains the ISD as being encoded = as labels:

within the label stack, e.g., encoded as labels, referred to as In=      

           =       Stack Data (ISD), and

I think s/as labels/into label stack elements/ makes the text a bi= t more accurate. What do you think?

  • in my earlier comments, I've noted that the informational RFC 8596 appears = not posing any requirements for enhancements in the MPLS data plane. If I a= m missing something, please let me know.
  • I might have missed it earlier. The TSN is the term used for a very specifi= c technology developed at IEEE to support, for example, URLLC services. The= DetNet WG defines the methodology in support of these services using IETF = technologies - MPLS and IP. I think it would be appropriate if an IETF document refers to Deterministic Networ= king, not TSN. What is your opinion?

Regards,

Greg

 

 

On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com> wrote:

Hi Greg,

 =

Thanks for your co= mments. I’ve addressed several of your comments. The latest diffs (re= vision to be uploaded soon) can be found at:

https://tools.ietf.org//rfcd= iff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00= .txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/drafts/master/m= iad-usecases/draft-dt-mpls-miad-usecases.txt

 =

Regards,

Tarek (for co-auth= ors)

 =

From: spri= ng <spring-= bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls= -miad-usecases@ietf.org>, mpls <mpls@ietf.org>, pals@ietf.org <pals@ietf.org>, Det= Net WG <detnet@ietf= .org>, spring <spring@ietf.org>
Subject: [spring] Comments on draft-saad-mpls-miad-usecases

Dear Authors,

thank you for your work putting this document= together. It helps to analyze essential use cases in the scope of the work= at the Open DT. Attached, please find a copy of the draft with my notes and some editorial suggestions. I h= ope you'll find some of them helpful.

I am looking forward to your feedback and que= stions.

 

Regards,

Greg

--_000_BY3PR13MB4787B6C6335342D1D3961C4E9A019BY3PR13MB4787namp_-- From nobody Mon Feb 28 14:33:24 2022 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 653103A1650; Mon, 28 Feb 2022 14:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 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_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qdo1Kt6AAZyl; Mon, 28 Feb 2022 14:33:10 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 C55E33A1651; Mon, 28 Feb 2022 14:32:52 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id bg10so27795095ejb.4; Mon, 28 Feb 2022 14:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7EGrViLPSmRrJSeg/5nxAHeWTPyQRti4sO8/3Zr/Sjc=; b=YpNtVeFy4vkEiEv5GEWrkCq18rVaILVhMC1qik7lU2GyPL7n+pZVM5oc4H2xxz1xzG E7K+Pbc8KGCJUIAbH0T3eJvboAWCwVVrIE5arvgqHmKDp43gAbEKz23MmvSgSm7uybLK JGatXkVX0unsETxNNNNrWhEIk6DLScIkp4/A1QaA2aYJToS8dAEUNMCamAIqX3Tx9slY j2D6q9tbbGr9jLr6lBk9rRwCjGW20OVf1wqQF+Qgi9vyHnOjJ77skOziNtNP0UV+HViQ +vN2T7BZ4rsbQEQ0CsrIqX+2WYqQAT+oF1yIPW+MJyaoAhwGq9okawR/0wQrHwTmCG3h 0E9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7EGrViLPSmRrJSeg/5nxAHeWTPyQRti4sO8/3Zr/Sjc=; b=Jfeio8EqAwckr1HJKut9WGzLGmRtM4aKAl0grTlU8ndM0lCeS3MMZDTgizyjAtshwV IJMzjIM6yj6eNVx1xWvrZ1jxXZQEV+kp+4kIEoKf1YI1n44bg4qR2aNJSKHA0K5ZBId2 NkmLYuci826Ti+MEixRajdGIITb56xg57pSynPvWCh5MhBEe6Zpz+3eMUSznkld3gf5y IHkvb+uU5Y3akAJmUpzgV9zdzro9q9CNs0H/CrGMR+xenwAv9FOY+Nvsc9/8FLM9iPMw NGRmvs4t+ZhfOw5x9QL8+5CqNBkqg+ANZ/mXelJW8yDp7bFT1mHB3c2mh+R6T5HOQQpP +Y/Q== X-Gm-Message-State: AOAM531KPk8edl4z9s/ae1QqY7PDcfW5WLExG5GVyYIqJ+FMZqbT7P/I ZwgW6U7XMZIAQ+GDrHse6x/5CZs9/kHnpsZ++Tw= X-Google-Smtp-Source: ABdhPJxCS7tDz2PmuqeT7kFb20TlcsEZ2tu9YRHXzVriynibwgJScAE0hmVHE8gNe/5EUPhIKv65YFKu3L+lfSnoXhc= X-Received: by 2002:a17:906:3e09:b0:6ce:d86c:91a3 with SMTP id k9-20020a1709063e0900b006ced86c91a3mr16423079eji.255.1646087570501; Mon, 28 Feb 2022 14:32:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 28 Feb 2022 14:32:39 -0800 Message-ID: To: Haoyu Song Cc: Tarek Saad , mpls , "pals@ietf.org" , DetNet WG , spring , "draft-saad-mpls-miad-usecases@ietf.org" , Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="000000000000e8b12f05d91ba06c" Archived-At: Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases 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, 28 Feb 2022 22:33:16 -0000 --000000000000e8b12f05d91ba06c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, please find my notes in-line below tagged by GIM>>. Regards, Greg On Mon, Feb 28, 2022 at 2:23 PM Haoyu Song wrote= : > Hi Greg, > > > > Thank you for the clarification. To further the discussion, could you > please answer the following questions? > > > > 1. Could you be specific on exactly what should be revisited on how > to do things over MPLS? This is very important and should be of the > interest of the open DT. > > GIM>> You either misunderstood my note or are trying to put words in my mouth that I didn't say. I merely extended the logic you've presented explaining your support of keeping RFC 8596 in the use case draft. > > > 1. Given that there=E2=80=99s no solution consensus yet at this stage,= what > make you think it will be dramatical changing existing mechanisms of > delivery services over an MPLS network? > > GIM>> Again, you're either misunderstanding my position or else. I am not proposing revisiting existing and well-known methods of delivering services over an MPLS network. > > 1. > 2. Similarly, based on what you think RFC8596 is the =E2=80=9Cbest pos= sible=E2=80=9D > solution? This seems a very bold claim. > > GIM>> Because it follows the KISS principle. > > 1. > > > > Thanks, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Monday, February 28, 2022 2:00 PM > *To:* Haoyu Song > *Cc:* Tarek Saad ; mpls ; > pals@ietf.org; DetNet WG ; spring ; > draft-saad-mpls-miad-usecases@ietf.org; Service Function Chaining IETF > list > *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases > > > > Hi Haoyu, > > adding the SFC WG to our discussion. > > > > I feel that if we continue your way of thinking about the SFC NSH and the > MIAD, then everything we know how to do over MPLS should be revisited. > Would you agree that is a fair conclusion based on your explanation of yo= ur > position? I can agree that the extended MPLS architecture enhanced by the > MIAD coupled with the new ways of doing things we already know how to do > might show some level of improvement. But I believe that would not be lev= el > to justify dramatically changing existing mechanisms of delivery services > over an MPLS network. And the same applies to SFC NSH over MPLS. RFC 8596 > is informational because it describes how existing and known MPLS > techniques can be used to connect elements of an SFP. I think that is the > best possible solution - re-using the existing technology. > > Regarding the reference to RFC 8596 in the use-cases draft. I'd appreciat= e > it if other participants of the Open DT work and members of WGs share the= ir > opinions. I've stated mine, I believe quite clearly. > > > > Regards, > > Greg > > > > On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song > wrote: > > Hi Greg, > > > > Here=E2=80=99s my logic. I think NSH SFC could be a use case in MPLS and = RFC8596, > as a reference, shows that this has been considered before, so I take it = as > an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are > working on a generic way to support different use cases in MPLS data plan= e > , so the use cases also include NSH SFC, right? Sure, finally we may end = up > with a different solution than RFC8596, but we have good reason for that, > as I have explained in pervious emails (e.g., to support multiple use cas= es > at the same time). Please note that this is only a use case draft and it > doesn=E2=80=99t enforce any solution but to show we have such requirement= s. When > MIAD is developed, whether and where another draft for applying NSH SFC i= n > it needs to be developed is a totally different issue. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Monday, February 28, 2022 12:58 PM > *To:* Haoyu Song > *Cc:* Tarek Saad ; mpls ; > pals@ietf.org; DetNet WG ; spring ; > draft-saad-mpls-miad-usecases@ietf.org > *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases > > > > Hi Haoyu, > > I wouldn't say that I don't like any use case, I just don't understand ho= w > the RFC 8596 is related to MIAD work. As for your questions, I believe th= at > all these scenarios should be discussed by the SFC WG. In fact, > draft-ietf-sfc-ioam-nsh defines one them already. > > > > Regards, > > Greg > > > > On Mon, Feb 28, 2022, 12:50 Haoyu Song wrote: > > Hi Greg, > > > > How about IOAM (or other types of OAM) + SFC (i.e., apply OAM > simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice= ) > ? I think these scenarios are possible. Maybe I misunderstand something. > Could you please give more explanation on why you don=E2=80=99t like this= use case > particularly? Thanks. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Monday, February 28, 2022 10:56 AM > *To:* Haoyu Song > *Cc:* Tarek Saad ; mpls ; > pals@ietf.org; DetNet WG ; spring ; > draft-saad-mpls-miad-usecases@ietf.org > *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases > > > > Hi Haoyu, > > can you give an example of "the other use cases in the same packet"? I > don't think that discussing some hypothetical scenarios is a productive w= ay > for the Open DT. > > > > Regards, > > Greg > > > > On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song > wrote: > > Hi Greg, > > > > What I think is that whatever output is from MIAD, it will provide a new > solution to support NSH SFC in MPLS. > > RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be > cooperative with the other use cases in the same packet. MIAD tries to > solve this problem. > > > > Best, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Saturday, February 26, 2022 4:36 PM > *To:* Haoyu Song > *Cc:* Tarek Saad ; mpls ; > pals@ietf.org; DetNet WG ; spring ; > draft-saad-mpls-miad-usecases@ietf.org > *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases > > > > Hi Haoyu, > > I am sorry, but after reading your note, I cannot find an answer to my > question How the MIAD work is applicable to the informational RFC 8596? I= n > other words, What do you see as missing in the solution described in RFC > 8596 that MIAD is expected to address? > > > > Regards, > > Greg > > > > On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song > wrote: > > Hi Greg, > > > > There have been some existing standards (e.g., EL and this one) and > proposals (some are listed in the document) with each dealing with a > specific use case. I think it=E2=80=99s beneficial to list them all and t= hen > consider to use a generic mechanism to handle all these otherwise pieceme= al > solutions. Of course, finally we would need to pick which shall actually = be > supported with the generic method, but at this point, we shall not limit > ourself. > > > > Regards, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Friday, February 25, 2022 9:54 AM > *To:* Haoyu Song > *Cc:* Tarek Saad ; mpls ; > pals@ietf.org; DetNet WG ; spring ; > draft-saad-mpls-miad-usecases@ietf.org > *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases > > > > Hi Haoyu, > > in RFC 8596 I don't find anything that would require any modification to > the existing MPLS architecture. I would agree that SFC NSH using MPLS to > connect SFP components might benefit from the new enhancements to the MPL= S, > but so would any other client that uses the MPLS network. Do you think th= at > the use case document should list them all? > > > > Regards, > > Greg > > > > On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song > wrote: > > > - in my earlier comments, I've noted that the informational RFC 8596 > appears not posing any requirements for enhancements in the MPLS data > plane. If I am missing something, please let me know. > > Hi Greg, > > > > The RFC is mentioned because it shows that SFC NSH has been considered to > be supported in MPLS as well, so it=E2=80=99s a legitimate use case like = the others > in the draft. When we need to support multiple such use cases at the same > time, we need a generic mechanism to support them, so the use-case draft > serves as a motivation for our work in the ODT. > > Hopefully this answers your question. Thanks, > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Thursday, February 24, 2022 5:09 PM > *To:* Tarek Saad > *Cc:* mpls ; pals@ietf.org; DetNet WG ; > spring ; draft-saad-mpls-miad-usecases@ietf.org > *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases > > > > Hi Tarek, > > thank you for your thoughtful consideration of my comments. I've reviewed > the diff and got several follow-up notes: > > - the new text in the Introduction section explains the ISD as being > encoded as labels: > > within the label stack, e.g., encoded as labels, referred to as In > > Stack Data (ISD), and > > I think s/as labels/into label stack elements/ makes the text a bit more > accurate. What do you think? > > > - in my earlier comments, I've noted that the informational RFC 8596 > appears not posing any requirements for enhancements in the MPLS data > plane. If I am missing something, please let me know. > - I might have missed it earlier. The TSN is the term used for a very > specific technology developed at IEEE to support, for example, URLLC > services. The DetNet WG defines the methodology in support of these > services using IETF technologies - MPLS and IP. I think it would be > appropriate if an IETF document refers to Deterministic Networking, no= t > TSN. What is your opinion? > > Regards, > > Greg > > > > > > On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad wrote: > > Hi Greg, > > > > Thanks for your comments. I=E2=80=99ve addressed several of your comments= . The > latest diffs (revision to be uploaded soon) can be found at: > > > https://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/dr= aft-saad-mpls-miad-usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com= /tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt > > > > > Regards, > > Tarek (for co-authors) > > > > *From: *spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Friday, February 18, 2022 at 4:15 PM > *To: *draft-saad-mpls-miad-usecases@ietf.org < > draft-saad-mpls-miad-usecases@ietf.org>, mpls , > pals@ietf.org , DetNet WG , spring < > spring@ietf.org> > *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases > > Dear Authors, > > thank you for your work putting this document together. It helps to > analyze essential use cases in the scope of the work at the Open DT. > Attached, please find a copy of the draft with my notes and some > editorial suggestions. I hope you'll find some of them helpful. > > I am looking forward to your feedback and questions. > > > > Regards, > > Greg > > --000000000000e8b12f05d91ba06c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Haoyu,
please find my notes in-lin= e below tagged by GIM>>.

Regards,
= Greg

On Mon, Feb 28, 2022 at 2:23 PM Haoyu Song <haoyu.song@futurewei.com> wrote:
=

Hi Greg,

=C2=A0

Thank you for the clarification. To further the disc= ussion, could you please answer the following questions?

=C2=A0

  1. Could you be specific on exactly what =C2=A0should be revisited o= n how to do things over MPLS? This is very important and should be of the i= nterest of the open DT.
GIM>> = You either misunderstood my note or are trying to put words in my mouth tha= t I didn't say. I merely extended the logic you've presented explai= ning your support of keeping RFC 8596 in the use case draft.

  1. Given= that there=E2=80=99s no solution consensus yet at this stage, what make yo= u think it will be dramatical changing =C2=A0existing mechanisms of deliver= y services over an MPLS network?
GIM= >> Again, you're either misunderstanding=C2=A0my position or else= . I am not proposing revisiting existing and well-known methods of deliveri= ng services over an MPLS network.
  2. Similar= ly, based on what you think RFC8596 is the =E2=80=9Cbest possible=E2=80=9D = solution? This seems a very bold claim.
<= div>GIM>> Because it follows the KISS principle.=C2=A0

=C2=A0

Thanks,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 28, 2022 2:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>; dra= ft-saad-mpls-miad-usecases@ietf.org; Service Function Chaining IETF lis= t <sfc@ietf.org>= ;
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi Haoyu,

adding the SFC WG to our discussion.

=C2=A0

I feel that if we continue your way of thinking abou= t the SFC NSH and the MIAD, then everything we know how to do over MPLS sho= uld be revisited. Would you agree that is a fair conclusion based on your e= xplanation of your position? I can agree that the extended MPLS architecture enhanced by the MIAD=C2=A0couple= d with the new ways of doing things we already know how to do might show so= me level of improvement. But I believe that would not be level to justify d= ramatically=C2=A0changing existing mechanisms of delivery services over an MPLS network. And the same applies to SFC NSH= over MPLS. RFC 8596 is informational because it describes how existing and= known MPLS techniques can be used to connect elements=C2=A0of an SFP. I th= ink that is the best possible solution=C2=A0- re-using=C2=A0the existing technology.

Regarding the reference to RFC 8596 in the use-cases= draft. I'd appreciate it if other participants of the Open DT work and= members=C2=A0of WGs share their opinions. I've stated mine, I believe = quite clearly.

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

Hi Greg,

=C2=A0

Here=E2=80=99s my logic. I think NSH SFC could be a = use case in MPLS and RFC8596, as a reference, shows that this has been cons= idered before, so I take it as an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are working on a generic way to su= pport different use cases in MPLS data plane , so the use cases also includ= e NSH SFC, right? Sure, finally we may end up with a different solution tha= n RFC8596, but we have good reason for that, as I have explained in pervious emails (e.g., to support multipl= e use cases at the same time). Please note that this is only a use case dra= ft and it doesn=E2=80=99t enforce any solution but to show we have such req= uirements. When MIAD is developed, whether and where another draft for applying NSH SFC in it needs to be developed i= s a totally different issue.

=C2=A0

Best,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 28, 2022 12:58 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi=C2=A0Haoyu,

I wouldn't say that I don't like any use cas= e, I just don't understand how the RFC 8596 is related to MIAD work. As= for your questions, I believe that all these scenarios should be discussed by the SFC WG. In fact, draft-ietf-sfc-ioam-nsh defines one t= hem already.

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 28, 2022, 12:50 Haoyu Song <haoyu.song@futurewei= .com> wrote:

Hi Greg,

=C2=A0

How about IOAM (or other types of OAM) + SFC (i.e., = apply OAM simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particul= ar slice) ? I think these scenarios are possible. Maybe I misunderstand something. Could you please give more explanation on= why you don=E2=80=99t like this use case particularly? Thanks.

=C2=A0

Best,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, February 28, 2022 10:56 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi Haoyu,

can you give an example of "the other use cases= in the same packet"? I don't think that discussing some hypotheti= cal scenarios is a productive way for the Open DT.

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <haoyu.song@future= wei.com> wrote:

Hi Greg,

=C2=A0

What I think is that whatever output is from MIAD, i= t will provide a new solution to support NSH SFC in MPLS.

RFC 8596 shows a way to support NSH SFC in MPLS, but= it may not be cooperative with the other use cases in the same packet. MIA= D tries to solve this problem.

=C2=A0

Best,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Saturday, February 26, 2022 4:36 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi Haoyu,

I am sorry, but after reading your note, I cannot fi= nd an answer to my question How the MIAD work is applicable to the informat= ional RFC 8596? In other words, What do you see as missing in the solution described in RFC 8596 that MIAD is expected to add= ress?

=C2=A0

Regards,

Greg

=C2=A0

On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@future= wei.com> wrote:

Hi Greg,

=C2=A0

There have been some existing standards (e.g., EL an= d this one) and proposals (some are listed in the document) with each deali= ng with a specific use case. I think it=E2=80=99s beneficial to list them all and then consider to use a generic mechanism to handle al= l these otherwise piecemeal solutions. Of course, finally we would need to = pick which shall actually be supported with the generic method, but at this= point, we shall not limit ourself.

=C2=A0

Regards,

Haoyu

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, February 25, 2022 9:54 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi=C2=A0Haoyu,

in RFC 8596 I don't find anything that would req= uire any modification to the existing MPLS architecture. I would=C2=A0agree= that SFC NSH using MPLS to connect SFP components might benefit from the new enhancements to the MPLS, but so would any other client that = uses the MPLS network. Do you think that the use case document should list = them all?

=C2=A0

Regards,

Greg

=C2=A0

On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurew= ei.com> wrote:

  • in my earlier comments, I've noted that the informational RFC 8596 appe= ars not posing any requirements for enhancements in the MPLS data plane. If= I am missing=C2=A0something, please let me know.

Hi Greg,

=C2=A0

The RFC is mentioned because it shows that SFC NSH h= as been considered to be supported in MPLS as well, so it=E2=80=99s a legit= imate use case like the others in the draft. When we need to support multiple such use cases at the same time, we need a generic mec= hanism to support them, so the use-case draft serves as a motivation for ou= r work in the ODT.

Hopefully this answers your question. Thanks,=

Haoyu =C2=A0

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, February 24, 2022 5:09 PM
To: Tarek Saad <tsaad.net@gmail.com>
Cc: mpls <mpls= @ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>; spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
Subject: Re: [spring] Comments on draft-saad-mpls-miad-usecases

=C2=A0

Hi Tarek,

thank you for your thoughtful=C2=A0consideration of = my comments. I've reviewed the diff and got several follow-up notes:=

  • the new text in the Introduction section explains the ISD as being encoded = as labels:

within the label stack, e.g., encoded as labels, ref= erred to as 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=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0Stack Data (ISD), and

I think s/as labels/into label stack elements/ makes= the text a bit more accurate. What do you think?

  • in my earlier comments, I've noted that the informational RFC 8596 appe= ars not posing any requirements for enhancements in the MPLS data plane. If= I am missing=C2=A0something, please let me know.
  • I might have missed it earlier. The TSN is the term used for a very specifi= c technology developed at IEEE to support, for example, URLLC services. The= DetNet WG defines the methodology in support of these services using IETF = technologies - MPLS and IP. I think it would be appropriate if an IETF document refers to Deterministic Networ= king, not TSN. What is your opinion?

Regards,

Greg

=C2=A0

=C2=A0

On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com= > wrote:

Hi Gre= g,

=C2=A0=

Thanks= for your comments. I=E2=80=99ve addressed several of your comments. The la= test diffs (revision to be uploaded soon) can be found at:=

https://tools.ie= tf.org//rfcdiff?url1=3Dhttps://www.ietf.org/archive/id/draft-saad-mpls-miad= -usecases-00.txt&url2=3Dhttps://raw.githubusercontent.com/tsaad-dev/dra= fts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt<= u>

=C2=A0=

Regard= s,

Tarek = (for co-authors)

=C2=A0=

From: spring= <spring-bo= unces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Friday, February 18, 2022 at 4:15 PM
To: draft-saad-mpls-miad-usecases@ietf.org <draft-saad-mpls= -miad-usecases@ietf.org>, mpls <mpls@ietf.org>, pals@ietf.org <pals@ietf.org>, Det= Net WG <detnet@ietf= .org>, spring <spring@ietf.org>
Subject: [spring] Comments on draft-saad-mpls-miad-usecases

Dear Authors,<= /u>

thank you for your work putting= this document together. It helps to analyze essential use cases in the sco= pe of the work at the Open DT. Attached, please find a copy of the draft with my notes and some editorial=C2=A0suggestions. I h= ope you'll find some of them helpful.

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

=C2=A0

Regards,

Greg

--000000000000e8b12f05d91ba06c-- From nobody Mon Feb 28 15:50:35 2022 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 001D93A172B; Mon, 28 Feb 2022 15:50:11 -0800 (PST) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164609221189.1465.9721284764641300538@ietfa.amsl.com> Date: Mon, 28 Feb 2022 15:50:11 -0800 Archived-At: Subject: [spring] I-D Action: draft-hu-spring-segment-routing-proxy-forwarding-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: Mon, 28 Feb 2022 23:50: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 : SR-TE Path Midpoint Restoration Authors : Zhibo Hu Huaimo Chen Junda Yao Chris Bowers Yongqing Yisong Filename : draft-hu-spring-segment-routing-proxy-forwarding-18.txt Pages : 14 Date : 2022-02-28 Abstract: Segment Routing Traffic Engineering (SR-TE) supports explicit paths using segment lists containing adjacency-SIDs, node-SIDs and binding- SIDs. The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node along a SR-TE path by the direct neighbor or say point of local repair (PLR) to the failure. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbors of the failure will no longer have a route to the failed node. This document describes a mechanism for the restoration of the routes to the failure of a SR-MPLS TE path after the IGP converges. It provides the restoration of the routes to an adjacency segment, a node segment and a binding segment of the path. With the restoration of the routes to the failure, the traffic is continuously sent to the neighbor of the failure after the IGP converges. The neighbor as a PLR fast re-routes the traffic around the failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-hu-spring-segment-routing-proxy-forwarding-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-hu-spring-segment-routing-proxy-forwarding-18 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Feb 28 19:00:32 2022 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 8EB1B3A0128 for ; Mon, 28 Feb 2022 19:00:29 -0800 (PST) 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 CrqIV9vPffya for ; Mon, 28 Feb 2022 19:00:24 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eab::72b]) (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 9E8F93A1815 for ; Mon, 28 Feb 2022 19:00:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YJS8Ckshi+/ZKHrVyDdNrreLsrbQw8dIt9GO1UJ8zOB5P+6c+Tc6KrH6qzpB9hiKMKCgObFBwVBRA7WPb5uEGz4AqaV26JbDEtynJaHnV69PxYquM0qd5xbYn2YaE1LA8YMthEuklxPH+3Fc2PMzOW47DnVWKpzHm3a4x0X1nGJLJOd7TLgvVwF3GBJKzrVhb16eVzTXn6ifdPOlC1e6s50QYkv3eC6pNTAdJIgp6kIvK8OauVkfqTOM/a86M9dbOZIHVHSkvEDEylWlGnPPnzGHzXb+FTBAMcHbxDY5kcbHY6+eB+4XfWHN6qahWzcujYtlydTTI0aw4Cs1pckUjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=D4xljPNjveU4sYnAGxBR/N7jNdW0D8RoKHOiNxUxHMk=; b=d/Q/K0YXDbadjREDv5r4E8BeL0kpX5si6GiaPgl30ySQEpNOtEveXEFhW946XqhpNfHPfjguYT9osuOORTscs3i5vnqg1YpS2/LTs3ET/0i1qb6BtBHifcw5M4paT9dEWMeEUlh6L3pi6t9n3TLtlz3YaB2D8DNoVRZp0CeMbro06PdDhJhIjg+gzOGvzVclYDlFiVHpE0yNz+evnqbfCSuenUGSAv6iaWRtkcGShGIPenUmuGFqzewgDAHczcNYzlx7+ocGAYl2VdV8dZ7dpm2E+4Ak22bp0EQOp7tRzk6Os6cMbg+VO1mOurGr70QFFkL3Pc7ToU8cDeZIWM5i3g== 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=D4xljPNjveU4sYnAGxBR/N7jNdW0D8RoKHOiNxUxHMk=; b=VDbVTuZQwVivT9ywSiZY9oFj58Q0sat4I6s8pyvtgRrfk6rtNJBD/EBYcE2mDBFvPR7UBP/8g0WXHWxxBg8Kotx5ogtoP3tvvwTA/mGiibl+ySWCVrlyRoRCLNiiu3+Cj1i9C6pw3u9bWXfN31xIy5zSqOnwc89ATgQT3oBszsA= Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by PH0PR13MB5975.namprd13.prod.outlook.com (2603:10b6:510:16e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.9; Tue, 1 Mar 2022 03:00:16 +0000 Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::a4b0:2b04:3072:6059%7]) with mapi id 15.20.5038.013; Tue, 1 Mar 2022 03:00:16 +0000 From: Huaimo Chen To: "bruno.decraene@orange.com" , SPRING WG Thread-Topic: WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding Thread-Index: AdgIZuyr9yYdtjOrSFSQcPhMc9AmsAhCCJgAAOigGZQ= Date: Tue, 1 Mar 2022 03:00:15 +0000 Message-ID: References: <16511_1642069161_61DFFCA9_16511_109_5_57d3682191ff4ba0af62841fa9517ecb@orange.com> <16252_1645701439_6217693F_16252_172_1_261dad9f8f154ff299920b2359f7d4d9@orange.com> In-Reply-To: <16252_1645701439_6217693F_16252_172_1_261dad9f8f154ff299920b2359f7d4d9@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-02-24T11:17:16Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; suggested_attachment_session_id: ba5cec36-b68b-1326-379d-89869a1a0026 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74acbb1f-8b70-4044-394e-08d9fb2f9cc2 x-ms-traffictypediagnostic: PH0PR13MB5975:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Zk+qnSyGvhgdQaonQ+iQqgLYRYAz8rW4cyt4LCySfKC/k0G4lv2Ky5agzvMhDyNKlsVXnm3ay3RsjfAg2tnjo0SFFFmV48OnqyLamA68ekEvU9+8RfWw8hnz4J+R5JFukzwm9kYpqNTXWlOBVvXAj3YEO7j71EBmjhiaS11RYvKs0qwufnSTeqfilis/SKoQ9gL7toqc0mtiXWciHA0y2vLG/X8SwFLIkffYLeaGpABl5T5Z6X+U5tlp80IbhyWQ4raTiqaMzytrQPoj80u5doRnRcb0MxwtLIDzLx3k4ylCmptVYT8TkjP3GiQFyPq8uLNTsybi6oP4Nj7v2UCSY94s//hO9Bwd8/bTQUZSVRBEzz8aAzHj49/135eAUBa1ZMOO0nMVQo//FNd48ARzRGjFcjcWtpQjS8eG+xm9bfunw29nLvmXuxlXEs8KqaWjb/7YyJfIS2JtSL7iyK3XYbP2R4c7X53YqHCWLlIEUs103kaz9HnQCVQrdWc5Tf8JA1zkLYQC8gJl3YpHgUpDZ54M3tDVON9/czZss7O1X1MlAv55KK0fPXrz+aCZtyyanJe23ANRuK7adOez7Vqt42e0eur9yckQy5QJnLfBcB8uXPblNhU80G3sezCW0R4/3SXm7MLYNel9qsrsLDCEaL6nDQlKUT8+k9xiX7QHmNo8ActM78p9GOXB+UgVHV9XGmZO+4Gm7fK1qY9V79pm9JUtoTpvHSoXppEYMng4pLjUV5vRqa+Bv2vvREwELsaL9vorgtgBoMwLqjKLHAq9jdVUINBMaZqorEahLpWYwtRlPW6+9pCVGLuP+Mbp7+QAz/1D9PNNW0sD0Hn4Mp0K5OwLfoOSKxFq/8oXanbNAYSZTBwXDGUufjLBkX0SBN9pltnXOKMMJwxOUJkD4HuH4Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66556008)(86362001)(53546011)(6506007)(83380400001)(19627405001)(8936002)(186003)(5660300002)(52536014)(55016003)(71200400001)(110136005)(9686003)(2906002)(33656002)(508600001)(166002)(7696005)(91956017)(76116006)(66946007)(66476007)(66446008)(64756008)(38070700005)(122000001)(38100700002)(8676002)(44832011)(316002)(966005)(15785145003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?7oW11TdiB5Ev9Y/vx070VGCetAU+zwgX8VpzkwsX3ltTLVSa99/Yxwqe?= =?Windows-1252?Q?iCHBBa7BD7br2Ocy9/w//jF5wY3jjFHwhjpb42ntTqSNRcGsd1SUYIaC?= =?Windows-1252?Q?Uv6EfRqK9wpQtQBMXxXAoqY9fdf/6i6gh62g0jv5pK4+XQGFWIq0VIa6?= =?Windows-1252?Q?gn3uP1319fa0JW+lLO6ImUULM+FjNdUntcGTP7RiBSLjz8h1hjQSw5Ko?= =?Windows-1252?Q?Jx65OnFQhyEYjXUBfXwxBXkP0FldFhiAmWlNtEHaC0KPfXZHh6HoD6Sm?= =?Windows-1252?Q?xzOP9v65O1cbl4UuX3KVwE8BpCwaXVtca1uEl8Oxir1jWWGFumZFS3Rr?= =?Windows-1252?Q?odOFx8MOfXJGSP5jZvpE4bIfwEQDk0dH4R+TQ+3czl5cdD1BxXAM6bhJ?= =?Windows-1252?Q?gU8aIE3XlITD2p3AQpzZY4sjzXzKhm8+zYAd7mCbFjd1c8/si0sxGcEb?= =?Windows-1252?Q?0E+BjvWpnKjhmuBv5eomDV2EQJJAR7ud0HtgHrkR1ystZZp9rt+J1q0l?= =?Windows-1252?Q?RecTnQQkUN/JfX2vGm8xr+936RSxTY2YaLzN8IwRS+3azlMp4f5O9sa6?= =?Windows-1252?Q?Dn1j4WALetx9WYZ693ie4c8rFGMUZhu5I5Fi8ojwr+tXXrmkGIh2Q5Gh?= =?Windows-1252?Q?A8iGDCq0KiMi/IXAjSX0ppgRi2wg1PRpncapqMVzUUL/7YDS9zMPZnUa?= =?Windows-1252?Q?ypPjMCy2xRVL3qGMmonitduIU7TqWka2wrF+C3bJHoCsngO8fbxbVqqV?= =?Windows-1252?Q?SKvp/uOxbMhBOnl6h0Yckg1PidRfuIniapxFoUgdOZjv0Mg/rR67ilY8?= =?Windows-1252?Q?8Lr9udNA225xxwdv6aIwqTxln8cTpQHRamIXTeiBCt1YsFbNqgnV+Yhn?= =?Windows-1252?Q?C0CLHOmuzE85NCt7UOATp8PZofzhPP5Tvg9ZYU8bFDWKbnrSnBcuT2tN?= =?Windows-1252?Q?/sC3V31GK95+riAN28G4arG5Y6R/iE3buz6GOMG87hwTcdmKVlw/M2bu?= =?Windows-1252?Q?Pz2OiiEu1BBHcfy/bE1bx4VJsy3/DuwWx96dHpwPatB+45KwJaQm1eFT?= =?Windows-1252?Q?FKmrJQDHKZzbQQox3BdUZIpQvT/rQvyhj65yaIBPkeYJWvAIAWsIUlEi?= =?Windows-1252?Q?etjU9n1+6URy5iyKvz23YXXa/XwvM3VPlyo399sbSLRvlFFyfgv6WwhD?= =?Windows-1252?Q?m87r6uWdo3lStwl5rc1PFMEFlMV0VNp9VUsN5LMcwhGl6vKv/W3/svb6?= =?Windows-1252?Q?igqAvFy0DshW/amisKJMuC/InwXqunElwbI9zbFOvYSnjkqY9Hz3t/rV?= =?Windows-1252?Q?66//27GVObkK1/K0fZBkWbtTKfBAxv/IkQ5atBH3F/ZIj8PyQIB5LLwD?= =?Windows-1252?Q?UbS6LkszUh/X/VZdZozuFkio0ZfWWLg6ebJ/JKsX8PguvUrfMLdDNI+z?= =?Windows-1252?Q?P+NFhOb3J4D+Z+hCMgst7DURC0w1XymRDvZLqFZeopXxLdp4sUu3DS/j?= =?Windows-1252?Q?5TCbw92IH5WiiRG3UlUFhaIz8NpSBny59xri3RGQXI4qE9SeF7KrIetF?= =?Windows-1252?Q?DGQC4iLaxTXVMuQhxB4BIZH+W5a6Un6OetAM86DOef9ShhUi0+mCZlRn?= =?Windows-1252?Q?DpFeTsF8F6aOaPvgX+8LI/JQ2vjKZNNpLdScE20YBWauYPblq5O+91dQ?= =?Windows-1252?Q?wTftVlD+XSaFpeyJK4atvatb1qpBNF+kGSC8nesL3bJxlhZRdlEYlUg2?= =?Windows-1252?Q?3AXQFF4yayPNHWTEDXuq8XcmAoqECf7MhoPV3ZHM1gQCuuzZdg9HQmWE?= =?Windows-1252?Q?3KtTVg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB50441AFD57F9A803D892D36AF2029BY3PR13MB5044namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74acbb1f-8b70-4044-394e-08d9fb2f9cc2 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2022 03:00:15.7739 (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: K/BaqCfJgFQrd1dyHYBfRtURm526feT5H89iXGnDkNTvJSQlf+bYy+dl5mPdTf2zOCc8hehHucQuz2CVldcpmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR13MB5975 Archived-At: Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding 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, 01 Mar 2022 03:00:30 -0000 --_000_BY3PR13MB50441AFD57F9A803D892D36AF2029BY3PR13MB5044namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, Thank you very much for your valuable points and comments. Your points are addressed in the updated draft and my responses/explanations inline below with [HC]. Best Regards, Huaimo on behalf of co-authors ________________________________ From: spring on behalf of bruno.decraene@orange.c= om Sent: Thursday, February 24, 2022 6:17 AM To: SPRING WG Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-routing-pr= oxy-forwarding Dear WG, Thank you for all comments received during this WG last call and for the de= tailed review of the document. In term of requirement, there is support for the need to protect SR-Policy = traffic from node failure both: a) for the protection/FRR duration (from failure detection to the start of = the IGP convergence) b) during the subsequent IGP restoration (from the beginning of the IGP con= vergence in the routing domain to the end of the re-computation and install= ation of SR-policy on all ingress). "a" is addressed by [2], with the exception of binding SIDs. Regarding "b", in term of the solution, two aspects have been discussed: I) the relation with the solution proposed in [2] II) the IGP extension for Proxy Forwarding proposed in [1] [1] https://datatracker.ietf.org/doc/html/draft-hu-spring-segment-routing-p= roxy-forwarding [2] https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protect= ion-sr-te-paths I) Regarding the relation with the solution proposed in [2]: - there is a claim that [1] provides better benefits in terms of incrementa= l deployment. During discussions it appeared to be true in some cases but t= hat the increased benefit seems relatively limited - there has been a claim that [2] already solves the problem. During discus= sions, it appeared that the solution proposed in [2] does not seem to work = as claimed. - problem space is twofold: a local fast reroute solution "a" and a global = IGP rerouting solution "b". In principle, both may be described in a single= or two documents. II) Regarding the IGP extension proposed in [1], the discussion during this= adoption call has not clarified the need to define a new IGP extension com= pared to re-using the existing Mirror SID defined in RFC 8402 (SR Architect= ure) and RFC 8667 (IS-IS extension). [HC]: Re-using the existing Mirror SID is added into the draft. Authors of [1] are suggested to dig on this point. In the meantime, the need for a new IGP extension for Proxy Forwarding has = not been demonstrated. Coming back to =93a=94, [1] also covers a solution for the FRR protection o= f binding SIDs. The problem seems real for networks using binding SIDs. The document propos= es to advertise them in IGP. However, during discussions, it appears that: - main IS-IS PDU (hello, LSP) are not well suited for the requirements (sco= pe of messages, capability of messages, scaling). During the call, the docu= ment has been changed to using CS-LSP which may not be well deployed and do= es not fully address the IGP scalability point. [HC]: For an IS-IS CS-LSP (Circuit Scoped LSP) defined in RFC 7356, it is advertised by its originator to the direct neighbors of the originator. The neighbors will not advertise the CS-LSP any further. It seems that there is no IGP (IS-IS) scalability issue here. - it seems debatable to choose to advertise the backup states in the IGP wh= en the nominal states have not been installed by the IGP but through existi= ng protocols extensions. [HC]: It seems that our draft does not advertise any backup state in the IGP. The normal states (i.e., the shortest path to each destination computed based on the current topology/LSDB) are installed normally by the IGP. This is independent of the protocol extensions if any. Only for the destination/SID of the failed node, which is not reachable through the current topology/LSDB (i.e., there is no path to the destination/SID of the failed node in the current network after the IGP converges on the current network with the failure), the backup state (the shortest path to the proxy destination/SID of the failed node, i.e., the proxy node of the failed node) is installed. Authors of [1] are suggested to dig on this point and study in depth the ex= isting configuration/signaling protocols used to install the nominal path a= nd study how they can be used, including extended if needed, to address the= need to install the backup states on the PLR. [HC]: The backup states on the PLR (i.e., the backup forwarding table/entries for a failed node on the proxy neighboring node P as PLR of the failed node) are those described in our draft. When P as PLR receives the packet with the destination/SID of the failed node, P uses the backup forwarding table for the failed node to do a SR proxy forwarding for the failed node and forward the packet towards its final destination without going through the failed node. This is independent of re-using the existing protocol or using some new protocol extensions. If the neighboring node P of the failed node does not support proxy forwarding (i.e., P does not have the capability of doing proxy forwarding for the failed node), after receiving the packet with the destination/SID of the failed node, P will do normal FRR. The normal FRR on P includes one of the following two cases: 1). P's neighbor supports the proxy forwarding indicated by the mirror SID for the failed node advertised by the neighbor: P pushes the mirror SID into the packet and forwards the packet to the neighbor, which uses the mirror SID for the failed node as context to the backup forwarding table/entries for the failed node to do a SR proxy forwarding for the failed node and forward the packet towards its final destination without going through the failed node. In this case, any binding SID of the failed node is also protected since the neighbor supports the proxy forwarding. 2). P's neighbor does not support the proxy forwarding: P forwards the packet with the SID of the failed node towards its final destination without going through the failed node. In this case, any binding SID of the failed node is not protected since P does not support the proxy forwarding. In the meantime, the call for adoption of draft-hu-spring-segment-routing-p= roxy-forwarding is suspended. Finally, there is the question of whether these different aspects are bette= r addressed in one document or in two documents. This will be further evaluated by chairs when we=92ll have a revised [1] do= cument addressing the two requested points. However we note that [1] covers= both a global IGP aspect (restoration) and a local restoration aspect (bin= ding SID) hence having two documents based on this dichotomy would not even= solve the interactions between the two documents. In addition, _assuming = that [1] does its homework and fully addresses the two above points_, if th= ey wish so, authors of both documents may discuss and may come back with pr= oposals on how to structure the whole solution space. Yours, --Bruno, Jim, Joel. Orange Restricted From: spring On Behalf Of bruno.decraene@orange.c= om Sent: Thursday, January 13, 2022 11:19 AM To: SPRING WG Subject: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-= forwarding Dear WG, This message starts a 2 week WG adoption call, ending 27/01/2022, for draft= -hu-spring-segment-routing-proxy-forwarding https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forw= arding/ After review of the document please indicate support (or not) for WG adopti= on of the document to the mailing list. Please also provide comments/reasons for your support (or lack thereof) as = this is a stronger way to indicate your (non) support as this is not a vote= . If you are willing to work on or review the document, please state this exp= licitly. This gives the chairs an indication of the energy level of people = in the working group willing to work on the document. Thanks! Bruno, Jim, Joel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_BY3PR13MB50441AFD57F9A803D892D36AF2029BY3PR13MB5044namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Bruno,

    Thank you very much for your valuable points and comment= s.

    Your points are addressed in the updated draft and
    my responses/explanations inline below with [HC].

Best Regards,
Huaimo
on behalf of co-authors

From: spring <spring-bou= nces@ietf.org> on behalf of bruno.decraene@orange.com <bruno.decraene= @orange.com>
Sent: Thursday, February 24, 2022 6:17 AM
To: SPRING WG <spring@ietf.org>
Subject: Re: [spring] WG adoption call - draft-hu-spring-segment-rou= ting-proxy-forwarding
 

Dear WG,

=  

Thank you for all comments received during this WG last call and = for the detailed review of the document.

 

In term of requirement, there is support for the need to protect = SR-Policy traffic from node failure both:

a) for the protection/FRR duration (from failure detection to the= start of the IGP convergence) =

b) during the subsequent IGP restoration (from the beginning of t= he IGP convergence in the routing domain to the end of the re-computation a= nd installation of SR-policy on all ingress).

 

"a" is addressed by [2], with the exception of binding = SIDs.

 

Regarding "b", in term of the solution, two aspects hav= e been discussed:

I) the relation with the solution proposed in [2]

II) the IGP extension for Proxy Forwarding proposed in [1]=

 

[1] https://datatracker.ietf.org/doc/html/draft-hu-spring-segment-routing-proxy= -forwarding

[2] https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-= sr-te-paths

 

I) Regarding the relation with the solution proposed in [2]:

- there is a claim that [1] provides better benefits in terms of = incremental deployment. During discussions it appeared to be true in some c= ases but that the increased benefit seems relatively limited

- there has been a claim that [2] already solves the problem. Dur= ing discussions, it appeared that the solution proposed in [2] does not see= m to work as claimed.

- problem space is twofold: a local fast reroute solution "a= " and a global IGP rerouting solution "b". In principle, bot= h may be described in a single or two documents.

 

II) Regarding the IGP extension proposed in [1], the discussion d= uring this adoption call has not clarified the need to define a new IGP ext= ension compared to re-using the existing Mirror SID defined in RFC 8402 (SR Architecture) and RFC 8667 (IS-IS extension).<= /span>

[HC]: Re-using the existing Mirror SID is added into the draft.

Authors of [1] are suggested to dig on this point.

In the meantime, the need for a new IGP extension for Proxy Forwa= rding has not been demonstrated.



Coming back to =93a=94, [1] also covers a solution for the FRR pr= otection of binding SIDs.

The problem seems real for networks using binding SIDs. The docum= ent proposes to advertise them in IGP. However, during discussions, it appe= ars that:

- main IS-IS PDU (hello, LSP) are not well suited for the require= ments (scope of messages, capability of messages, scaling). During the call= , the document has been changed to using CS-LSP which may not be well deployed and does not fully address the IGP scalabil= ity point.

[HC]: For an IS-IS CS-LSP (Circuit Scoped LSP) defined in RFC 735= 6,

it is advertised by its originator to the direct neighbors of the
originator. The neighbors will not advertise the CS-LSP any further. It seems that there is no IGP (IS-IS) scalability issue here.


- it seems debatable to choose to advertise the backup states in = the IGP when the nominal states have not been installed by the IGP but thro= ugh existing protocols extensions.

[HC]: It seems that our draft does not advertise any backup state= in

the IGP. The normal states (i.e., the shortest path to each destinatio= n
computed based on the current topology/LSDB) are installed normally
by the IGP. This is independent of the protocol extensions if any.
Only for the destination/SID of the failed node, which is not reachabl= e
through the current topology/LSDB (i.e., there is no path to the
destination/SID of the failed node in the current network after the
IGP converges on the current network with the failure), the backup
state (the shortest path to the proxy destination/SID of the failed node, i.e., the proxy node of the failed node) is installed.

 

Authors of [1] are suggested to dig on this point and study in de= pth the existing configuration/signaling protocols used to install the nomi= nal path and study how they can be used, including extended if needed, to address the need to install the backup states on th= e PLR.

[HC]: The backup states on the PLR (i.e., the backup forwarding

table/entries for a failed node on the proxy neighboring node P
as PLR of the failed node) are those described in our draft.
When P as PLR receives the packet with the destination/SID of the
failed node, P uses the backup forwarding table for the failed node
to do a SR proxy forwarding for the failed node and forward the
packet towards its final destination without going through the
failed node. This is independent of re-using the existing protocol
or using some new protocol extensions.
If the neighboring node P of the failed node does not support proxy
forwarding (i.e., P does not have the capability of doing proxy
forwarding for the failed node), after receiving the packet with
the destination/SID of the failed node, P will do normal FRR.
The normal FRR on P includes one of the following two cases:
1). P's neighbor supports the proxy forwarding indicated by the
mirror SID for the failed node advertised by the neighbor:
P pushes the mirror SID into the packet and forwards the packet
to the neighbor, which uses the mirror SID for the failed node
as context to the backup forwarding table/entries for the failed node<= /div>
to do a SR proxy forwarding for the failed node and forward the
packet towards its final destination without going through the
failed node. In this case, any binding SID of the failed node is =
also protected since the neighbor supports the proxy forwarding.
2). P's neighbor does not support the proxy forwarding:
P forwards the packet with the SID of the failed node towards its
final destination without going through the failed node. In this
case, any binding SID of the failed node is not protected since P

does not support the proxy forwarding.

 

In the meantime, the call for adoption of draft-hu-spring-segment= -routing-proxy-forwarding is suspended.

 

Finally, there is the question of whether these different aspects= are better addressed in one document or in two documents.

This will be further evaluated by chairs when we=92ll have a revi= sed [1] document addressing the two requested points. However we note that = [1] covers both a global IGP aspect (restoration) and a local restoration aspect (binding SID) hence having two documents ba= sed on this dichotomy would not even solve the interactions between the two= documents. In addition,  _assuming that [1] does its homework and ful= ly addresses the two above points_, if they wish so, authors of both documents may discuss and may come back with= proposals on how to structure the whole solution space.


Yours,

--Bruno, Jim, Joel.

 

 

Orange Restricted

From: spring <spring-bou= nces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: Thursday, January 13, 2022 11:19 AM
To: SPRING WG <spring@ietf.org>
Subject: [spring] WG adoption call - draft-hu-spring-segment-routing= -proxy-forwarding

 

Dear WG,

 

This message starts a 2 week WG adoption call, ending 27/01/= 2022, for draft-hu-spring-segment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/draf= t-hu-spring-segment-routing-proxy-forwarding/

 

After review of the document please indicate support (or not= ) for WG adoption of the document to the mailing list.

 

Please also provide comments/reasons for your support (or la= ck thereof) as this is a stronger way to indicate your (non) support as thi= s is not a vote.      

 

If you are willing to work on or review the document, please= state this explicitly. This gives the chairs an indication of the energy l= evel of people in the working group willing to work on the document.

=  

= Thanks!

= Bruno, Jim, Joel

______________________________________________________=
___________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisati=
on. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces joi=
ntes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a et=
e altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confident=
ial 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 notif=
y the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for mes=
sages that have been modified, changed or falsified.
Thank you.
______________________________________________________=
___________________________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
--_000_BY3PR13MB50441AFD57F9A803D892D36AF2029BY3PR13MB5044namp_--